Re: [COSE] Stephen Farrell's Discuss on draft-ietf-cose-msg-19: (with DISCUSS and COMMENT)
Jim Schaad <ietf@augustcellars.com> Tue, 11 October 2016 03:27 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56DA12944E; Mon, 10 Oct 2016 20:27:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.897
X-Spam-Level:
X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlhAhKpmms_X; Mon, 10 Oct 2016 20:27:46 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9317129440; Mon, 10 Oct 2016 20:27:45 -0700 (PDT)
Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 10 Oct 2016 20:41:00 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Stephen Farrell' <stephen.farrell@cs.tcd.ie>, 'The IESG' <iesg@ietf.org>
References: <147506634324.16628.6590617577304586745.idtracker@ietfa.amsl.com> <076601d21d38$1e5162f0$5af428d0$@augustcellars.com> <21d32017-8dc8-5971-ef5c-b2083cdb6848@cs.tcd.ie>
In-Reply-To: <21d32017-8dc8-5971-ef5c-b2083cdb6848@cs.tcd.ie>
Date: Mon, 10 Oct 2016 20:27:37 -0700
Message-ID: <091901d2236f$6be6de40$43b49ac0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQM0sPyC3CV9N63JinowM6PtUp5t4AEQq3b7AkHo5xudwufnoA==
Content-Language: en-us
X-Originating-IP: [24.21.96.37]
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/IySn6segwvUwLAKgddhZGfeZanc>
Cc: cose-chairs@ietf.org, cose@ietf.org, draft-ietf-cose-msg@ietf.org, goran.selander@ericsson.com
Subject: Re: [COSE] Stephen Farrell's Discuss on draft-ietf-cose-msg-19: (with DISCUSS and COMMENT)
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Oct 2016 03:27:50 -0000
I have just published a draft -20 of the document. I believe that this document addresses all of the issues that have been raised by the IESG. This document does not address the blocking IANA issues. I should have these addressed and a new version published by the start of next week. Jim > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Monday, October 03, 2016 3:16 AM > To: Jim Schaad <ietf@augustcellars.com>; 'The IESG' <iesg@ietf.org> > Cc: cose-chairs@ietf.org; goran.selander@ericsson.com; cose@ietf.org; draft- > ietf-cose-msg@ietf.org > Subject: Re: [COSE] Stephen Farrell's Discuss on draft-ietf-cose-msg-19: (with > DISCUSS and COMMENT) > > > Hi Jim, > > On 03/10/16 06:36, Jim Schaad wrote: > > Stephen, > > > > Answers and questions interspersed below along with some - yes I need > > to do that. I should be able to get to those in the first half of > > this week. Am building a github branch for responses if you want to > > look at things as we go along. > > Good stuff. Some answers below where they seem useful. > > > > > Jim > > > > > >> -----Original Message----- From: Stephen Farrell > >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, September 28, > >> 2016 5:39 AM To: The IESG <iesg@ietf.org> Cc: > >> draft-ietf-cose-msg@ietf.org; Goeran Selander > >> <goran.selander@ericsson.com>; cose-chairs@ietf.org; > >> goran.selander@ericsson.com; cose@ietf.org Subject: Stephen > >> Farrell's Discuss on draft-ietf-cose-msg-19: (with DISCUSS and > >> COMMENT) > >> > >> Stephen Farrell has entered the following ballot position for > >> draft-ietf-cose-msg-19: Discuss > >> > >> When responding, please keep the subject line intact and reply to > >> all email addresses included in the To and CC lines. (Feel free to > >> cut this introductory paragraph, however.) > >> > >> > >> Please refer to > >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more > >> information about IESG DISCUSS and COMMENT positions. > >> > >> > >> The document, along with other ballot positions, can be found > >> here: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ > >> > >> > >> > >> ---------------------------------------------------------------------- > >> > >> > DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> > >> > >> > I think this is a fine design and well documented, (though > >> long) and I'm sure we'll clear up the points below quickly enough. > >> Some of them may need some discussion but others are mostly > >> checking. > >> > >> (1) general: I think the inclusion of CDDL is an error here and > >> we'd be better off having someone (if interested) generate the CDDL > >> schema stuff later on when/if CDDL is standardised/stabilised. > >> Including it now creates the potential for breakage unnecessarily > >> IMO. However, the WG did explicitly discuss iirc, so this is just a > >> personal comment that I'm also in the rough on inclusion of CDDL in > >> this spec. (As an example, for someone not familiar with CDDL, the > >> inclusion of fragments interspersed in the text is distracting and > >> potentially puzzling when one gets to the end of section 3.) > >> However, I do think there are places where the CDDL is effectively > >> normative despite what is said in the introduction, the ones I've > >> spotted are below. (Happy to chat about 'em as I may be mistaken.) > >> I also wondered if one could really implement this if all the CDDL > >> was removed from the text, which is what I think would be required > >> if CDDL were really to be informative. Anyway the places I think > >> some more text may be needed are: > > > > > > I build a version of the document with no CDDL, I have added some > > pointers to the use of "/" and "[+ FOO]" to the CDDL preview section > > at the top of the document. I have also identified the structures > > Sig_structure and Enc_structure like I did the Mac_structure in the > > text. (Also found a COSE_Encrypt that should have been a > > COSE_Encrypt0.) > > > >> > >> (1.1) table 2: As-is the value type column seems to me to make CDDL > >> normative. I don't see the natural language version that you said > >> would be normative. > >> > >> (1.2) 4.4, 2nd list point 1: the use of Sig_structure makes the > >> CDDL normative. (Same with the use in 4.5 and Enc_structure in > >> 5.3.) > >> > >> (1.3) 7.1, the key_ops value is only specified in CDDL, in Table 3. > >> (It is well- defined below the table in text though, so this one's > >> borderline.) > > > > The description for key_ops points to Table 3, so I think it is fully > > supplied. > > > >> > >> (1.4) 11.2: it's not clear to me that a reader knows how to handle > >> decoding of the two optional fields at the end (other and > >> SuppPrivInfo) without looking at the CDDL. Can you explain? (That > >> might be just my ignorance of CBOR, but wanted to check.) > > > > I am not sure that I would know how to do it even with CDDL, however > > in this case that is a moot question as this structure is only > > encoded and never transmitted or decoded. > > > > Will also note, that you have better eyes than me as I do not see two > > optional fields at the end. I see one optional field at the end of > > two different arrays, so that would be a CBOR ignorance I think. > > I'd say we should be able to kill this discuss point easily > with the changes you're making. > > > > >> > >> (2) 3.1, alg: so you're disallowing a setup where the kid alone > >> identifies the key and algorithm to the recipient? That is used in > >> some IETF protocols (OSPF iirc) so rhat's a pity, and will in > >> those (maybe less common) cases consume a few bytes that could > >> otherwise be saved. I think, but am not sure, that the WG already > >> discussed this, but if not, maybe worth a thought? (Or even a 2nd > >> thought:-) And appendix A.1 is really puzzling - as it provides > >> instructions for how to not follow a MUST in the body of the > >> document. > > > > I have come around to the feeling that the algorithm needs to be part > > of the value that is being authenticated as part of all of the > > messages. > > Is that just a feeling of yours or are we confident it > represents WG consensus? (Honest question - I just don't > recall.) > > > This being the case, the only what that it can be enforced > > is to make the algorithm be a part of the protected attributes. In > > my mind the cost of the 2 bytes for this purpose seems to be > > sufficiently small that including it does not seem to be a large > > burden. > > > > There were several people in the IoT world who felt as you that one > > could have an implicit algorithm and they did not want to spend the > > two bytes for the purpose of including it in the AEAD. This being > > the case, I did provide the appendix to tell how to do this. I > > expect that people are going to do this and not following the > > guidance that was provided about making sure that the algorithm is > > authenticated. > > Right, but isn't that then pretty much an RFC6919 "MUST, but > we know you (sometimes) won't"? I just don't see how that helps > with interop. > > I do agree that it's conceivable that the lack of an alg in > a protocol could lead to vulnerabilities. However, there are > clearly cases where a protocol can be secure without an > explicit alg, and we know that folks will do that optimisation > sometimes, so I think the most that'd be right is a SHOULD, > but likely a MAY is even better. (If however, there's a clear > WG consensus to take the RFC6919 route, then I'll get out of > the way, but with an "I told you so" in my back pocket;-) > > > > >> > >> (3) 7.1: key_op 8, "derive bits" - I don't think this usage is > >> clear enough, can you say what's meant here? > > > > Derive bits was added to the JOSE documents in response to the W3C > > WebCrypto work where they wanted to be able to control that something > > could derive bits but not derive a key. These were initially not > > present in this document but was added by request so that it would > > match what the JWK document had. The description in JWK is "derive > > bits not to be used as a key". Does that read better? If so I can > > change this. > > That is clearer yes. Maybe add a pointer to the JWK doc as well? > I'm not convinced of the utility myself though but so long as > it's clearly described then that'll sort this discuss point. > > > > >> > >> (4) Why not make deterministic ECDSA a MUST? 8.1.1 says: > >> "Applications that specify ECDSA should evaluate the ability to get > >> good random number generation and require deterministic signatures > >> where poor random number generation exists." I don't think that is > >> sufficiently clear, nor realistic, and I don't recall this being > >> discussed on the list (sorry if I'm forgetting) and bad random > >> values are a killer flaw here that has happened in the wild. > > > > It is not clear to me that many, if any, current packages support the > > concept of doing deterministic ECDSA. > > But they don't to COSE either so I'm not clear that's a good > argument unless there's evidence that crypto libraries likely > to be used for COSE won't include deterministic ECDSA. (That > last would be a surprise given that deterministic is clearly > superior.) > > > If this case it seems to be > > odd that we would require it. I can do some research to figure this > > out. > > Cool. Be interested in what you find. > > > > >> > >> (5) Table 6, is this 25519 or 448? Where does it say? Sorry if I'm > >> being dumb here, but I don't see where you say which curve is > >> specified, the definition of 'crv' says defined for this alg which > >> I assume means listed in Table 6. > > > > The value of 'crv' is defined in table 22. The same algorithm is > > used to identify all of the curves. > > I'm still not getting that but didn't yet re-read the doc. I will > as we go so let's punt on this for the moment. > > > > >> > >> (6) section 10: why MUST the kty values be present always? That > >> seems unnecessary in some contexts and I don't get a security > >> reason why it's needed e.g. if there's an alg id somewhere - can > >> you explain? I can see folks omitting this leading to interop > >> problems for not useful reasons. (Same comment applies in other > >> cases where kty is a MUST, e.g. 12.1.2, 12.2.1.) > > > > This follows what JOSE did in in RFC 7517 (JWK). I might, or might > > not, agree with you that specifying an algorithm would be sufficient. > > Consider one of the ECDH-ES variants. It is defined to work with > > keys of the key type 'EC2' as well as 'OKP'. These two key types > > have different sets of required parameters but some of them overlap. > > Specifically, 'x' is in both but 'y' is only in one of them. In this > > case the additional parameter of 'crv' could also be used to > > distinguish them but a generic piece of code looking only at the > > algorithm would not have enough detail. > > Hmm. Still not convinced, but I'll look again as we go. This is > I guess similar to the issue with the alg as a MUST in that we > can be pretty sure some folks will ignore that MUST I think. > > > > >> > >> (7) section 11: given that we know people will use human memorable > >> secrets, why have you not defined codepoints for PBES2 (or the more > >> commonly supported?) PBDKF2? I'm fine if there's a reason, or even > >> if it was discussed by the WG, but just wanted to check as I'd > >> worry that folks will use the ones defined here with human > >> memorable secrets no matter what the spec says so giving 'em > >> something more tailored might be better. (OTOH, one could argue > >> that making this apparent might be worse too I guess.) > > > > This was part of the secondary algorithm draft which the WG decided > > not to do as part of the 'we are not going to do RSA at this time'. > > I expect that I will write an individual draft to cover these. It > > was also not clear to me that small devices were going to be using > > this type of secret to start with in any event. > > Fair enough. Consider this bit sorted. > > > > >> > >> (8) 12.4: Why is no ephemeral-ephemeral (E-E) variant supported? > >> Some protocols will allow for that and it seems wrong to disallow > >> it when it could relatively easily be supported. For some > >> applications where content is dealt with in store-and-forward mode, > >> there may be situations (e.g. provisioning, "introduction") where > >> E-E could be used. As-is, applications wanting that will have to > >> hack the recipient DH-public into a home-grown structure (or use > >> one of the COSE_Key labels from Table 19) and then treat that as > >> ES-DH. That seems likely to lead to non-interop or security errors > >> being made. I'd be fine if you even said how to re-use the > >> structures currently defined for E-E btw and didn't introduce new > >> structures. > > > > See https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe/ > > for how this is being addressed. > > Hmm. No 25519? Odd that. But fair enough I suppose if it's being > handled somewhere. > > > > >> > >> (9) 16.4: I'm not sure expert review is right here. What if the > >> expert is asked to add SM2/SM4 while there is still no widely > >> available non-Chinese text to describe those? I think the expert > >> ought enforce a "specification required" rule at least and maybe > >> more. (And ought never allow an algorithm with no specification > >> publicly available.) > > > > This view was advanced by several people in the WG as well. My worry > > about this position is that it might encourage point squatting. I > > cannot respond for other experts, but I would ask for a usable > > description of the algorithm. If I was not familiar I would also > > request either additional review from CFRG and/or conference papers > > on the algorithm. If it was not a publicly available specification, > > I would then assign a "non-optimal" point. My expectation is that > > there are going to be more small networks of IoT devices than there > > are for TLS systems. This means that it is more likely that > > localized algorithms may be desired. > > Yeah but desired-by-someone != desirable-for-the-Internet :-) > > I would worry about less well reviewed lightweight crypto in this > space - that'll be attractive for implementers/vendors but might > not be a good plan. > > > > > I am not against raising the level to specification required, but > > would worry about point squatting. > > > > If this is not "expert review" what do you believe would be a better > > requirement? I do not believe this should be dumped on either the > > IESG or CFRG. > > I think expert review with specification required is maybe right > with the guidance tightened up along the lines you state above. > (But see below.) > > > > >> > >> (10) 16.4 (and elsewhere maybe) I think this registry is missing a > >> column - as is being done in the TLS WG, I think there should be a > >> column saying if the IETF is happy enough with an algorithm and > >> that getting a "Y" in that ought require standards action. (Or some > >> similar scheme.) I don't think the standards-track range of > >> codepoints is enough here, e.g. at some time we will want to > >> deprecate things, and at other times we may want to define things > >> for the future on the standards-track but not (yet) recommend their > >> use. The last bullet in 16.11 does help here, but I'd argue that > >> we need to do more to protect the expert (and implementers) from > >> the trickle of vanity/national algorithms/curves that are always > >> being proposed. > > > > I would not object to doing this. While I don't know if the TLS > > experiment on this is going to work, I don't have any problems with > > participating in the same experiment here as well. > > Great. If we do that then I think the expert's job can be easier > as it'll be much clearer what the IETF likes. (And that'd sort > my discuss point #9 too.) > > > > > I am not sure what we should say for deprecation of algorithms here > > should be, they are going to live for a long time and new systems > > will probably ship with the same algorithms as long as they need to > > interoperate. Consider the lighting use case that is being fought > > over in ACE right now. You cannot put a new light bulb in that uses > > a different algorithm unless you are willing to start broadcasting > > two messages. This is probably going to lead to very slow > > deprecation over time. > > Well, it's always slow. But I think if we can clearly see from the > registry what the IETF currently likes, then implementers should > have an easier time. I'd have no objection if the extra column > wasn't just a binary y/n, but I think it's hard to come up with > good semantics for anything else. (Where "y" just means that the > IETF currently likes the registry entry.) > > > > > > >> > >> > >> ---------------------------------------------------------------------- > >> > >> > COMMENT: > >> ---------------------------------------------------------------------- > >> > > I'll go over these later if that's ok, gotta do another thing > right now;-) Please ping me if you need a response before you > do edits though. > > Cheers, > S. > > > >> > >> > >> > >> > - 1.4: the 2nd last paragraph is unclear to me. Probably just needs > re-phrasing. > > > > Which is unclear, the problem or the action? > > > >> > >> - 1.5: I'd add a reference to RFC5116. > > > > Reasonable and done. > > > >> > >> - 3.1, crit: The statement that security libraries or application > >> code can handle this is odd - isn't that an API requirement? (I'm > >> not objecting, but it's odd.) > > > > I agree that this is an API requirement. > > > >> > >> - 3.1, "content type" is the space there intended? If so, maybe > >> add quotes or a comma or something to disambiguate the name and > >> descriptive text? Same for other multi-word names here. > > > > Given that this is the second person suggesting this (also in Gen-Art > > review). I am going to add a colon to deal with this. > > > >> > >> - 3.1, "all the keys may need to be checked" - really? Or do you > >> mean all the keys associated with this kid? > > > > I thought that this said keys associated with the kid. Did you not > > read it this way? If not then I will look at re-phrasing. > > > >> > >> - 3.1, IV/Partial IV - I think it's an error to define this here. > >> What if some algorithm can't use that kind of (0|partial)^IV but > >> needs something else instead? Shouldn't all mechanism for handling > >> IVs be defined by the algorithm/mode? (This isn't a discuss because > >> I can't think of a good counter example and there'd be other ways > >> around the problem too probably.) > > > > I was originally going to make IV an algorithm specific parameter > > rather than a common parameter. It was just so common that it seemed > > to be better to only define it once. Any algorithm that needed > > different behavior could easily define an algorithm specific > > parameter for IV work instead. So as you say an easy work around > > exists if needed. > > > >> > >> - 4.1: signingTime is often needed with signatures. Isn't that > >> common enough to want to define a way to do it, as an option? > > > > There was a signingTime parameter in the original document. The WG > > decided that it was not going to be needed enough at this point in > > time to have it defined now. Additionally, there were some arguments > > over the format of the time field as some systems support a real > > clock and some only support a relative clock to when they were last > > started up. > > > >> > >> - 4.1: If I sign with a private key corresponding to a 2047 or 2049 > >> bit RSA public key modulus, then is it clear what to put where in > >> the signature bstr? (Yes, that'd be dumb, but I wonder is what to > >> do well enough defined, as I don't think you can rule it out in all > >> cases.) Since you don't include RSA here I guess it's ok to skip > >> this, but maybe you need to say that such issues need to be handled > >> in the definition of signature algs. > > > > I would say that this is not real, but I looked carefully at this > > when doing the EdDSA algorithms. I will look at this and see if I > > cannot find some way to state this either generally or specifically. > > > >> > >> - 4.3: "cannot bleed" isn't clear enough maybe, give an example > >> perhaps where the decoder can fail to disambiguate a boundary? > > > > I'll look at this and see if I cannot come up with better language. > > However, there are no decode issues here. > > > >> > >> 4.4, last para: I disagree that one must (even lowercase must) > >> check the signing identity. That's application behaviour and > >> should be stated here in such concrete terms. At least s/must > >> also/may also want to/ > > > > What if it is s/one must also/the application must also/ > > > >> > >> (Note - the above were comments on -18, but also seem to work based > >> on -19. Subsequent comments are on -19.) > >> > >> - 7.1: "starting at the same base IV" - are you missing "and > >> incrementing" or something? Otherwise I think this seems unclear. > > > > The "and incrementing" to me was implied in the first paragraph with > > the fact that this is intended to be used with the "partial IV" > > parameter. I'll see if I can make this cleaner. > > > >> > >> - 8.2.1: is the phrasing of the 1st para right? would it be better > >> to say that the value of a key for EdDSA MUST NOT be used for ECDH > >> and vice-versa. (Or maybe points instead of keys?) > > > > Yeah, reads messy - let me think about it. > > > >> > >> - 8.2.1: you need a reference for batch signing. (Or could it be > >> omitted?) > > > > I kept asking for one in the EdDSA document and never got one there, > > so I don't have one to push in here. > > > >> > >> - section 9: I think it'd be good to be clearer about the strength > >> of truncated MAC values. (And I can't recall the right thing to say > >> off the top of my head:-) > > > > When I was doing research about this, I could not find any solid > > results on truncated MAC values that people seemed to agree on. Most > > people seem to look at this as just a birthday attack so I would need > > to do more searching to find something useful. > > > >> > >> - 11: RFC2898 is about to be obsoleted by [1]. I suspect it'd be > >> better to refer to the draft as that should be published soon. > >> (Same for RFC3447 btw.) > > > > Will do. > > > >> > >> [1] https://datatracker.ietf.org/doc/draft-moriarty-pkcs5-v2dot1/ > >> > >> - 12.4: Why "OKP"? And saying there's no "simple way" to do point > >> validation seems fairly opaque, a reference there or explanatory > >> text would be good. (Ah, it's in section 13, maybe shuffle the text > >> or include a pointer.) Octet key pair doesn't seem like that good a > >> name to me btw. > > > > I copied "OKP" from draft-ietf-jose-cfrg-curves. Since it has > > already gone through there I am reluctant to be different. > > > > I will re-look at the order and make sure that there is something > > lying around for the acronym expansion. > > > >> > >> - 12.5: The 1st para seems wrong. (Or at least is unclear to me.) > >> "Encrypted with <foo> and <bar>" seems ambiguous anyway, does it > >> mean double encryption or two parallel ciphertexts? (I assume the > >> former.) What's the algebraic thing you're trying to explain? > >> It'd be good to provide that for such relatively complex operations > >> I think. Is this what you mean? > >> > >> KW(KDF(DH-shared),CEK) > > > > Yes that is the formula and yes it makes sense to document it in that > > manner. > > > >> > >> - Table 22: The EC2 or OKP value is fixed per curve and the > >> cryptographic function being performed so seems unnecessary. Do you > >> really need it so? Why? (I'm not buying that some future form of > >> ECC might mean this is needed btw - and codepoints aren't expensive > >> here, right? So other forms of ECC can burn codepoints when that's > >> needed and in the meantime we'd save bytes and complexity.) > > > > I am lost and don't understand what you are saying here. > > > > * For EC2 key types the curve is fixed, but the cryptographic > > function is not fixed. * For OKP key types, the curve/cryptographic > > function pair is fixed. > > > > This is analogous to what is happing for the PKIX world. > > > > Are you suggesting that something change? If so what? (Just so I > > can evaluate it.) > > > >> > >> - Section 15: Do we have any examples of such a profile? I think > >> it'd be great if we did and could add an informative reference here > >> (even if that's to an early I- D). > > > > Will add a reference to draft-selander-ace-object-security. (Which > > is being discussed in core not ace). > > > >> > >> - section 19: I don't get how ECDSA is normative and the cfrg > >> curves are not. Same for RFC6979. Maybe these all could do with > >> checking? (No big deal IMO but maybe worth it.) > > > > Yes, the cfrg curves should be normative and yes I will go back over > > the list. > > > >> > >> - Appendices A.1 (as already noted) and A.2 are a puzzle. Why say > >> in the body of the document to do <foo> and then an appendix that > >> says how to do <not-foo>? > > > > Answer above. > > > > > > Jim > > > > > >> > >> - Appendix C and the implementation status section: Many thanks - > >> great to see that! (I didn't check 'em though:-) > >> > >> - Thanks also for speedily handling the extensive secdir review. > >> > >> [2] > >> https://www.ietf.org/mail-archive/web/secdir/current/msg06801.html > >> > > > > > > _______________________________________________ COSE mailing list > > COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose > >
- [COSE] Stephen Farrell's Discuss on draft-ietf-co… Stephen Farrell
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Jim Schaad
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Carsten Bormann
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Stephen Farrell
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Jim Schaad
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Jim Schaad
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Stephen Farrell
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Jim Schaad
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… Jim Schaad
- Re: [COSE] Stephen Farrell's Discuss on draft-iet… kathleen.moriarty.ietf