Proposals for clarifying certificate encoding

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 Monday, 17 November 2008 18:10:17 UTC