W3C home > Mailing lists > Public > public-xmlsec@w3.org > September 2008

RE: ISSUE-52 (scantor): Rules for syntax of KeyInfo child elements should be unambiguous [Errata-XML Signature]

From: Brian LaMacchia <bal@exchange.microsoft.com>
Date: Mon, 15 Sep 2008 12:56:04 -0700
To: Scott Cantor <cantor.2@osu.edu>
CC: 'XML Security Working Group WG' <public-xmlsec@w3.org>
Message-ID: <7684468BFDC4704884E4688E5CD105057BF0355BA1@df-whippet-msg.exchange.corp.microsoft.com>
> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Monday, September 15, 2008 12:35 PM
> To: Brian LaMacchia
> Cc: 'XML Security Working Group WG'
> Subject: RE: ISSUE-52 (scantor): Rules for syntax of KeyInfo child
> elements should be unambiguous [Errata-XML Signature]
> Standards Development Organization. Specifically OASIS, and I could
> probably find many standards that reference it, but a lot of recent
> work in SAML that profiles KeyInfo (the source of most non-interop in
> this space) is the source of the issue.

Can you point us to some specific details of the types of interop issues SAML is encountering?  What sort of profiling is giving rise to the interop problems?

> That's essentially the issue being raised. I think that's a poor
> choice, but if there are use cases that necessitate not constraining
> this, then we (meaning people relying on this spec) will need to
> profile it in lots of other places.

I believe it was simply a matter of not wanting to restrict the set of valid X.509v3 certs or CRLs that could be used with XMLDSIG.  As a practical matter I'm not aware of any broad use of non-DER-encoded X.509v3 certs.

> BTW, as a practical matter, I don't see what RFC5280 has to do with it.
> I don't see a normative reference to it, or to 3280, so I don't know if
> that can be a basis for deciding this.

Sorry, that's my shorthand for "current implementations of X.509v3 and PKIX Part 1".  All the major implementations of X.509v3 certs that I am aware of are concerned with conformance to the IETF PKIX version of the standard, not the official ITU-T one, and that's the one they reference.  (And, of course, TLS and S/MIME and IPSEC also reference the PKIX RFCs.)  I don't recall why we referenced the ITU-T version of X.509v3 instead of RFC 2459 (the then-current version of PKIX Part 1, which has been obsoleted by RFC 3280 and then RFC 5280).

> I reread it several times, in light of the statement that they "all use
> ds:CryptoBinary", and I think I get it. I wouldn't have written it all
> the way that it's presented, but I see what it's saying now. I'll see
> if I can modify the issue.

I believe ds:CryptoBinary was a patch made due to the leading zero octet problem sometime in the middle of development of the standard, but I'd have to search the archives to be certain.

Received on Monday, 15 September 2008 19:56:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:09 UTC