XML Signature

History

IETF BOF and W3C Signed XML Workshop in March and April
WG chartered, IETF meeting in Oslo in July.
Had Brown proposal in July, present draft evolved from a smaller proposal from end of August.
Requirements document completed W3C Last Call, now working its way through the IESG towards Information RFC.

Activity	Charter	Expected
"Consistent Draft" (push out to wider community for comments)	-	Nov 27
XML Core to Last Call for Proposed Recommendation/Standard	Nov	Dec 21
Face-to-Face		Jan 7/10 21/24
Interoperability Test Cases and Results document to Last Call as NOTE / Informational RFC	Dec	Dec (first draft)
Recharter	Jan	Jan
Publication of Signature Syntax and Processing document as Proposed Recommendation / Proposed Standard RFC	Jan	March
Face-to-Face IETF47		March 27-31

Will want to structure it such that we can use these specifications
inline instead of the DTD
Can't have types be "or'd" subtypes, consequently keep location tag such
that:
<ObjectReference URI="http://...">
<ObjectReference IDREF="..."

or (depending on whichever we choose)

<Location URI="http://...">
<Location IDREF="...">

treat DigestMethod and others the similarly

<DigestMethod URI="http://...."
...
<Type MIME="mime-type/...">
<Type URI="urn:...">
<Type URI="http://..."
How to associate a prefix (that is associated with a namespace) when used in an attribute value?
<Signature xmlns="http://www.w3.org/1999/10/signature-core"
xmlns:nist="http://www.w3.org/1999/sig-core/nist>
...
<Algorithm URI="nist:sha1">
</Signature>

minimal	REQUIRED	http://www.w3.org/1999/10/signature-core/minimal
XML-Canonicalization	RECOMMENDED	http://www.w3.org/1999/07/WD-xml-c14n-19990729

Canonicalization over Objects: WG agrees such processing is an optional choice of the signer. Failure of receiver to canonicalize results in a SignedInfo validation but ObjectReference failure --> Signature failure.
Canonicalization over SignedInfo: Presently, such processing is an optional choice of the signer. WG would like to consider a single mandatory to use

Proposal	Usage Scenario
none: data is not canonicalized, bytestream is derived from the sequence of characters in their native encoding starting with "<SignedInfo..."	simple signatures over simple data where XML functionality (including "Infoset parsing") is at a minimum.
simple: data is canonicalized such that: (a) converting from the input encoding to UTF-8 and (b) normalizing the new lines to UTF-8 0x0A	ensures that encodings and new lines are not changed in transit.
XML: data is canonicalized according to Canonical-XML/Infoset/DOM.	Needed for XML parsing and Infoset/DOM processing

Can any usage scenario be said to dominate?
1. If people are using full XML functionality, will they be satisfied with none? (For instance, any entities declaration will not be expanded.)
2. Do we really need to worry about transport issues (email)?
3. Do we disenfranchise the none scneario via XML c14n?
Should we continue with signer chooses? Or should we settle on one for mandatory to use and implement.