RE: [security-services] W3C Last Call: XML Signature 1.1 and XML Signature Properties

["Scott Cantor" <cantor.2@osu.edu>]

I took an action on the last call to try and identify some areas of
relevance in 1.1 to SAML.

The broad question that I think has to be addressed by the TC is whether
SAML 2.0 "permits" use of the material in XML Signature 1.1 in any formal
sense, or whether it could preclude that even if it wanted to. In some ways,
I would have preferred that 1.1 be done as a set of extensions to 1.0 to
address this versioning issue, but given that it's not, I don't know what
the clearest way to deal with this would be.

I think it's questionable to just update the 2.0 references to this spec,
because the algorithm conformance requirements are different. The SAML 2.0
conformance document depends directly on the conformance rules in XML
Signature and incorporates them by reference, essentially. So that puts us
in a bit of a bind.

A thought that I had was to weasel this by creating an errata in the specs
that have the key dependency (core and metadata primarily) and adding some
wording along the lines of:

"SAML implementations MAY support XML Signature extension specifications or
subsequent versions of the XML Signature specification designed to be
compatible with [XMLSig10], subject to the normative requirements in this
specification."

In other words, if it doesn't violate the signature profile (which limits
transforms, c14n, etc), it's fair game. This will NOT get us compatibility
with the XML Signature 2.0 work that's coming later, but it might get us 1.1
without having to rev anything.

I think if we had known what was going to come down the road, we would have
done something like that to protect implementers.

Anyway, some of the new stuff:

* Algorithm changes

There are different conformance requirements (e.g. deprecating SHA1, making
SHA256 the "suggested" and MTI choice). There's also material on ECC
algorithms.

This is all relevant to questions that have been raised across a lot of
specs, SAML included, about modernizing them with respect to algorithm
assumptions and defaults. On an earlier call, the point was made that we're
not free to "just" update the SAML Conformance spec because it's part of a
unit with the rest of 2.0. It would seem to me that producing a new set of
conformance classes as a profile would get around this easily enough, but
some might object to such classes referencing XML Signature 1.1 if the base
specs still reference 1.0.

There's also apparently not agreement that specs should tackle this problem
independently, but I don't see what alternatives exist at the moment, or
whether OASIS has the will to address this at a different level.

* KeyInfo additions

The last call draft contains a syntax I proposed for embedding bare keys
into KeyInfo using base64-encoded DER rather than the XML syntax used in
KeyValue now. This is a convenience for expressing bare keys in metadata or
subject confirmation.

A change that is apparently going to be accepted after last call is a new
element called KeyInfoReference that replaces RetrievalMethod for use cases
in which one KeyInfo wants to point to another. This works around problems
in the schema that make RetrievalMethod impractical. This is useful for
avoiding key duplication in large metadata batches, for example cases where
a bunch of SPs share a common keypair.

-- Scott