Re: [saag] AD Review of draft-eastlake-rfc6931bis-xmlsec-uris-17

[Donald Eastlake <[e-mail]>]

Hi Roman,

Thanks for the review. See below:

On Sun, Nov 7, 2021 at 11:34 AM Roman Danyliw <[e-mail]> wrote:
> Hi!
>
> I performed an AD review on draft-eastlake-rfc6931bis-xmlsec-uris-17.  As this document is AD-sponsored, I would also appreciate additional reviewer either now or when the document enters IETF LC.  My feedback is below:
>
> ** I checked all of the new URIs listed in the document.  Generally, they returned a page saying that these identifiers are reserved and pointed back to this document.  The following URIs demonstrated different behavior.  Is this expected or a sign that further coordination with W3C is required?
>
> -- Returns a 404:
> http://www.w3.org/2021/04/xmldsg-more#siphash-2-4

I believe the W3C will set up web pages or fix them as needed for UIRs
defined by this document or its predecessors. I've suggested to them
that we might as well wait until the document is a bit further through
the process.

> -- Returns a generic page on namespaces (but I'll note that these URI are also already defined in [GENERIC], aka https://www.w3.org/TR/xmlsec-generic-hybrid/):
>
> http://www.w3.org/2010/xmlsec-ghc#rsaes-kem
> http://www.w3.org/2010/xmlsec-ghc#ecies-kem

URIs defined in other documents but included in this draft for
convenience are somewhat of a different matter.

> ** Editorial.  Why do only of some the algorithms have examples?  For example, in the original RFC6931 text, Section 2.1.3 (SHA-384) has one, but Section 2.1.4 (Whirlpool) does not.  Section 2.1.5 (SHA3) was originally in RFC6931 and in this bis got an example (for SHA3-224).  Of the newly added algorithms, Section 2.2.4 (Poly1305), 2.2.5 (SipHash-2-4), 2.2.6 (XMSS), 2.6.7 (ChaCha20) didn't get examples (not an exhaustive list), but Section 2.3.12 (Edwards-Curve) and Section 2.6.8 (ChaCha20+Poly1305) did.

There is no particularly good reason. I can add some examples.

> ** Abstract.  Editorial.
>
> OLD
>    This document updates and corrects the IANA registry for the list of
>    URIs intended for use with XML digital signatures, encryption,
>    canonicalization, and key management.  These URIs identify algorithms
>    and types of information.
>
> NEW
> This document updates and corrects the IANA "XML Security URIs" registry that lists the URIs intended for use with XML digital signatures, encryption, canonicalization, and key management.  These URIs identify algorithms and their associated type information.

OK on the change of the first sentence. However, at least the URIs in
Section 3.2 seem to me to identify types of information and I'm not
sure they can be said to be associated with a crypto algorithm.

> ** Section 1.  Typo. s/has has/has/
>
> ** Section 1.  Typo. s/elemets/elements/
>
> ** Section 2.  This section discusses the namespace change from #xmldsig to #xmldsig-more.  It seems like an introduction of #xmlsec-ghc should also be added here.
>
> ** Section 2.2.3. Editorial.  s/is here used/is used here/
>
> ** Section 2.2.4.  Typo in the identifier URI:
>
> OLD
> http://www.w3.org/2021/04/xml6dsig-more#poly1305
> NEW
> http://www.w3.org/2021/04/xmldsig-more#poly1305

OK on the above.

> ** Section 2.2.6.  Is there a reason there isn't more narrative text point out the different variants of XMSS the same way that Section 2.1.5 or 2.2.2 ?

This is one of the algorithms added in this version of the draft. I'll
see if I can add some more useful text.

> ** Section 2.6.4.  This is comment on the original text from RFC6931 copied into this document. Why doesn't the full namespace from the "identifiers" list match the example for #psec-kem?  The latter says "xmldsig-more#psec-kem" but the example says "xmlenc#psec-kem".

The namespace from specific W3C documents, such as in this case,
<https://www.w3.org/TR/xmlsec-generic-hybrid/>, should dominate name
spaces created for this draft or its predecessors. I'll check into
this case.

> ** Section 2.6.7.  Typo. s/repreented/represented/
>
> ** Section 2.6.7.  Typo. /nexted/nested/
>
> ** Section 2.7.2.  Typo. s/specificed/specified/
>
> ** Section 2.7.2.  Typo.  In the example:
> OLD
> /AgreementMethod>
>
> NEW
> </AgreementMethod>
>
> ** Section 4.2.  Typo in the fragment name of the table (used to update the IANA registry)
>
> OLD
> 2021/04/xmldsig-more#po1305
>
> NEW
> 2021/04/xmldsig-more#po1y305

OK on the above.

> ** Section 5.1
>    The W3C has assigned "http://www.w3.org/2021/04/xmldsig-more#" for
>    additional new URIs specified in this document.
>
> "xmlsec-ghc#" is also used.  Perhaps we should ls

I think xmlsec-ghc is not an added namespace for this draft, it's from
https://www.w3.org/TR/xmlsec-generic-hybrid/. I'll say something about
it.

> ** Section 5.2.  Why loosen the registration procedure from specification required to expert review?  The documentation requirement seems nearly equivalent to "specification required".  Given how little churn this gets (especially in new Types), what would be the circumstances where the rigor of a W3C or IETF wouldn't be appropriate?

This text was just carried forward from RFC 6931. The question is why
did the IANA Registry not use the registration procedure specified by
RFC 6931? In any case, I'd be happy to change this in the draft
Specification Required.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

> Regards,
> Roman