RE: encoding an X.509 certificate

["Santosh Chokhani" <SChokhani@xxxxxxxxxxxx>]

Peter,

How do you reconcile what you say with the following in Section 4.1 of
5280:

"The X.509 v3 certificate basic syntax is as follows.  For signature
calculation, the data that is to be signed is encoded using the ASN.1
   distinguished encoding rules (DER) [X.690].  

-----Original Message-----
From: pgut001 [mailto:pgut001@xxxxxxxxxxxxxxxxx] 
Sent: Friday, November 07, 2008 10:36 AM
To: ietf-pkix@xxxxxxx; Santosh Chokhani; trscavo@xxxxxxxxx
Subject: 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.