On 7/15/2014 3:21 AM, Ben Laurie wrote: > On 15 July 2014 06:15, Matt Palmer <[email protected]> wrote: >> On Wed, Jul 09, 2014 at 05:49:49PM +0100, Ben Laurie wrote: >>> On 9 July 2014 03:16, Melinda Shore <[email protected]> wrote: >>>> On 7/4/14 4:13 AM, Ben Laurie wrote: >>>>> Given that there's a certain amount of angst about precertificates and >>>>> PKI rules, it could be that we really want to sign some other >>>>> structure altogether, at least for precertificates. >>>> Is there a proposal for that that's ready for discussion? >>> Sorry, I mis-spoke. We pretty clearly need to sign the TBSCertificate >>> (or at least, all the data that is in it). What we might want to do, >>> at least for Precertificates, is to sign it in a way that is not >>> X.509v3, to completely remove all question that it could be used as an >>> X.509v3 certificate, or be subject to their validation rules. >>> >>> As for exactly how it is signed, I don't have strong feelings about >>> that. Is there some appropriate RFC that specifies how to sign some >>> arbitrary binary blob using RSA or EC keys? >> struct { >> digitally-signed TBSCertificate; >> opaque TBSCertificate<1..2^24-1>; >> } Precertificate; > Hmm. That's a tempting thought!
Why not use a modified Certificate structure with a non-optional, explictly-tagged (tag 1 or something) datum in the place of the Version field? Especially if it wasn't an INTEGER, it would cause any conformant Certificate parser to reject it. (Anything that checks to see that the first item either isn't tagged or has tag 0 will refuse to parse it.) -Kyle H
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
