Re: DER encoding in RFC 3161

Peter Gutmann <[email protected]> wrote:
[ Charset windows-1252 unsupported, converting... ]
> Martin Rex <[email protected]> writes:
> 
> >That installed base maps Certificate based on the certificate fingerprint.
> 
> Why is this a problem?

Because it hashes/fingerprints a non-persistent *OUTER* container, rather than ToBeSigned --
the data element for which preproduction in bit-by-bit is clear from the specification.

>
> In order to make it "break horribly" you'd need to deliberately re-encode
> the malleable parts of the certificate in a different format.

No, the breakage occurs when suddenly expecting that malleable parts of an X.509 certificate
(=everyting *OUTSIDE* of ToBeSigned) are guaranteed to be unchanged by whatever storage
and transports a Certificate is going through, including any ASN.1 length encodings on the outside.


> Given the very widespread use of hash fingerprints to uniquely
> identify data items, I think people know how to work with them by now, the rule
> being "don't gratuitously change the data being identified by the hash value".


Creating a hash over a the outer transport encoding of an object looks like
a terribly dumb idea to me.  In particular when the verification of the certificate shows
that it is still a perfectly valid certificate, and it becomes pretty difficult to determine
why the receipient is failing to recognize it.


This particular server is accepting TLS client certificates, but only when they are conveyed
in a blue wrapper.  It will reject TLS client certificates that are submitted in red, pink
yellow, green or any other perfectly valid wrapping, just because the very first time the
server received this certificate, it had been wrapped in blue.  Unfortunately, the server
will not reveal which particular wrapping color it is stuck on, other than failing for
every other color that the one it is secretly holding.

-Martin