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: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Mon, 15 Sep 2008 20:45:55 -0400
Message-Id: <20177529-DA61-40E8-917F-650AE84C4BE8@nokia.com>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, "'Brian LaMacchia'" <bal@exchange.microsoft.com>, "'XML Security Working Group WG'" <public-xmlsec@w3.org>
To: ext Scott Cantor <cantor.2@osu.edu>

comment inline

regards, Frederick

Frederick Hirsch

On Sep 15, 2008, at 5:51 PM, ext Scott Cantor wrote:

>> 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?
> The profiling I'm referring to is work that limits the types of  
> KeyInfo children to support in particular contexts (Metadata,  
> Holder of Key assertions), and it was noted in review of that work  
> that technically (at least in the case of X509Certificate), you  
> can't get interop unless you nail down the encoding, which I had  
> thought the Signature spec did.
> I noted, as you did, that practically speaking, everybody just does  
> DER. But "everybody does it" isn't a conformance tool, so it has to  
> get nailed down somewhere. If not here, then in every spec that  
> needs to constrain it to guarantee what can legally appear.
> The interop comment was a generality. I was referring to the fact  
> that in most XML security specs that rely on KeyInfo,  
> interoperability tends to end once you hit that step, because it's  
> left out of scope of most specs, and isn't constrained by XML  
> Signature from a processing model standpoint. Trust is always out  
> of scope, in other words.
> A few people, including myself, have started to write SAML profiles  
> that end that practice, and include trust processing as part of the  
> profiles. Doing that requires nailing down KeyInfo, and thus we  
> start finding these questions about what's actually defined by it.
>> 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.
> I guess I'd suggest that might be reconsidered. If there's no use  
> case, I think it should be restricted to DER and leave it at that.  
> People can always use an extension if they need something else  
> (X509Data is element-extensible).

any reason not to restrict to DER , in v.next profile. Separate  
discussion is errata .

>> 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).
> Understood, didn't know they were (somewhat) equivalent.

Are we able to do anything here?

>> 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.
> What confused me was that it's defined in a separate spot, and I  
> missed the brief sentence there that says "and it's also base64- 
> encoded", so I couldn't understand why the definitions under RSA/ 
> DSAKeyValue seemed to say "use CryptoBinary" but the examples (and  
> my experience with them) showed them to be base64'd.

sounds like some additional clarification text might be useful,  
perhaps a proposed errata?

> -- Scott
Received on Tuesday, 16 September 2008 00:47:26 UTC

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