Benjamin Kaduk <[email protected]> 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 <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
