ACTION 108: Consolidated certificate encoding proposal

Here's a proposal to combine my proposal with Magnus' suggestions for both
the 1.1 spec and best practices.

For the spec, in section 4.4.4, I suggest a shorter statement derived from
my original suggestion last week:
------
"While in principle many certificate encodings are possible, it is
RECOMMENDED that certificates appearing in an X509Certificate element be
limited to an encoding of BER or its DER subset, allowing that within the
certificate other content may be present. The use of other encodings may
lead to interoperability issues. In any case, XML Signature implementations
SHOULD NOT alter or re-encode certificates, as doing so could invalidate
their signatures."
------

For the Best Practices draft, I didn't see an existing spot to put anything.
The current section that talks about certificates is really about something
else, so I don't think we should overcomplicate that section by adding text
about this.

I guess that would leave adding a new section:
------
For Implementors: be aware of certificate encoding issues

Although X.509 certificates are meant to be encoded using DER before being
signed, many implementations (particularly older ones) got various aspects
of DER wrong, so that their certificates are encoded using BER, which is a
less rigorous form of DER. Thus, following the X.509 specification to
re-encode in DER before applying the signature check will invalidate the
signature on the certificate.

In practice, X.509 implementations check the signature on certificates
exactly as encoded, which means that they're verifying exactly the same data
as the signer signed, and the signature will remain valid regardless of
whether the signer and verifier agree on what constitutes a DER encoding. As
a result, the safest course is to treat the certificate opaquely where
possible and avoid any re-encoding steps that might invalidate the
signature.

The X509Certificate element is generically defined to contain a
base64-encoded certificate without regard to the underlying ASN.1 encoding
used. However, experience has shown that interoperability issues are
possible if encodings other than BER or DER are used, and use of other
certificate encodings should be approached with caution. While some
applications may not have flexibility in the certificates they must deal
with, others might, and such applications may wish to consider further
constraints on the encodings they allow.
------

I guess the "Best Practice" that would be summed up in a box for this would
be "Certificates should be handled opaquely whenever possible, but
interoperability issues are possible if non-BER/DER encoded certificates
appear in the X509Certificate element"

-- Scott

Received on Sunday, 23 November 2008 19:27:06 UTC