Additional XML Security Uniform Resource Identifiers (URIs)
draft-eastlake-additional-xmlsec-uris-10

[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.

[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

[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.

[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.

[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.

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.

[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."

[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

[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.

  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.

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