Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2022-07-01
27 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2022-06-14
27 (System) RFC Editor state changed to AUTH48
2022-06-03
27 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2022-03-31
27 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2022-03-30
27 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2022-03-30
27 (System) IANA Action state changed to In Progress from Waiting on Authors
2022-03-29
27 (System) IANA Action state changed to Waiting on Authors from In Progress
2022-03-21
27 (System) RFC Editor state changed to EDIT
2022-03-21
27 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2022-03-21
27 (System) Announcement was received by RFC Editor
2022-03-20
27 (System) IANA Action state changed to In Progress
2022-03-20
27 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2022-03-20
27 Cindy Morgan IESG has approved the document
2022-03-20
27 Cindy Morgan Closed "Approve" ballot
2022-03-20
27 Cindy Morgan Ballot approval text was generated
2022-03-19
27 (System) Removed all action holders (IESG state changed)
2022-03-19
27 Roman Danyliw IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2022-03-19
27 Benjamin Kaduk
[Ballot comment]
Thank you for addressing my Discuss points.

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

Section 2.6.7

  be encrypted, ChaCha20 …
[Ballot comment]
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/
2022-03-19
27 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2022-03-15
27 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-27.txt
2022-03-15
27 (System) Posted submission manually
2022-02-23
26 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-26.txt
2022-02-23
26 (System) New version accepted (logged-in submitter: Donald Eastlake)
2022-02-23
26 Donald Eastlake Uploaded new revision
2022-02-22
25 Benjamin Kaduk
[Ballot discuss]
Thanks for the updates in the -23 through -25, they include many good
fixes.  Unfortunately, the changes introduced a new issue, and in …
[Ballot discuss]
Thanks for the updates in the -23 through -25, they include many good
fixes.  Unfortunately, the changes introduced a new issue, and in
reviewing around that I noticed another thing that seems problematic.

The XMSS and XMSSMT identifiers listed don't match up with the prose and
are hard to match up to FIPS 202, the stated reference for the SHAKE
XOF(s).  Specifically, FIPS 202 defines *two* XOFs, SHAKE128 and SHAKE256,
not the (one) "SHAKE extensible output function" mentioned in the prose.
The tabulated identifiers include in the second token of the URI anchor
both "shake" and "shake256", which one might presume to indicate SHAKE128
and SHAKE256, respectively, but we should really be more explicit about
what the "shake" token means (or just switch to "shake128").
We definitely need to correct the prose to indicate that there are two
XOFs, though.

I'm also a bit confused by the options given for 192-bit output sizes.
The prose indicates that there should be a "SHA2 output size" of 192 bits,
but the listed reference for SHA2 (RFC 6234) does not offer a native
192-bit hash function, and if a truncated version of a SHA2 family hash
function is desired, we would need to indicate which member of the SHA2
family is to be used prior to truncation.  My apologies for not having
noticed this previously.
(The SHAKE functions, as XOFs, of course have no difficulty producing a
192-bit output, though the security strength of such an offering is low
enough that it's unclear whether we actually want to provide that option.)
2022-02-22
25 Benjamin Kaduk
[Ballot comment]
Please also consider whether we should provide a complete matrix of (hash
function, output size) -- we currently offer the 192-bit option only …
[Ballot comment]
Please also consider whether we should provide a complete matrix of (hash
function, output size) -- we currently offer the 192-bit option only for
"sha2" and "shake256" but not "shake", which seems hard to explain.

I'd also recommend ordering the list of XMSS identifiers in a regular
fashion that iterates oer hash, tree depth, and output size in a
predictable pattern; the current listing has all the shake256 entries at
the end, whereas the entries preceding it alternate in chunks of sha2 and
shake.

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/
2022-02-22
25 Benjamin Kaduk Ballot comment and discuss text updated for Benjamin Kaduk
2022-02-18
25 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2022-02-18
25 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-25.txt
2022-02-18
25 (System) New version accepted (logged-in submitter: Donald Eastlake)
2022-02-18
25 Donald Eastlake Uploaded new revision
2022-02-03
24 Amanda Baber Expert has approved.
2022-02-03
24 Sabrina Tanamal IANA Experts State changed to Expert Reviews OK from Issues identified
2022-02-03
24 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2022-02-02
24 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-24.txt
2022-02-02
24 (System) New version accepted (logged-in submitter: Donald Eastlake)
2022-02-02
24 Donald Eastlake Uploaded new revision
2022-01-25
23 (System) Changed action holders to Roman Danyliw (IESG state changed)
2022-01-25
23 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-01-25
23 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2022-01-25
23 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-23.txt
2022-01-25
23 (System) New version accepted (logged-in submitter: Donald Eastlake)
2022-01-25
23 Donald Eastlake Uploaded new revision
2022-01-20
22 (System) Changed action holders to Donald Eastlake, Roman Danyliw (IESG state changed)
2022-01-20
22 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2022-01-20
22 Lars Eggert
[Ballot comment]
These DOWNREFs were not in the Last Call announcement:

  * DOWNREF [RFC3076] from this Proposed Standard to Informational RFC3076. …
[Ballot comment]
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:                                  ^^^^^^^^^^^^^
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
2022-01-20
22 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2022-01-20
22 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2022-01-20
22 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2022-01-19
22 Amanda Baber IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2022-01-19
22 Francesca Palombini
[Ballot comment]

Thank you for the work on this document.

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

Francesca

1. -----

  …
[Ballot comment]

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)
2022-01-19
22 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2022-01-19
22 Amanda Baber
Expert response:

I reviewed changed in this draft in comparison to RFC 6931 and they
mostly look fine to me. (I am generally happy with …
Expert response:

I reviewed changed in this draft in comparison to RFC 6931 and they
mostly look fine to me. (I am generally happy with how errata was
addressed and what kind of algorithms were added.) I have
concerns/questions about one of the section, which I quote below:

Hide quoted text
> 2.2.6 XMSS and XMSSMT
>
>    Identifiers:
>        http://www.w3.org/2021/04/xmldsig-more#xmss-sha2-192
>        http://www.w3.org/2021/04/xmldsig-more#xmss-sha2-256
>        http://www.w3.org/2021/04/xmldsig-more#xmss-shake256-192
>        http://www.w3.org/2021/04/xmldsig-more#xmss-shake256-256
>        http://www.w3.org/2021/04/xmldsig-more#xmssmt-sha2-192
>        http://www.w3.org/2021/04/xmldsig-more#xmssmt-sha2-256
> http://www.w3.org/2021/04/xmldsig-more#xmssmt-shake256-192
> http://www.w3.org/2021/04/xmldsig-more#xmssmt-shake256-256

I might got this completely wrong, but looking at the IANA registry

and NIST800-208 document itself I see that it is using identifiers in
the form XMSS-SHA2_h_256, where "h" is one of 10/16/20. (There is a
similar problem with xmssmt). I am wondering why "h" is not included in
the fragment part, as it seems like an important parameter for
XMSS/XMSSMT. Or possibly it should be included as an XML element,
similar to ?
2022-01-19
22 Amanda Baber IANA Experts State changed to Issues identified from Reviews assigned
2022-01-18
22 Benjamin Kaduk
[Ballot discuss]
These should be quite straightforward to resolve, but do need to be
addressed before publication:

(1) Section 2.6.4 lists some KEM identifiers and …
[Ballot discuss]
These should be quite straightforward to resolve, but do need to be
addressed before publication:

(1) Section 2.6.4 lists some KEM identifiers and says that "these
algorithms ... are key encapsulation mechanisms using elliptic curve
encryption".  But RSAES-KEM is in the list, which is based on RSA
encryption, not elliptic-curve encryption.  (I note that the example in
§2.6.4 has an  element, which seems to make it not a
terribly useful example for RSAEA-KEM usage.)

(2) Section 2.3 also makes this interesting statement:

                                    That is to say, the verification
  key is different from and not feasibly derivable from the signing
  key.

This is demonstrably false; e.g., for the Edwards-Curve methods, where
§5.1.5 of RFC 8032 provides a step-by-step procedure for determining the
verification key from the signing key.  If the statement was reversed
("signing key is not feasibly derivable from the verification key"), it
would seem unobjectionable.
2022-01-18
22 Benjamin Kaduk
[Ballot comment]
Section 1.2

RFC 2104 doesn't really provide a good/clear expansion for "HMAC", but
RFC 5869 does ("Hashed Message Authentication Code (HMAC)"), which is …
[Ballot comment]
Section 1.2

RFC 2104 doesn't really provide a good/clear expansion for "HMAC", but
RFC 5869 does ("Hashed Message Authentication Code (HMAC)"), which is
different from the one listed here.

Section 2.3.7

  The ESIGN algorithm specified in [IEEEP1363a] is a signature scheme
  based on the integer factorization problem. It is much faster than
  previous digital signature schemes, so ESIGN can be implemented on
  smart cards without special co-processors.

How does ESIGN speed compare to ECC speed (ECDSA, EdDSA)?

Section 2.3.12

  Ed25519 uses 32-octet public keys and produces 64-octet signatures.
  It provides about 128 bits of security and uses SHA-512 (see Section
  2.2.2) as its hash algorithm.

  Ed448 uses 57-octet public keys and produces 114-octet signatures. It
  provides about 224 bits of security and uses "SHAKE256" [FIPS202] as
  its hash algorithm. (SHAKE256 is specified by NIST as an "Extensible

The way in which EdDSA uses hash functions diverges from the traditional
hash+sigh signature construction in such a way that I think "uses
as its hash algorithm" is misleading.  I would rather say that it "uses
internally as part of signature generation.

Also, Section 2.2.2 seems to only cover HMAC-SHA512, not SHA-512 itself.
I would probably reference RFC 6234 (and maybe FIPS180-4] here rather
than §2.2.2.
The actual URL for just SHA-512 seems to come from [XMLENC11], interesting...

Section 2.4

  Thus far, two independent interoperable implementations of Minimal
  Canonicalization have not been announced.  [...]

Do we have any current data on this topic?

Section 2.6.1

Do we think we should add a note about RC4 being ostracized after (e.g.)
the well-publicized attacks on its usage in TLS in 2013 due to the
keystring bias?

Unfortunately, RFCs 8758, 8429, and 7465 are specific to SSH, Kerberos,
and TLS, respectively, so are not super-great references here.

Section 2.6.7

  implementations. In addition to a 256-bit key and the plain text to
  be encrypted, ChaCha20 takes a 96-bit Nonce and a 32-bit Counter. The

ChaCha20 as specified in RFC 8439 takes an *initial* block counter
argument.  The operation that just takes a "counter" input is the
ChaCha20 block function, not the stream cipher.

Section 6

  [RFC6151] should be consulted before considering the use of MD5 as a
  DigestMethod or RSA-MD5 as a SignatureMethod.

HMAC-MD5 is also covered in this document (as a SignatureMethod) and
should probably be listed here.

  readily inserted.  That is, implementers should be prepared for the
  set of mandatory-to-implement algorithms for any particular use to
  change over time. This is sometimes referred to as "algorithm
  agility".

BCP 201 is a good reference on algorithm agility.

NITS

Section 1

  In addition, the XML Encryption recommendation has been augmented by
  [GENERIC] which defines algorithms, XML types, and elements necessary
  to use generic hybrid ciphers in XML Security applications. [GENERIC]
  also provides a key encapsulation algorithm and a data encapsulation
  algorithm (see Section 2.6.4).

I might phrase this as something like "also provides for a key
encapsulation algorithm and a data encapsulation algorithm, with the
combination of the two forming the generic hybrid cipher".  The point
being that providing these functions is not the primary purpose of
[GENERIC], but just a means to an end.

Section 1.2

"RC" seems to be used only once, in the context of RC4 that is also
individually explained; it may not need listing here.

Section 2.2.3

  RIPEMD-160 [10118-3] is a 160-bit hash that is used here in HMAC.
  It's output can be optionally truncated. An example is as follows:

s/It's/Its/ as a minimal fix, but more preferably "The HMAC output can
be optionally truncated".

Section 2.3.6

  see [X9.62] and [RFC4050].  The #sha3-*, #ecdsa-ripemd160, and
  #ecdsa-whirlpool fragments identify a signature method processed in
  the same way as specified by the #ecdsa-sha1 fragment, with the
  exception that SHA3 (see Section 2.1.5), RIPEMD160, or Whirlpool (see
  Section 2.1.4) is used instead of SHA-1.

Pedantically, SHA3 is a family of hash functions, so we shouldn't say
just "that SHA3 [...] is used"; it would have to be more like "that a
SHA3 function [...] is used".

Also, to get singular/plural agreement we might need s/a signature
method/signature methods/

  The output of the ECDSA algorithm consists of a pair of integers
  usually referred to by the pair (r, s).  The signature value consists

I would probably s/by/as/

  For an introduction to elliptic curve cryptographic algorithms, see
  [RFC6090] and note the errata (Errata ID 2773-2777).

Should that be "IDs" plural?

Section 2.6.5

  SEED [RFC4269] is a 128-bit block size with 128-bit key size. In XML

I'd say "is a block cipher with 128-bit block size and 128-bit key
size".  In particular, SEED is a cipher, not a block size.

Section 2.7.2

  The HMAC-based Extract-and-Expand Key Derivation Function (HKDF
  [RFC5869]). Although perhaps not exactly the sort of key agreement

(incomplete sentence)

Section 3

Is the KeyInfo element child really "new" still?

Section 5.1

Looking at the diff from RFC 6931, I se wee had to drop the "beyond
those enumerated in this RFC" as applies to the 2007/05 URIs.  I can see
some argument that we don't need to make such a statement about the
2021/04 URIs (since they properly are under control of W3C), but it does
seem like we might want to give the 2001/04 and 2007/05 URIs similar
treatment -- they currently are described rather differently.
2022-01-18
22 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2022-01-18
22 Robert Wilton
[Ballot comment]
Thanks for this document and thanks Al for the Opsdir review.

I only checked the diff against the previous RFC, but have no …
[Ballot comment]
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
2022-01-18
22 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2022-01-18
22 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-22.txt
2022-01-18
22 (System) New version accepted (logged-in submitter: Donald Eastlake)
2022-01-18
22 Donald Eastlake Uploaded new revision
2022-01-18
21 Martin Vigoureux
[Ballot comment]
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 …
[Ballot comment]
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:

 
2022-01-18
21 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2022-01-17
21 Erik Kline
[Ballot comment]
[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] …
[Ballot comment]
[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
  rather than ?
2022-01-17
21 Erik Kline Ballot comment text updated for Erik Kline
2022-01-17
21 Erik Kline
[Ballot comment]
[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] …
[Ballot comment]
[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 the expansion of the acronym.)

  I guess, more directly: should the example be
  rather than ?
2022-01-17
21 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2022-01-17
21 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2022-01-17
21 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. It must be a tedious task but an important one!

Please find below some …
[Ballot comment]
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 ?
2022-01-17
21 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2022-01-14
21 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-21.txt
2022-01-14
21 (System) New version accepted (logged-in submitter: Donald Eastlake)
2022-01-14
21 Donald Eastlake Uploaded new revision
2022-01-14
20 John Scudder
[Ballot comment]
Thanks for doing this work! I have a few comments below. You may choose to resolve them, or not. I hope they help. …
[Ballot comment]
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

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  form, so if you don’t choose to change it, I’m not going to be offended.
2022-01-14
20 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2022-01-07
20 Sabrina Tanamal IANA Experts State changed to Reviews assigned from Need IANA Expert(s)
2022-01-05
20 Amy Vezza Placed on agenda for telechat - 2022-01-20
2022-01-05
20 Roman Danyliw Ballot has been issued
2022-01-05
20 Roman Danyliw [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw
2022-01-05
20 Roman Danyliw Created "Approve" ballot
2022-01-05
20 Roman Danyliw IESG state changed to IESG Evaluation from Waiting for Writeup
2022-01-05
20 Roman Danyliw Ballot writeup was changed
2021-12-19
20 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2021-12-19
20 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-20.txt
2021-12-19
20 (System) New version accepted (logged-in submitter: Donald Eastlake)
2021-12-19
20 Donald Eastlake Uploaded new revision
2021-12-15
19 (System) IESG state changed to Waiting for Writeup from In Last Call
2021-12-14
19 Peter Yee Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. Sent review to list.
2021-12-12
19 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events'
2021-12-12
19 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Jürgen Schönwälder was withdrawn
2021-12-10
19 Sabrina Tanamal IANA Experts State changed to Need IANA Expert(s)
2021-12-10
19 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2021-12-10
19 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-eastlake-rfc6931bis-xmlsec-uris-19. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-eastlake-rfc6931bis-xmlsec-uris-19. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, the XML Security URIs registry located at:

https://www.iana.org/assignments/xml-security-uris/

will be completely replaced by the following registrations:

URI Reference Type
---------------------------------------+----------------------------+----------------------------
2000/09/xmldsig#base64 [RFC3275] Transform
2000/09/xmldsig#DSAKeyValue [RFC3275] Retrieval type
2000/09/xmldsig#dsa-sha1 [RFC3275] SignatureMethod
2000/09/xmldsig#enveloped-signature [RFC3275] Transform
2000/09/xmldsig#hmac-sha1 [RFC3275] SignatureMethod
2000/09/xmldsig#MgmtData [RFC3275] Retrieval type
2000/09/xmldsig#minimal [ RFC-to-be; Section 2.4 ] Canonicalization
2000/09/xmldsig#PGPData [RFC3275] Retrieval type
2000/09/xmldsig#rawX509Certificate [RFC3275] Retrieval type
2000/09/xmldsig#rsa-sha1 [RFC3275] SignatureMethod
2000/09/xmldsig#RSAKeyValue [RFC3275] Retrieval type
2000/09/xmldsig#sha1 [RFC3275] DigestAlgorithm
2000/09/xmldsig#SPKIData [RFC3275] Retrieval type
2000/09/xmldsig#X509Data [RFC3275] Retrieval type

2001/04/xmldsig-more#arcfour [ RFC-to-be; Section 2.6.1 ] EncryptionMethod
2001/04/xmldsig-more#camellia128-cbc [ RFC-to-be; Section 2.6.2 ] EncryptionMethod
2001/04/xmldsig-more#camellia192-cbc [ RFC-to-be; Section 2.6.2 ] EncryptionMethod
2001/04/xmldsig-more#camellia256-cbc [ RFC-to-be; Section 2.6.2 ] EncryptionMethod
2001/04/xmldsig-more#ecdsa-sha1 [ RFC-to-be; Section 2.3.6 ] SignatureMethod
2001/04/xmldsig-more#ecdsa-sha224 [ RFC-to-be; Section 2.3.6 ] SignatureMethod
2001/04/xmldsig-more#ecdsa-sha256 [ RFC-to-be; Section 2.3.6 ] SignatureMethod
2001/04/xmldsig-more#ecdsa-sha384 [ RFC-to-be; Section 2.3.6 ] SignatureMethod
2001/04/xmldsig-more#ecdsa-sha512 [ RFC-to-be; Section 2.3.6 ] SignatureMethod
2001/04/xmldsig-more#esign-sha1 [ RFC-to-be; Section 2.3.7 ] SignatureMethod
2001/04/xmldsig-more#esign-sha224 [ RFC-to-be; Section 2.3.7 ] SignatureMethod
2001/04/xmldsig-more#esign-sha256 [ RFC-to-be; Section 2.3.7 ] SignatureMethod
2001/04/xmldsig-more#esign-sha384 [ RFC-to-be; Section 2.3.7 ] SignatureMethod
2001/04/xmldsig-more#esign-sha512 [ RFC-to-be; Section 2.3.7 ] SignatureMethod
2001/04/xmldsig-more#hmac-md5 [ RFC-to-be; Section 2.2.1 ] SignatureMethod
2001/04/xmldsig-more#hmac-ripemd160 [ RFC-to-be; Section 2.2.3 ] SignatureMethod
2001/04/xmldsig-more#hmac-sha224 [ RFC-to-be; Section 2.2.2 ] SignatureMethod
2001/04/xmldsig-more#hmac-sha256 [ RFC-to-be; Section 2.2.2 ] SignatureMethod
2001/04/xmldsig-more#hmac-sha384 [ RFC-to-be; Section 2.2.2 ] SignatureMethod
2001/04/xmldsig-more#hmac-sha512 [ RFC-to-be; Section 2.2.2 ] SignatureMethod
2001/04/xmldsig-more#KeyName [ RFC-to-be; Section 3.2 ] Retrieval type
2001/04/xmldsig-more#KeyValue [ RFC-to-be; Section 3.2 ] Retrieval type
2001/04/xmldsig-more#kw-camellia128 [ RFC-to-be; Section 2.6.3 ] EncryptionMethod
2001/04/xmldsig-more#kw-camellia192 [ RFC-to-be; Section 2.6.3 ] EncryptionMethod
2001/04/xmldsig-more#kw-camellia256 [ RFC-to-be; Section 2.6.3 ] EncryptionMethod
2001/04/xmldsig-more#md5 [ RFC-to-be; Section 2.1.1 ] DigestAlgorithm
2001/04/xmldsig-more#PKCS7signedData [ RFC-to-be; Section 3.2 ] Retrieval type
2001/04/xmldsig-more#psec-kem [ RFC-to-be; Section 2.6.4 ] EncryptionMethod
2001/04/xmldsig-more#rawPGPKeyPacket [ RFC-to-be; Section 3.2 ] Retrieval type
2001/04/xmldsig-more#rawPKCS7signedData [ RFC-to-be; Section 3.2 ] Retrieval type
2001/04/xmldsig-more#rawSPKISexp [ RFC-to-be; Section 3.2 ] Retrieval type
2001/04/xmldsig-more#rawX509CRL [ RFC-to-be; Section 3.2 ] Retrieval type
2001/04/xmldsig-more#RetrievalMethod [ RFC-to-be; Section 3.2 ] Retrieval type
2001/04/xmldsig-more#rsa-md5 [ RFC-to-be; Section 2.3.1 ] SignatureMethod
2001/04/xmldsig-more#rsa-sha224 [ RFC-to-be; Section 2.3.11] SignatureMethod
2001/04/xmldsig-more#rsa-sha256 [ RFC-to-be; Section 2.3.2 ] SignatureMethod
2001/04/xmldsig-more#rsa-sha384 [ RFC-to-be; Section 2.3.3 ] SignatureMethod
2001/04/xmldsig-more#rsa-sha512 [ RFC-to-be; Section 2.3.4 ] SignatureMethod
2001/04/xmldsig-more#rsa-ripemd160 [ RFC-to-be; Section 2.3.5 ] SignatureMethod
2001/04/xmldsig-more#sha224 [ RFC-to-be; Section 2.1.2 ] DigestAlgorithm
2001/04/xmldsig-more#sha384 [ RFC-to-be; Section 2.1.3 ] DigestAlgorithm
2001/04/xmldsig-more#xptr [ RFC-to-be; Section 2.5.1 ] Transform
2001/04/xmldsig-more#PKCS7signedData [ RFC-to-be; Section 3.1 ] KeyInfo child

2001/04/xmlenc#aes128-cbc [XMLENC11] EncryptionMethod
2001/04/xmlenc#aes192-cbc [XMLENC11] EncryptionMethod
2001/04/xmlenc#aes256-cbc [XMLENC11] EncryptionMethod
2001/04/xmlenc#dh [XMLENC11] AgreementMethod
2001/04/xmlenc#kw-aes128 [XMLENC11] EncryptionMethod
2001/04/xmlenc#kw-aes192 [XMLENC11] EncryptionMethod
2001/04/xmlenc#kw-aes256 [XMLENC11] EncryptionMethod
2001/04/xmlenc#ripemd160 [XMLENC11] DigestAlgorithm
2001/04/xmlenc#rsa-1_5 [XMLENC11] EncryptionMethod
2001/04/xmlenc#rsa-oaep-mgf1p [XMLENC11] EncryptionMethod
2001/04/xmlenc#sha256 [XMLENC11] DigestAlgorithm
2001/04/xmlenc#sha512 [XMLENC11] DigestAlgorithm
2001/04/xmlenc#tripledes-cbc [XMLENC11] EncryptionMethod

2002/06/xmldsig-filter2 [XPATH] Transform

2002/07/decrypt#XML [DECRYPT] Transform
2002/07/decrypt#Binary [DECRYPT] Transform

2006/12/xmlc12n11# {Bad} [CANON11] Canonicalization
2006/12/xmlc14n11# [CANON11] Canonicalization
2006/12/xmlc14n11#WithComments [CANON11] Canonicalization

2007/05/xmldsig-more#ecdsa-ripemd160 [ RFC-to-be; Section 2.3.6 ] SignatureMethod
2007/05/xmldsig-more#ecdsa-whirlpool [ RFC-to-be; Section 2.3.5 ] SignatureMethod
2007/05/xmldsig-more#kw-seed128 [ RFC-to-be; Section 2.6.6 ] EncryptionMethod
2007/05/xmldsig-more#md2-rsa-MGF1 [ RFC-to-be; Section 2.3.10 ] SignatureMethod
2007/05/xmldsig-more#md5-rsa-MGF1 [ RFC-to-be; Section 2.3.10 ] SignatureMethod
2007/05/xmldsig-more#MGF1 [ RFC-to-be; Section 2.3.9 ] SignatureMethod
2007/05/xmldsig-more#ripemd128-rsa-MGF1 [ RFC-to-be; Section 2.3.10] SignatureMethod
2007/05/xmldsig-more#ripemd160-rsa-MGF1 [ RFC-to-be; Section 2.3.10] SignatureMethod
2007/05/xmldsig-more#rsa-pss [ RFC-to-be; Section 2.3.9 ] SignatureMethod
2007/05/xmldsig-more#rsa-sha224 {Bad} [ RFC-to-be; Section 2.3.11 ] SignatureMethod
2007/05/xmldsig-more#rsa-whirlpool [ RFC-to-be; Section 2.3.5 ] SignatureMethod
2007/05/xmldsig-more#seed128-cbc [ RFC-to-be; Section 2.6.5 ] EncryptionMethod
2007/05/xmldsig-more#sha1-rsa-MGF1 [ RFC-to-be; Section 2.3.10 ] SignatureMethod
2007/05/xmldsig-more#sha224-rsa-MGF1 [ RFC-to-be; Section 2.3.10 ] SignatureMethod
2007/05/xmldsig-more#sha256-rsa-MGF1 [ RFC-to-be; Section 2.3.10 ] SignatureMethod
2007/05/xmldsig-more#sha3-224 [ RFC-to-be; Section 2.1.5 ] DigestAlgorithm
2007/05/xmldsig-more#sha3-224-rsa-MGF1 [ RFC-to-be; Section 2.3.10 ] SignatureMethod
2007/05/xmldsig-more#sha3-256 [ RFC-to-be; Section 2.1.5 ] DigestAlgorithm
2007/05/xmldsig-more#sha3-256-rsa-MGF1 [ RFC-to-be; Section 2.3.10 ] SignatureMethod
2007/05/xmldsig-more#sha3-384 [ RFC-to-be; Section 2.1.5 ] DigestAlgorithm
2007/05/xmldsig-more#sha3-384-rsa-MGF1 [ RFC-to-be; Section 2.3.10 ] SignatureMethod
2007/05/xmldsig-more#sha3-512 [ RFC-to-be; Section 2.1.5 ] DigestAlgorithm
2007/05/xmldsig-more#sha3-512-rsa-MGF1 [ RFC-to-be; Section 2.3.10 ] SignatureMethod
2007/05/xmldsig-more#sha384-rsa-MGF1 [ RFC-to-be; Section 2.3.10 ] SignatureMethod
2007/05/xmldsig-more#sha512-rsa-MGF1 [ RFC-to-be; Section 2.3.10 ] SignatureMethod
2007/05/xmldsig-more#whirlpool [ RFC-to-be; Section 2.1.4 ] DigestAlgorithm
2007/05/xmldsig-more#whirlpool-rsa-MGF1 [ RFC-to-be; Section 2.3.10] SignatureMethod
2009/xmlenc11#kw-aes-128-pad [XMLENC11] EncryptionMethod
2009/xmlenc11#kw-aes-192-pad [XMLENC11] EncryptionMethod
2009/xmlenc11#kw-aes-256-pad [XMLENC11] EncryptionMethod

2009/xmldsig11#dsa-sha256 [XMLDSIG11] SignatureMethod
2009/xmldsig11#ECKeyValue [XMLDSIG11] Retrieval type
2009/xmldsig11#DEREncodedKeyValue [XMLDSIG11] Retrieval type

2009/xmlenc11#aes128-gcm [XMLENC11] EncryptionMethod
2009/xmlenc11#aes192-gcm [XMLENC11] EncryptionMethod
2009/xmlenc11#aes256-gcm [XMLENC11] EncryptionMethod
2009/xmlenc11#ConcatKDF [XMLENC11] EncryptionMethod
2009/xmlenc11#mgf1sha1 [XMLENC11] SignatureMethod
2009/xmlenc11#mgf1sha224 [XMLENC11] SignatureMethod
2009/xmlenc11#mgf1sha256 [XMLENC11] SignatureMethod
2009/xmlenc11#mgf1sha384 [XMLENC11] SignatureMethod
2009/xmlenc11#mgf1sha512 [XMLENC11] SignatureMethod
2009/xmlenc11#pbkdf2 [XMLENC11] EncryptionMethod
2009/xmlenc11#rsa-oaep [XMLENC11] EncryptionMethod

2009/xmlenc11#ECDH-ES [XMLENC11] EncryptionMethod
2009/xmlenc11#dh-es [XMLENC11] EncryptionMethod

2010/xmlsec-ghc#generic-hybrid [GENERIC] Generic Hybrid
2010/xmlsec-ghc#rsaes-kem [GENERIC] Generic Hybrid
2010/xmlsec-ghc#ecies-kem [GENERIC] Generic Hybrid

2021/04/xmldsig-more#chacha20 [ RFC-to-be; Section 2.6.7 ] EncryptionMethod
2021/04/xmldsig-more#chacha20poly1305 [ RFC-to-be; Section 2.6.8 ] EncryptionMethod
2021/04/xmldsig-more#ecdsa-sha3-224 [ RFC-to-be; Section 2.3.6 ] SignatureMethod
2021/04/xmldsig-more#ecdsa-sha3-256 [ RFC-to-be; Section 2.3.6 ] SignatureMethod
2021/04/xmldsig-more#ecdsa-sha3-384 [ RFC-to-be; Section 2.3.6 ] SignatureMethod
2021/04/xmldsig-more#ecdsa-sha3-512 [ RFC-to-be; Section 2.3.6 ] SignatureMethod
2021/04/xmldsig-more#eddsa-ed25519ph [ RFC-to-be; Section 2.3.12 ] SignatureMethod
2021/04/xmldsig-more#eddsa-ed25519ctx [ RFC-to-be; Section 2.3.12 ] SignatureMethod
2021/04/xmldsig-more#eddsa-ed25519 [ RFC-to-be; Section 2.3.12 ] SignatureMethod
2021/04/xmldsig-more#eddsa-ed448 [ RFC-to-be; Section 2.3.12 ] SignatureMethod
2021/04/xmldsig-more#eddsa-ed448ph [ RFC-to-be; Section 2.3.12 ] SignatureMethod
2021/04/xmldsig-more#hkdf [ RFC-to-be; Section 2.7.2 ] AgreementMethod
2021/04/xmldsig-more#po1y305 [ RFC-to-be; Section 2.2.4 ] SignatureMethod
2021/04/xmldsig-more#siphash-2-4 [ RFC-to-be; Section 2.2.5 ] SignatureMethod
2021/04/xmldsig-more#x25519 [ RFC-to-be; Section 2.7.1 ] AgreementMethod
2021/04/xmldsig-more#xmss-sha2-192 [ RFC-to-be; Section 2.2.6 ] SignatureMethod
2021/04/xmldsig-more#xmss-sha2-256 [ RFC-to-be; Section 2.2.6 ] SignatureMethod
2021/04/xmldsig-more#xmss-shake256-192 [ RFC-to-be; Section 2.2.6 ] SignatureMethod
2021/04/xmldsig-more#xmss-shake256-256 [ RFC-to-be; Section 2.2.6 ] SignatureMethod
2021/04/xmldsig-more#xmssmt-sha2-192 [ RFC-to-be; Section 2.2.6 ] SignatureMethod
2021/04/xmldsig-more#xmssmt-sha2-256 [ RFC-to-be; Section 2.2.6 ] SignatureMethod
2021/04/xmldsig-more#xmssmt-shake256-192 [ RFC-to-be; Section 2.2.6] SignatureMethod
2021/04/xmldsig-more#xmssmt-shake256-256 [ RFC-to-be; Section 2.2.6] SignatureMethod

TR/1999/REC-xpath-19991116 [XPATH] Transform
TR/1999/REC-xslt-19991116 [XSLT] Transform
TR/2001/06/xml-exc-c14n# [XCANON] Canonicalization
TR/2001/06/xml-exc-c14n#WithComments [XCANON] Canonicalization
TR/2001/REC-xml-c14n-20010315 [CANON10] Canonicalization
TR/2001/REC-xml-c14n-20010315#WithComments [CANON10] Canonicalization
TR/2001/REC-xmlschema-1-20010502 [Schema] Transformocument

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, also the XML Security URIs registry located at:

https://www.iana.org/assignments/xml-security-uris/

all references to [RFC6931] will be changed to [ RFC-to-be ].

The registration policy for the registry will remain as Specification Required as defined in RFC8126.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist
2021-11-23
19 Al Morton Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Al Morton. Sent review to list.
2021-11-23
19 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder
2021-11-23
19 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder
2021-11-23
19 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Al Morton
2021-11-23
19 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Al Morton
2021-11-22
19 Rifaat Shekh-Yusef Request for Last Call review by SECDIR Completed: Ready. Reviewer: Rifaat Shekh-Yusef. Sent review to list.
2021-11-22
19 Niclas Comstedt Assignment of request for Last Call review by OPSDIR to Niclas Comstedt was rejected
2021-11-19
19 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2021-11-19
19 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2021-11-18
19 Tero Kivinen Request for Last Call review by SECDIR is assigned to Rifaat Shekh-Yusef
2021-11-18
19 Tero Kivinen Request for Last Call review by SECDIR is assigned to Rifaat Shekh-Yusef
2021-11-17
19 Cindy Morgan
The following Last Call announcement was sent out (ends 2021-12-15):

From: The IESG
To: IETF-Announce
CC: draft-eastlake-rfc6931bis-xmlsec-uris@ietf.org, rdd@cert.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  …
The following Last Call announcement was sent out (ends 2021-12-15):

From: The IESG
To: IETF-Announce
CC: draft-eastlake-rfc6931bis-xmlsec-uris@ietf.org, rdd@cert.org
Reply-To: last-call@ietf.org
Sender:
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
last-call@ietf.org mailing lists by 2021-12-15. 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 updates and corrects the IANA "XML Security URIs"
  registry that lists URIs intended for use with XML digital
  signatures, encryption, canonicalization, and key management.  These
  URIs identify algorithms and types of information.  This document
  also updates, corrects three errata against, and obsoletes RFC 6931.


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


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

The document contains these normative downward references.
See RFC 3967 for additional information:

    RFC 8439: ChaCha20 and Poly1305 for IETF Protocols (Informational - Internet Research Task Force (IRTF)
    RFC 8017: PKCS #1: RSA Cryptography Specifications Version 2.2 (Informational - Internet Engineering Task Force (IETF))




2021-11-17
19 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2021-11-17
19 Cindy Morgan Last call was requested
2021-11-17
19 Cindy Morgan IESG state changed to Last Call Requested from In Last Call
2021-11-17
19 Cindy Morgan Last call announcement was changed
2021-11-17
19 Cindy Morgan Last call announcement was generated
2021-11-17
19 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-19.txt
2021-11-17
19 (System) New version accepted (logged-in submitter: Donald Eastlake)
2021-11-17
19 Donald Eastlake Uploaded new revision
2021-11-16
18 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Niclas Comstedt
2021-11-16
18 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Niclas Comstedt
2021-11-15
18 Cindy Morgan IANA Review state changed to IANA - Review Needed
2021-11-15
18 Cindy Morgan
The following Last Call announcement was sent out (ends 2021-12-13):

From: The IESG
To: IETF-Announce
CC: draft-eastlake-rfc6931bis-xmlsec-uris@ietf.org, rdd@cert.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  …
The following Last Call announcement was sent out (ends 2021-12-13):

From: The IESG
To: IETF-Announce
CC: draft-eastlake-rfc6931bis-xmlsec-uris@ietf.org, rdd@cert.org
Reply-To: last-call@ietf.org
Sender:
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
last-call@ietf.org mailing lists by 2021-12-13. 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 updates and corrects the IANA "XML Security URIs"
  registry that lists URIs intended for use with XML digital
  signatures, encryption, canonicalization, and key management.  These
  URIs identify algorithms and types of information.  This document
  also updates, corrects three errata against, and obsoletes RFC 6931.






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



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




2021-11-15
18 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2021-11-15
18 Roman Danyliw Nits to fix with IETF LC: https://mailarchive.ietf.org/arch/msg/saag/vdtpqIxasjfJ5iohB8BZE7EMo2Q/
2021-11-15
18 Roman Danyliw Last call was requested
2021-11-15
18 Roman Danyliw Last call announcement was generated
2021-11-15
18 Roman Danyliw Ballot approval text was generated
2021-11-15
18 Roman Danyliw Ballot writeup was generated
2021-11-15
18 Roman Danyliw IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2021-11-14
18 (System) Changed action holders to Roman Danyliw (IESG state changed)
2021-11-14
18 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-11-14
18 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-18.txt
2021-11-14
18 (System) New version approved
2021-11-14
18 (System) Request for posting confirmation emailed to previous authors: Donald Eastlake
2021-11-14
18 Donald Eastlake Uploaded new revision
2021-11-07
17 (System) Changed action holders to Donald Eastlake, Roman Danyliw (IESG state changed)
2021-11-07
17 Roman Danyliw IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested
2021-11-07
17 (System) Changed action holders to Roman Danyliw (IESG state changed)
2021-11-07
17 Roman Danyliw IESG process started in state Publication Requested
2021-11-07
17 Roman Danyliw AD Review: https://mailarchive.ietf.org/arch/msg/saag/MQffU2ntJEHhKPU-bJ-pdlVmNqc/
2021-11-02
17 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-17.txt
2021-11-02
17 (System) Forced post of submission
2021-11-02
17 (System) Request for posting confirmation emailed to previous authors: Donald Eastlake
2021-11-02
17 Donald Eastlake Uploaded new revision
2021-10-28
16 Roman Danyliw Inquiry send to W3C on 10/15/2021 to confirm that it is ready prior to IETC LC
2021-07-09
16 Roman Danyliw Changed consensus to Yes from Unknown
2021-07-09
16 Roman Danyliw Intended Status changed to Proposed Standard from None
2021-07-09
16 Roman Danyliw Stream changed to IETF from None
2021-07-09
16 Roman Danyliw Shepherding AD changed to Roman Danyliw
2021-06-25
16 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-16.txt
2021-06-25
16 (System) New version approved
2021-06-25
16 (System) Request for posting confirmation emailed to previous authors: Donald Eastlake
2021-06-25
16 Donald Eastlake Uploaded new revision
2021-06-15
15 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-15.txt
2021-06-15
15 (System) New version accepted (logged-in submitter: Donald Eastlake)
2021-06-15
15 Donald Eastlake Uploaded new revision
2021-04-03
14 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-14.txt
2021-04-03
14 (System) New version approved
2021-04-03
14 (System) Request for posting confirmation emailed to previous authors: Donald Eastlake
2021-04-03
14 Donald Eastlake Uploaded new revision
2020-12-27
13 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-13.txt
2020-12-27
13 (System) New version approved
2020-12-27
13 (System) Request for posting confirmation emailed to previous authors: Donald Eastlake
2020-12-27
13 Donald Eastlake Uploaded new revision
2020-06-28
12 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-12.txt
2020-06-28
12 (System) New version approved
2020-06-28
12 (System) Request for posting confirmation emailed to previous authors: Donald Eastlake
2020-06-28
12 Donald Eastlake Uploaded new revision
2020-01-02
11 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-11.txt
2020-01-02
11 (System) New version approved
2020-01-02
11 (System) Request for posting confirmation emailed to previous authors: Donald Eastlake
2020-01-02
11 Donald Eastlake Uploaded new revision
2019-07-02
10 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-10.txt
2019-07-02
10 (System) New version approved
2019-07-02
10 (System) Request for posting confirmation emailed to previous authors: Donald Eastlake
2019-07-02
10 Donald Eastlake Uploaded new revision
2019-03-26
09 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-09.txt
2019-03-26
09 (System) New version approved
2019-03-26
09 (System) Request for posting confirmation emailed to previous authors: Donald Eastlake
2019-03-26
09 Donald Eastlake Uploaded new revision
2018-10-02
08 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-08.txt
2018-10-02
08 (System) New version approved
2018-10-02
08 (System) Request for posting confirmation emailed to previous authors: Donald Eastlake
2018-10-02
08 Donald Eastlake Uploaded new revision
2018-04-04
07 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-07.txt
2018-04-04
07 (System) New version approved
2018-04-04
07 (System) Request for posting confirmation emailed to previous authors: Donald Eastlake
2018-04-04
07 Donald Eastlake Uploaded new revision
2017-09-29
06 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-06.txt
2017-09-29
06 (System) New version approved
2017-09-29
06 (System) Request for posting confirmation emailed to previous authors: Donald Eastlake
2017-09-29
06 Donald Eastlake Uploaded new revision
2017-09-29
05 (System) Document has expired
2017-03-28
05 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-05.txt
2017-03-28
05 (System) New version approved
2017-03-28
05 (System) Request for posting confirmation emailed to previous authors: Donald Eastlake
2017-03-28
05 Donald Eastlake Uploaded new revision
2016-09-26
04 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-04.txt
2016-09-26
04 Donald Eastlake New version approved
2016-09-26
04 Donald Eastlake Request for posting confirmation emailed to previous authors: none-chairs@ietf.org, "Donald E. Eastlake 3rd"
2016-09-26
04 (System) Uploaded new revision
2016-04-04
03 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-03.txt
2015-09-26
02 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-02.txt
2015-03-29
01 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-01.txt
2014-10-06
00 Donald Eastlake New version available: draft-eastlake-rfc6931bis-xmlsec-uris-00.txt