- From: Scott Cantor <cantor.2@osu.edu>
- Date: Mon, 17 Nov 2008 13:09:38 -0500
- To: <public-xmlsec@w3.org>
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