linux-kernel - Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c33c759d-9243-8885-7c5f-667681b759c2@gmail.com>
Date:   Tue, 18 Sep 2018 12:00:49 -0500
From:   Denis Kenzior <denkenz@...il.com>
To:     David Howells <dhowells@...hat.com>
Cc:     David Woodhouse <dwmw2@...radead.org>, jmorris@...ei.org,
        keyrings@...r.kernel.org, linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops

Hi David,

On 09/18/2018 11:55 AM, David Howells wrote:
> Denis Kenzior <denkenz@...il.com> wrote:
> 
>> In theory the PEM file already contains the type of the certificate, at least
>> at a high level.  E.g. private, public, tpm.  So if we accept PEM files
>> directly that could be potentially a faster way of determining the parser to
>> use and would still work with keyctl update/instantiate, right?
> 
> Yes.  It shouldn't be much code, either.  You still have to check for X.509
> DER since the kernel currently supports that.

For reasons of backward compatibility, correct?  The kernel also has 
mscode.asn1 which we would need to support as well.  Since we can't 
break compatibility then perhaps this doesn't buy us a whole lot in the end.

Regards,
-Denis