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

[[e-mail]]

Thank you, Jim.  I'll double check before you post the next version.

Kathleen 

Please excuse typos, sent from handheld device 

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