Additional XML Security Uniform Resource Identifiers (URIs)
draft-eastlake-rfc6931bis-xmlsec-uris-27

[S2.1.1,elsewhere; question]

* Is RFC 4648 a reasonable reference for base64 (in addition to/as an
  alternative to RFC 2045)?

[S2.2.6; question]

* Pardon my total ignorance, but are XMSS{,MT} SignatureMethods, like
  the rest of 2.2.*, or are they really DigestAlgorithms (like 2.1.*)?
  (Yes, I see the answer is in the expansion of the acronym.)

  I guess, more directly: should the example be <SignatureMethod .../>
  rather than <DigestAlgorithm .../>?

Thank you for the work on this document.

Just noticed a couple of easy-to-fix nits while reading it through.

Francesca

1. -----

   It's output can be optionally truncated. An example is as follows:

FP: s/It's/Its

2. -----

   SigntureMethod element is as follows:

FP: s/SigntureMethod/SignatureMethod (2 occurrences)

Thanks for doing this work! I have a few comments below. You may choose to resolve them, or not. I hope they help.

1. Forgive me, but I’m having a hard time following this paragraph:

   All of the URIs appear in the indexes in Section 4.  The URIs that
   were added by earlier RFCs or this document and some other URIs have
   a subsection in Section 2 or 3.  But most URIs defined elsewhere, for
   example, use of SHA-256 as defined in [XMLENC11], have no subsection
   on that algorithm here, but their URI may be included in the indexes
   in Section 4.

Difficulties include:

- “All of the URIs” seems rather expansive. Presumably you don’t really mean this in the plain-English sense of All. The. URIs. (that can be conceived of in the universe) but rather that it be limited to all the URIs in some class or category, but what? 
- Other than that, the prose is just difficult to follow. I *think* what you mean is:
  - URIs that were added by earlier RFCs have a subsection in §2 or §3
  - URIs that were added by this document have a subsection in §2 or §3
  - Some other URIs (unspecified) have a subsection in §2 or §3
  - No other URIs (you say “most”) have a subsection
  - Most URIs defined elsewhere may be listed in §4. Or I guess, they may not, because "most" and "may".

I do see this paragraph comes to us from RFC 6931, but it’s been rewritten in a way that loses context that was present in the earlier version.

2. Nit, in §1:

   This required removal of the Minimal Canonicalization algorithm, in
   which was continued interest.  The URI for Minimal Canonicalization

“… which was” should be “… which there was”. 

3. In §1.2 of course I (think I) know what you’re getting at with the FQDNs in angle brackets, as in 

      IETF - Internet Engineering Task Force <www.ietf.org>

but they’re still a bit funny to encounter. Probably these would be better as proper references, with properly written-out URLs (i.e., including the “https://“ part) in the reference section? I do see that RFC 6931 was published with the <FQDN> form, so if you don’t choose to change it, I’m not going to be offended.

Thank you for the work put into this document. It must be a tedious task but an important one!

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

I hope that this helps to improve the document,

Regards,

-éric

Is it because the IANA XML Security URIs registry is specification required that this kind of document has always published as AD-sponsored: RFC 6931 and RFC 4051? As this is my guess, should this registry become more relaxed and allow easier updates ?

-- Section 4.2 --
Is it on purpose that the preamble of the long list appears to be repeated after the list ?

Thank you for addressing my Discuss points.

I believe the following (retained from the -25) still applies:

Section 2.6.7

   be encrypted, ChaCha20 takes a 96-bit Nonce and an initial 32-bit

(editorial) I'd recommend s/an initial 32-bit/a 32-bit initial/

These DOWNREFs were not in the Last Call announcement:

  * DOWNREF [RFC3076] from this Proposed Standard to Informational RFC3076.
  * DOWNREF [RFC3092] from this Proposed Standard to Informational RFC3092.
  * DOWNREF [RFC3741] from this Proposed Standard to Informational RFC3741.
  * DOWNREF [RFC6194] from this Proposed Standard to Informational RFC6194.

I-D Guidelines boilerplate text seems to have issues.

TLP Section 6.b "Copyright and License Notice" boilerplate text seems to have
issues.

Found stray text in boilerplate: "Distribution of this document is unlimited.
Comments should be sent to the author."

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

This document seems to have unresolved IANA issues.

Thanks to Peter E. Yee for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/53HUJMv7i6I5xJMLPZLVUkdmJLg).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2.2.1 , paragraph 4, nit:
> bit hash that is used here in HMAC. It's output can be optionally truncated.
>                                     ^^^^
It seems that the possessive pronoun "its" fits better in this context.

Section 2.3.6 , paragraph 2, nit:
> d on smart cards without special co-processors. An example of use is: <Signat
>                                  ^^^^^^^^^^^^^
This word is normally spelled as one.

Section 2.3.9 , paragraph 7, nit:
>  curves. A specification is provided and some advantages listed in [RFC8032]
>                                     ^^^^
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

Section 4.2 , paragraph 11, nit:
> siderations for XML security are outside of the scope of this document but a
>                                  ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

Section 4.2 , paragraph 14, nit:
>  reference to RFC 4051 and to the one Errata against RFC 4051. 2. Fix three e
>                                   ^^^^^^^^^^
Don't use the number "one" with plural words. Did you mean "one erratum", "an
erratum", or simply "Errata"?

"Normative References", paragraph 8, nit:
> d, "Etymology of "Foo"", RFC 3092, April 1 2001. [RFC3741] - Boyer, J., East
>                                    ^^^^^^^
Commas set off the year in a month-day-year date.

Reference [RFC3075] to RFC3075, which was obsoleted by RFC3275 (this may be on
purpose).

These URLs in the document did not return content:
 * http://www.w3.org/TR/2002/
 * http://www.w3.org/TR/2013/
 * http://www.w3.org/TR/2003/
 * http://www.w3.org/2001/04/xmldsig-more/xptr
 * http://www.w3/org/xmlsec-ghc#

These URLs in the document can probably be converted to HTTPS:
 * everything at w3.org
 * http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf
 * http://cr.yp.to/mac/poly1305-20050329.pdf
 * http://www.rfc-editor.org
 * http://cr.yp.to/chacha/chacha-20080128.pdf

Hi,

just a minor typo: both urls seem to be missing an 'i' (s/dsg/dsig/)

2.2.5 SipHash-2-4

   Identifier:
        http://www.w3.org/2021/04/xmldsg-more#siphash-2-4

   SipHash [SipHash1] [SipHash2] computes a 64-bit MAC from a 128-bit
   secret key and a variable length message. An example of a SipHash-2-4
   SigntureMethod element is as follows:

   <SignatureMethod
      Algorithm="http://www.w3.org/2021/04/xmldsg-more#siphash-2-4"/>

Thanks for this document and thanks Al for the Opsdir review.

I only checked the diff against the previous RFC, but have no comments/suggestions!

Regards,
Rob