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 |