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

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

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

-- Scott

Received on Monday, 15 September 2008 21:52:14 UTC