There is no header ("magic bits") at the beginning of an encoded
transfer string, so there is not a deterministic mechanism for
determining an arbitrary encoding. However, heuristically it is trivial
to examine a transfer string and determine that it is a) BER/DER/CER
encoded, b) XER endoded, or c) PER encoded. In practice, if you were
given an X.509 certificate of unknown encoding, there is only one
encoding that it could possibly be (DER) because no other encoding is
ever used. Because the signature is computed over the DER-encoded
transfer string, a certificate in any other format would need to be
re-encoded into DER before validating the signature, and that's too much
effort for most applications.
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
On Behalf Of Tom Scavo
Sent: Thursday, November 06, 2008 12:49 PM
Subject: encoding an X.509 certificate
I've asked the following question in a number of forums with no luck.
I'm hoping someone with intimate knowledge of ASN.1 encodings can help
me out here. Many thanks in advance.
Currently there are three profiles before the OASIS Security Services
Technical Committee (SSTC) that rely on XML elements of the form:
Interestingly, the above element has sparked a vigorous debate within
the SSTC, which has since spread to the W3C XML Signature WG. The
issue involves the ASN.1 encoding of the underlying certificate (which
is base64 encoded in the XML). Specifically, should the certificate
be DER-encoded or should the encoding be left unspecified?
So my question is: If you were given an X.509 certificate of unknown
encoding, could you determine the encoding by simply inspecting the
bytes? Does your favorite ASN.1 library support such a function?
Thanks for shedding some light on this issue.