IETF Logo W3C Logo

Author: Joseph Reagle

Audience: IETF46

Question: Where does the WG stand?


  1. Charter

XML Signature

Joseph M. Reagle Jr.

IETF/W3C XML Signatures Co-Chair


Near Future

After this week

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

Comments Resulting from Schema

  1. Will want to structure it such that we can use these specifications
    inline instead of the DTD
  2. Can't have types be "or'd" subtypes, consequently keep location tag such

    <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://..."

  3. How to associate a prefix (that is associated with a namespace) when used in an attribute value?

    <Signature xmlns=""
            <Algorithm URI="nist:sha1">

C14N Implementation

minimal REQUIRED
XML-Canonicalization RECOMMENDED

C14N Usage

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

C14N 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

C14N Questions

  1. 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?
  2. Should we continue with signer chooses? Or should we settle on one for mandatory to use and implement.