From nobody Sun Oct 2 22:36:51 2016 Return-Path: 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 8271612B140; Sun, 2 Oct 2016 22:36: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 6TQqjR0czcdM; Sun, 2 Oct 2016 22:36: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 1390C12B13D; Sun, 2 Oct 2016 22:36: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; Sun, 2 Oct 2016 22:50:03 -0700 From: Jim Schaad To: 'Stephen Farrell' , 'The IESG' References: <147506634324.16628.6590617577304586745.idtracker@ietfa.amsl.com> In-Reply-To: <147506634324.16628.6590617577304586745.idtracker@ietfa.amsl.com> Date: Sun, 2 Oct 2016 22:36:37 -0700 Message-ID: <076601d21d38$1e5162f0$5af428d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQM0sPyC3CV9N63JinowM6PtUp5t4J3KCnog X-Originating-IP: [24.21.96.37] Archived-At: 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) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 05:36:49 -0000 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. Jim > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Wednesday, September 28, 2016 5:39 AM > To: The IESG > Cc: draft-ietf-cose-msg@ietf.org; Goeran Selander > ; 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) >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-cose-msg-19: Discuss >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 >=20 > 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. >=20 > (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.) >=20 > (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. >=20 > (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.) >=20 > (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. >=20 > (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. >=20 > (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. = 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. =20 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. =20 >=20 > (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. >=20 > (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. If this case it seems to be odd = that we would require it. I can do some research to figure this out. >=20 > (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. >=20 > (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. >=20 > (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. >=20 > (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. >=20 > (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. =20 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.=20 >=20 > (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. 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. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 >=20 > - 1.4: the 2nd last paragraph is unclear to me. Probably just needs = re-phrasing. Which is unclear, the problem or the action? >=20 > - 1.5: I'd add a reference to RFC5116. Reasonable and done. >=20 > - 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. >=20 > - 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. >=20 > - 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. >=20 > - 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. >=20 > - 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. >=20 > - 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. >=20 > - 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. >=20 > 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/ >=20 > (Note - the above were comments on -18, but also seem to work based on = -19. > Subsequent comments are on -19.) >=20 > - 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. >=20 > - 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. >=20 > - 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. >=20 > - 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. >=20 > - 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. >=20 > [1] https://datatracker.ietf.org/doc/draft-moriarty-pkcs5-v2dot1/ >=20 > - 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. >=20 > - 12.5: The 1st para seems wrong. (Or at least is unclear to > me.) "Encrypted with and " 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? >=20 > KW(KDF(DH-shared),CEK) Yes that is the formula and yes it makes sense to document it in that = manner. >=20 > - 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.) >=20 > - 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). >=20 > - 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. >=20 > - Appendices A.1 (as already noted) and A.2 are a puzzle. > Why say in the body of the document to do and then an appendix = that > says how to do ? Answer above. Jim >=20 > - Appendix C and the implementation status section: Many thanks - = great to see > that! (I didn't check 'em though:-) >=20 > - Thanks also for speedily handling the extensive secdir review. >=20 > [2] = https://www.ietf.org/mail-archive/web/secdir/current/msg06801.html >=20 From nobody Mon Oct 3 01:04:57 2016 Return-Path: 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 C089812B14C; Mon, 3 Oct 2016 01:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 Mp0SGPoCpi_j; Mon, 3 Oct 2016 01:04:47 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2978912B143; Mon, 3 Oct 2016 01:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u9384ZaZ006149; Mon, 3 Oct 2016 10:04:36 +0200 (CEST) Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3snZMR3pVTz2jh2; Mon, 3 Oct 2016 10:04:35 +0200 (CEST) Message-ID: <57F21118.4070709@tzi.org> Date: Mon, 03 Oct 2016 10:04:40 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Jim Schaad References: <147506634324.16628.6590617577304586745.idtracker@ietfa.amsl.com> <076601d21d38$1e5162f0$5af428d0$@augustcellars.com> In-Reply-To: <076601d21d38$1e5162f0$5af428d0$@augustcellars.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: 'Stephen Farrell' , cose-chairs@ietf.org, 'The IESG' , draft-ietf-cose-msg@ietf.org, goran.selander@ericsson.com, cose@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 08:04:50 -0000 Jim, please do not remove the CDDL from the text. We discussed this in the WG and the result was very clear. (I do agree with Stephen's comments that the English text needs to be completed where it does not fully mirror the CDDL yet.) Grüße, Carsten Jim Schaad wrote: > 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.) From nobody Mon Oct 3 03:21:03 2016 Return-Path: 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 BCC8712B0DA; Mon, 3 Oct 2016 03:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.297 X-Spam-Level: X-Spam-Status: No, score=-7.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 APNklnN09Eas; Mon, 3 Oct 2016 03:20:59 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D56312B42B; Mon, 3 Oct 2016 03:16:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8CF73BDF9; Mon, 3 Oct 2016 11:16:22 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYd0pEDBaEbQ; Mon, 3 Oct 2016 11:16:22 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E08D6BDCC; Mon, 3 Oct 2016 11:16:21 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1475489782; bh=mD2Ophk6721/arayPaEKfB1Lyw9426kfSHy9wk1AEhs=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=pk+vpP+dTfnjyhA47+Gda25fYFDlKnH0uH8rQ9MBoo31LVaGeTyiQA1LKj8qwZa9R ddOlenXFlDLqOMAZDQzqQrFsIbJ5o6gN9FdeKpzu/0ndEz1mm0QSwqsJpSjTECNq0F toAQvL76H1rnuhB3xsSchcAMwRM+Hq2rD+I821GA= To: Jim Schaad , 'The IESG' References: <147506634324.16628.6590617577304586745.idtracker@ietfa.amsl.com> <076601d21d38$1e5162f0$5af428d0$@augustcellars.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <21d32017-8dc8-5971-ef5c-b2083cdb6848@cs.tcd.ie> Date: Mon, 3 Oct 2016 11:16:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <076601d21d38$1e5162f0$5af428d0$@augustcellars.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000603060906030205050800" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 10:21:02 -0000 This is a cryptographically signed message in MIME format. --------------ms000603060906030205050800 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, On 03/10/16 06:36, Jim Schaad wrote: > Stephen, >=20 > 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. >=20 > Jim >=20 >=20 >> -----Original Message----- From: Stephen Farrell >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, September 28, >> 2016 5:39 AM To: The IESG Cc: >> draft-ietf-cose-msg@ietf.org; Goeran Selander=20 >> ; cose-chairs@ietf.org;=20 >> goran.selander@ericsson.com; cose@ietf.org Subject: Stephen >> Farrell's Discuss on draft-ietf-cose-msg-19: (with DISCUSS and=20 >> COMMENT) >>=20 >> Stephen Farrell has entered the following ballot position for=20 >> draft-ietf-cose-msg-19: Discuss >>=20 >> 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.) >>=20 >>=20 >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found >> here: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ >>=20 >>=20 >>=20 >> ----------------------------------------------------------------------= >> >>=20 DISCUSS: >> ----------------------------------------------------------------------= >> >> >> >>=20 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. >>=20 >> (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=20 >> 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: >=20 >=20 > 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.) >=20 >>=20 >> (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. >>=20 >> (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.) >>=20 >> (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.) >=20 > The description for key_ops points to Table 3, so I think it is fully > supplied. >=20 >>=20 >> (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.) >=20 > 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. >=20 > 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. >=20 >>=20 >> (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. >=20 > 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.=20 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. >=20 > 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;-) >=20 >>=20 >> (3) 7.1: key_op 8, "derive bits" - I don't think this usage is >> clear enough, can you say what's meant here? >=20 > 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. >=20 >>=20 >> (4) Why not make deterministic ECDSA a MUST? 8.1.1 says:=20 >> "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. >=20 > It is not clear to me that many, if any, current packages support the > concept of doing deterministic ECDSA. =20 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. >=20 >>=20 >> (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. >=20 > 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. >=20 >>=20 >> (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.) >=20 > 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. >=20 >>=20 >> (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.) >=20 > 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. >=20 >>=20 >> (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. >=20 > 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. >=20 >>=20 >> (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=20 >> publicly available.) >=20 > 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 !=3D 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. >=20 > I am not against raising the level to specification required, but > would worry about point squatting. >=20 > 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.) >=20 >>=20 >> (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=20 >> 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. >=20 > 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.) >=20 > 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.) >=20 >=20 >>=20 >>=20 >> ----------------------------------------------------------------------= >> >>=20 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. >> >> >> >>=20 - 1.4: the 2nd last paragraph is unclear to me. Probably just needs re-phrasing. >=20 > Which is unclear, the problem or the action? >=20 >>=20 >> - 1.5: I'd add a reference to RFC5116. >=20 > Reasonable and done. >=20 >>=20 >> - 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.) >=20 > I agree that this is an API requirement. >=20 >>=20 >> - 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. >=20 > 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. >=20 >>=20 >> - 3.1, "all the keys may need to be checked" - really? Or do you >> mean all the keys associated with this kid? >=20 > 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. >=20 >>=20 >> - 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.) >=20 > 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. >=20 >>=20 >> - 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? >=20 > 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. >=20 >>=20 >> - 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=20 >> this, but maybe you need to say that such issues need to be handled >> in the definition of signature algs. >=20 > 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. >=20 >>=20 >> - 4.3: "cannot bleed" isn't clear enough maybe, give an example >> perhaps where the decoder can fail to disambiguate a boundary? >=20 > I'll look at this and see if I cannot come up with better language. > However, there are no decode issues here. >=20 >>=20 >> 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/ >=20 > What if it is s/one must also/the application must also/ >=20 >>=20 >> (Note - the above were comments on -18, but also seem to work based >> on -19. Subsequent comments are on -19.) >>=20 >> - 7.1: "starting at the same base IV" - are you missing "and >> incrementing" or something? Otherwise I think this seems unclear. >=20 > 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. >=20 >>=20 >> - 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?) >=20 > Yeah, reads messy - let me think about it. >=20 >>=20 >> - 8.2.1: you need a reference for batch signing. (Or could it be >> omitted?) >=20 > I kept asking for one in the EdDSA document and never got one there, > so I don't have one to push in here. >=20 >>=20 >> - 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:-) >=20 > 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. >=20 >>=20 >> - 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.) >=20 > Will do. >=20 >>=20 >> [1] https://datatracker.ietf.org/doc/draft-moriarty-pkcs5-v2dot1/ >>=20 >> - 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. >=20 > I copied "OKP" from draft-ietf-jose-cfrg-curves. Since it has > already gone through there I am reluctant to be different. >=20 > I will re-look at the order and make sure that there is something > lying around for the acronym expansion. >=20 >>=20 >> - 12.5: The 1st para seems wrong. (Or at least is unclear to me.) >> "Encrypted with and " 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? >>=20 >> KW(KDF(DH-shared),CEK) >=20 > Yes that is the formula and yes it makes sense to document it in that > manner. >=20 >>=20 >> - 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.) >=20 > I am lost and don't understand what you are saying here. >=20 > * 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. >=20 > This is analogous to what is happing for the PKIX world. >=20 > Are you suggesting that something change? If so what? (Just so I > can evaluate it.) >=20 >>=20 >> - 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). >=20 > Will add a reference to draft-selander-ace-object-security. (Which > is being discussed in core not ace). >=20 >>=20 >> - 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.) >=20 > Yes, the cfrg curves should be normative and yes I will go back over > the list. >=20 >>=20 >> - Appendices A.1 (as already noted) and A.2 are a puzzle. Why say >> in the body of the document to do and then an appendix that=20 >> says how to do ? >=20 > Answer above. >=20 >=20 > Jim >=20 >=20 >>=20 >> - Appendix C and the implementation status section: Many thanks - >> great to see that! (I didn't check 'em though:-) >>=20 >> - Thanks also for speedily handling the extensive secdir review. >>=20 >> [2] >> https://www.ietf.org/mail-archive/web/secdir/current/msg06801.html >>=20 >=20 >=20 > _______________________________________________ COSE mailing list=20 > COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose >=20 --------------ms000603060906030205050800 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMDMx MDE2MjJaMC8GCSqGSIb3DQEJBDEiBCDv7XOyQm0CdWa4Nd6QeKeT8+DGa318wcO47lBTH4NK 8DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBEV23CJDGdNr6N6efXIdB1usyUMG0tsTHDXCanBkfXlvMHAziPyn2t 0grEx8Q24ICk3gaXvRgU/zEi0gWdDf/Axq80a1LWw4ASKobITuNek/GAkPrdIkOTDsOygBve SzIE0wACM4hxGNggF3OxGXM3u9VcJFK5wx45UFNSGZXO140Tz/tY6eiLOZ9OMfiOVtZ0L9cL Q3/l4aOU/qn520YdCO8Ja4Lux40XYP21coq316XLIWxk+eiIna1NgduqH52I9lZiikFnft6y Wwm808tiVdcyUyO14TMnEiTOjAyHHjKu020osX1QxIPe+k+xC9Uzb0JddxsQ3Ec06+Gcu6ys AAAAAAAA --------------ms000603060906030205050800-- From nobody Mon Oct 3 09:55:57 2016 Return-Path: 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 88078129416; Mon, 3 Oct 2016 09:55:55 -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 0lD1uYlEG9wF; Mon, 3 Oct 2016 09:55:54 -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 A9FBB12940E; Mon, 3 Oct 2016 09:55:53 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 3 Oct 2016 10:09:03 -0700 From: Jim Schaad To: 'Carsten Bormann' References: <147506634324.16628.6590617577304586745.idtracker@ietfa.amsl.com> <076601d21d38$1e5162f0$5af428d0$@augustcellars.com> <57F21118.4070709@tzi.org> In-Reply-To: <57F21118.4070709@tzi.org> Date: Mon, 3 Oct 2016 09:55:38 -0700 Message-ID: <001701d21d96$f9f1d0c0$edd57240$@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: AQM0sPyC3CV9N63JinowM6PtUp5t4AEQq3b7Ae7MiwqdudAKIA== Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Cc: 'Stephen Farrell' , cose-chairs@ietf.org, 'The IESG' , draft-ietf-cose-msg@ietf.org, goran.selander@ericsson.com, cose@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 16:55:55 -0000 Carsten, I built this version for review to make sure that all of the necessary = text was present not as a step to removing the CDDL from the document. Jim > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Monday, October 03, 2016 1:05 AM > To: Jim Schaad > Cc: 'Stephen Farrell' ; 'The IESG' = ; > 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) >=20 > Jim, >=20 > please do not remove the CDDL from the text. >=20 > We discussed this in the WG and the result was very clear. >=20 > (I do agree with Stephen's comments that the English text needs to be > completed where it does not fully mirror the CDDL yet.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > Jim Schaad wrote: > > 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.) From nobody Wed Oct 5 14:42:10 2016 Return-Path: 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 225B21294A1 for ; Wed, 5 Oct 2016 14:42:09 -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 TP4Aswi0Gist for ; Wed, 5 Oct 2016 14:42:08 -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 9D69B12949D for ; Wed, 5 Oct 2016 14:42:07 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 5 Oct 2016 14:55:17 -0700 From: Jim Schaad To: Date: Wed, 5 Oct 2016 14:41:51 -0700 Message-ID: <027f01d21f51$4a2e0e30$de8a2a90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdIfUOLzVVpr2yaZThGcHsNHmZLcWQ== Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Subject: [COSE] Stephen Farrell's Comments X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 21:42:09 -0000 One of the issues that Stephen raised was a question of why we did not make deterministic ECDSA be mandatory rather than just strongly suggesting that it be done. My initial response was that I did not believe that this was implemented in a sufficient number of libraries to go forward, but that I would do a review of some of the libraries out there and report back. Looking at the four libraries that I am currently using for COSE implementations, imagine my surprise to find that all of them now support doing deterministic ECDSA. Based on this and the request from Stephen, I suggest that we make deterministic ECDSA be a MUST. Are there any objections to this course of action? Jim From nobody Wed Oct 5 20:25:11 2016 Return-Path: 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 A4C8B1293F5; Wed, 5 Oct 2016 20:25:10 -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=unavailable 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 MRdz-Zuwp_IX; Wed, 5 Oct 2016 20:25:08 -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 D5B2F127077; Wed, 5 Oct 2016 20:17:09 -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; Wed, 5 Oct 2016 20:29:51 -0700 From: Jim Schaad To: 'Stephen Farrell' , 'The IESG' 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: Wed, 5 Oct 2016 20:16:25 -0700 Message-ID: <02e401d21f80$08265310$1872f930$@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: AQM0sPyC3CV9N63JinowM6PtUp5t4AEQq3b7AkHo5xudurNqsA== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 03:25:11 -0000 Stephen, Couple of items below asking for input. However, I think that I have = dealt with most of the issues and will be pulling them into the version = on github. Jim Editors copy is at https://cose-wg.github.io/cose-spec/ A diff to -19 can be found at = https://tools.ietf.org/rfcdiff?url1=3Dhttps://www.ietf.org/id/draft-ietf-= cose-msg&url2=3Dhttps://cose-wg.github.io/cose-spec/draft-ietf-cose-msg.t= xt > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Monday, October 03, 2016 3:16 AM > To: Jim Schaad ; 'The IESG' > 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) >=20 >=20 > Hi Jim, >=20 > 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. >=20 > Good stuff. Some answers below where they seem useful. >=20 > > > > Jim > > > > > >> -----Original Message----- From: Stephen Farrell > >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, September 28, > >> 2016 5:39 AM To: The IESG Cc: > >> draft-ietf-cose-msg@ietf.org; Goeran Selander > >> ; 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. >=20 > I'd say we should be able to kill this discuss point easily > with the changes you're making. >=20 > > > >> > >> (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. >=20 > Is that just a feeling of yours or are we confident it > represents WG consensus? (Honest question - I just don't > recall.) This is a question you would need to ask the chairs rather than me = because I am a very strong partisan on this issue. The question was = discussed multiple times and I think that it was a WG consensus, but it = is possible that it represents a brow beating from a very strong = partisan. >=20 > > 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. >=20 > 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. >=20 > 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;-) Let's leave it here for now and revisit when we have more info and we = are doing an update/advancement of the document. >=20 > > > >> > >> (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. >=20 > 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. Done >=20 > > > >> > >> (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. >=20 > 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.) >=20 > > If this case it seems to be > > odd that we would require it. I can do some research to figure = this > > out. >=20 > Cool. Be interested in what you find. It seems to be much more widely implemented than I thought. I have sent = a note to the COSE mailing list to see if there are objections to making = this change. >=20 > > > >> > >> (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. >=20 > 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. ack >=20 > > > >> > >> (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. >=20 > 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. > Until we have more info - I think we just differ on this one. =20 > > > >> > >> (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. >=20 > Fair enough. Consider this bit sorted. ack >=20 > > > >> > >> (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. >=20 > Hmm. No 25519? Odd that. But fair enough I suppose if it's being > handled somewhere. They are thinking about putting it in - so it will probably show up = given some time. >=20 > > > >> > >> (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. >=20 > Yeah but desired-by-someone !=3D desirable-for-the-Internet :-) >=20 > 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. >=20 > > > > 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. >=20 > I think expert review with specification required is maybe right > with the guidance tightened up along the lines you state above. > (But see below.) >=20 > > > >> > >> (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. >=20 > 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.) Done >=20 > > > > 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. >=20 > 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.) >=20 > > > > > >> > >> > >> = ---------------------------------------------------------------------- > >> > >> > COMMENT: > >> = ---------------------------------------------------------------------- > >> >=20 > 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. >=20 > Cheers, > S. >=20 >=20 > >> > >> > >> > >> > - 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. Done > > > >> > >> - 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. > > Need input > >> > >> - 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. No action taken. > > > >> > >> - 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. No action taken > > > >> > >> - 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. Added the following sentence: Algorithms MUST specify padding if the signature value is = not a multiple of 8 bits. > > > >> > >> - 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. I have modified this text. > > > >> > >> 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/ Looking for comment > > > >> > >> (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. I have re-written this text. > > > >> > >> - 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. I have done a re-write on this. > > > >> > >> - 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. No action - but I think it needs to be stated > > > >> > >> - 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. I did some more research and all I could find was: - Birthday attack for collisions - brute search for forgery on a message 2^(r-1)-1 attempts - Changing the algorithm to use a shorter MAC code which can lead to a = drastically smaller search space, but of course is prevented by MAC-ing = the algorithm identifier. I am not sure that including any of these, except maybe the last one, = adds anything to the list of considerations. > > > >> > >> - 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. Done > > > >> > >> [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. Done > > > >> > >> - 12.5: The 1st para seems wrong. (Or at least is unclear to me.) > >> "Encrypted with and " 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. Done > > > >> > >> - 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.) Request for information > > > >> > >> - 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). done > > > >> > >> - 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. Shifted around a couple of items > > > >> > >> - Appendices A.1 (as already noted) and A.2 are a puzzle. Why say > >> in the body of the document to do and then an appendix that > >> says how to do ? > > > > 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 > > From nobody Wed Oct 5 20:30:47 2016 Return-Path: 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 28B8F127ABE; Wed, 5 Oct 2016 20:30:40 -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 UrfHBfzQOp-I; Wed, 5 Oct 2016 20:30:38 -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 503B912944C; Wed, 5 Oct 2016 20:30:38 -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; Wed, 5 Oct 2016 20:43:54 -0700 From: Jim Schaad To: 'Alexey Melnikov' , 'The IESG' References: <147510124114.16603.14442590762723238530.idtracker@ietfa.amsl.com> In-Reply-To: <147510124114.16603.14442590762723238530.idtracker@ietfa.amsl.com> Date: Wed, 5 Oct 2016 20:30:26 -0700 Message-ID: <02eb01d21f81$ff0c63d0$fd252b70$@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: AQFdmcsPCLxivvE/OjaL7TR+h4lxnKGD0Dvw Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: cose-chairs@ietf.org, goran.selander@ericsson.com, cose@ietf.org, draft-ietf-cose-msg@ietf.org Subject: Re: [COSE] Alexey Melnikov's No Objection on draft-ietf-cose-msg-19: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 03:30:40 -0000 Alexey, I think that I have responded to all of these comments in the draft on = github. Jim > -----Original Message----- > From: Alexey Melnikov [mailto:aamelnikov@fastmail.fm] > Sent: Wednesday, September 28, 2016 3:21 PM > To: The IESG > Cc: draft-ietf-cose-msg@ietf.org; Goeran Selander > ; cose-chairs@ietf.org; > goran.selander@ericsson.com; cose@ietf.org > Subject: Alexey Melnikov's No Objection on draft-ietf-cose-msg-19: = (with > COMMENT) >=20 > Alexey Melnikov has entered the following ballot position for > draft-ietf-cose-msg-19: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Stephen, I've seen several documents recently that "reference CDDL > informatively" and I don't believe that. So the whole situation with = CDDL makes > me rather unhappy. >=20 > Comments on the document: >=20 > This is a well written document, despite its length. Thank you for = that. >=20 > Some specific comments: >=20 > I am pretty sure that the CDDL reference is normative. >=20 > On page 13: media type syntax reference is outdated, you should = reference RFC > 6838, Section 4.2 has relevant ABNF. >=20 > In Media type registrations: >=20 > Applications that use this media type: To be identified >=20 > This answer is not useful, please specify types of applications that = will be using > these media types. Something along the lines of what you specified in = the > Introduction. >=20 From nobody Thu Oct 6 04:05:35 2016 Return-Path: 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 D62A21295E5; Thu, 6 Oct 2016 04:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.297 X-Spam-Level: X-Spam-Status: No, score=-7.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 aabMBOKbc3q1; Thu, 6 Oct 2016 04:05:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6161D1295E6; Thu, 6 Oct 2016 04:05:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4B52BBE7C; Thu, 6 Oct 2016 12:05:28 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dp3k2cfyr4wy; Thu, 6 Oct 2016 12:05:28 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 118EDBE73; Thu, 6 Oct 2016 12:05:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1475751910; bh=0BQPadE0bVVMtqwxJnCtqawug32Is++HwO7J8e35ROo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=wUoO9PJcYzYS8DtB64WR1kNLSPZ9aQmGkgV4nLYrWyllPaaXfAK1yoNZoNPlXO5kK 4UjzNgh3+HtAmnIuc/VH4OKAhGkaC4YF+xyyjl+Fqu/NQUF9Gw/qmVwSknPmKZuQgO wAVLpRJWT/U5th4kHUZkuZQIBSf2LogTbr2aE7hE= To: Jim Schaad , 'The IESG' References: <147506634324.16628.6590617577304586745.idtracker@ietfa.amsl.com> <076601d21d38$1e5162f0$5af428d0$@augustcellars.com> <21d32017-8dc8-5971-ef5c-b2083cdb6848@cs.tcd.ie> <02e401d21f80$08265310$1872f930$@augustcellars.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 6 Oct 2016 12:05:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <02e401d21f80$08265310$1872f930$@augustcellars.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000906060104090408010002" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 11:05:34 -0000 This is a cryptographically signed message in MIME format. --------------ms000906060104090408010002 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, On 06/10/16 04:16, Jim Schaad wrote: > Stephen, >=20 > Couple of items below asking for input. However, I think that I have > dealt with most of the issues and will be pulling them into the > version on github. I'll trim to just those input'y bits... >>>> (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. >>>=20 >>> 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. >>=20 >> Is that just a feeling of yours or are we confident it represents >> WG consensus? (Honest question - I just don't recall.) >=20 > This is a question you would need to ask the chairs rather than me > because I am a very strong partisan on this issue. The question was > discussed multiple times and I think that it was a WG consensus, but > it is possible that it represents a brow beating from a very strong > partisan. Fair enough - cose WG chairs, what do you think? >>>> (4) Why not make deterministic ECDSA a MUST? 8.1.1 says:=20 >>>> "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. >>>=20 >>> It is not clear to me that many, if any, current packages support >>> the concept of doing deterministic ECDSA. >>=20 >> But they don't to COSE either so I'm not clear that's a good=20 >> 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.) >>=20 >>> If this case it seems to be odd that we would require it. I can >>> do some research to figure this out. >>=20 >> Cool. Be interested in what you find. >=20 > It seems to be much more widely implemented than I thought. I have > sent a note to the COSE mailing list to see if there are objections > to making this change. Saw that and thanks. Be interesting to see if anyone objects to this good change. >>>> --------------------------------------------------------------------= -- >>>> >>>> >> >>>>=20 COMMENT: >>>> --------------------------------------------------------------------= -- >>>> >> >> >>>> - 3.1, "all the keys may need to be checked" - really? Or do >>>> you mean all the keys associated with this kid? >>>=20 >>> 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. >>>=20 >=20 > Need input If you said "all the keys associated with this kid may need to be checked" then I think it'd be clear >>>> 4.4, last para: I disagree that one must (even lowercase must)=20 >>>> check the signing identity. That's application behaviour and=20 >>>> should be stated here in such concrete terms. At least s/must=20 >>>> also/may also want to/ >>>=20 >>> What if it is s/one must also/the application must also/ >=20 > Looking for comment I still think "must" isn't right and "may" is correct >>>> - Table 22: The EC2 or OKP value is fixed per curve and the=20 >>>> 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.) >>>=20 >>> I am lost and don't understand what you are saying here. >>>=20 >>> * For EC2 key types the curve is fixed, but the cryptographic=20 >>> function is not fixed. * For OKP key types, the >>> curve/cryptographic function pair is fixed. >>>=20 >>> This is analogous to what is happing for the PKIX world. >>>=20 >>> Are you suggesting that something change? If so what? (Just so >>> I can evaluate it.) >=20 > Request for information I'm suggesting that the key type is not needed once you know what curve you're dealing with and hence the "MUST check" is just adding cruft. Cheers, S. --------------ms000906060104090408010002 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMDYx MTA1MTBaMC8GCSqGSIb3DQEJBDEiBCCYj+wGvOc3xy4nu18NkTwHpKORcJC7bp0YhysK+EMF HjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQANIeF5mmJ2JNvE0//p1vgQgpW5etEg3zcwp/Hk85T+TVjBsAqbDZnX 62pJb2vC3Wi7gPYp1Ce5RIm9ehUftubpkfeM7rmNDZ9euguW2qTgG90dY0dwzpyxsdVW3FlA KuAlb/LibWi1/OmKl8MYCDoUCXydS3JHsuwVxGKeNVi+uCzec8OvTlJ1vjSX4YFwQDe8W0oM AHzEYvYgXyWM91/CLJGHiqGljr9HoBehmyIxqLZFCVSZlduO1Kxz3NRnKH0/kaTWOmV/JtWV 2gpVrzQPLpMjjyAS9lVV62bxnY+Y1XajXDaBlcHBzJZ7qrvmXyLv3UQva+eIKE+x1j5Fc6cT AAAAAAAA --------------ms000906060104090408010002-- From nobody Thu Oct 6 19:04:46 2016 Return-Path: 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 79F9E1294E0; Thu, 6 Oct 2016 19:04:40 -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 Xbzj1dkHIXo9; Thu, 6 Oct 2016 19:04:38 -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 661AE129553; Thu, 6 Oct 2016 19:04:38 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Oct 2016 19:17:33 -0700 From: Jim Schaad To: 'Stephen Farrell' , 'The IESG' References: <147506634324.16628.6590617577304586745.idtracker@ietfa.amsl.com> <076601d21d38$1e5162f0$5af428d0$@augustcellars.com> <21d32017-8dc8-5971-ef5c-b2083cdb6848@cs.tcd.ie> <02e401d21f80$08265310$1872f930$@augustcellars.com> In-Reply-To: Date: Thu, 6 Oct 2016 19:04:07 -0700 Message-ID: <043201d2203f$188e8eb0$49abac10$@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: AQM0sPyC3CV9N63JinowM6PtUp5t4AEQq3b7AkHo5xsCKTpUgQIcwnvenZpT1gA= Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Cc: cose-chairs@ietf.org, goran.selander@ericsson.com, draft-ietf-cose-msg@ietf.org, cose@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 02:04:40 -0000 > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Thursday, October 06, 2016 4:05 AM > To: Jim Schaad ; 'The IESG' > 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) >=20 >=20 > Hi Jim, >=20 > On 06/10/16 04:16, Jim Schaad wrote: > > Stephen, > > > > Couple of items below asking for input. However, I think that I = have > > dealt with most of the issues and will be pulling them into the > > version on github. >=20 > I'll trim to just those input'y bits... >=20 >=20 > COMMENT: > >>>> = ------------------------------------------------------------------- > >>>> --- > >>>> > >> > >> >=20 > >>>> - 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. > >>> > > > > Need input >=20 > If you said "all the keys associated with this kid may need to be = checked" then I > think it'd be clear That seems fine - I'll get this done. >=20 >=20 > >>>> 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/ > > > > Looking for comment >=20 > I still think "must" isn't right and "may" is correct I think you are wrong, but it is not worth arguing about. I'll get this = in. >=20 >=20 > >>>> - 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.) > > > > Request for information >=20 > I'm suggesting that the key type is not needed once you know what = curve you're > dealing with and hence the "MUST check" is just adding cruft. Right - so this is what an EC2 key looks like: { 1:2, -1:1,=20 -2:h'65eda5...de439c08551d',=20 -3:h'1e52ed...cd0084d19c' } A shared secret key looks like: { 1:4,=20 -1:h'849b57...ea6c427188' }, And a hypothetical RSA key would look like { 1:3, -1:h'83425...25239fa', -2:3 } Since label for curve is '-1', one would need to infer that it was a = curve by being an integer and then based on the curve know what the rest = of the parameters are. The key type ('1') lets you know what the = negative labels are. So you cannot infer that the curve field is a = curve field based on the text value as the same label is used multiple = ways for different key types. Jim >=20 > Cheers, > S. >=20 From nobody Mon Oct 10 20:24:36 2016 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D68D9129440; Mon, 10 Oct 2016 20:24:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147615627387.31502.6630928920547397097.idtracker@ietfa.amsl.com> Date: Mon, 10 Oct 2016 20:24:33 -0700 Archived-At: Cc: cose@ietf.org Subject: [COSE] I-D Action: draft-ietf-cose-msg-20.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 03:24:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption of the IETF. Title : CBOR Object Signing and Encryption (COSE) Author : Jim Schaad Filename : draft-ietf-cose-msg-20.txt Pages : 119 Date : 2016-10-10 Abstract: Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) specification. This specification describes how to create and process signature, message authentication codes and encryption using CBOR for serialization. This specification additionally specifies how to represent cryptographic keys using CBOR. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cose-msg-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 10 20:26:14 2016 Return-Path: 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 0E91F12945B for ; Mon, 10 Oct 2016 20:26:13 -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 7aI7LUtOAJKE for ; Mon, 10 Oct 2016 20:26:10 -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 134B712944E for ; Mon, 10 Oct 2016 20:26:10 -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:39:23 -0700 From: Jim Schaad To: References: <147615627387.31502.6630928920547397097.idtracker@ietfa.amsl.com> In-Reply-To: <147615627387.31502.6630928920547397097.idtracker@ietfa.amsl.com> Date: Mon, 10 Oct 2016 20:26:00 -0700 Message-ID: <091401d2236f$318b9920$94a2cb60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIutndJi5asO1zgR2rXMt5lVzvX9Z/pcUew Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: [COSE] FW: I-D Action: draft-ietf-cose-msg-20.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 03:26:13 -0000 This draft should address all IESG comments. It does not address the IANA issues, that version should be up by the start of next week. > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Monday, October 10, 2016 8:25 PM > To: i-d-announce@ietf.org > Cc: cose@ietf.org > Subject: [COSE] I-D Action: draft-ietf-cose-msg-20.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the CBOR Object Signing and Encryption of the IETF. > > Title : CBOR Object Signing and Encryption (COSE) > Author : Jim Schaad > Filename : draft-ietf-cose-msg-20.txt > Pages : 119 > Date : 2016-10-10 > > Abstract: > Concise Binary Object Representation (CBOR) is data format designed > for small code size and small message size. There is a need for the > ability to have basic security services defined for this data format. > This document defines the CBOR Object Signing and Encryption (COSE) > specification. This specification describes how to create and > process signature, message authentication codes and encryption using > CBOR for serialization. This specification additionally specifies > how to represent cryptographic keys using CBOR. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-cose-msg-20 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-20 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Mon Oct 10 20:27:51 2016 Return-Path: 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 To: 'Stephen Farrell' , 'The IESG' 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 'The IESG' > 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) >=20 >=20 > Hi Jim, >=20 > 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. >=20 > Good stuff. Some answers below where they seem useful. >=20 > > > > Jim > > > > > >> -----Original Message----- From: Stephen Farrell > >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, September 28, > >> 2016 5:39 AM To: The IESG Cc: > >> draft-ietf-cose-msg@ietf.org; Goeran Selander > >> ; 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. >=20 > I'd say we should be able to kill this discuss point easily > with the changes you're making. >=20 > > > >> > >> (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. >=20 > Is that just a feeling of yours or are we confident it > represents WG consensus? (Honest question - I just don't > recall.) >=20 > > 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. >=20 > 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. >=20 > 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;-) >=20 > > > >> > >> (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. >=20 > 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. >=20 > > > >> > >> (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. >=20 > 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.) >=20 > > If this case it seems to be > > odd that we would require it. I can do some research to figure = this > > out. >=20 > Cool. Be interested in what you find. >=20 > > > >> > >> (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. >=20 > 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. >=20 > > > >> > >> (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. >=20 > 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. >=20 > > > >> > >> (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. >=20 > Fair enough. Consider this bit sorted. >=20 > > > >> > >> (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. >=20 > Hmm. No 25519? Odd that. But fair enough I suppose if it's being > handled somewhere. >=20 > > > >> > >> (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. >=20 > Yeah but desired-by-someone !=3D desirable-for-the-Internet :-) >=20 > 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. >=20 > > > > 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. >=20 > I think expert review with specification required is maybe right > with the guidance tightened up along the lines you state above. > (But see below.) >=20 > > > >> > >> (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. >=20 > 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.) >=20 > > > > 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. >=20 > 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.) >=20 > > > > > >> > >> > >> = ---------------------------------------------------------------------- > >> > >> > COMMENT: > >> = ---------------------------------------------------------------------- > >> >=20 > 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. >=20 > Cheers, > S. >=20 >=20 > >> > >> > >> > >> > - 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 and " 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 and then an appendix that > >> says how to do ? > > > > 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 > > From nobody Tue Oct 11 04:26:58 2016 Return-Path: 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 53C411294F1; Tue, 11 Oct 2016 04:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 764SPLAvVeMZ; Tue, 11 Oct 2016 04:26:49 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDBBA129759; Tue, 11 Oct 2016 04:26:48 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id o68so27666427qkf.3; Tue, 11 Oct 2016 04:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Oo2FIafJ2UilIkEPuyPvc/VHlc65huSP9y2JBrvZMc8=; b=jRMp/hEl963myX1Ydz0yqMox5k6Xwr+Ah89Wf8syv23pRac4DnP6LED1ZyiCfxhE5Y Fj4pFU7rsvyOFwVC0Aloi1jy3yiFCPZodaGpMv/rQN0gs+DeDplfMTnqvWrgp8VyXU7/ 5ljZ5j1I+Xjq7cYzhhhQubLvNuhEav+spS5mNQ9RJZubVlF9URFZXL5/2muCt5nTenta +PMlHJLzVpEfUKaK1TbTW9rNpxPFTL3pCdtIlFWPlpZCeI7AJGm1Bg0k/xqDBxN63/70 ymdwXthpR051q7t5YAY4CCF+2bIxiQbQ9Wacy+PHmZtvf4J5FYWf58X1egXvM5pboUKc +nvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Oo2FIafJ2UilIkEPuyPvc/VHlc65huSP9y2JBrvZMc8=; b=Ui6ITKRCjfj1UXcl/v4YAy/ZT4yUo6Coc/Z3CYUG9b78hNimTGuZ56uNbRUumpurAy /ExvuKYTLrueYR67FHm/0Al2I+EmrSXcj+s+plVi0g8WpdeKVWgOODzLguXOg3K98/R1 cVm+GsPspnp4lpAsOGhzdGIQbD38sL7RnuVkTR/dy6YWI8KAqOoJMt1OSilgJaka+KXm HXhj075rphue2Zi58ddGSzq5D9uxDxpLyqv7Eavxx7Zgq81U/NpXJT2rNiVtwFlrcmY0 yPuH8gZm18p6vuo7JlQ1rDX8CxnWc5WyddL8Z/PSq8S+YmNo7vAOhz+oBbEinGEjhUGW G4jA== X-Gm-Message-State: AA6/9RlnDW1XwKFzBxTaYYak0tbRDyMn1VtbvNPFJ92eyL3NhmvExd8YQrJTQTvEuLRrWw== X-Received: by 10.55.21.69 with SMTP id f66mr2484600qkh.131.1476185207751; Tue, 11 Oct 2016 04:26:47 -0700 (PDT) Received: from [192.168.1.4] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id s23sm972250qka.10.2016.10.11.04.26.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 11 Oct 2016 04:26:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13G36) In-Reply-To: <091901d2236f$6be6de40$43b49ac0$@augustcellars.com> Date: Tue, 11 Oct 2016 07:26:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <99805C4D-65E7-4D34-A034-3BC1F24E060D@gmail.com> References: <147506634324.16628.6590617577304586745.idtracker@ietfa.amsl.com> <076601d21d38$1e5162f0$5af428d0$@augustcellars.com> <21d32017-8dc8-5971-ef5c-b2083cdb6848@cs.tcd.ie> <091901d2236f$6be6de40$43b49ac0$@augustcellars.com> To: Jim Schaad Archived-At: Cc: Stephen Farrell , cose-chairs@ietf.org, The IESG , draft-ietf-cose-msg@ietf.org, goran.selander@ericsson.com, cose@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 11:26:52 -0000 Thank you, Jim. I'll double check before you post the next version. Kathleen=20 Please excuse typos, sent from handheld device=20 > On Oct 10, 2016, at 11:27 PM, Jim Schaad wrote: >=20 > I have just published a draft -20 of the document. >=20 > I believe that this document addresses all of the issues that have been ra= ised by the IESG. >=20 > This document does not address the blocking IANA issues. I should have th= ese addressed and a new version published by the start of next week. >=20 > Jim >=20 >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Monday, October 03, 2016 3:16 AM >> To: Jim Schaad ; 'The IESG' >> Cc: cose-chairs@ietf.org; goran.selander@ericsson.com; cose@ietf.org; dra= ft- >> ietf-cose-msg@ietf.org >> Subject: Re: [COSE] Stephen Farrell's Discuss on draft-ietf-cose-msg-19: (= with >> DISCUSS and COMMENT) >>=20 >>=20 >> Hi Jim, >>=20 >>> On 03/10/16 06:36, Jim Schaad wrote: >>> Stephen, >>>=20 >>> 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. >>=20 >> Good stuff. Some answers below where they seem useful. >>=20 >>>=20 >>> Jim >>>=20 >>>=20 >>>> -----Original Message----- From: Stephen Farrell >>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, September 28, >>>> 2016 5:39 AM To: The IESG Cc: >>>> draft-ietf-cose-msg@ietf.org; Goeran Selander >>>> ; 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) >>>>=20 >>>> Stephen Farrell has entered the following ballot position for >>>> draft-ietf-cose-msg-19: Discuss >>>>=20 >>>> 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.) >>>>=20 >>>>=20 >>>> Please refer to >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more >>>> information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found >>>> here: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ >>>>=20 >>>>=20 >>>>=20 >>>> ---------------------------------------------------------------------- >> 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. >>>>=20 >>>> (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: >>>=20 >>>=20 >>> 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.) >>>=20 >>>>=20 >>>> (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. >>>>=20 >>>> (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.) >>>>=20 >>>> (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.) >>>=20 >>> The description for key_ops points to Table 3, so I think it is fully >>> supplied. >>>=20 >>>>=20 >>>> (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.) >>>=20 >>> 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. >>>=20 >>> 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. >>=20 >> I'd say we should be able to kill this discuss point easily >> with the changes you're making. >>=20 >>>=20 >>>>=20 >>>> (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. >>>=20 >>> 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. >>=20 >> Is that just a feeling of yours or are we confident it >> represents WG consensus? (Honest question - I just don't >> recall.) >>=20 >>> 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. >>>=20 >>> 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. >>=20 >> 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. >>=20 >> 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;-) >>=20 >>>=20 >>>>=20 >>>> (3) 7.1: key_op 8, "derive bits" - I don't think this usage is >>>> clear enough, can you say what's meant here? >>>=20 >>> 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. >>=20 >> 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. >>=20 >>>=20 >>>>=20 >>>> (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. >>>=20 >>> It is not clear to me that many, if any, current packages support the >>> concept of doing deterministic ECDSA. >>=20 >> 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.) >>=20 >>> If this case it seems to be >>> odd that we would require it. I can do some research to figure this >>> out. >>=20 >> Cool. Be interested in what you find. >>=20 >>>=20 >>>>=20 >>>> (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. >>>=20 >>> The value of 'crv' is defined in table 22. The same algorithm is >>> used to identify all of the curves. >>=20 >> 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. >>=20 >>>=20 >>>>=20 >>>> (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.) >>>=20 >>> 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. >>=20 >> 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. >>=20 >>>=20 >>>>=20 >>>> (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.) >>>=20 >>> 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. >>=20 >> Fair enough. Consider this bit sorted. >>=20 >>>=20 >>>>=20 >>>> (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. >>>=20 >>> See https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe/ >>> for how this is being addressed. >>=20 >> Hmm. No 25519? Odd that. But fair enough I suppose if it's being >> handled somewhere. >>=20 >>>=20 >>>>=20 >>>> (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.) >>>=20 >>> 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. >>=20 >> Yeah but desired-by-someone !=3D desirable-for-the-Internet :-) >>=20 >> 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. >>=20 >>>=20 >>> I am not against raising the level to specification required, but >>> would worry about point squatting. >>>=20 >>> 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. >>=20 >> I think expert review with specification required is maybe right >> with the guidance tightened up along the lines you state above. >> (But see below.) >>=20 >>>=20 >>>>=20 >>>> (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. >>>=20 >>> 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. >>=20 >> 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.) >>=20 >>>=20 >>> 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. >>=20 >> 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.) >>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 >>>> ---------------------------------------------------------------------- >> COMMENT: >>>> ---------------------------------------------------------------------- >>=20 >> 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. >>=20 >> Cheers, >> S. >>=20 >>=20 >> - 1.4: the 2nd last paragraph is unclear to me. Probably just needs >> re-phrasing. >>>=20 >>> Which is unclear, the problem or the action? >>>=20 >>>>=20 >>>> - 1.5: I'd add a reference to RFC5116. >>>=20 >>> Reasonable and done. >>>=20 >>>>=20 >>>> - 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.) >>>=20 >>> I agree that this is an API requirement. >>>=20 >>>>=20 >>>> - 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. >>>=20 >>> 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. >>>=20 >>>>=20 >>>> - 3.1, "all the keys may need to be checked" - really? Or do you >>>> mean all the keys associated with this kid? >>>=20 >>> 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. >>>=20 >>>>=20 >>>> - 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.) >>>=20 >>> 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. >>>=20 >>>>=20 >>>> - 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? >>>=20 >>> 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. >>>=20 >>>>=20 >>>> - 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. >>>=20 >>> 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. >>>=20 >>>>=20 >>>> - 4.3: "cannot bleed" isn't clear enough maybe, give an example >>>> perhaps where the decoder can fail to disambiguate a boundary? >>>=20 >>> I'll look at this and see if I cannot come up with better language. >>> However, there are no decode issues here. >>>=20 >>>>=20 >>>> 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/ >>>=20 >>> What if it is s/one must also/the application must also/ >>>=20 >>>>=20 >>>> (Note - the above were comments on -18, but also seem to work based >>>> on -19. Subsequent comments are on -19.) >>>>=20 >>>> - 7.1: "starting at the same base IV" - are you missing "and >>>> incrementing" or something? Otherwise I think this seems unclear. >>>=20 >>> 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. >>>=20 >>>>=20 >>>> - 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?) >>>=20 >>> Yeah, reads messy - let me think about it. >>>=20 >>>>=20 >>>> - 8.2.1: you need a reference for batch signing. (Or could it be >>>> omitted?) >>>=20 >>> I kept asking for one in the EdDSA document and never got one there, >>> so I don't have one to push in here. >>>=20 >>>>=20 >>>> - 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:-) >>>=20 >>> 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. >>>=20 >>>>=20 >>>> - 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.) >>>=20 >>> Will do. >>>=20 >>>>=20 >>>> [1] https://datatracker.ietf.org/doc/draft-moriarty-pkcs5-v2dot1/ >>>>=20 >>>> - 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. >>>=20 >>> I copied "OKP" from draft-ietf-jose-cfrg-curves. Since it has >>> already gone through there I am reluctant to be different. >>>=20 >>> I will re-look at the order and make sure that there is something >>> lying around for the acronym expansion. >>>=20 >>>>=20 >>>> - 12.5: The 1st para seems wrong. (Or at least is unclear to me.) >>>> "Encrypted with and " 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? >>>>=20 >>>> KW(KDF(DH-shared),CEK) >>>=20 >>> Yes that is the formula and yes it makes sense to document it in that >>> manner. >>>=20 >>>>=20 >>>> - 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.) >>>=20 >>> I am lost and don't understand what you are saying here. >>>=20 >>> * 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. >>>=20 >>> This is analogous to what is happing for the PKIX world. >>>=20 >>> Are you suggesting that something change? If so what? (Just so I >>> can evaluate it.) >>>=20 >>>>=20 >>>> - 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). >>>=20 >>> Will add a reference to draft-selander-ace-object-security. (Which >>> is being discussed in core not ace). >>>=20 >>>>=20 >>>> - 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.) >>>=20 >>> Yes, the cfrg curves should be normative and yes I will go back over >>> the list. >>>=20 >>>>=20 >>>> - Appendices A.1 (as already noted) and A.2 are a puzzle. Why say >>>> in the body of the document to do and then an appendix that >>>> says how to do ? >>>=20 >>> Answer above. >>>=20 >>>=20 >>> Jim >>>=20 >>>=20 >>>>=20 >>>> - Appendix C and the implementation status section: Many thanks - >>>> great to see that! (I didn't check 'em though:-) >>>>=20 >>>> - Thanks also for speedily handling the extensive secdir review. >>>>=20 >>>> [2] >>>> https://www.ietf.org/mail-archive/web/secdir/current/msg06801.html >>>=20 >>>=20 >>> _______________________________________________ COSE mailing list >>> COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose >=20 >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Fri Oct 14 20:50:40 2016 Return-Path: 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 37C69129409; Fri, 14 Oct 2016 20:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 p9uJoQYC8Kov; Fri, 14 Oct 2016 20:50:32 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767741293E1; Fri, 14 Oct 2016 20:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u9F3oSV1024801; Sat, 15 Oct 2016 05:50:28 +0200 (CEST) Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3swr8h0lH6z7xhk; Sat, 15 Oct 2016 05:50:28 +0200 (CEST) Message-ID: <5801A7D0.8050100@tzi.org> Date: Sat, 15 Oct 2016 05:51:44 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: ace@ietf.org, core@ietf.org, cose@ietf.org, dtls-iot@ietf.org, t2trg@irtf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [COSE] Constrained Node/Network Cluster @ IETF97: DRAFT AGENDA X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2016 03:50:35 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF97. Remember that there is still quite some potential for changes. IoT is starting a bit late at IETF97; only two meetings of cluster WGs on Mon/Tue (but then of course we start big with the Sunday icnrg/t2trg joint meeting). CORE on HOMENET and IPWAVE (Wed) and CORE on ICNRG (Fri) are a bit painful but probably the unavoidable level of conflict. Moves due to other conflict avoidance may make this worse, though. All times are KST (UTC+0900) -- there is no DST in Korea, and DST will have ended in Europe and North America by then. (The browser timezone function still is not yet reinstated on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Grüße, Carsten SUNDAY, November 13, 2016 1300-1600 IRTF*** icnrg+t2trg joint meeting MONDAY, November 14, 2016 1330-1530 Afternoon Session I Studio 3 ART ice Interactive Connectivity Establishment WG Park BR 1 IRTF cfrg Crypto Forum Grand BR II OPS v6ops IPv6 Operations WG 1550-1750 Afternoon Session II Grand BR III INT *** lpwan IPv6 over Low Power Wide-Area Networks WG Studio 3 RTG bier Bit Indexed Explicit Replication WG TUESDAY, November 15, 2016 0930-1200 Morning Session I Grand BR II INT 6man IPv6 Maintenance WG Park BR 1 RTG detnet Deterministic Networking WG Grand BR I TSV quic QUIC WG 1330-1530 Afternoon Session I Park BR 1 ART httpbis Hypertext Transfer Protocol WG Grand BR I RTG rtgarea Routing Area Open Meeting Studio 4 SEC tokbind Token Binding WG Grand BR III TSV tsvwg Transport Area Working Group WG 1550-1820 Afternoon Session II Grand BR II INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG Park BR 1 SEC tls Transport Layer Security WG WEDNESDAY, November 16, 2016 0930-1100 Morning Session I Grand BR III OPS anima Autonomic Networking Integrated Model and Approach WG Grand BR II TSV taps Transport Services WG 1110-1210 Morning Session II Park BR 2 RTG *** roll Routing Over Low power and Lossy networks WG Grand BR I TSV tsvwg Transport Area Working Group WG 1330-1500 Afternoon Session I Studio 2 ART *** core Constrained RESTful Environments WG Grand BR I INT homenet Home Networking WG Grand BR III INT ipwave IP Wireless Access in Vehicular Environments WG Studio 4 SEC acme Automated Certificate Management Environment WG Grand BR II TSV tsvarea Transport Area Open Meeting 1520-1620 Afternoon Session II Park BR 2 INT intarea Internet Area Working Group WG Park BR 1 IRTF*** t2trg Thing-to-Thing Studio 3 SEC curdle CURves, Deprecating and a Little more Encryption WG THURSDAY, November 17, 2016 0930-1100 Morning Session I Park BR 1 INT *** 6tisch IPv6 over the TSCH mode of IEEE 802.15.4e WG Studio 4 INT dnssd Extensions for Scalable DNS Service Discovery WG Grand BR II IRTF maprg Measurement and Analysis for Protocols Grand BR I SEC saag Security Area Open Meeting 1110-1210 Morning Session II Park BR 1 ART httpbis Hypertext Transfer Protocol WG Grand BR III INT *** lwig Light-Weight Implementation Guidance WG Grand BR I SEC saag Security Area Open Meeting 1330-1500 Afternoon Session I Studio 3 SEC oauth Web Authorization Protocol WG 1520-1750 Afternoon Session II Studio 4 SEC *** ace Authentication and Authorization for Constrained Environments WG Studio 2 TSV rmcat RTP Media Congestion Avoidance Techniques WG FRIDAY, November 18, 2016 0930-1130 Morning Session I Studio 4 ART *** core Constrained RESTful Environments WG Grand BR II IRTF icnrg Information-Centric Networking Park BR 1 OPS anima Autonomic Networking Integrated Model and Approach WG Park BR 2 TSV tcpinc TCP Increased Security WG 1150-1320 Afternoon Session I Studio 2 ART webpush Web-Based Push Notifications WG Park BR 1 RTG babel Babel routing protocol WG Studio 4 SEC oauth Web Authorization Protocol WG From nobody Sun Oct 16 13:56:58 2016 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 631D1129439; Sun, 16 Oct 2016 13:56:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147665141739.25813.4419576200342341528.idtracker@ietfa.amsl.com> Date: Sun, 16 Oct 2016 13:56:57 -0700 Archived-At: Cc: cose-chairs@ietf.org, goran.selander@ericsson.com, cose@ietf.org, draft-ietf-cose-msg@ietf.org Subject: [COSE] Stephen Farrell's Discuss on draft-ietf-cose-msg-20: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 20:56:57 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-cose-msg-20: 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: ---------------------------------------------------------------------- Thanks for the updates in -20. I think we've only the following points left. Note that 2 of those are questions to the WG chairs and not to Jim. (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. Can you help me see that the changes there are such that CDDL is ok as informative? I'm not sure but as I read it there is still no natural language statement that a "counter signature" is one (or more) COSE_Signature values. (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 think we left the mail thread on this with you saying "Best to ask the chairs if they agree that this is WG consensus," as you're an admitteddly strong partisan on this topic. So, COSE chairs - what's your take? (If you say this is ok with the WG, I'll clear.) (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.) I think this is the similar to discuss point (2) above. So again, COSE chairs, can you confirm that this design does reflect WG consensus and isn't just a thorough and good editor getting his way? (If you say this is ok with the WG, I'll clear.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- OLD COMMENTS BELOW, I DIDN'T CHECK THEM. Happy to chat more about 'em if that's useful. - 1.4: the 2nd last paragraph is unclear to me. Probably just needs re-phrasing. - 1.5: I'd add a reference to RFC5116. - 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.) - 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. - 3.1, "all the keys may need to be checked" - really? Or do you mean all the keys associated with this kid? - 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.) - 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? - 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. - 4.3: "cannot bleed" isn't clear enough maybe, give an example perhaps where the decoder can fail to disambiguate a boundary? 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/ (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. - 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?) - 8.2.1: you need a reference for batch signing. (Or could it be omitted?) - 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:-) - 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.) [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. - 12.5: The 1st para seems wrong. (Or at least is unclear to me.) "Encrypted with and " 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) - 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.) - 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). - 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.) - Appendices A.1 (as already noted) and A.2 are a puzzle. Why say in the body of the document to do and then an appendix that says how to do ? - 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 From nobody Sun Oct 16 14:51:08 2016 Return-Path: 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 780E61294C1; Sun, 16 Oct 2016 14:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, 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 W3mgQVxZ3rGn; Sun, 16 Oct 2016 14:51:00 -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 180971294E0; Sun, 16 Oct 2016 14:50:59 -0700 (PDT) Received: from hebrews (50.45.239.150) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 16 Oct 2016 15:07:07 -0700 From: Jim Schaad To: 'Stephen Farrell' , 'The IESG' References: <147665141739.25813.4419576200342341528.idtracker@ietfa.amsl.com> In-Reply-To: <147665141739.25813.4419576200342341528.idtracker@ietfa.amsl.com> Date: Sun, 16 Oct 2016 14:50:48 -0700 Message-ID: <029401d227f7$5cdb7fa0$16927ee0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQHNbS3DXaOw24A1fPGcVnzLF6ZbJ6C1E6Qw X-Originating-IP: [50.45.239.150] Archived-At: 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-20: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 21:51:02 -0000 I think we dealt with all of the comments. I cannot help you with = getting chair response. See below for my one issue. Jim > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Sunday, October 16, 2016 1:57 PM > To: The IESG > Cc: draft-ietf-cose-msg@ietf.org; Goeran Selander > ; cose-chairs@ietf.org; > goran.selander@ericsson.com; cose@ietf.org > Subject: Stephen Farrell's Discuss on draft-ietf-cose-msg-20: (with = DISCUSS and > COMMENT) >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-cose-msg-20: Discuss >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 >=20 > Thanks for the updates in -20. I think we've only the following points = left. Note > that 2 of those are questions to the WG chairs and not to Jim. >=20 > (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. >=20 > Can you help me see that the changes there are such that CDDL is ok as > informative? I'm not sure but as I read it there is still no natural = language > statement that a "counter signature" is one (or more) COSE_Signature = values. In section 1.3 the following text was added: Two syntaxes from CDDL appear in this document as shorthand. These are: FOO / BAR - indicates that either FOO or BAR can appear here [+ FOO] - indicates that the type FOO appears one or more times in = an array The value from the table is: COSE_Signature / [+ COSE_Signature ] Section 4.1 contains the text: The CBOR object that carries the signature and information about the = signature is called the COSE_Signature structure. >From that I think that all of the needed normative text is present. >=20 > (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. >=20 > I think we left the mail thread on this with you saying "Best to ask = the chairs if > they agree that this is WG consensus," as you're an admitteddly strong = partisan > on this topic. >=20 > So, COSE chairs - what's your take? (If you say this is ok with the = WG, I'll clear.) >=20 > (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.) >=20 > I think this is the similar to discuss point (2) above. >=20 > So again, COSE chairs, can you confirm that this design does reflect = WG > consensus and isn't just a thorough and good editor getting his way? = (If you say > this is ok with the WG, I'll clear.) >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > OLD COMMENTS BELOW, I DIDN'T CHECK THEM. Happy to chat more about 'em > if that's useful. >=20 > - 1.4: the 2nd last paragraph is unclear to me. Probably just needs = re-phrasing. >=20 > - 1.5: I'd add a reference to RFC5116. >=20 > - 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.) >=20 > - 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. >=20 > - 3.1, "all the keys may need to be checked" - really? Or do you mean = all the > keys associated with this kid? >=20 > - 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.) >=20 > - 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? >=20 > - 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. >=20 > - 4.3: "cannot bleed" isn't clear enough maybe, give an example = perhaps where > the decoder can fail to disambiguate a boundary? >=20 > 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/ >=20 > (Note - the above were comments on -18, but also seem to work based on = -19. > Subsequent comments are on -19.) >=20 > - 7.1: "starting at the same base IV" - are you missing "and = incrementing" or > something? Otherwise I think this seems unclear. >=20 > - 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?) >=20 > - 8.2.1: you need a reference for batch signing. (Or could it be = omitted?) >=20 > - 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:-) >=20 > - 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.) >=20 > [1] https://datatracker.ietf.org/doc/draft-moriarty-pkcs5-v2dot1/ >=20 > - 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. >=20 > - 12.5: The 1st para seems wrong. (Or at least is unclear to > me.) "Encrypted with and " 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? >=20 > KW(KDF(DH-shared),CEK) >=20 > - 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.) >=20 > - 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). >=20 > - 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.) >=20 > - Appendices A.1 (as already noted) and A.2 are a puzzle. > Why say in the body of the document to do and then an appendix = that > says how to do ? >=20 > - Appendix C and the implementation status section: Many thanks - = great to see > that! (I didn't check 'em though:-) >=20 > - Thanks also for speedily handling the extensive secdir review. >=20 > [2] = https://www.ietf.org/mail-archive/web/secdir/current/msg06801.html From nobody Sun Oct 16 15:41:51 2016 Return-Path: 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 78748129510; Sun, 16 Oct 2016 15:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.732 X-Spam-Level: X-Spam-Status: No, score=-4.732 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 R31Va2sRdnMA; Sun, 16 Oct 2016 15:41:45 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 540C2129481; Sun, 16 Oct 2016 15:41:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 163C7BE3E; Sun, 16 Oct 2016 23:41:42 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDoOAj11RaOj; Sun, 16 Oct 2016 23:41:40 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7D036BE39; Sun, 16 Oct 2016 23:41:39 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1476657700; bh=sflH0Q0bROfnr0frq3+zrrXM2VmyteeY0+fSZrzXqg4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=AECAB/GzCM3nQFkHJoO+owkOVSkZq6TEQSw6V+wvoCJE98HhezHigG8iqe/arsx2z WGULKEMEQt8q5rdSams7OqIHOWJek86B1hm68jbtuvLvRk4mZUsBi3l7DKSbQiJIdC TdSrE8+tsDj34Md/4nTQZrXyXYJZ3Z3OEbS86BYk= To: Jim Schaad , 'The IESG' References: <147665141739.25813.4419576200342341528.idtracker@ietfa.amsl.com> <029401d227f7$5cdb7fa0$16927ee0$@augustcellars.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sun, 16 Oct 2016 23:41:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <029401d227f7$5cdb7fa0$16927ee0$@augustcellars.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090700070206040301000204" Archived-At: 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-20: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 22:41:49 -0000 This is a cryptographically signed message in MIME format. --------------ms090700070206040301000204 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Dear cose-chairs - there is stuff in this discuss for you to deal with. (Just putting that there in case you're not delving down into the body of the mails:-) On 16/10/16 22:50, Jim Schaad wrote: > I think we dealt with all of the comments. I cannot help you with gett= ing chair response. >=20 > See below for my one issue. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Sunday, October 16, 2016 1:57 PM >> To: The IESG >> Cc: draft-ietf-cose-msg@ietf.org; Goeran Selander >> ; cose-chairs@ietf.org; >> goran.selander@ericsson.com; cose@ietf.org >> Subject: Stephen Farrell's Discuss on draft-ietf-cose-msg-20: (with DI= SCUSS and >> COMMENT) >> >> Stephen Farrell has entered the following ballot position for >> draft-ietf-cose-msg-20: 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 intr= oductory >> paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml >> 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: >> ----------------------------------------------------------------------= >> >> >> Thanks for the updates in -20. I think we've only the following points= left. Note >> that 2 of those are questions to the WG chairs and not to Jim. >> >> (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. >> >> Can you help me see that the changes there are such that CDDL is ok as= >> informative? I'm not sure but as I read it there is still no natural l= anguage >> statement that a "counter signature" is one (or more) COSE_Signature v= alues. >=20 > In section 1.3 the following text was added: >=20 > Two syntaxes from CDDL appear in this document as shorthand. These are:= >=20 > FOO / BAR - indicates that either FOO or BAR can appear here > [+ FOO] - indicates that the type FOO appears one or more times in = an array >=20 > The value from the table is: >=20 > COSE_Signature / [+ COSE_Signature ] >=20 > Section 4.1 contains the text: >=20 > The CBOR object that carries the signature and information about the si= gnature is called the COSE_Signature structure. >=20 >>From that I think that all of the needed normative text is present. Yeah, I get that. But then I think you've embedded some CDDL notation at least as normative. (I mean the constructs you describe with FOO/BAR above.) While I do start to feel pedantry-panic that I'm saying it, if really treating CDDL as informative, I think you ought say in text that one or more COSE_Signature fields need to be in a counter signature. But I'm gonna clear that anyway as the whole CDDL is not normative thing is really pretence IMO and there's no point in me joining in with that further. That means that clearing this discuss is now solely down to the chairs saying they're happy that Jim's positions do reflect wG consensus. Cheers, S. >=20 >> >> (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 think we left the mail thread on this with you saying "Best to ask t= he chairs if >> they agree that this is WG consensus," as you're an admitteddly strong= partisan >> on this topic. >> >> So, COSE chairs - what's your take? (If you say this is ok with the WG= , I'll clear.) >> >> (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.) >> >> I think this is the similar to discuss point (2) above. >> >> So again, COSE chairs, can you confirm that this design does reflect W= G >> consensus and isn't just a thorough and good editor getting his way? (= If you say >> this is ok with the WG, I'll clear.) >> >> >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> >> OLD COMMENTS BELOW, I DIDN'T CHECK THEM. Happy to chat more about 'em >> if that's useful. >> >> - 1.4: the 2nd last paragraph is unclear to me. Probably just needs re= -phrasing. >> >> - 1.5: I'd add a reference to RFC5116. >> >> - 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 i= t's odd.) >> >> - 3.1, "content type" is the space there intended? If so, maybe add q= uotes or a >> comma or something to disambiguate the name and descriptive text? Same= for >> other multi-word names here. >> >> - 3.1, "all the keys may need to be checked" - really? Or do you mean= all the >> keys associated with this kid? >> >> - 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 el= se instead? >> Shouldn't all mechanism for handling IVs be defined by the algorithm/m= ode? >> (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.) >> >> - 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? >> >> - 4.1: If I sign with a private key corresponding to a 2047 or 2049 bi= t 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 th= ink you >> can rule it out in all cases.) Since you don't include RSA here I gues= s 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. >> >> - 4.3: "cannot bleed" isn't clear enough maybe, give an example perhap= s where >> the decoder can fail to disambiguate a boundary? >> >> 4.4, last para: I disagree that one must (even lowercase >> must) check the signing identity. That's application behaviour and sh= ould be >> stated here in such concrete terms. >> At least s/must also/may also want to/ >> >> (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 increment= ing" or >> something? Otherwise I think this seems unclear. >> >> - 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?) >> >> - 8.2.1: you need a reference for batch signing. (Or could it be omitt= ed?) >> >> - 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:-) >> >> - 11: RFC2898 is about to be obsoleted by [1]. I suspect it'd be bette= r to refer to >> the draft as that should be published soon. (Same for RFC3447 btw.) >> >> [1] https://datatracker.ietf.org/doc/draft-moriarty-pkcs5-v2dot1/ >> >> - 12.4: Why "OKP"? And saying there's no "simple way" to do point vali= dation >> seems fairly opaque, a reference there or explanatory text would be go= od. (Ah, >> it's in section 13, maybe shuffle the text or include a pointer.) Octe= t key pair >> doesn't seem like that good a name to me btw. >> >> - 12.5: The 1st para seems wrong. (Or at least is unclear to >> me.) "Encrypted with and " 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 exp= lain? It'd >> be good to provide that for such relatively complex operations I think= =2E Is this >> what you mean? >> >> KW(KDF(DH-shared),CEK) >> >> - Table 22: The EC2 or OKP value is fixed per curve and the cryptograp= hic >> function being performed so seems unnecessary. >> Do you really need it so? Why? (I'm not buying that some future form o= f 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.) >> >> - 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). >> >> - section 19: I don't get how ECDSA is normative and the cfrg curves a= re not. >> Same for RFC6979. Maybe these all could do with checking? (No big deal= IMO >> but maybe worth it.) >> >> - Appendices A.1 (as already noted) and A.2 are a puzzle. >> Why say in the body of the document to do and then an appendix t= hat >> says how to do ? >> >> - Appendix C and the implementation status section: Many thanks - grea= t 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.h= tml >=20 >=20 --------------ms090700070206040301000204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMTYy MjQxMzlaMC8GCSqGSIb3DQEJBDEiBCAgiNhABfijOXV2lt70wKGUlFCToKLT4ObYMso91Ctj vDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQADDWuy9J7SCrG7eDl8ObpAo0lcc/UGjVsw/c8D9m0wBf4/+DS0kuAg XCp5y47BDICizEsF0aNsBuDt/eIfe2vTSepx01o2Yr2YgDQSW253STP/NzUNxoQxnKpevtbZ qGya8e6pi7WwdIRCS2kj89eCc5Uli6j93025OMHc7FZ46yXZe09ofgW5ZjVjNYgrehVPa+G9 0sLKyFNyeRX0WXdoeCEEGleSTMiAJNAVgpFvbJKOXzNteyv2O900XojuiBDfNyl5suvkXO7a 91iKrHpILaO9GLDhXlsipMlZsOkbjQW4CJUy3gop2wLtMbDfQrmNQFrcplx02hQawIEZeYWd AAAAAAAA --------------ms090700070206040301000204-- From nobody Sun Oct 16 15:42:49 2016 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1268129481; Sun, 16 Oct 2016 15:42:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147665776585.25862.148606130111503753.idtracker@ietfa.amsl.com> Date: Sun, 16 Oct 2016 15:42:45 -0700 Archived-At: Cc: cose-chairs@ietf.org, goran.selander@ericsson.com, cose@ietf.org, draft-ietf-cose-msg@ietf.org Subject: [COSE] Stephen Farrell's Discuss on draft-ietf-cose-msg-20: (with DISCUSS) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 22:42:46 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-cose-msg-20: 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: ---------------------------------------------------------------------- Thanks for the updates in -20. I think we've only the following points left. Note that all of those are questions to the WG chairs and not to Jim. (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 think we left the mail thread on this with you saying "Best to ask the chairs if they agree that this is WG consensus," as you're an admitteddly strong partisan on this topic. So, COSE chairs - what's your take? (If you say this is ok with the WG, I'll clear.) (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.) I think this is the similar to discuss point (2) above. So again, COSE chairs, can you confirm that this design does reflect WG consensus and isn't just a thorough and good editor getting his way? (If you say this is ok with the WG, I'll clear.) From nobody Sun Oct 16 15:58:29 2016 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F18129473; Sun, 16 Oct 2016 15:58:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147665870802.25897.423579786414842884.idtracker@ietfa.amsl.com> Date: Sun, 16 Oct 2016 15:58:28 -0700 Archived-At: Cc: cose@ietf.org Subject: [COSE] I-D Action: draft-ietf-cose-msg-21.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 22:58:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption of the IETF. Title : CBOR Object Signing and Encryption (COSE) Author : Jim Schaad Filename : draft-ietf-cose-msg-21.txt Pages : 121 Date : 2016-10-16 Abstract: Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) specification. This specification describes how to create and process signature, message authentication codes and encryption using CBOR for serialization. This specification additionally specifies how to represent cryptographic keys using CBOR. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cose-msg-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 16 20:32:02 2016 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F9D129576; Sun, 16 Oct 2016 20:32:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147667512114.25878.2641646693383494747.idtracker@ietfa.amsl.com> Date: Sun, 16 Oct 2016 20:32:01 -0700 Archived-At: Cc: cose@ietf.org Subject: [COSE] I-D Action: draft-ietf-cose-msg-22.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 03:32:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption of the IETF. Title : CBOR Object Signing and Encryption (COSE) Author : Jim Schaad Filename : draft-ietf-cose-msg-22.txt Pages : 121 Date : 2016-10-16 Abstract: Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) specification. This specification describes how to create and process signature, message authentication codes and encryption using CBOR for serialization. This specification additionally specifies how to represent cryptographic keys using CBOR. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cose-msg-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 16 20:37:40 2016 Return-Path: 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 E3354129569 for ; Sun, 16 Oct 2016 20:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, 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 unTZ49rOTywx for ; Sun, 16 Oct 2016 20:37:37 -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 3EC38129568 for ; Sun, 16 Oct 2016 20:37:37 -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; Sun, 16 Oct 2016 20:53:49 -0700 From: Jim Schaad To: References: <147667512114.25878.2641646693383494747.idtracker@ietfa.amsl.com> In-Reply-To: <147667512114.25878.2641646693383494747.idtracker@ietfa.amsl.com> Date: Sun, 16 Oct 2016 20:37:29 -0700 Message-ID: <02e501d22827$cabd60d0$60382270$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQHspmconfbgosbTxIH2NocIvYimgaB3AlVg X-Originating-IP: [24.21.96.37] Archived-At: Subject: [COSE] FW: I-D Action: draft-ietf-cose-msg-22.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 03:37:40 -0000 This update represents fixing the problems that IANA had raised during their review. This version was needed because I accidently lost some updates when -21 was published dealing with deterministic ECDSA. With this publication, I believe that all issues raised have been addressed and the IESG should be able to progress to the RFC editor queue. Jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Sunday, October 16, 2016 8:32 PM > To: i-d-announce@ietf.org > Cc: cose@ietf.org > Subject: [COSE] I-D Action: draft-ietf-cose-msg-22.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the CBOR Object Signing and Encryption of the IETF. > > Title : CBOR Object Signing and Encryption (COSE) > Author : Jim Schaad > Filename : draft-ietf-cose-msg-22.txt > Pages : 121 > Date : 2016-10-16 > > Abstract: > Concise Binary Object Representation (CBOR) is data format designed > for small code size and small message size. There is a need for the > ability to have basic security services defined for this data format. > This document defines the CBOR Object Signing and Encryption (COSE) > specification. This specification describes how to create and > process signature, message authentication codes and encryption using > CBOR for serialization. This specification additionally specifies > how to represent cryptographic keys using CBOR. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-cose-msg-22 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-22 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Mon Oct 17 08:38:33 2016 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2956D129455; Mon, 17 Oct 2016 08:38:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147671871216.4522.13176318555275171854.idtracker@ietfa.amsl.com> Date: Mon, 17 Oct 2016 08:38:32 -0700 Archived-At: Cc: cose-chairs@ietf.org, goran.selander@ericsson.com, cose@ietf.org, draft-ietf-cose-msg@ietf.org Subject: [COSE] Alexey Melnikov's No Objection on draft-ietf-cose-msg-22: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 15:38:32 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-cose-msg-22: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my earlier comments. I have one small issue that resulted in a recent change: This is a well written document, despite its length. Thank you for that. Some specific comments: content type: This parameter is used to indicate the content type of the data in the payload or cipher text fields. Integers are from the "CoAP Content-Formats" IANA registry table [COAP.Formats]. Text values following the syntax of Content-Type defined in Section 4.2 of [RFC6838] omitting the prefix string "Content- Type:". This is not quite right, as Section 4.2 of [RFC6838] doesn't define Content-Type header field. It defines: type-name = restricted-name subtype-name = restricted-name restricted-name = restricted-name-first *126restricted-name-chars restricted-name-first = ALPHA / DIGIT restricted-name-chars = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "-" / "^" / "_" restricted-name-chars =/ "." ; Characters before first dot always ; specify a facet name restricted-name-chars =/ "+" ; Characters after last plus always ; specify a structured syntax suffix So you should say something like this instead: Text values following the syntax "/", where and are defined in Section 4.2 of [RFC6838]. From nobody Tue Oct 18 11:20:19 2016 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97972129423; Tue, 18 Oct 2016 11:20:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147681481461.30714.1341264893502253060.idtracker@ietfa.amsl.com> Date: Tue, 18 Oct 2016 11:20:14 -0700 Archived-At: Cc: cose@ietf.org Subject: [COSE] I-D Action: draft-ietf-cose-msg-23.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 18:20:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption of the IETF. Title : CBOR Object Signing and Encryption (COSE) Author : Jim Schaad Filename : draft-ietf-cose-msg-23.txt Pages : 121 Date : 2016-10-18 Abstract: Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) specification. This specification describes how to create and process signature, message authentication codes and encryption using CBOR for serialization. This specification additionally specifies how to represent cryptographic keys using CBOR. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cose-msg-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-23 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 18 11:51:48 2016 Return-Path: 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 6E7711296CE for ; Tue, 18 Oct 2016 11:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, 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 MpTvqSD4L_oe for ; Tue, 18 Oct 2016 11:51:45 -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 998691296FD for ; Tue, 18 Oct 2016 11:51:44 -0700 (PDT) Received: from hebrews (50.45.239.150) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Oct 2016 12:07:55 -0700 From: Jim Schaad To: References: <147681481461.30714.1341264893502253060.idtracker@ietfa.amsl.com> In-Reply-To: <147681481461.30714.1341264893502253060.idtracker@ietfa.amsl.com> Date: Tue, 18 Oct 2016 11:51:36 -0700 Message-ID: <053301d22970$a8df2d00$fa9d8700$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQFjCKVqe8KlU+PpWZzoc8kaRqjfcqGMz94A X-Originating-IP: [50.45.239.150] Archived-At: Subject: [COSE] FW: I-D Action: draft-ietf-cose-msg-23.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 18:51:47 -0000 This version has a wording change suggested by Alexey about how content type fields are constructed. Nothing major. Jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Tuesday, October 18, 2016 11:20 AM > To: i-d-announce@ietf.org > Cc: cose@ietf.org > Subject: [COSE] I-D Action: draft-ietf-cose-msg-23.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the CBOR Object Signing and Encryption of the IETF. > > Title : CBOR Object Signing and Encryption (COSE) > Author : Jim Schaad > Filename : draft-ietf-cose-msg-23.txt > Pages : 121 > Date : 2016-10-18 > > Abstract: > Concise Binary Object Representation (CBOR) is data format designed > for small code size and small message size. There is a need for the > ability to have basic security services defined for this data format. > This document defines the CBOR Object Signing and Encryption (COSE) > specification. This specification describes how to create and > process signature, message authentication codes and encryption using > CBOR for serialization. This specification additionally specifies > how to represent cryptographic keys using CBOR. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-cose-msg-23 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-23 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Wed Oct 19 09:02:34 2016 Return-Path: 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 3972A129687; Wed, 19 Oct 2016 09:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.631 X-Spam-Level: X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, 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 ioa2ehTugQZr; Wed, 19 Oct 2016 09:02:24 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E3C129590; Wed, 19 Oct 2016 09:02:23 -0700 (PDT) X-AuditID: 12074423-efbff70000004bee-52-5807990d5e33 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 18.C8.19438.D0997085; Wed, 19 Oct 2016 12:02:21 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u9JG2Kex018715; Wed, 19 Oct 2016 12:02:20 -0400 Received: from [10.251.13.126] ([204.63.45.72]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u9JFxo9e024599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Oct 2016 12:02:15 -0400 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C1CA8B33-B76C-41DF-9F87-3EA703443D66"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Justin Richer In-Reply-To: Date: Wed, 19 Oct 2016 08:59:43 -0700 Message-Id: <822A08BC-5710-48E6-BCC7-AC86A554EFEC@mit.edu> References: <147665141739.25813.4419576200342341528.idtracker@ietfa.amsl.com> <029401d227f7$5cdb7fa0$16927ee0$@augustcellars.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA2VSfUgTYRjnvd1ut7WTa072trJoJmU2NQhZ+ZUQJvqPUKSFkKe73HCbejdN /UcJClK21HR+YPMTTY3yI6molJaElVqQpkwIE7FSDEGmJkLdeX5B//2e5/fxPC/vg4sUa2I1 brRYacZCmTSYDFVIffy0RI0kKeTW1xDd775+oHP0VYp1tpkpoPuxcF+iq94oE+k6q1ax81hs d10VFrvuGcdiW1r+IAmia7JwPW0y5tJMcGSKzOBeKZVkDa8ieZ7ph2gRcL5BioEUh+QZ+GBk BRQDGa4g7yDQNj2ECUU3gOX1LSKheITASodTzFu8yWS49nME8Jggg2DPk0WEF4nICgCH1opE Qq4Slgwvbxow0h/Wt7s350nJCOh5uo7xGOX6n2zDmGDuBbB5YgUTUs/B2cFGRBjdA6DdtbaZ pCSD4eveUYkwwRfOvm9CSwFZu2eT2r2b8ISITIVfBj5u4UDY2riwhQPgQEkb+n//BLy7UiYW 8BH4bLFuq38WNtdMbukjoNvegAg4Es44msQNYF8H8NWbC7Rmymhi6TQtm0ZZLDSjDQ0yG61B tD6nB/CfKrng9xz8sse7AIkDjZzouilJUoipXDbf7AIHcETjQ8jtXMsrNVOfb6BYw3Umx0Sz LnCMmzXT1fkZqFFLpoXWKAl9Bacj9FR+Ac1kbssO4qhGRfyN8SQqyHTKSmfQdBbNbLOHcFwD CXE1Z9zP0Ol03g2jybpLI7jUBSAu58KDeQ3BZlFm1pgu8B/AUbWKmKviCJInDDmWHS9/sMNR 2th5oOKe5U2U83Y5d8477nkuGOGCRy0oH2yldil1EbiMpY6/nTyle8U43b09V8Oi5ju+9Ucv bNiDsk3hzjLZZHRYjmq07mVD7r2LL+L8r8gnWqdymSZz4sDcY6841+xy1feU40pdoeF2yTuH s3egKSHePhZCUpewOVth+/TY4YzAsbb6giVJUuho/ohrrMwm8xjVMViAd7ZqUJ+8pEFZA3X6 pIhhqX+sPeg2iwMAAA== Archived-At: Cc: Jim Schaad , cose-chairs@ietf.org, The IESG , draft-ietf-cose-msg@ietf.org, goran.selander@ericsson.com, cose@ietf.org Subject: Re: [COSE] Stephen Farrell's Discuss on draft-ietf-cose-msg-20: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 16:02:28 -0000 --Apple-Mail=_C1CA8B33-B76C-41DF-9F87-3EA703443D66 Content-Type: multipart/alternative; boundary="Apple-Mail=_3D933C28-DC52-4B7D-99D8-D16058EA16FD" --Apple-Mail=_3D933C28-DC52-4B7D-99D8-D16058EA16FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Stephen, The consensus of the working group after Yokohama was to make the CDDL = non-normative and still use it as a description/example format. https://www.ietf.org/mail-archive/web/cose/current/msg00802.html = I believe the current draft reflects that state. Yes, CDDL syntax is = peppered throughout the document as illustration, but it=E2=80=99s the = English text that=E2=80=99s normative. One point that was discussed was that if the draft did not use CDDL, = then another description language would likely need to be made up to = make human-readable examples in the text. The group felt that it was = better to use an existing (even if unfinished/unofficial) description = format but remove the normative dependency. =E2=80=94 Justin, as chair. > On Oct 16, 2016, at 3:41 PM, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > Dear cose-chairs - there is stuff in this discuss for you to deal > with. (Just putting that there in case you're not delving down > into the body of the mails:-) >=20 > On 16/10/16 22:50, Jim Schaad wrote: >> I think we dealt with all of the comments. I cannot help you with = getting chair response. >>=20 >> See below for my one issue. >>=20 >> Jim >>=20 >>=20 >>> -----Original Message----- >>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >>> Sent: Sunday, October 16, 2016 1:57 PM >>> To: The IESG >>> Cc: draft-ietf-cose-msg@ietf.org; Goeran Selander >>> ; cose-chairs@ietf.org; >>> goran.selander@ericsson.com; cose@ietf.org >>> Subject: Stephen Farrell's Discuss on draft-ietf-cose-msg-20: (with = DISCUSS and >>> COMMENT) >>>=20 >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-cose-msg-20: Discuss >>>=20 >>> 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.) >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>>=20 >>> Thanks for the updates in -20. I think we've only the following = points left. Note >>> that 2 of those are questions to the WG chairs and not to Jim. >>>=20 >>> (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. >>>=20 >>> Can you help me see that the changes there are such that CDDL is ok = as >>> informative? I'm not sure but as I read it there is still no natural = language >>> statement that a "counter signature" is one (or more) COSE_Signature = values. >>=20 >> In section 1.3 the following text was added: >>=20 >> Two syntaxes from CDDL appear in this document as shorthand. These = are: >>=20 >> FOO / BAR - indicates that either FOO or BAR can appear here >> [+ FOO] - indicates that the type FOO appears one or more times in = an array >>=20 >> The value from the table is: >>=20 >> COSE_Signature / [+ COSE_Signature ] >>=20 >> Section 4.1 contains the text: >>=20 >> The CBOR object that carries the signature and information about the = signature is called the COSE_Signature structure. >>=20 >>> =46rom that I think that all of the needed normative text is = present. >=20 > Yeah, I get that. But then I think you've embedded some > CDDL notation at least as normative. (I mean the constructs > you describe with FOO/BAR above.) >=20 > While I do start to feel pedantry-panic that I'm saying > it, if really treating CDDL as informative, I think you > ought say in text that one or more COSE_Signature fields > need to be in a counter signature. >=20 > But I'm gonna clear that anyway as the whole CDDL is not > normative thing is really pretence IMO and there's no point > in me joining in with that further. >=20 > That means that clearing this discuss is now solely down > to the chairs saying they're happy that Jim's positions > do reflect wG consensus. >=20 > Cheers, > S. >=20 >=20 >=20 >=20 >>=20 >>>=20 >>> (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. >>>=20 >>> I think we left the mail thread on this with you saying "Best to ask = the chairs if >>> they agree that this is WG consensus," as you're an admitteddly = strong partisan >>> on this topic. >>>=20 >>> So, COSE chairs - what's your take? (If you say this is ok with the = WG, I'll clear.) >>>=20 >>> (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.) >>>=20 >>> I think this is the similar to discuss point (2) above. >>>=20 >>> So again, COSE chairs, can you confirm that this design does reflect = WG >>> consensus and isn't just a thorough and good editor getting his way? = (If you say >>> this is ok with the WG, I'll clear.) >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>>=20 >>> OLD COMMENTS BELOW, I DIDN'T CHECK THEM. Happy to chat more about = 'em >>> if that's useful. >>>=20 >>> - 1.4: the 2nd last paragraph is unclear to me. Probably just needs = re-phrasing. >>>=20 >>> - 1.5: I'd add a reference to RFC5116. >>>=20 >>> - 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.) >>>=20 >>> - 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. >>>=20 >>> - 3.1, "all the keys may need to be checked" - really? Or do you = mean all the >>> keys associated with this kid? >>>=20 >>> - 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.) >>>=20 >>> - 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? >>>=20 >>> - 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. >>>=20 >>> - 4.3: "cannot bleed" isn't clear enough maybe, give an example = perhaps where >>> the decoder can fail to disambiguate a boundary? >>>=20 >>> 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/ >>>=20 >>> (Note - the above were comments on -18, but also seem to work based = on -19. >>> Subsequent comments are on -19.) >>>=20 >>> - 7.1: "starting at the same base IV" - are you missing "and = incrementing" or >>> something? Otherwise I think this seems unclear. >>>=20 >>> - 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?) >>>=20 >>> - 8.2.1: you need a reference for batch signing. (Or could it be = omitted?) >>>=20 >>> - 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:-) >>>=20 >>> - 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.) >>>=20 >>> [1] https://datatracker.ietf.org/doc/draft-moriarty-pkcs5-v2dot1/ >>>=20 >>> - 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. >>>=20 >>> - 12.5: The 1st para seems wrong. (Or at least is unclear to >>> me.) "Encrypted with and " 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? >>>=20 >>> KW(KDF(DH-shared),CEK) >>>=20 >>> - 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.) >>>=20 >>> - 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). >>>=20 >>> - 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.) >>>=20 >>> - Appendices A.1 (as already noted) and A.2 are a puzzle. >>> Why say in the body of the document to do and then an appendix = that >>> says how to do ? >>>=20 >>> - Appendix C and the implementation status section: Many thanks - = great to see >>> that! (I didn't check 'em though:-) >>>=20 >>> - Thanks also for speedily handling the extensive secdir review. >>>=20 >>> [2] = https://www.ietf.org/mail-archive/web/secdir/current/msg06801.html --Apple-Mail=_3D933C28-DC52-4B7D-99D8-D16058EA16FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Stephen,

The consensus of the working group after Yokohama was to make = the CDDL non-normative and still use it as a description/example = format. 

https://www.ietf.org/mail-archive/web/cose/current/msg00802.htm= l

I = believe the current draft reflects that state. Yes, CDDL syntax is = peppered throughout the document as illustration, but it=E2=80=99s the = English text that=E2=80=99s normative.

One point that was discussed was that = if the draft did not use CDDL, then another description language would = likely need to be made up to make human-readable examples in the text. = The group felt that it was better to use an existing (even if = unfinished/unofficial) description format but remove the normative = dependency.

 =E2=80=94 Justin, as chair.

On = Oct 16, 2016, at 3:41 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


Hiya,

Dear cose-chairs - there is stuff in this = discuss for you to deal
with. (Just putting that there in case = you're not delving down
into the body of the mails:-)

On 16/10/16 22:50, Jim Schaad = wrote:
I think = we dealt with all of the comments.  I cannot help you with getting = chair response.

See below for my one = issue.

Jim


-----Original = Message-----
From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
Sent: = Sunday, October 16, 2016 1:57 PM
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-20: = (with DISCUSS and
COMMENT)

Stephen Farrell has entered the following ballot position = for
draft-ietf-cose-msg-20: 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.htmlfor 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:
---------------------------------------------------------------= -------


Thanks for the = updates in -20. I think we've only the following points left. Note
that 2 of those are questions to the WG chairs and not to = Jim.

  (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.
Can you help me see that the changes there are such that = CDDL is ok as
informative? I'm not sure but as I read it = there is still no natural language
statement that a = "counter signature" is one (or more) COSE_Signature values.

In section 1.3 the following text = was added:

Two syntaxes from CDDL appear in = this document as shorthand. These are:

   FOO / BAR - indicates that either FOO or = BAR can appear here
   [+ FOO] - indicates = that the type FOO appears one or more times in an array

The value from the table is:

COSE_Signature / [+ COSE_Signature ]

Section 4.1 contains the text:

The= CBOR object that carries the signature and information about the = signature is called the COSE_Signature structure.

=46rom that I think that = all of the needed normative text is present.

Yeah, I get that. But then I think you've = embedded some
CDDL notation at least as normative. (I mean the = constructs
you describe with FOO/BAR above.)

While I do start to feel pedantry-panic = that I'm saying
it, if really treating CDDL as informative, I = think you
ought say in text that one or more = COSE_Signature fields
need to be in a counter = signature.

But I'm gonna clear = that anyway as the whole CDDL is not
normative thing is really pretence IMO = and there's no point
in me joining in with that = further.

That means that = clearing this discuss is now solely down
to the chairs saying they're happy that = Jim's positions
do reflect wG consensus.

Cheers,
S.






  (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 think we left the mail = thread on this with you saying "Best to ask the chairs if
they agree that this is WG consensus," as you're an = admitteddly strong partisan
on this topic.
So, COSE chairs - what's your take? (If you say this is ok = with the WG, I'll clear.)

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

I think this is the similar to discuss point (2) above.

So again, COSE chairs, can you confirm that = this design does reflect WG
consensus and isn't just a = thorough and good editor getting his way? (If you say
this = is ok with the WG, I'll clear.)


---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------


OLD COMMENTS BELOW, = I DIDN'T CHECK THEM. Happy to chat more about 'em
if = that's useful.

- 1.4: the 2nd last = paragraph is unclear to me. Probably just needs re-phrasing.

- 1.5: I'd add a reference to RFC5116.

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

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

- = 3.1, "all the keys may need to be checked" - really?  Or do you = mean all the
keys associated with this kid?

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

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

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

- 4.3: "cannot bleed" isn't clear enough = maybe, give an example perhaps where
the decoder can fail = to disambiguate a boundary?

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/

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

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

- 8.2.1: you need a reference for batch = signing. (Or could it be omitted?)

- = 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:-)

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

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

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

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

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

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

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

- 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.h= tml

= --Apple-Mail=_3D933C28-DC52-4B7D-99D8-D16058EA16FD-- --Apple-Mail=_C1CA8B33-B76C-41DF-9F87-3EA703443D66 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYB5hvAAoJEDPAngkbd+w9AcQH+wQaclVXnLHXefWsdXcM1hW0 TVkJB7GF2FpVJzNA8hsM1ncASN/xS7YOTvZjVHBEBPo0rvwQ9e3M7XQDZGH0tJyV 7hu+/Yfl3z/lvKkkp6e0yxZD4cxT7RYSAnU3C0coQthQBEpKR3dLktSbCDBx6Uyy ZPSv/FwhzDd75qnbEMpCzkBedE0YJXxsDO7IkkoGmc2vSnKsKePdML2sNt9ja9/x frVdIUUMQ1OX2Z/H9+amU2zcQ26n4x19rkUuk/3lY5s3lngOay9lK9Dddn2wm9j4 QvXtBCPuYhU3LKbsnISdvn0fln41r4eJgx6niBfLlsDstikUI5SNYDav9O5JIso= =Gcy8 -----END PGP SIGNATURE----- --Apple-Mail=_C1CA8B33-B76C-41DF-9F87-3EA703443D66-- From nobody Sat Oct 22 01:45:37 2016 Return-Path: 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 22C58129440; Sat, 22 Oct 2016 01:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=2.699, RCVD_IN_DNSWL_MED=-2.3] autolearn=no 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 IkVMbQZK5nb9; Sat, 22 Oct 2016 01:45:30 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06D41293D6; Sat, 22 Oct 2016 01:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u9M8jOf9021213; Sat, 22 Oct 2016 10:45:24 +0200 (CEST) Received: from client-0074.vpn.uni-bremen.de.mail (client-0074.vpn.uni-bremen.de [134.102.107.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3t1GMX3vQYz7xR8; Sat, 22 Oct 2016 10:45:11 +0200 (CEST) Date: Sat, 22 Oct 2016 10:42:20 +0200 From: Carsten Bormann To: cose@ietf.org, dtls-iot@ietf.org, t2trg@irtf.org, ace@ietf.org, core@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Airmail (390) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="580b270a_37ba36b9_ff73" Archived-At: Subject: [COSE] Constrained Node/Network Cluster @ IETF97: FINAL AGENDA X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 08:45:33 -0000 --580b270a_37ba36b9_ff73 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Here is my usual eclectic condensed agenda based on the =22=46INAL=22 AGE= NDA for IET=4697. =C2=A0(=22=46INAL=22 historically has not always been =22fi= nal=22...) Not many changes; TOKBIND, OAUTH, CURDLE moved around, and the big clashing cluster on =46riday morning has become bigger with another TLS session. =C2=A0(I previously wrote: IoT is starting a bit late at IET=469= 7; only two meetings of cluster WGs on Mon/Tue (but then of course we start big with the Sunday icnrg/t2trg joint meeting). =C2=A0CORE on HOMEN= ET and IPWAVE (Wed) and CORE on ICNRG (=46ri) are a bit painful but probably the unavoidable level of conflict.) All times are KST (UTC+0900) -- there is no DST in Korea, and DST will have ended in Europe and North America by then. (The browser timezone function still is not yet reinstated on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SUNDAY, November 13, 2016 1300-1600 =C2=A0 =C2=A0 =C2=A0 IRT=46*** icnrg+t2trg joint meeting MONDAY, November 14, 2016 0930-1200 =C2=A0Morning Session I Grand BR 2 ART dispatch Dispatch WG - 09:30-11:00 Studio 3 SEC oauth Web Authorization Protocol WG 1330-1530 =C2=A0Afternoon Session I Studio 3 ART ice Interactive Connectivity Establishment WG Park BR 1 IRT=46 cfrg Crypto =46orum Grand BR 2 OPS v6ops IPv6 Operations WG 1550-1750 =C2=A0Afternoon Session II Grand BR 2 INT *** lpwan IPv6 over Low Power Wide-Area Networks WG Studio 3 RTG bier Bit Indexed Explicit Replication WG Studio 4 SEC tokbind Token Binding WG TUESDAY, November 15, 2016 0930-1200 =C2=A0Morning Session I Grand BR 2 INT 6man IPv6 Maintenance WG Park BR 1 RTG detnet Deterministic Networking WG Grand BR 1 TSV quic QUIC WG 1330-1530 =C2=A0Afternoon Session I Park BR 2 ART httpbis Hypertext Transfer Protocol WG Grand BR 2 RTG rtgarea Routing Area Open Meeting Park BR 1 TSV tsvwg Transport Area Working Group WG 1550-1820 =C2=A0Afternoon Session II Grand BR 2 INT *** 6lo IPv6 over Networks of Resource-constrained Nodes W= G Park BR 1 SEC tls Transport Layer Security WG WEDNESDAY, November 16, 2016 0930-1100 =C2=A0Morning Session I Grand BR 3 OPS anima Autonomic Networking Integrated Model and Approach W= G Grand BR 2 TSV taps Transport Services WG 1110-1210 =C2=A0Morning Session II Park BR 2 RTG *** roll Routing Over Low power and Lossy networks WG Grand BR 1 TSV tsvwg Transport Area Working Group WG 1330-1500 =C2=A0Afternoon Session I Studio 2 ART *** core Constrained RESTful Environments WG Grand BR 1 INT homenet Home Networking WG Grand BR 3 INT ipwave IP Wireless Access in Vehicular Environments WG Studio 4 SEC acme Automated Certificate Management Environment WG Grand BR 2 TSV tsvarea Transport Area Open Meeting 1520-1620 =C2=A0Afternoon Session II Park BR 2 INT intarea Internet Area Working Group WG Park BR 1 IRT=46*** t2trg Thing-to-Thing Studio 3 SEC oauth Web Authorization Protocol WG THURSDAY, November 17, 2016 0930-1100 =C2=A0Morning Session I Park BR 1 INT *** 6tisch IPv6 over the TSCH mode of IEEE 802.15.4e WG Studio 4 INT dnssd Extensions for Scalable DNS Service Discovery =C2=A0WG= Grand BR 2 IRT=46 maprg Measurement and Analysis for Protocols Grand BR 1 SEC saag Security Area Open Meeting 1110-1210 =C2=A0Morning Session II Park BR 1 ART httpbis Hypertext Transfer Protocol WG Grand BR 3 INT *** lwig Light-Weight Implementation Guidance WG Grand BR 1 SEC saag Security Area Open Meeting 1520-1750 =C2=A0Afternoon Session II Studio 4 SEC *** ace Authentication and Authorization for Constrained Env= ironments WG Studio 3 TSV rmcat RTP Media Congestion Avoidance Techniques WG =46RIDAY, November 18, 2016 0930-1130 =C2=A0Morning Session I Studio 2 ART *** core Constrained RESTful Environments WG Grand BR 3 IRT=46 icnrg Information-Centric Networking Park BR 2 OPS anima Autonomic Networking Integrated Model and Approach WG= Grand BR 2 SEC tls Transport Layer Security WG Studio 4 TSV tcpinc TCP Increased Security WG 1150-1320 =C2=A0Afternoon Session I Studio 2 ART webpush Web-Based Push Notifications WG Studio 4 ART webpush Web-Based Push Notifications WG Park BR 2 RTG babel Babel routing protocol WG Park BR 1 RTG babel Babel routing protocol WG Studio 3 SEC curdle CURves, Deprecating and a Little more Encryption WG --580b270a_37ba36b9_ff73 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline