[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: encoding an X.509 certificate



Santosh Chokhani <SChokhani@xxxxxxxxxxxx> writes:

>An X.509 certificate is always DER encoded.

Actually I should have edited the above to say:

  Santosh Chokhani <SChokhani@xxxxxxxxxxxx> quotes the standard:

  >An X.509 certificate is always DER encoded.

In practice it's actually:

  "An X.509 certificate is always encoded in any damn way the originator
  pleases, as long as MSIE, Netscape/FF, and OpenSSL can still swallow the
  result".

with the corollary:

  "Any downstream party keeps a copy of the binary exactly as originally
  encoded and reuses that as and when required".

In other words "there is only one encoding rule and that is memcpy()".  There
have been CAs whose certs break into BER in the middle of the cert, whose
certs contain totally incorrect ASN.1, in at least one memorable occasion
which didn't even contain ASN.1 at all but just raw binary data (and these
were major commercial CAs, Verisign, Thawte, European government-level CAs,
operations at that level), and no-one noticed because they just accepted
whatever they were given without being too choosy.  It's stil going on today,
I got a non-DER cert as recently as a week ago, in this case one with the
keyUsage encoded wrong.

So trying to enforce any kind of encoding is just going to lead to endless
pain.  Given their ongoing c18n problems I'd have thought the XML security
guys would be more aware of this than most :-).

[Reading through numerous other posts from people all saying you use DER,
 e.g.]:

>Certificate and signature could be encoded ways other than DER.  But, in
>order to verify the signature you need to encode the payload in DER since the
>signature is computed on DER.

>DER

>Please use DER.  If you use BER, then the recipient will have to decode the
>certificate and re-encode it with DER in order to validate the signature,
>wasting much effort.

>Certificate and signature could be encoded ways other than DER.  But, in
>order to verify the signature you need to encode the payload in DER since the
>signature is computed on DER.

>Obviously the signature will only verify if it is DER encoded. So, there's
>generally not much point in supporting other encodings.

No, you need to leave the payload exactly in whatever form the signer left it
(and specifically not DER-encode it) or your sig-checks will start failing.

Sheesh, are there *any* implementers still left on this list?  Everyone seems
to be blindly repeating X.509 dogma without any (apparent) awareness of how
things really work.  The repeated advice to enforce DER is just going to cause
your signatures to fail whenever you encounter something that isn't DER-
encoded.

>What's actually needed is the original encoding over which the signature was
>calculated, which although it's supposed to be the DER encoding sometimes
>isn't quite (in which case any re-encoding of the certificate breaks the
>signature). The safest thing to do is accept BER and preserve the exact
>encoding received. That's what directory implementations do.

OK, so there is at least one :-).

Peter.