Re: [COSE] Stephen Farrell's Discuss on draft-ietf-cose-msg-19: (with DISCUSS and COMMENT)

Jim Schaad <ietf@augustcellars.com> Thu, 06 October 2016 03:25 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 <ietf@augustcellars.com>
To: 'Stephen Farrell' <stephen.farrell@cs.tcd.ie>, 'The IESG' <iesg@ietf.org>
References: <147506634324.16628.6590617577304586745.idtracker@ietfa.amsl.com> <076601d21d38$1e5162f0$5af428d0$@augustcellars.com> <21d32017-8dc8-5971-ef5c-b2083cdb6848@cs.tcd.ie>
In-Reply-To: <21d32017-8dc8-5971-ef5c-b2083cdb6848@cs.tcd.ie>
Date: Wed, 05 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: <https://mailarchive.ietf.org/arch/msg/cose/W1p786EDelrrlUqWDHw-uOBpBMg>
Cc: cose-chairs@ietf.org, cose@ietf.org, draft-ietf-cose-msg@ietf.org, goran.selander@ericsson.com
Subject: Re: [COSE] Stephen Farrell's Discuss on draft-ietf-cose-msg-19: (with DISCUSS and COMMENT)
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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=https://www.ietf.org/id/draft-ietf-cose-msg&url2=https://cose-wg.github.io/cose-spec/draft-ietf-cose-msg.txt



> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> Sent: Monday, October 03, 2016 3:16 AM
> To: Jim Schaad <ietf@augustcellars.com>; 'The IESG' <iesg@ietf.org>
> Cc: cose-chairs@ietf.org; goran.selander@ericsson.com; cose@ietf.org; draft-
> ietf-cose-msg@ietf.org
> Subject: Re: [COSE] Stephen Farrell's Discuss on draft-ietf-cose-msg-19: (with
> DISCUSS and COMMENT)
> 
> 
> Hi Jim,
> 
> On 03/10/16 06:36, Jim Schaad wrote:
> > Stephen,
> >
> > Answers and questions interspersed below along with some - yes I need
> > to do that.  I should be able to get to those in the first half of
> > this week.  Am building a github branch for responses if you want to
> > look at things as we go along.
> 
> Good stuff. Some answers below where they seem useful.
> 
> >
> > Jim
> >
> >
> >> -----Original Message----- From: Stephen Farrell
> >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, September 28,
> >> 2016 5:39 AM To: The IESG <iesg@ietf.org> Cc:
> >> draft-ietf-cose-msg@ietf.org; Goeran Selander
> >> <goran.selander@ericsson.com>; cose-chairs@ietf.org;
> >> goran.selander@ericsson.com; cose@ietf.org Subject: Stephen
> >> Farrell's Discuss on draft-ietf-cose-msg-19: (with DISCUSS and
> >> COMMENT)
> >>
> >> Stephen Farrell has entered the following ballot position for
> >> draft-ietf-cose-msg-19: Discuss
> >>
> >> When responding, please keep the subject line intact and reply to
> >> all email addresses included in the To and CC lines. (Feel free to
> >> cut this introductory paragraph, however.)
> >>
> >>
> >> Please refer to
> >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more
> >> information about IESG DISCUSS and COMMENT positions.
> >>
> >>
> >> The document, along with other ballot positions, can be found
> >> here: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/
> >>
> >>
> >>
> >> ----------------------------------------------------------------------
> >>
> >>
> DISCUSS:
> >> ----------------------------------------------------------------------
> >>
> >>
> >>
> >>
> I think this is a fine design and well documented, (though
> >> long) and I'm sure we'll clear up the points below quickly enough.
> >> Some of them may need some discussion but others are mostly
> >> checking.
> >>
> >> (1) general: I think the inclusion of CDDL is an error here and
> >> we'd be better off having someone (if interested) generate the CDDL
> >> schema stuff later on when/if CDDL is standardised/stabilised.
> >> Including it now creates the potential for breakage unnecessarily
> >> IMO. However, the WG did explicitly discuss iirc, so this is just a
> >> personal comment that I'm also in the rough on inclusion of CDDL in
> >> this spec. (As an example, for someone not familiar with CDDL, the
> >> inclusion of fragments interspersed in the text is distracting and
> >> potentially puzzling when one gets to the end of section 3.)
> >> However, I do think there are places where the CDDL is effectively
> >> normative despite what is said in the introduction, the ones I've
> >> spotted are below. (Happy to chat about 'em as I may be mistaken.)
> >> I also wondered if one could really implement this if all the CDDL
> >> was removed from the text, which is what I think would be required
> >> if CDDL were really to be informative. Anyway the places I think
> >> some more text may be needed are:
> >
> >
> > I build a version of the document with no CDDL, I have added some
> > pointers to the use of "/" and "[+ FOO]" to the CDDL preview section
> > at the top of the document.  I have also identified the structures
> > Sig_structure and Enc_structure like I did the Mac_structure in the
> > text.  (Also found a COSE_Encrypt that should have been a
> > COSE_Encrypt0.)
> >
> >>
> >> (1.1) table 2: As-is the value type column seems to me to make CDDL
> >> normative. I don't see the natural language version that you said
> >> would be normative.
> >>
> >> (1.2) 4.4, 2nd list point 1: the use of Sig_structure makes the
> >> CDDL normative. (Same with the use in 4.5 and Enc_structure in
> >> 5.3.)
> >>
> >> (1.3) 7.1, the key_ops value is only specified in CDDL, in Table 3.
> >> (It is well- defined below the table in text though, so this one's
> >> borderline.)
> >
> > The description for key_ops points to Table 3, so I think it is fully
> > supplied.
> >
> >>
> >> (1.4) 11.2: it's not clear to me that a reader knows how to handle
> >> decoding of the two optional fields at the end (other and
> >> SuppPrivInfo) without looking at the CDDL. Can you explain? (That
> >> might be just my ignorance of CBOR, but wanted to check.)
> >
> > I am not sure that I would know how to do it even with CDDL, however
> > in this case that is a moot question as this structure is only
> > encoded and never transmitted or decoded.
> >
> > Will also note, that you have better eyes than me as I do not see two
> > optional fields at the end.  I see one optional field at the end of
> > two different arrays, so that would be a CBOR ignorance I think.
> 
> I'd say we should be able to kill this discuss point easily
> with the changes you're making.
> 
> >
> >>
> >> (2) 3.1, alg: so you're disallowing a setup where the kid alone
> >> identifies the key and algorithm to the recipient? That is used in
> >> some IETF protocols (OSPF iirc) so rhat's a pity, and will in
> >> those (maybe less common) cases consume a few bytes that could
> >> otherwise be saved.  I think, but am not sure, that the WG already
> >> discussed this, but if not, maybe worth a thought? (Or even a 2nd
> >> thought:-) And appendix A.1 is really puzzling - as it provides
> >> instructions for how to not follow a MUST in the body of the
> >> document.
> >
> > I have come around to the feeling that the algorithm needs to be part
> > of the value that is being authenticated as part of all of the
> > messages.
> 
> Is that just a feeling of yours or are we confident it
> represents WG consensus? (Honest question - I just don't
> recall.)

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

> 
> > This being the case, the only what that it can be enforced
> > is to make the algorithm be a part of the protected attributes.   In
> > my mind the cost of the 2 bytes for this purpose seems to be
> > sufficiently small that including it does not seem to be a large
> > burden.
> >
> > There were several people in the IoT world who felt as you that one
> > could have an implicit algorithm and they did not want to spend the
> > two bytes for the purpose of including it in the AEAD.  This being
> > the case, I did provide the appendix to tell how to do this.  I
> > expect that people are going to do this and not following the
> > guidance that was provided about making sure that the algorithm is
> > authenticated.
> 
> Right, but isn't that then pretty much an RFC6919 "MUST, but
> we know you (sometimes) won't"? I just don't see how that helps
> with interop.
> 
> I do agree that it's conceivable that the lack of an alg in
> a protocol could lead to vulnerabilities. However, there are
> clearly cases where a protocol can be secure without an
> explicit alg, and we know that folks will do that optimisation
> sometimes, so I think the most that'd be right is a SHOULD,
> but likely a MAY is even better. (If however, there's a clear
> WG consensus to take the RFC6919 route, then I'll get out of
> the way, but with an "I told you so" in my back pocket;-)


Let's leave it here for now and revisit when we have more info and we are doing an update/advancement of the document.

> 
> >
> >>
> >> (3) 7.1: key_op 8, "derive bits" - I don't think this usage is
> >> clear enough, can you say what's meant here?
> >
> > Derive bits was added to the JOSE documents in response to the W3C
> > WebCrypto work where they wanted to be able to control that something
> > could derive bits but not derive a key.  These were initially not
> > present in this document but was added by request so that it would
> > match what the JWK document had.  The description in JWK is "derive
> > bits not to be used as a key".  Does that read better?  If so I can
> > change this.
> 
> That is clearer yes. Maybe add a pointer to the JWK doc as well?
> I'm not convinced of the utility myself though but so long as
> it's clearly described then that'll sort this discuss point.

Done

> 
> >
> >>
> >> (4) Why not make deterministic ECDSA a MUST?  8.1.1 says:
> >> "Applications that specify ECDSA should evaluate the ability to get
> >> good random number generation and require deterministic signatures
> >> where poor random number generation exists."  I don't think that is
> >> sufficiently clear, nor realistic, and I don't recall this being
> >> discussed on the list (sorry if I'm forgetting) and bad random
> >> values are a killer flaw here that has happened in the wild.
> >
> > It is not clear to me that many, if any, current packages support the
> > concept of doing deterministic ECDSA.
> 
> But they don't to COSE either so I'm not clear that's a good
> argument unless there's evidence that crypto libraries likely
> to be used for COSE won't include deterministic ECDSA. (That
> last would be a surprise given that deterministic is clearly
> superior.)
> 
> > If this case it seems to be
> > odd that we would require it.   I can do some research to figure this
> > out.
> 
> Cool. Be interested in what you find.

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.

> 
> >
> >>
> >> (5) Table 6, is this 25519 or 448? Where does it say?  Sorry if I'm
> >> being dumb here, but I don't see where you say which curve is
> >> specified, the definition of 'crv' says defined for this alg which
> >> I assume means listed in Table 6.
> >
> > The value of 'crv' is defined in table 22.  The same algorithm is
> > used to identify all of the curves.
> 
> I'm still not getting that but didn't yet re-read the doc. I will
> as we go so let's punt on this for the moment.

ack

> 
> >
> >>
> >> (6) section 10: why MUST the kty values be present always? That
> >> seems unnecessary in some contexts and I don't get a security
> >> reason why it's needed e.g. if there's an alg id somewhere - can
> >> you explain? I can see folks omitting this leading to interop
> >> problems for not useful reasons. (Same comment applies in other
> >> cases where kty is a MUST, e.g. 12.1.2, 12.2.1.)
> >
> > This follows what JOSE did in in RFC 7517 (JWK).  I might, or might
> > not, agree with you that specifying an algorithm would be sufficient.
> > Consider one of the ECDH-ES variants.  It is defined to work with
> > keys of the key type 'EC2' as well as 'OKP'.  These two key types
> > have different sets of required parameters but some of them overlap.
> > Specifically, 'x' is in both but 'y' is only in one of them.  In this
> > case the additional parameter of 'crv' could also be used to
> > distinguish them but a generic piece of code looking only at the
> > algorithm would not have enough detail.
> 
> Hmm. Still not convinced, but I'll look again as we go. This is
> I guess similar to the issue with the alg as a MUST in that we
> can be pretty sure some folks will ignore that MUST I think.
>

Until we have more info - I think we just differ on this one.
 
> >
> >>
> >> (7) section 11: given that we know people will use human memorable
> >> secrets, why have you not defined codepoints for PBES2 (or the more
> >> commonly supported?) PBDKF2?  I'm fine if there's a reason, or even
> >> if it was discussed by the WG, but just wanted to check as I'd
> >> worry that folks will use the ones defined here with human
> >> memorable secrets no matter what the spec says so giving 'em
> >> something more tailored might be better. (OTOH, one could argue
> >> that making this apparent might be worse too I guess.)
> >
> > This was part of the secondary algorithm draft which the WG decided
> > not to do as part of the 'we are not going to do RSA at this time'.
> > I expect that I will write an individual draft to cover these.  It
> > was also not clear to me that small devices were going to be using
> > this type of secret to start with in any event.
> 
> Fair enough. Consider this bit sorted.

ack

> 
> >
> >>
> >> (8) 12.4: Why is no ephemeral-ephemeral (E-E) variant supported?
> >> Some protocols will allow for that and it seems wrong to disallow
> >> it when it could relatively easily be supported. For some
> >> applications where content is dealt with in store-and-forward mode,
> >> there may be situations (e.g. provisioning, "introduction") where
> >> E-E could be used. As-is, applications wanting that will have to
> >> hack the recipient DH-public into a home-grown structure (or use
> >> one of the COSE_Key labels from Table 19) and then treat that as
> >> ES-DH. That seems likely to lead to non-interop or security errors
> >> being made. I'd be fine if you even said how to re-use the
> >> structures currently defined for E-E btw and didn't introduce new
> >> structures.
> >
> > See https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe/
> > for how this is being addressed.
> 
> Hmm. No 25519? Odd that. But fair enough I suppose if it's being
> handled somewhere.

They are thinking about putting it in - so it will probably show up given some time.

> 
> >
> >>
> >> (9) 16.4: I'm not sure expert review is right here.  What if the
> >> expert is asked to add SM2/SM4 while there is still no widely
> >> available non-Chinese text to describe those?  I think the expert
> >> ought enforce a "specification required" rule at least and maybe
> >> more.  (And ought never allow an algorithm with no specification
> >> publicly available.)
> >
> > This view was advanced by several people in the WG as well.  My worry
> > about this position is that it might encourage point squatting.  I
> > cannot respond for other experts, but I would ask for a usable
> > description of the algorithm.  If I was not familiar I would also
> > request either additional review from CFRG and/or conference papers
> > on the algorithm.  If it was not a publicly available specification,
> > I would then assign a "non-optimal" point.  My expectation is that
> > there are going to be more small networks of IoT devices than there
> > are for TLS systems.  This means that it is more likely that
> > localized algorithms may be desired.
> 
> Yeah but desired-by-someone != desirable-for-the-Internet :-)
> 
> I would worry about less well reviewed lightweight crypto in this
> space - that'll be attractive for implementers/vendors but might
> not be a good plan.
> 
> >
> > I am not against raising the level to specification required, but
> > would worry about point squatting.
> >
> > If this is not "expert review" what do you believe would be a better
> > requirement?  I do not believe this should be dumped on either the
> > IESG or CFRG.
> 
> I think expert review with specification required is maybe right
> with the guidance tightened up along the lines you state above.
> (But see below.)
> 
> >
> >>
> >> (10) 16.4 (and elsewhere maybe) I think this registry is missing a
> >> column - as is being done in the TLS WG, I think there should be a
> >> column saying if the IETF is happy enough with an algorithm and
> >> that getting a "Y" in that ought require standards action. (Or some
> >> similar scheme.) I don't think the standards-track range of
> >> codepoints is enough here, e.g. at some time we will want to
> >> deprecate things, and at other times we may want to define things
> >> for the future on the standards-track but not (yet) recommend their
> >> use.  The last bullet in 16.11 does help here, but I'd argue that
> >> we need to do more to protect the expert (and implementers) from
> >> the trickle of vanity/national algorithms/curves that are always
> >> being proposed.
> >
> > I would not object to doing this.  While I don't know if the TLS
> > experiment on this is going to work, I don't have any problems with
> > participating in the same experiment here as well.
> 
> Great. If we do that then I think the expert's job can be easier
> as it'll be much clearer what the IETF likes. (And that'd sort
> my discuss point #9 too.)

Done

> 
> >
> > I am not sure what we should say for deprecation of algorithms here
> > should be, they are going to live for a long time and new systems
> > will probably ship with the same algorithms as long as they need to
> > interoperate.  Consider the lighting use case that is being fought
> > over in ACE right now.  You cannot put a new light bulb in that uses
> > a different algorithm unless you are willing to start broadcasting
> > two messages.  This is probably going to lead to very slow
> > deprecation over time.
> 
> Well, it's always slow. But I think if we can clearly see from the
> registry what the IETF currently likes, then implementers should
> have an easier time. I'd have no objection if the extra column
> wasn't just a binary y/n, but I think it's hard to come up with
> good semantics for anything else. (Where "y" just means that the
> IETF currently likes the registry entry.)
> 
> >
> >
> >>
> >>
> >> ----------------------------------------------------------------------
> >>
> >>
> COMMENT:
> >> ----------------------------------------------------------------------
> >>
> 
> I'll go over these later if that's ok, gotta do another thing
> right now;-) Please ping me if you need a response before you
> do edits though.
> 
> Cheers,
> S.
> 
> 
> >>
> >>
> >>
> >>
> - 1.4: the 2nd last paragraph is unclear to me. Probably just needs
> re-phrasing.
> >
> > Which is unclear, the problem or the action?
> >
> >>
> >> - 1.5: I'd add a reference to RFC5116.
> >
> > Reasonable and done.
> >
> >>
> >> - 3.1, crit: The statement that security libraries or application
> >> code can handle this is odd - isn't that an API requirement? (I'm
> >> not objecting, but it's odd.)
> >
> > I agree that this is an API requirement.
> >
> >>
> >> - 3.1, "content type" is the space there intended?  If so, maybe
> >> add quotes or a comma or something to disambiguate the name and
> >> descriptive text? Same for other multi-word names here.
> >
> > Given that this is the second person suggesting this (also in Gen-Art
> > review). I am going to add a colon to deal with this.

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 <foo> and <bar>" seems ambiguous anyway, does it
> >> mean double encryption or two parallel ciphertexts? (I assume the
> >> former.) What's the algebraic thing you're trying to explain?
> >> It'd be good to provide that for such relatively complex operations
> >> I think. Is this what you mean?
> >>
> >> KW(KDF(DH-shared),CEK)
> >
> > Yes that is the formula and yes it makes sense to document it in that
> > manner.

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 <foo> and then an appendix that
> >> says how to do <not-foo>?
> >
> > Answer above.
> >
> >
> > Jim
> >
> >
> >>
> >> - Appendix C and the implementation status section: Many thanks -
> >> great to see that! (I didn't check 'em though:-)
> >>
> >> - Thanks also for speedily handling the extensive secdir review.
> >>
> >> [2]
> >> https://www.ietf.org/mail-archive/web/secdir/current/msg06801.html
> >>
> >
> >
> > _______________________________________________ COSE mailing list
> > COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
> >