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

comment inline

regards, Frederick

Frederick Hirsch
Nokia



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).

+1
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