[openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 18:06 +0100, Richard Levitte wrote:
> 
> Actually, I agree with this, and that goes along with how our PEM
> routines work (specifically, PEM_X509_INFO_read_bio()), it just
> treats the data as an octet string and hands it down to a d2i routine
> of choice, with a pointer to where to place the result.
> 
> It's not very hard to imagine adding the possibility for external
> handlers for specific PEM content types, which could be handed an
> octet string and a pointer to a X509_INFO (which is the structure used
> to collect the data in), or something like that (I can also imagine
> having one separate handler for each type of data that can be
> returned, so one for a EVP_KEY, one for a X509, one for a X509_CRL,
> and so on and so forth).  That would make it possible for an engine to
> declare its own handler during the binding call, along with all other
> information it feeds back to libcrypto.

Yeah, something like that.

It's worth noting that the 'PEM content types' are just the same as the
'DER content types'. It's just that if you have a PEM header, you know
precisely *which* DER content type you have after base64-decoding (and
decryption in some cases), and you don't have to do what
d2i_AutoPrivateKey() does to infer it from the ASN.1 structure.

So maybe it's just "content types" that we have handlers for, each with
an optional PEM tag for matching, *and* an optional match function
which is given the parsed ASN.1 and checks if it's a match.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161123/f6e36e1b/attachment-0001.bin>