> -----Original Message-----
> From: Michael Richardson <[email protected]>
> Sent: Thursday, July 23, 2020 3:08 PM
> To: Jim Schaad <[email protected]>; [email protected]
> Subject: Re: [COSE] COSE Struct Discuss
>
>
> I'm sorry, I've been pretty much unaware of the 8152bis effort.
> I feel rather embarrassed about that, having written some code that did
not
> (yet) fully interoperate with Jim's code (That TODO item shouts at me
daily)
>
> Jim Schaad <[email protected]> wrote:
> > During the IESG review of draft-ietf-cose-rfc8152bis-struct a
DISCUSS was
> > raised that it took a while to convince me was a real problem and I
have
> > been since looking at this to try and figure out if there were any
good
> > answers. Unfortunately I did not find anything that I really liked.
So
> > this is going to the list to try and get some type of resolution for
the
> > problem.
>
> > All of the structures start out the same
> > * bstr w/ protected attributes
> > * map w/ unprotected attributes
> > * bstr w/ some type of content
> > * Array of items above (i.e. recipients) or nothing
>
> > For all but four of the COSE message structures, what goes into the
second
> > bstr is some type of cryptographically computed value and thus
applying a
> > countersignature to that value provides additional benefits.
>
> I found your words "second bstr" mystyfing because it maps to "* bstr w/
some
> type of content"
> rather than the "second" item, "map w/ unprotected attributes" :-) Next
time,
> can we number the items...
>
> > COSE_Signature has this layout, but it does not have any
cryptographically
> > computed values so the document describes putting a countersignature
on
> this
> > structure as being the same as adding a parallel signature.
>
> I understand this part.
>
> > The last three structures have one additional bstr added so that you
get
> > * bstr w/ protected attributes
> > * map w/ unprotected attributes
> > * bstr w/ some type of content
> > * bstr w/ cryptographic value
> > * Array of items above (i.e. recipients) or nothing
>
> "Last three structures"... I think you must mean COSE_Encrypt,
COSE_recipient
> and COSE_Mac.
> (Why on page 16 are they:
> COSE_Sign1, COSE_Signature, COSE_Encrypt,
> COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0.
>
> In this order, rather than:
> COSE_Signature, COSE_Sign1,
> COSE_Encrypt0, COSE_Encrypt,
> COSE_recipient, COSE_Mac, and COSE_Mac0.
> )
>
> But, COSE_Encrypt combines: "* bstr w/ some type of content"/"* bstr w/
> cryptographic value"
> because it's encrypted, right?
>
No - The last three structures were COSE_Sign1, COSE_Mac and COSE_Mac0 -
they are enumerated below
> > In these cases if you wanted to provide additional value with the
> > countersignature you need to be computing it on the fourth value in
the
> > structure and not the third. This was correctly indicated for
COSE_Mac
> and
> > COSE_Mac0 in the current document, but it was not correctly
indicated for
> > COSE_Sign1. The following are the options that I have come up with
so far:
>
> Can you give a use case here?
>
> I think that I get that we are either breaking COSE_Sign1 (which has been
> rarely used so far), or COSE_Mac*, in-so-far as they need
countersignatures
> with additional values.
> If no additional values, then not a problem.
I think there have been a fair number of possible standards that are using
or planning to use COSE_Sign1. However, as Carsten said we are not breaking
COE_Sign1, COSE_Mac0 or COSE_Mac1. We are breaking how countersignatures
are applied to them.
>
> > I don't have any preference between the options above. They all
have
> good
> > points and bad points. The first one is the easiest to implement as
it
> > would only require adding some text to the document. But the
frisson
> > between what one would expect a countersignature to be and what it
is in
> > actuality for a COSE_Sign1 is jarring.
>
> I think that I'm okay with breaking/updating COSE_Sign1.
> Don't we need Sign1 for SUIT?
> I believe that Henk's SBOM proposal (outside of the IETF), does.
Does knowing that only countersignatures are being broken change how you
would weight the options?
Jim
>
> --
> ] Never tell me the odds! | ipv6 mesh
networks [
> ] Michael Richardson, Sandelman Software Works | IoT architect
[
> ] [email protected] http://www.sandelman.ca/ | ruby on rails
[
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
