Re: [secdir] secdir review of cose-msg-18

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Friday, September 23, 2016 10:54 AM
> To: Jim Schaad <[e-mail]>; 'secdir' <[e-mail]>; 'Justin
> Richer' <[e-mail]>; 'Kepeng Li' <[e-mail]>; 'Kathleen
> Moriarty' <[e-mail]>
> Subject: Re: secdir review of cose-msg-18
> 
> Jim,
> 
> Thanks for making the changes you describe as done. Comments below on the
> few remaining items.
> 
> > Applications should have a statement if the label can be omitted.
> > -> Applications SHOULD (?) have a statement if the label can be omitted.
> >
> > [JLS] I believe that lower case is correct here.  This would not be a
> > requirement on the COSE protocol, but on the application that is using
> > COSE.  It does not make sense to me to have 2119 language for this
> > type of statement.  (Partly from an initial brow beating from Russ.)
> OK.
> > Integers are from the "CoAP Content-Formats" IANA registry table. (no
> > reference)
> >
> > [JLS] What do you think should be referenced here?  Are you looking for a URL
> to iana.org?  Not sure that this makes sense.
> When you refer to IANA registries defined in the doc you cite the relevant
> section of the doc. Since this registry already exists I think it would be
> appropriate to include a pointer to it:
> http://www.iana.org/assignments/core-parameters/core-parameters.xhtml

I am not overwhelmed, but I will do this

> > As the IV is authenticated by the encryption process, it can be placed
> > in the unprotected header bucket. (in general, an encryption process
> > will not “authenticate” an IV, but use of a modified IV will yield
> > mangled plaintext, which can be detected by an integrity check or a
> > signature. the same comment applies to the similar statement in the
> > “partial IV” description.)
> >
> > [JLS] Does this work?
> >
> > The IV can be placed in the unprotected header as modifying the IV will cause
> the decryption of the plaintext to fail.
> How about:
> 
> The IV can be placed in the unprotected header as modifying the IV will cause
> the decryption to yield plaintext that is readily detectable as garbled.

That works for me.  Will do

> 
> 
> The decryption process will not, itself, detect any error, so it will not "fail" per
> se.
> 
> Steve