Hi Jim, 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.
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. >>> >>> 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. Fair enough - cose WG chairs, what do you think? >>>> (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. Saw that and thanks. Be interesting to see if anyone objects to this good change. >>>> ---------------------------------------------------------------------- >>>> >>>> >> >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >> >> >>>> - 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 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) >>>> 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 I still think "must" isn't right and "may" is correct >>>> - 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 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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
