Re: [Trans] Bad Technical Decision: Closing out the SCT encoding discussion

[Nico Williams <[e-mail]>]

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
--