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: Scott Cantor <cantor.2@osu.edu>
Date: Mon, 15 Sep 2008 15:35:14 -0400
To: "'Brian LaMacchia'" <bal@exchange.microsoft.com>
Cc: "'XML Security Working Group WG'" <public-xmlsec@w3.org>
Message-ID: <007a01c9176a$2d348a40$879d9ec0$@2@osu.edu>

> I have a few questions about this issue you just raised and am hoping you
> can provide some additional context:
> 1) What's an SDO?  "Standard definition organization"?  Assuming that's the
> case, what specific standard that references XMLDSIG is being questioned?

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.

> 2) Regarding the encoding of X509Data elements, if you look at RFC 5280 (the
> most recent version of the PKIX RFC for certs and CRLs), technically the
> cert format is defined just as an ASN.1 structure without a required ASN.1
> encoding rule that must be used.  So, I think technically once could express
> an X.509v3 cert using DER, BER, PER, XER, whatever.  However, certain fields
> within the X.509v3 cert do have a hard requirement on DER encoding (the
> signature, in particular, is taken over the DER encoding of the cert's
> contents, and cert extensions that are expressed as OID/value pairs must
> DER-encode the value), so as a practical matter everyone uses DER.  But I
> believe that technically once could choose to BER-encode a cert and it would
> be a valid X.509v3 production.  So XMLDSIG just says "base64 the encoding"
> since there isn't a required encoding.

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.

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.

> 3) Regarding KeyValue, can you expand on what you find confusing?  KeyValue
> itself does not define directly any elements that require base64 encoding.
> The defined subtypes RSAkeyValue and DSAKeyValue all use ds:CryptoBinary to
> encode their bignum values.  We use ds:CryptoBinary or base64Binary
> depending on whether leading zero octets are significant (see Section
> 4.0.1).

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.

-- Scott
Received on Monday, 15 September 2008 19:36:01 UTC

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