On Wed, 2016-11-23 at 09:56 +0100, Richard Levitte wrote: > > > dwmw2> So maybe it's just "content types" that we have handlers for, each with > dwmw2> an optional PEM tag for matching, *and* an optional match function > dwmw2> which is given the parsed ASN.1 and checks if it's a match. > > I'm not sure what you mean with a match function... but going off on > a limb, how about a reference to an OpenSSL style ASN1 description? > So basically, for an imaginary TSS KEY BLOB (one that actually would > use that TssBlob definition we talked about earlier), these three > items would be specified: > > "TSS KEY BLOB", > ASN1_ITEM_rptr(TSS_BLOB), /* TSS_BLOB ASN1 stuff defined in engine */ > handler /* Essentially a d2i function */ > > Or did you mean that the matching would also involve checking the > contents of the OCTET_STRING that TSS KEY BLOBs currently are, to see > if they correspond to your structures? If that's what you mean, my > gut feeling tells me - and I haven't had my morning coffee yet - we're > now moving into a territory where I fully expect dragons... not to > mention the worries Rich expressed.
Oh $DEITY no, not looking in the contents of the OCTET_STRING. Basically I'm thinking of doing precisely what d2i_AutoPrivateKey() already does, just with expanded coverage and slightly less hard-coded stuff. The "match" part there is a little simplistic; we basically parse the ASN.1 into a STACK_OF(ASN1_TYPE), then if (sk_ASN1_TYPE_num(inkey) == 6) /* it's DSA in OpenSSL's format */ if (sk_ASN1_TYPE_num(inkey) == 4) /* it's ECDSA according to RFC5915 */ if (sk_ASN1_TYPE_num(unkey) == 3) /* Unencrypted PKCS#8 */ ... etc. Those checks could possibly stand to be a *little* more discerning, and each one might live in a specific format-handler's "ASN.1 match" function. But that's the general idea. And we *do* already have the "decide, then parse" model that Rich was talking about. And yes, if we're going to make the checks slightly more discerning then instead of just counting the items in the sequence, we could see if it matches the ASN.1 description. And as you say, it doesn't have to be a match *function* for each handler; just the ASN.1 description. Doing it like that would prevent any implementations (like the one in the TPM engine) from being *tempted* to go prodding around in the contents of OCTET STRINGs. Which is probably a feature :) -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
