[Cryptography] Is ASN.1 still the thing?

[Nico Williams]

On Thu, Nov 16, 2017 at 01:25:20AM -0500, Viktor Dukhovni wrote:
> > On Nov 15, 2017, at 9:15 PM, Carl Wallace <carl at redhoundsoftware.com> wrote:
> >     [...]. I tend to doubt many implementations re-encode because
> > that will fail too often if you try that approach. I am curious, has
> > anyone ever seen a certificate that was presented with a BER encoded
> > TBSCertificate structure that required DER re-encoding to verify? I
> > have not, but I have seen structures that will not verify if you
> > re-encode.
> 
> I doubt that's at all common.  OpenSSL caches the "wire-form" of
> TBSCertificate, and verifies that instead of re-encoding.  We don't
> hear too many complaints (about that).

If this is what relying parties do, then maybe it's time to update PKIX
to say that TBSCertificate MUST be encoded in DER and drop the language
about having to [re-]encode in DER before verifying the signature.

Alternatively simply state that the TBSCertificate MUST be delivered in
the same form as the input to the signature function.  Who cares if it's
BER or DER or CER, as long as a) the RP can decode it, b) there's no
need to re-encode to verify the signature?

Sometimes the spec has to reflect reality.

Tero's post does make me think that this is mostly something we'd see
only in the context of something like LDAP re-encoding.  Clearly this
can't really happen in any other case: CAs themselves must sign DER if
the PKIX language is to work at all, or else CAs sign whatever is also
always delivered to users (and thence RPs).

As for the LDAP server re-encoding case, it's easy enough to push the
re-encoding requirement to LDAP clients that care *if* there are any
such servers left anywhere.  Or to the servers and say they "MUST NOT
re-encode TBSCertificate", or even just say that in PKIX and be done.

I guess it's time to take this to the appropriate list at the IETF...

Nico
--