Re: [COSE] questions for the WG from 8152bis AUTH48

[Michael Richardson <[e-mail]>]

Benjamin Kaduk <[e-mail]> wrote:
    > The chairs and I are continuing to work through the AUTH48 process for
    > the 8152bis drafts, and a couple topics have come up that would benefit
    > from some broader input.

Thanks for this.

    > In
    > https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-struct-15#section-7.1
    > we we have a table of "Key Operation Values", discussing the various
    > operations that are possible.  Some of them include the statement
    > "Requires private key fields", and for operations like "sign" or
    > "unwraap key" this is pretty obviously true.  But for "derive key" and
    > "derive bits" this is less clear to me.  In particular, my
    > understanding is that I can do the derivation operations by combining a
    > public key I control and a public key received from the peer.

My reading of this is that it is about some kind of DH key operation.
Do you think of your g^x as being public or derived from private?
The x is obviously private, and you need it to compute (g^y)^x.

I'm not sure what other method derives keys from two public things without
each party also having some private parts.

    > That, in
    > turn, seems to imply that the serialized public key that I receive from
    > the peer would be intended to be used for a derivation operation but
    > would not contain the private key fields.

Here, I think you are asking if the COSE Key Common Parameters would contain
private keys?  I don't get that impression... the kid would identity what
private components are being referenced.

    > Are we supposed to indicate
    > the derivation operations in the "key_ops" field of such a
    > public-key-only COSE_Key?  I believe we are supposed to, and so have
    > directed the RFC Editor to just remove the statement about "requires
    > private key fields" for those two entries.  This seems low-risk in that
    > the statement itself is mostly informative, so we're either removing a
    > false statement or removing something that's informative but obvious
    > when you go to implement it.  Do people agree with that interpretation
    > of the "key_ops" for public-key-only key objects destined for
    > derivation operations?

I agree with you conclusion, but I'm not sure that I agree we got there the
same way.

    > The other question is in -algs; in
    > https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-algs#section-8
    > we start off with a rather awkward sentence "There are some situations
    > that have been identified where identification of capabilities of an
    > algorithm or a key type need to be specified."

    > In particular (at least
    > to me), the "identification ... needs to be specified" seems like the
    > verb tenses don't even match up properly, or something of that nature,
    > but I can't properly describe exactly what seems off.  The current
    > proposal from the RFC Editor is to dramatically replace this sentence
    > with the bland "The capabilities of an algorithm or key type need to be
    > specified in some situations".  Does anyone object to that change?

I can live with that.
The repeated use of "identified" / "identification" is really really awkward,
and I think uselessly obtuse.   Maybe more detail from core-oscore-groupcomm
would help the reader.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide