Advancement of xmldsig onto Standards Track

[I just realized I forgot to cc: the list. I hope that by the time the
Director and IESG have looked at this and coordinated we'll have a maturer
C14N spec and can normatively reference that specification and use it in the
generation of the non-normative examples ...)

Forwarded Text ----
 Date: Thu, 01 Jun 2000 18:13:03 -0400
 To: Jeffrey Schiller <jis@mit.edu>, Tim Berners-Lee <timbl@w3.org>,
mleech@nortelnetworks.com, Danny Weitzner <djw@w3.org>
 From: "Joseph M. Reagle Jr." <reagle@w3.org>
 Subject: Advancement of xmldsig onto Standards Track
 Cc: "Donald Eastlake" <dee3@torque.pothole.com>, <lde008@dma.isg.mot.com>,
Scott Bradner <sob@harvard.edu>
 
 The XML Signature WG asks that the XML Signature Syntax and Processing
specification be considered for advanced to Candidate REC and Proposed
Standard. We are now at a point where the design of the Signature syntax and
process is quite stable and we need to encourage further implementation to
discover those ambiguities we are not yet aware of.
 
 In compliance with [b, +3], "Target date for Proposed/Candidate: June 15th
; Schiller needs to send ballet by June 8th," the XML Signature WG published
a version yesterday for review [1] by the W3C and Area Directors. (The
ietf-draft version [2] has been sent, and should be available at
http://www.ietf.org/ in a day or two.) The document is accompanied by its
Last Call issues document [3], and a preliminary interoperality matrix [4].
Those issues where we expect further implementation experience to be most
helpful are documented in the STATUS of the document [a]. Also, I expect the
issue of joint-copyright needs to resolved in order to advance this document
as well. However, I hope the document will receive your full consideration
such that we can dispatch all issues barring advancement onto the standards
track at once, instead of proceeding through each serially with substantive
latency between each management review.
 
 Thanks!
 
 ___
 
 [1] http://www.w3.org/TR/2000/WD-xmldsig-core-20000601/
 [2]
http://www.w3.org/TR/2000/WD-xmldsig-core-20000601/draft-ietf-xmldsig-core-07
.txt
 [3] http://www.w3.org/Signature/20000228-last-call-issues.html
 [4] http://www.w3.org/Signature/2000/05/30-interop.html
 
 [a] Status of this document
 
    This specification of the IETF/W3C [26]XML Signature Working Group
    follows the XML Signature Last Call and attempts to address all
    [27]last call comments sent to the list and those issues discussed at
    the [28]April meeting. This is the version being forward to the IESG
    and W3C Director for consideration as a Proposed Draft and Candidate
    Recommendation. During this phase we will hope to gain implementation
    experience over the following
     1. Ensure that our use of [29]schema namespaces and qualifications
        provides a single schema that can be used for [30]enveloped
        signatures (signature within content being signed), [31]enveloping
        signatures (content is within signature being signed) and
        [32]detached signatures (over data external to the signature
        document).
     2. Further test our employment of URIs, IDs, and XPath
     3. Ensure that if the syntax constraints of section 7.1 are followed,
        a [33]validating parser is not needed.
     4. Clarify remaining ambiguities related to the cryptographic and
        keying information
     5. Presently, there are interoperable implementations of the 19991115
        draft of the Canonical XML [[34]XML-C14N] specification and that
        algorithm is used in the examples in this version of the
        specification. However, further implementation experience will be
        used to refine the 20000601 version [[35]XML-C14N-a] which will
        then replace the older version as the MANDATORY canonicalization
        algorithm.
     6. And demonstrate interoperability over all required and recommended
        features.
 
 
 [b] Forwarded Text ----
 
  Date: Tue, 09 May 2000 14:38:20 -0400
  Subject: Results of 20000509 Call on xmldsig
  ...
      Timing
  
       * How do we enter Candidate REC/Proposed Draft, are they necessarily
         bound?
            + Schiller needs to create and send a ballet to the IESG one
              week prior to May 18th, next date is in two weeks. (We won't
              make that).
            + Target date for Proposed/Candidate: June 15th
                 o Schiller needs to send ballet by June 8th.
            + Eastlake/Reagle: need to get Jeff a copy by June 2nd for
              review.
                 o As that draft shouldn't differ too much from the version
                   being published April 10th, Eastlake/Reagle will send
                   that version to Jeff, and then publish the June 2nd
                   version then point out the (if any) substantive changes
                   in the June version by the 2nd.
                 o If miss this deadline, push dates ahead two weeks.
            + Schiller/IESG needs to say yes; Tim needs to say yes; then
              Chairs send publication request to make the document
              Propose/Candidate.
            + Canonical XML
                 o Continue running it through the W3C TR process till
                   Candidate REC, then generate an informational RFC.
 
 End Forwarded Text ----
End Forwarded Text ----

_________________________________________________________
Joseph Reagle Jr.   
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Monday, 12 June 2000 16:41:45 UTC