On Fri, Mar 13, 2015 at 09:57:57PM -0400, Paul Wouters wrote: > On Fri, 13 Mar 2015, Nico Williams wrote: > > >Indeed. The fact that Certificate includes TBSCertificate without > >wrapping it in an OCTET STRING has caused problems before. > > Can you share what problems this has caused before? That would be > a useful addition to this discussion.
Yes, I can. Say you want to use an ASN.1 compiler to generate all your encoding and decoding code... A compiler-generated decoder will generally lose all information about encoding options (think BER) for the TBSCertificate, so that if you write code that passes around decoded structures without passing around the original cert... then you can't validate signatures that were taken over a non-canonical encoding of the tbsCertificate. Even if you pass the original cert around, you need to hand-code a parser to extract the tbsCertificate. Fun stuff. Wrapping to-be-signed objects in OCTET STRINGs completely solves the problem. We use ASN.1 in part because the idea that we can use off-the-shelf compilers is attractive. There exist such x.509 implementations, FYI. Heimdal's libhx509, for example. Nico -- _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
