ietf-eat-profile: allow kid as alternative to x5chain for space-const…

[fdamato]

…rained attesters

[bluegate010]

Any reason we need to be normative here?

[fdamato]

no probably not, but I would still prefer to use a single way to identify the key...perhaps we can change with "SHOULD"

[steven-bellock]

This is effectively a new profile or version of the profile.

[gmandyam]

This is effectively a new profile or version of the profile.

I assumed that this would be only applicable to the ML-DSA version, which already required a new profile.

[bluegate010]

This is effectively a new profile or version of the profile.

I assumed that this would be only applicable to the ML-DSA version, which already required a new profile.

IMO we should try and have the new guidance be algorithm-agnostic; that being said, we could have the new profile version include both this and PQC.

[fdamato]

IMO we should try and have the new guidance be algorithm-agnostic; that being said, we could have the new profile version include both this and PQC.

I agree. We can perhaps allocate a new OID for a new profile that covers both ECDSA and MLDSA. The proposed change of this PR will only affect the new OID. Also I would suggest to register in CWT a "profile_version" claim. This way, if in future, we want to make other "small" adjustments. Those could be contained in the scope of the same OID, by revving up the profile_version number. @bluegate010 / @steven-bellock are you ok with this ?

[parvathib]

Based on the discussion, it sounds like relaxing the embedded certificate requirement would require defining new profile OIDs.

In that case, it would be good for us to align on the profile strategy and clarify in the spec as part of this PR. Specifically:

• Should the kid-based variant be represented by new profile OIDs?
• If so, can we define the ECDSA kid-based profile OID in this PR?
• Since we'll also need MLDSA support, can we define the corresponding MLDSA kid-based profile OID(s) at the same time?

That would make the verifier behavior unambiguous for both ECDSA and MLDSA profiles.