Re: [COSE] [Suit] draft-atkins-suit-cose-walnutdsa
Derek Atkins wrote: >> And the other two are Expert Review anyway, no specification required! >> You are even listed as one of the experts for COSE Key Types :-) > Yes, I know I am one of the experts for these registries. However, I > feel I must recuse myself from approval of these. Yes, obviously, but the point is that you will know how to ask nicely :-) >> You could also ask for early allocation via the COSE WG, but that >> probably requires the document to be adopted first! > Does it? Or does the WG just need to approve of the document going > through any of the publication processes? If the document isn't adopted, then I don't think the WG chairs can ask the AD to approve. I think that adoption is the only required step; your document could take awhile to progress. IANA will check back on progress for the early allocation, to make sure the document is still of interest. >> That's what I would do: just ask for the values via Expert Review, and >> live for now, with the a five-bye (encoded) COSE Algorithm code, if >> your market need is urgent. > Yes, I could just request the entries in the registry. However, I am > trying to be a good netizen; I want to have a document that people can > look at to understand what the registry items mean. While you don't have to provide a specification for Expert Review, I think that if you *do* that it will get recorded. If you later on get a 1-byte code allocated then, it's code complexity, but it's not too terrible, I think. At some point, your constrained devices will only use the 1-byte code, and your non-constrained devices will continue to be tolerant of both. >> Derek Atkins wrote: > We have customers who are >> looking to use this technology today, so we > would like to do it in a >> standard way that others could understand. > Personally, I'm fine >> with an Informational (instead of Standards-track) > publication if >> that would make people happier. Even so, the RFC Editor > would still >> require approval from this WG as it is within their (the > WG's) area. >> >> yes, if you went ISE, which would still take awhile. > I am fine going through the ISE, however I suspect that the IESG in > their conflict review would then go and ask this WG about it. So I > wanted to bring it up here, first. What is your definition of > "awhile"? Given the conflict review and the typical length of the RFC editor Production queue, I would say you are looking at a year before AUTH48, but the early allocation could occur much sooner. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
Re: [COSE] Review of draft-ietf-cose-rfc8152bis-struct for WGLC of rfc8152bis drafts
Comments inline. -Original Message- From: COSE On Behalf Of Matthew A. Miller Sent: Tuesday, July 30, 2019 9:17 AM To: cose Subject: [COSE] Review of draft-ietf-cose-rfc8152bis-struct for WGLC of rfc8152bis drafts [ Posting as an individual ] This is my review of draft-ietf-cose-rfc8152bis-struct. Overall I think the document is nearly ready, with what I consider editorial issues (some larger than others) that ought to be addressed one way or another. I note that I have not tried to verify the examples in -rfc8152bis-struct, though the diagnostic values all seem correct to me (where a visual inspection is possible). [JLS] The good news is that as long as I do not touch them, the examples were pulled directly from the examples website as they were automatically generated for RFC 8152. Thank you again, Jim, for undertaking this document. ## Minor Questions/Concerns ## * The term "context" is used throughout as an information set and/or configuration not discretely encoded in the protocol, but is never explicitly defined. I think it important to define, especially as abbreviated counter signatures wholly depend on inferred parameters. [JLS] Proposed text: Context is used throughout the document to represent information that is not part of the COSE message. Information which is part of the context can come from several different sources including: Protocol interactions, associated key structures and program configuration. Context should generally be included in the cryptographic configuration, for more details see . * Further with abbreviated counter signatures, I think the original text in RFC 8152 Appendix A.2 did a bit better to be explicit on what was implicit, and that CounterSignature0 applied to more than encrypted data. I suggest rewording the first paragraph to something like the following: """ Abbreviated countersignatures were designed primarily to deal with the problem of having group encrypted messaging, but still needing to know who originated the message. The object was to keep the countersignature as small as possible while still providing the needed security. For abbreviated countersignatures, there is no provision for any protected attributes related to the signing operation. Instead, the parameters for computing or verifying the abbreviated countersignature are inferred from the same context used to describe the encryption, signature, or MAC processing. """ [JLS] Looks good - done. * The sections that describe generically describe algorithm classes (Sections 9 through 13), to me, break with the flow of the document and can seem to imply the actual algorithms are still defined herein. I think it would be worth making them all subsections under a "Algorithm Classes in Use" (or a better title), with a short paragraph stating the following describe categories of algorithms and the requirements or restrictions placed on algorithms that apply. [JLS] This makes a good deal of sense to me. Even if it means that I need to go and refresh all of the references in other documents. For now I have used the section title "Taxonomy of Algorithms used by COSE" although Classification might be a less esoteric term. Text for the section is currently In this section, a taxonomy of the different algorithm types that can be used in COSE is laid out. This taxonomy should not be considered to be exhaustive as there are new algorithm structures that could be found or are not known to the author. ## Nits ## * The reference to I-D.ietf-cbor-cddl should be updated to RFC 8610. [JLS] Done * In Section 1.2 "Changes from RFC8152", "standalong" should be "standalone". [JLS] Done. * Table 2 ought to be explicitly changed to`[[ this document ]]` to aid the RFC Editor. [JLS] Done. * In Section 4.4 "Signing and Verification Process", the CDDL for `Sig_structure` is missing "CounterSignature0" as an option for `context`. [JLS] Done. * In Section 5 "Counter Signatures", paragraph 2, the word "oppose" should be "opposed" in the sentence "It should be noted as oppose to attesting to the unencrypted data." [JLS] Done. * In Section 5.2 "Abbreviated Countersignatures", first paragraph, "orginated" should be "originated". [JLS} Done * In Section 6.1.1 "Content Key Distribution Methods", the "key transport" and "passwords" entries have a note on "[no] algorithms are defined in this document". I think it enough to strike this last sentence completely from each, but can see a case for saying "[no] algorithms are defined in [I-D.ietf-cose-rfc8152bis-algs]" instead. [JLS] Eliminated for key transport, since RSA algorithms now exist. Changed the language on passwords to " As of when this document was published, no password algorithms have been defined." * In Section 10 "Message Authentication Code (MAC) Algorithms", the penultimate paragraph should have
Re: [COSE] [IANA #1148103] Early Code Point Assignments
As a Chair, I approve of this early assignment. - m Matthew A. Miller On 19/07/31 09:51, Sabrina Tanamal via RT wrote: > Hi Jim, all, > > Before we can make RFC 7120 early allocations for the registrations listed > below, we need approval from a chair and an AD. > > Because these are Standards Action with Expert Review registries, we'll have > to ask the designated experts for approval as well. > > Best regards, > > Sabrina Tanamal > Senior IANA Services Specialist > > On Mon Jul 29 14:52:02 2019, i...@augustcellars.com wrote: >> Following the meeting in Montreal where I asked for the ability to do early >> point assignment for documents in the working group and got permission, >> these are the code points that I am assigning. I am only assigning points >> that I know people are asking for now, some points will be setup later. >> >> For draft-ietf-cose-x509 (https://tools.ietf.org/html/draft-ietf-cose-x509): >> >> Table COSE Header Parameters >> https://www.iana.org/assignments/cose/cose.xhtml#header-parameters >> >> Name Value >> x5bag32 >> x5chain 33 >> x5t 34 >> x5u 35 >> >> For draft-ietf-cose-hash-algs >> (https://tools.ietf.org/html/draft-ietf-cose-hash-algs): >> >> Table COSE Algorithms >> https://www.iana.org/assignments/cose/cose.xhtml#algorithms >> >> Name Value >> >> SHA-1-14 >> SHA-256/64 -15 >> SHA-256 -16 >> SHA-384 -43 >> SHA-512 -44 >> SHA-512/256 -17 >> SHAKE128 -18 >> SHAKE256 -45 >> >> >> Jim >> >> > ___ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
[COSE] [IANA #1148103] Early Code Point Assignments
Hi Jim, all, Before we can make RFC 7120 early allocations for the registrations listed below, we need approval from a chair and an AD. Because these are Standards Action with Expert Review registries, we'll have to ask the designated experts for approval as well. Best regards, Sabrina Tanamal Senior IANA Services Specialist On Mon Jul 29 14:52:02 2019, i...@augustcellars.com wrote: > Following the meeting in Montreal where I asked for the ability to do early > point assignment for documents in the working group and got permission, > these are the code points that I am assigning. I am only assigning points > that I know people are asking for now, some points will be setup later. > > For draft-ietf-cose-x509 (https://tools.ietf.org/html/draft-ietf-cose-x509): > > Table COSE Header Parameters > https://www.iana.org/assignments/cose/cose.xhtml#header-parameters > > Name Value > x5bag 32 > x5chain 33 > x5t 34 > x5u 35 > > For draft-ietf-cose-hash-algs > (https://tools.ietf.org/html/draft-ietf-cose-hash-algs): > > Table COSE Algorithms > https://www.iana.org/assignments/cose/cose.xhtml#algorithms > > Name Value > > SHA-1 -14 > SHA-256/64-15 > SHA-256 -16 > SHA-384 -43 > SHA-512 -44 > SHA-512/256 -17 > SHAKE128 -18 > SHAKE256 -45 > > > Jim > > ___ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
