RE: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-06-04

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

Drummond Reed wrote on 2009-06-05:
> Following are the minutes of unofficial telecon of the XRI TC at:

Some clarifications inline (not corrections to the minutes, just the
statements made in them).

> Drummond asked for clarification on whether the signature MAY be
> referenced rather than enveloped. It was still unclear whether the
> constrained XML dSig profile allows this or not - what we are sure of is
> that it supports enveloped signatures.

It doesn't preclude it, but it isn't formally addressed by a profile
describing constraints on enveloped signatures. A detached signature would
need to be described separately, but is supported by XML Signature itself.

> (Dirk made the point that adding
> an element to XML dSig should not break it because the added element
> should be able to be excluded.)

I'm not sure what that refers to, but adding elements to the XML Signature
schema is only permitted in a few places where wildcards were defined. You
can't do anyting that violates the schema.

> Will explained this this profile references a W3C spec for "exclusive XML
> canonicalization" adds a few additional constraints, most notably a strong
> recommendation against using Q-names.

That isn't a constraint of excl c14n, it's a best practice in order to
maximize interoperability when you use it. With excl c14n, you don't output
a namespace prefix decl until/unless it gets "used" by an element or
attribute. With QNames in content, you don't know that the prefix is being
used because the c14n algorithm is unaware of QNames in content. The fix is
to include the prefix in the InclusivePrefixes parameter to the algorithm,
but knowing to include the prefix in that list when signing requires
application intervention.

The support for InclusivePrefixes is trivial to implement in the
signing/verifying layer. It doesn't make the work harder. The cost comes in
the outer layer that's handling the thing being signed.

> Will explained that normal XML dSig
> canonicalization inherits from parent elements. Exclusive does not do
that,
> and does not require XPath referencing, because all you can reference is a
> single element by its ID attribute.

That's also coming not from c14n itself but the profile. You avoid XPath by
limiting what you can sign and place in the Reference URI, and by limiting
the Transforms allowed so that you don't have to support XPath at all unless
you choose to implement more than the profile requires.

> Brian suggested that we have either use an existing set of XML dSig
> libraries for testing or develop our own. There was strong consensus that
> this is essential.

As I said, there are test vectors from W3C that should work, or we can
generate some easily enough.

-- Scott