Re: Proposals for clarifying certificate encoding

Scott,

Thanks for your proposal. For the existing "branch", could I instead 
suggest:

"Although certificates are 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.  This means that the advice to re-encode in DER 
before applying the signature check, will invalidate the signature on the 
data.  In practice implementations check the signature on the certificate 
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. So implementations should assume BER encoding (DER being merely 
a profile of BER, so the same decoder can be used for both), and verify 
the certificate data exactly as encoded, with no re-coding performed".

For the future schema version, I suggest we look at that when we have 
agreed on the wording for the "current" version.

-- Magnus

On Mon, 17 Nov 2008, Scott Cantor wrote:

>
> I don't see an action item recorded, but I think I agreed to post another
> set of suggestions following the last round of comments and concerns about
> this. I read all of the PKIX WG responses from last week and took into
> consideration the points that have been raised, and I think I understand the
> concerns.
>
> It is not my intent to try to limit the certificates people can use, but to
> recognize that there is a cost for some of us that either need to handle
> certificates in unusual ways or rely on implementations that build in
> assumptions already about the possible certificate encodings.
>
> I recognize that for many of you your implementations of *this* spec don't
> have any dependencies on this issue because you leave it to the application
> to do anything with the blob in the X509Certificate element. That's
> absolutely fine. But some implementations do parse this element, and that's
> what I'm trying to address.
>
> So, my proposal for the existing "branch" of the specification is that we
> add some short advisory text to section 4.4.4 (where X509Data gets defined),
> perhaps at the end of that section before or after the note about PKCS#7.
>
> A possible suggestion:
> ----
> "Certificates are usually encoded as DER, but there are extant Certificate
> Authorities that have or issue more generally BER-encoded certificates. Even
> in the case of DER, there are examples of certificate content such as
> extensions that are separately encoded as BER, or even raw binary data.
>
> While in principle many possibly encodings exist, it is RECOMMENDED that
> certificates appearing in an X509Certificate element be limited to an
> encoding of DER or BER, allowing that within the certificate other content
> may be present. Experience shows that some recipients are limited in their
> ability to process other encodings, and the use of other encodings may lead
> to interoperability issues."
> ----
>
> The wording of the recommendation is obviously open for any input. I tried
> to incorporate the information people provided about DER vs. BER, but I'm
> not very literate in that.
>
> With respect to some future version of the schema, assuming we were to do
> one, my recommendation would be to change that RECOMMENDED to a MUST,
> assuming we can get satisfactory wording on the DER/BER "umbrella". I base
> this on the fact that I see no evidence that the majority of implementations
> of certificate processing code will handle anything but DER/BER, and I don't
> see why we would want to give people the impression that things will work
> fine if they use something like XER, PER, CER, or whatever.
>
> If that's not the case, and existing path validation code will simply work
> in most cases, then people can simply correct me, and I'll drop the issue.
>
> Note that I do not accept the argument that this is PKIX' problem. They
> don't control the X509Certificate element; we do. If we're not prepared to
> define its content, then we should add language that explicitly states that
> we don't constrain it. We do this implicitly now by not saying anything, but
> we should make it explicit.
>
> Another consequence of this discussion is that I recognize now that
> different profiles that sit on top of this spec probably are going to have
> different standards for judging whether any restrictions are warranted. I
> started out strongly against such material in some of my profiles, in the
> interest of not constraining things in only one spot, but I understand the
> problems better now, so it hasn't been time wasted (for me).
>
> I suggest we limit our time on the next call and just resolve this. If
> people aren't comfortable saying anything close to what I want to say, then
> my suggestion is we adopt language going forward that states outright we
> don't limit the encodings in that element and I'll consider the issue
> resolved.
>
> -- Scott
>
>
>
>
>

Received on Tuesday, 18 November 2008 12:28:48 UTC