Skip to main content

Additional XML Security Uniform Resource Identifiers (URIs)
RFC 6931

Revision differences

Document history

Date Rev. By Action
2015-10-14
10 (System) Notify list changed from d3e3e3@gmail.com, draft-eastlake-additional-xmlsec-uris@ietf.org, charliek@microsoft.com to charliek@microsoft.com
2013-06-26
10 (System) IANA registries were updated to include RFC6931
2013-04-18
10 (System) RFC published
2013-04-16
10 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2013-04-12
10 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2013-04-08
10 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2013-04-05
10 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2013-04-05
10 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2013-04-04
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2013-04-03
10 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent
2013-04-03
10 (System) RFC Editor state changed to EDIT
2013-04-03
10 (System) Announcement was received by RFC Editor
2013-04-03
10 (System) IANA Action state changed to In Progress
2013-04-03
10 Cindy Morgan State changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed
2013-04-03
10 Cindy Morgan IESG has approved the document
2013-04-03
10 Cindy Morgan Closed "Approve" ballot
2013-04-03
10 Cindy Morgan Ballot approval text was changed
2013-04-03
10 Cindy Morgan Ballot approval text was generated
2013-04-03
10 Cindy Morgan Ballot writeup was changed
2013-03-27
10 Donald Eastlake New version available: draft-eastlake-additional-xmlsec-uris-10.txt
2013-03-07
09 Tero Kivinen Closed request for Last Call review by SECDIR with state 'No Response'
2013-02-28
09 Cindy Morgan State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2013-02-28
09 Russ Housley
[Ballot comment]

  The Gen-ART Review by Suresh Krishnan on 23-Feb-2013 raised two
  concerns about the language associated with MD5.  In addition, I
  …
[Ballot comment]

  The Gen-ART Review by Suresh Krishnan on 23-Feb-2013 raised two
  concerns about the language associated with MD5.  In addition, I
  have a concern with the language associated with SHA-384.

  In Section 2.1.1, the following text is a bit misleading as it looks
  like this document is taking a stance on the use of MD5:
  >
  > Use of MD5 is NOT RECOMMENDED [RFC6151].
  >
  Suresh proposed this rewording, and I agree with it:
  >
  > Please note that the use of MD5 is no longer recommended for digital
  > signatures [RFC6151].

  In Section 2.3.1, the following text is concerning to me:
  >
  > Because it takes roughly the same amount of effort to compute a
  > SHA-384 message digest as a SHA-512 digest and terseness is usually
  > not a criteria in XML application, consideration should be given to
  > the use of SHA-512 as an alternative.
  >
  There are more criteria than hash size when selecting a hash
  algorithm.  This is just one consideration, and this advice ignores
  all other aspects of the decision.  Note that Suite B that is being
  advocated by NSA uses SHA-384 (not SHA-512) at the higher of the two
  security strengths.  So, I suggest that a more complete picture be
  included or that this advice be removed.
 
  In the Security Considerations, this test duplicates the RFC 6151.
  >
  > Due to computer speed and cryptographic advances, the use of MD5 as
  > a DigestMethod or in the RSA-MD5 SignatureMethod is NOT RECOMMENDED.
  > The cryptographic advances concerned do not affect the security of
  > HMAC-MD5; however, there is little reason not to go for one of the
  > SHA series of algorithms.
  >
  I think that a warning might be better.  For example, this text comes
  from RFC 2630:
  >
  > Implementers should be aware that cryptographic algorithms become
  > weaker with time.  As new cryptoanalysis techniques are developed and
  > computing performance improves, the work factor to break a particular
  > cryptographic algorithm will reduce.  Therefore, cryptographic
  > algorithm implementations should be modular allowing new algorithms
  > to be readily inserted.  That is, implementers should be prepared for
  > the set of mandatory to implement algorithms to change over time.
  >
  Taking the ideas from this paragraph from RFC 2630 and a reference to
  RFC 6151 seems like a very good way to make the point about MD5 and
  make it clear that all algorithms age.
2013-02-28
09 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss
2013-02-28
09 Stephen Farrell
[Ballot comment]

was discuss: I don't get why RIPEMD, Whirlpool, ESIGN, PSEC-KEM and SEED
are all included, I do see some were in 4051 but …
[Ballot comment]

was discuss: I don't get why RIPEMD, Whirlpool, ESIGN, PSEC-KEM and SEED
are all included, I do see some were in 4051 but I don't know
that any "substantial" community makes use of each of these. I
think that you therefore need to include a statement something
like: "Inclusion of an algorithm in this document has no
implication that the authors or the IETF consider those
algorithms fit for any purpose. At present, specific protocol
documents specify the algorithms that are mandatory to
implement for that protocol. As security considerations for
algorithms are constantly developing those are also documented
in relevant protocol specifications. This specification
therefore simply provides the URIs and defines relevant
formatting for when those URIs are used."

- general: it'd be far better if you could include test
vectors for more/all algorithms.

- I think this document needs to be, but is not, clear as to
whether its making any new RECOMMENDations regarding use or
non-use of algorithms for IETF applications that make use or
URIs for algorithm identifiers.  If it is makeing new
recommendations then more review would be needed.  If its just
listing the URIs and making comments in passing, then the use
of 2119 terms for innovative algorithm recommendations is not
appropriate and nor are qualitative assessments of algorithm
strength. If you want to make new recommendations then I think
we need text that says that explicitly and a new IETF LC that
makes that clear. If you want to just have an inclusive list
of well-defined URIs (which I think is better) then some text
changes in sections listed below are needed.  Note that if
some existing IETF consensus document has already got 2119
terms about use of an algorithm then its perfectly fine to
quote that, e.g. say that "RFC foo, section bar, says that
'MD5 is NOT RECOMMENDED for use in signatures'" etc. but I'd
like all such statements to be quotes so that we know that
we're not innovating here, without proper review.  These are
the places I spotted that need looking at based on the above:

  - 2.1.1 "NOT RECOMMENDED"
  - 2.6.3 - "the implementation of camellia is OPTIONAL"
  - 2.6.2 - please delete claims that camellia is "efficient
and secure" or else add similar descriptions to all other
    sections. (Same for SEED in 2.6.5)
  - 2nd para of section 6

- intro: what is the definition of "substantial interest"
which seems to be used as the criterion for inclusion here?  I
think that'd be better changed, e.g. to say that you're aiming
to be inclusive here, but that that has no significance in
terms of algorithm strength or suitability.

- intro: refers to "Draft Standard" which doesn't exist any
more. The reference is historical but maybe ought be fixed?
(I don't care much, but maybe someone does.)

- intro: I'd suggest you add the example that sha-256 is
defined in XMLENC (5.8.2) and hence is not here.

- 1.1, I think you could say here that this isn't innovating
in terms of alg strength etc and that all 2119 terms on that
topic are just quotes from existing RFCs.

- 2.1.1 and elsewhere: when you say that the encoding of the
output "shall be" something, is that intended as a 2119 term?
I think it ought and would be better as SHALL (or MUST) since
people do get these subtly wrong all the time.

- 2.1.1 and elsewhere: you assume I know what a DigestValue
element is. Maybe you ought say that camel case element names
are all from either xmldsig or xmlenc (or whereever they are
from). That's almost obvious enough, but you never know there
might be another DigestValue definition somewhere else that'd
confuse someone.

- 2.1.2 - suggest adding a reference to where sha-256 is
defined in XMLENC. Similarly for 2.1.3

- 2.1.5 - wouldn't it be better to make NIST's sha-3 FIPS a
normative reference and add the details needed here for base64
encoding of outputs and just let this wait on the FIPS to
issue before the RFC does? If not, won't someone have to do
that then anyway?

- 2.3.7 - the title of this section is wrong since it doesn't
only define sha-1 stuff

- 3.2 - I assume retrieval is via HTTP - where's that stated?
Is the "Type attribute" mentioned in the last sentence meant
to be a Content-Type or what? I think you ought clarify.

- wouldn't section 4 be better put into an IANA registry? Why
not?

- references: XMLENC 1st URL gives a 404, why not just use the
2nd?
h
2013-02-28
09 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2013-02-28
09 Sean Turner State changed to IESG Evaluation from Waiting for AD Go-Ahead
2013-02-28
09 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2013-02-28
09 Benoît Claise
[Ballot comment]
No really sure why the acknowledgements section is in the front?
I thought that we had guidelines for section order somewhere, but I …
[Ballot comment]
No really sure why the acknowledgements section is in the front?
I thought that we had guidelines for section order somewhere, but I can't find them right now...
So this comment is more about my own question: do we actually have requirements regarding the sections order?
I'll shoot an email now to the RFC editor notes.
Note: RFC 4051 had the acknowledgements section at the usual place.
2013-02-28
09 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2013-02-28
09 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2013-02-27
09 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy
2013-02-26
09 Stewart Bryant
[Ballot comment]
I agree with Adrian and further wonder why, if we need an RFC, this document does not simply update RFC4051 rather than apparently …
[Ballot comment]
I agree with Adrian and further wonder why, if we need an RFC, this document does not simply update RFC4051 rather than apparently duplicating much of its material.
2013-02-26
09 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2013-02-26
09 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2013-02-26
09 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks
2013-02-26
09 Adrian Farrel
[Ballot comment]
The subject material of this document is so far from my competence that
I will rely on the Security ADs to provide the …
[Ballot comment]
The subject material of this document is so far from my competence that
I will rely on the Security ADs to provide the necessary reviews.  I
have a meta question for them which is: does the publication of this
document as a PS imply IETF endorsement for the use of these algorithms?
And wouldn't it be easier to turn this into an IANA registry to avoid
frequent updates?


While reading the document, I found a few nits and questions:

---

Section 1
  Informational or Standards Track documents
Is that s/documents/RFCs/ ?

---

Section 1
  All of these are now W3C Recommendations and IETF
  Informational or Standards Track documents.

The table that follows is ambiguous since it looks like maybe [XMLENC]
does not have an RFC equivalent.

---

Section 1
s/[XMLENC}/[XMLENC]/

---

Section 2.1.5

  NIST has recently completed a hash function competition for an
  alternative to the SHA family.  The Keccak-f[1600] algorithm was
  selected [Keccak]. This section is a space holder and reservation of
  URIs for future information on Keccak use in XML security.

I really don't understand this!
It seems to say
- Here are the URIs for SHA-3
- NIST says don't use SHA-3
- This document will be updated to include URIs for Keccak.
That seems odd to me. Why not:
- Include URIs for SHA-3 but say you expect their use to be deprecated
  soon
- Include a separate section for Keccak
- If no URIs yet exist for Keccak, then don't include them.

---

2.2.1

  Although cryptographic suspicions have recently been cast on MD5 for
  use in signatures such as RSA-MD5 below, this does not affect use of
  MD5 in HMAC [RFC6151].

"suspicions" seems to rather underplay the situation, doesn't it?
The last paragraph of Section 2 of RFC 6151 says it all.
2013-02-26
09 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2013-02-26
09 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2013-02-25
09 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica
2013-02-25
09 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-eastlake-additional-xmlsec-uris, which is
currently in Last Call, and has the following comments:

We understand that, upon approval of this …
IESG/Authors/WG Chairs:

IANA has reviewed draft-eastlake-additional-xmlsec-uris, which is
currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA
Actions that need completion.

If this assessment is not accurate, please respond as soon as possible.
2013-02-25
09 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2013-02-25
09 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2013-02-25
09 Stephen Farrell
[Ballot discuss]

I don't get why RIPEMD, Whirlpool, ESIGN, PSEC-KEM and SEED
are all included, I do see some were in 4051 but I don't …
[Ballot discuss]

I don't get why RIPEMD, Whirlpool, ESIGN, PSEC-KEM and SEED
are all included, I do see some were in 4051 but I don't know
that any "substantial" community makes use of each of these. I
think that you therefore need to include a statement something
like: "Inclusion of an algorithm in this document has no
implication that the authors or the IETF consider those
algorithms fit for any purpose. At present, specific protocol
documents specify the algorithms that are mandatory to
implement for that protocol. As security considerations for
algorithms are constantly developing those are also documented
in relevant protocol specifications. This specification
therefore simply provides the URIs and defines relevant
formatting for when those URIs are used."
2013-02-25
09 Stephen Farrell
[Ballot comment]

- general: it'd be far better if you could include test
vectors for more/all algorithms.

- I think this document needs to be, …
[Ballot comment]

- general: it'd be far better if you could include test
vectors for more/all algorithms.

- I think this document needs to be, but is not, clear as to
whether its making any new RECOMMENDations regarding use or
non-use of algorithms for IETF applications that make use or
URIs for algorithm identifiers.  If it is makeing new
recommendations then more review would be needed.  If its just
listing the URIs and making comments in passing, then the use
of 2119 terms for innovative algorithm recommendations is not
appropriate and nor are qualitative assessments of algorithm
strength. If you want to make new recommendations then I think
we need text that says that explicitly and a new IETF LC that
makes that clear. If you want to just have an inclusive list
of well-defined URIs (which I think is better) then some text
changes in sections listed below are needed.  Note that if
some existing IETF consensus document has already got 2119
terms about use of an algorithm then its perfectly fine to
quote that, e.g. say that "RFC foo, section bar, says that
'MD5 is NOT RECOMMENDED for use in signatures'" etc. but I'd
like all such statements to be quotes so that we know that
we're not innovating here, without proper review.  These are
the places I spotted that need looking at based on the above:

  - 2.1.1 "NOT RECOMMENDED"
  - 2.6.3 - "the implementation of camellia is OPTIONAL"
  - 2.6.2 - please delete claims that camellia is "efficient
and secure" or else add similar descriptions to all other
    sections. (Same for SEED in 2.6.5)
  - 2nd para of section 6

- intro: what is the definition of "substantial interest"
which seems to be used as the criterion for inclusion here?  I
think that'd be better changed, e.g. to say that you're aiming
to be inclusive here, but that that has no significance in
terms of algorithm strength or suitability.

- intro: refers to "Draft Standard" which doesn't exist any
more. The reference is historical but maybe ought be fixed?
(I don't care much, but maybe someone does.)

- intro: I'd suggest you add the example that sha-256 is
defined in XMLENC (5.8.2) and hence is not here.

- 1.1, I think you could say here that this isn't innovating
in terms of alg strength etc and that all 2119 terms on that
topic are just quotes from existing RFCs.

- 2.1.1 and elsewhere: when you say that the encoding of the
output "shall be" something, is that intended as a 2119 term?
I think it ought and would be better as SHALL (or MUST) since
people do get these subtly wrong all the time.

- 2.1.1 and elsewhere: you assume I know what a DigestValue
element is. Maybe you ought say that camel case element names
are all from either xmldsig or xmlenc (or whereever they are
from). That's almost obvious enough, but you never know there
might be another DigestValue definition somewhere else that'd
confuse someone.

- 2.1.2 - suggest adding a reference to where sha-256 is
defined in XMLENC. Similarly for 2.1.3

- 2.1.5 - wouldn't it be better to make NIST's sha-3 FIPS a
normative reference and add the details needed here for base64
encoding of outputs and just let this wait on the FIPS to
issue before the RFC does? If not, won't someone have to do
that then anyway?

- 2.3.7 - the title of this section is wrong since it doesn't
only define sha-1 stuff

- 3.2 - I assume retrieval is via HTTP - where's that stated?
Is the "Type attribute" mentioned in the last sentence meant
to be a Content-Type or what? I think you ought clarify.

- wouldn't section 4 be better put into an IANA registry? Why
not?

- references: XMLENC 1st URL gives a 404, why not just use the
2nd?
h
2013-02-25
09 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2013-02-24
09 Russ Housley
[Ballot discuss]

  The Gen-ART Review by Suresh Krishnan on 23-Feb-2013 raised two
  concerns about the language associated with MD5.  In addition, I
  …
[Ballot discuss]

  The Gen-ART Review by Suresh Krishnan on 23-Feb-2013 raised two
  concerns about the language associated with MD5.  In addition, I
  have a concern with the language associated with SHA-384.

  In Section 2.1.1, the following text is a bit misleading as it looks
  like this document is taking a stance on the use of MD5:
  >
  > Use of MD5 is NOT RECOMMENDED [RFC6151].
  >
  Suresh proposed this rewording, and I agree with it:
  >
  > Please note that the use of MD5 is no longer recommended for digital
  > signatures [RFC6151].

  In Section 2.3.1, the following text is concerning to me:
  >
  > Because it takes roughly the same amount of effort to compute a
  > SHA-384 message digest as a SHA-512 digest and terseness is usually
  > not a criteria in XML application, consideration should be given to
  > the use of SHA-512 as an alternative.
  >
  There are more criteria than hash size when selecting a hash
  algorithm.  This is just one consideration, and this advice ignores
  all other aspects of the decision.  Note that Suite B that is being
  advocated by NSA uses SHA-384 (not SHA-512) at the higher of the two
  security strengths.  So, I suggest that a more complete picture be
  included or that this advice be removed.
 
  In the Security Considerations, this test duplicates the RFC 6151.
  >
  > Due to computer speed and cryptographic advances, the use of MD5 as
  > a DigestMethod or in the RSA-MD5 SignatureMethod is NOT RECOMMENDED.
  > The cryptographic advances concerned do not affect the security of
  > HMAC-MD5; however, there is little reason not to go for one of the
  > SHA series of algorithms.
  >
  I think that a warning might be better.  For example, this text comes
  from RFC 2630:
  >
  > Implementers should be aware that cryptographic algorithms become
  > weaker with time.  As new cryptoanalysis techniques are developed and
  > computing performance improves, the work factor to break a particular
  > cryptographic algorithm will reduce.  Therefore, cryptographic
  > algorithm implementations should be modular allowing new algorithms
  > to be readily inserted.  That is, implementers should be prepared for
  > the set of mandatory to implement algorithms to change over time.
  >
  Taking the ideas from this paragraph from RFC 2630 and a reference to
  RFC 6151 seems like a very good way to make the point about MD5 and
  make it clear that all algorithms age.
2013-02-24
09 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley
2013-02-24
09 Suresh Krishnan Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Suresh Krishnan.
2013-02-21
09 Jean Mahoney Request for Last Call review by GENART is assigned to Suresh Krishnan
2013-02-21
09 Jean Mahoney Request for Last Call review by GENART is assigned to Suresh Krishnan
2013-02-21
09 Sean Turner Ballot has been issued
2013-02-21
09 Sean Turner Ballot writeup was changed
2013-02-19
09 Sean Turner Ballot has been issued
2013-02-19
09 Sean Turner [Ballot Position Update] New position, Yes, has been recorded for Sean Turner
2013-02-19
09 Sean Turner Created "Approve" ballot
2013-02-19
09 Sean Turner Ballot writeup was changed
2013-02-09
09 Donald Eastlake New version available: draft-eastlake-additional-xmlsec-uris-09.txt
2013-02-07
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Alan DeKok
2013-02-07
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Alan DeKok
2013-02-05
08 Amy Vezza
  draft-eastlake-additional-xmlsec-uris

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type …
  draft-eastlake-additional-xmlsec-uris

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

  Proposed Standard is requested and noted in the title page header.
  This document obsoletes RFC 4051, which is a Proposed Standard.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  XML Digital Signatures, Encryption, and Canonicalization identify
  algorithms with URIs documented in an RFC due to the beginning of
  XML security in a joint IETF / W3C working group. The last version
  of this was RFC 4051 issued over 7 years ago. There have been major
  advances in crypto algorithms since then and this complete revision
  adds many new URIs for significant new algorithms and a few for
  previously overlooked algorithms. It also provides indexes by URI
  and fragment portion of URI.

Working Group Summary:

  This is an individual submission. It has been carefully reviewed by
  the XML security community and all comments resolved.

Document Quality:

  This document follows the same pattern as its predecessor, RFC
  4051
, but has been enhanced by adding indexes based on URI and on
  URI fragment. (See Section 4 of the draft.)

Personnel:

  Charlie Kaufman is the Document Shepherd.
  Sean Turner is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The Document Shepherd reviewed the document and confirmed the
  correctness of its contents against the document it obsoletes and
  his understanding of the evolving cryptographic standards.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  There are pieces of XML in this draft. It has been reviewed by the
  XML security community.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  No concerns or issues.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78
and BCP 79 have already been filed. If not, explain why?

  Yes. (Their might be IPR on some of the algorithms themselves but
  this draft is just about the URIs used as names of the algorithms.)

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  This is an individual submission, as was its predecessor, RFC 4051.
  It has been reviewed by and has the support of the XML Security
  community.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

  No nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No specific formal review criteria apply to this document.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references (see RFC 3967)? If so,
list these downward references to support the Area Director in the
Last Call procedure.

  There are numerous normative references to non-IETF standards, ISO,
  NIST, and W3C in particular, and a few informational RFCs.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFC is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

  Yes, it obsoletes RFC 4051 as indicated on the title page and in
  the Abstract and discussed in the Introduction. Appendix A
  summarizes the changes from RFC 4051 in this document.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226
).

  This document requires no IANA actions. New URIs are based on a
  root under www.w3.org that has been allocated by the W3C for this
  purpose as mentioned in the IANA Considerations section.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

  No new registries created.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No such checks were performed.
2013-02-01
08 Donald Eastlake New version available: draft-eastlake-additional-xmlsec-uris-08.txt
2013-01-31
07 Jean Mahoney Request for Last Call review by GENART is assigned to Suresh Krishnan
2013-01-31
07 Jean Mahoney Request for Last Call review by GENART is assigned to Suresh Krishnan
2013-01-31
07 Sean Turner Placed on agenda for telechat - 2013-02-28
2013-01-31
07 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Additional XML Security Uniform Resource Identifiers (URIs)) …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Additional XML Security Uniform Resource Identifiers (URIs)) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Additional XML Security Uniform Resource Identifiers (URIs)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-02-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document expands and updates the list of URIs specified in RFC
  4051
and intended for use with XML Digital Signatures, Encryption,
  Canonicalization, and Key Management. These URIs identify algorithms
  and types of information. This document obsoletes RFC 4051.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-eastlake-additional-xmlsec-uris/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-eastlake-additional-xmlsec-uris/ballot/


No IPR declarations have been submitted directly on this I-D.

Note that this document includes the following downrefs:

RFC 2315
RFC 4050
RFC 4269
RFC 6234
2013-01-31
07 Amy Vezza State changed to In Last Call from Last Call Requested
2013-01-31
07 Amy Vezza Last call announcement was changed
2013-01-30
07 Sean Turner Last call was requested
2013-01-30
07 Sean Turner Ballot approval text was generated
2013-01-30
07 Sean Turner Ballot writeup was generated
2013-01-30
07 Sean Turner State changed to Last Call Requested from Publication Requested
2013-01-30
07 Sean Turner Last call announcement was changed
2013-01-30
07 Sean Turner Last call announcement was generated
2013-01-30
07 Sean Turner Note added 'Charlie Kaufman is the document shepherd (charliek@microsoft.com).'
2013-01-30
07 Sean Turner State Change Notice email list changed to d3e3e3@gmail.com, draft-eastlake-additional-xmlsec-uris@tools.ietf.org, charliek@microsoft.com
2013-01-30
07 Sean Turner IESG process started in state Publication Requested
2013-01-30
07 Sean Turner Shepherding AD changed to Sean Turner
2013-01-30
07 Sean Turner Intended Status changed to Proposed Standard from None
2013-01-30
07 Sean Turner Stream changed to IETF from None
2013-01-25
07 Donald Eastlake New version available: draft-eastlake-additional-xmlsec-uris-07.txt
2013-01-05
06 Donald Eastlake New version available: draft-eastlake-additional-xmlsec-uris-06.txt
2012-12-27
05 Donald Eastlake New version available: draft-eastlake-additional-xmlsec-uris-05.txt
2012-12-10
04 Stephanie McCammon New version available: draft-eastlake-additional-xmlsec-uris-04.txt
2012-10-22
03 Donald Eastlake New version available: draft-eastlake-additional-xmlsec-uris-03.txt
2012-07-16
02 Donald Eastlake New version available: draft-eastlake-additional-xmlsec-uris-02.txt
2011-09-09
01 (System) New version available: draft-eastlake-additional-xmlsec-uris-01.txt
2008-05-16
01 (System) Document has expired
2007-11-13
00 (System) New version available: draft-eastlake-additional-xmlsec-uris-00.txt