how to find/label Endorsement and Verification Keys

[mcr]

Moving this to an appendix does not really solve the problem.

> 14) I think that section 6 serves no purpose.  _Endorsements and
> Verification Keys_ _There is not yet any standard format(s) for an
> Endorsement._

It was moved to an appendix. There is not one standard method.

This sure seems like a bug to me. I'd really like EAT to specify (create a standard) a way to use the kid to identify keys. Maybe there have to be n methods, and the profile will have pick one of the n methods.

I'd like to see text that says things like:

When the endorsement is in the form of an RFC5280 PKIX certificate(*)
then Reference Values and implied claims can be carried in X.509 v3 extensions. ...

(*)"X.509" is a meaningless term from the ITU-T of the 1990s

[laurencelundblade]

I spent some time thinking about this.

I can't think of anything to say about use of the kid in this document. Seems like COSE says most of what is there is to say in a generic way.

I think it would be useful and interesting to write a separate document that describes how to use deterministic creation of an ECDSA key pair and kid from a single random seed and describe how it can fit in with the end-end implementation of EAT. But this is only one specific end-end system.

I definitely think we should not do anything normative with endorsements in EAT. They are not well defined yet. When they are defined, I think a follow on standard to EAT would be the place to down how end-end keying works for them.

This is also all taking a clue from COSE, JOSE, CWT and JWT that don't go into any about key identification. I know we don't have to do exactly what they did, but unless there is a clear path, I prefer to do the same as they did.

Basically I think end-end keying systems seems like an overreach for this EAT document at this point, anything here would be substantial work, we need to get EAT done, but I think they would be great in follow-on documents that take particular focus on particular end-end keying systems -- one for X.509(*) endorsements, one for basic ECDSA from a seed,...

[mcr]

I'm not saying to standardize endorsements. I'm saying then when Evidence is signed that the Attester MUST put in a clear kid that identities the key which is being used to sign. Hash of SPKI would be fine. CWT/COSE, JWT/JOSE quite reasonably punted on what kid looks like. They punted to US to specify it, and we should do exactly that. It is not overreach for EAT to specify at least one format.

[gmandyam]

CWT/COSE, JWT/JOSE quite reasonably punted on what kid looks like.

Can you provide any kind of of pointers to the text in the above specifications where this is stated?

My interpretation of the COSE text below does not match the above interpretation:

"Applications MUST NOT assume that 'kid' values are unique. There may be more than one key with the same 'kid' value, so all of the keys associated with this 'kid' may need to be checked. The internal structure of 'kid' values is not defined and cannot be relied on by applications. Key identifier values are hints about which key to use. This is not a security-critical field."

I'm saying then when Evidence is signed that the Attester MUST put in a clear kid that identities the key which is being used to sign.

There is no reason for this to be a MUST requirement. There are existing implementations of EAT that work without it, and I believe the quoted text above from the COSE spec provides sufficient reason as to why it isn't necessary. If someone who is interested wants to add interoperable semantics to kid then it can be done separately from EAT (I suspect such an effort will not gain much traction in terms of commercial implementations).

I would recommend taking this back to the list and try to obtain consensus within the WG as to whether (a) it is important to define how kid values are determined, and (b) whether this should only be specified in the EAT document.

[laurencelundblade]

There's a lot of good examples in Appendix F many of which are reasonably clear and direct, for example an AKI.

I agree with Giri -- the thing to do is get some consensus on the WG list for some specific stuff and a specific direction to strike out on beyond what is here.

[laurencelundblade]

Closed per discussion at virtual interim December 12, 2023