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