Re: DER encoding in RFC 3161

Phillip Hallam-Baker <[email protected]> wrote:
>
> I have been doing X.509v3 for 30 years now. I have yet to hear a good
> answer to the question of why DER encoding is needed in PKIX.
> 
> It is a requirement of X.509 but not one that makes the slightest sense in
> these days when you can store a billion certs on one disk drive and X.500
> directory has fewer active users than Edison phonographs. Certificates are
> moved from point A to point B as an opaque binary blob which is encoded by
> the signer at signing time and only at signing time. This notion of signing
> the abstract data rather than the binary bits keeps coming up but I have
> yet to see anyone work out how to do it reliably, let alone add value by
> doing so.
> 
> A digital signature is over a string of bits. The road to madness is paved
> by canonicalization schemes.
> 

There seems to be a significant amount of installed base which breaks
horribly if you change the encoding even slightly.  That installed base
maps Certificate based on the certificate fingerprint.

If the outermost encoding of the X.509v3 certificate encoding is changed,
like a proper ASN.1 DER encoding of the PKCS#1 RSA-PSS signature AlgID,
or use of an indefinite length encoding, that installed base implementation
will no longer recognize a TLS client certificate because of the changed
certificate fingerprint.  That the digital signature on that TLS client
certificate verifies just fine, does not seem to matter at all.

That installed base is using a Microsoft Windows 2016 Server, and
was previously using a Microsoft Windows 2008R2 Server.

IIRC there are a number of places in Microsoft CryptoAPI, SChannel and
Microsoft http.sys where the certificate fingerprint is used.

-Martin