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

From: Roman Danyliw <[email-masked]>
Date: Sun, 7 Nov 2021 16:32:46 +0000

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

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

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

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

** 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

** 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 ?

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

** 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              

** 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

** 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?

Regards,
Roman

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 7 Nov 2021 21:31:27 -0500

Hi Roman,

Thanks for the review. See below:

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

> 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…

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

> 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 U…

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.

> 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 latt…

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.

> 2021/04/xmldsig-more#po1y305

OK on the above.

> "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 l…

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   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 11 Nov 2021 21:04:05 +0000

Hi Donald

> -----Original Message-----
> From: Donald Eastlake <[email-masked]>
> Sent: Sunday, November 7, 2021 9:31 PM
> To: Roman Danyliw <[email-masked]>
> Cc: saag <[email-masked]>
> Subject: Re: [saag] AD Review of draft-eastlake-rfc6931bis-xmlsec-uris-17

[snip]

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

Doing the diff with RFC6931,  I see what you mean.  Almost no text changed.  

Why I flagged this text (assuming that something changed in the bis) was that the Section 5.2 text doesn't match what I see in the registry.  In RFC6931 and this update, the text says that "New entries, including new Types, will be added based on Expert Review [RFC8126]."  The subsequent text provides guidance to the expert reviewer.   When I check https://www.iana.org/assignments/xml-security-uris/xml-security-uris.xhtml, the listed registration procedure is "specification required".  It's not that the text is wrong, "specification required" also includes an expert review and further guidance is fine to give to the expert.  However, the top-line policy in the text seems like it should say "specification required" + guidance to the expert.  Rather than what I reads like now which is effectively "spec required" enforced by the expert.

Regards,
Roman

>  2386 Panoramic Circle, Apopka, FL 32703 USA  [email-masked]
> 
> > Regards,
> > Roman

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 11 Nov 2021 23:02:07 -0500

OK, as I said I'm fine with changing this to say Specification
Required instead of Expert Review.

This draft originally said Expert Review for historic reasons that are
no longer relevant.

Thanks,
Donald

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 12 Nov 2021 11:21:15 +0000

Hi Donald!

> Sent: Thursday, November 11, 2021 11:02 PM
> OK, as I said I'm fine with changing this to say Specification Required instead of
> Expert Review.

Great.

> This draft originally said Expert Review for historic reasons that are no longer
> relevant.

Understood.  Thanks for clarifying.

Regards,
Roman

> > > 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.
> >
> > Why I flagged this text (assuming that something changed in the bis) was that
> the Section 5.2 text doesn't match what I see in the registry.  In RFC6931 and
> this update, the text says that "New entries, including new Types, will be added
> based on Expert Review [RFC8126]."  The subsequent text provides guidance to
> the expert reviewer.   When I check https://www.iana.org/assignments/xml-
> security-uris/xml-security-uris.xhtml, the listed registration procedure is
> "specification required".  It's not that the text is wrong, "specification required"
> also includes an expert review and further guidance is fine to give to the
> expert.  However, the top-line policy in the text seems like it should say
> "specification required" + guidance to the expert.  Rather than what I reads like
> now which is effectively "spec required" enforced by the expert.
> >
> > Regards,
> > Roman
> >
> > >
> > > Thanks,
> > > Donald

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 14 Nov 2021 21:50:49 -0500

Hi Roman,

On Sun, Nov 7, 2021 at 9:31 PM Donald Eastlake <[email-masked]> wrote:
>...

On further investigation, I believe the identifiers given are correct
and the example xml was wrong.

Thanks,
Donald

>...