Re: [Rats] Why variability is needed (Re: EAT Profiles)

[Michael Richardson <[e-mail]>]

Laurence Lundblade <[e-mail]> wrote:
    > Here’s use cases that diverge from 6.3 to serve as examples that cover
    > just about everything listed in 6.3

> Composite of pure HW attester and TEE/HLOS attester
> - HW uses non-preferred encoding of integers to output registers directly
> - HW is simpler because an indefinite length map is used to hold the Claims-Set

Okay, so could we call the first profile "Purple" and the one of the HW
attester above "Brown", and name them in the EAT document?

> JSON attester - Some one doesn’t use CBOR

Well, yes, but isn't not using CBOR, so it's automatically not a CBOR
Protocol.  It's "Blue"

    > Chinese Attester - Must use Chinese crypto
    > Don’t trust NIST - Want Edwards algorithm. See TEEP profile.

I don't think that profiles should name crypto algorithms.
Please see RFC https://www.rfc-editor.org/rfc/rfc8247.html for what we should
do, if we really need to write down MTIs.  I don't think we can/should though.

    > Multiple signing for PQ - Use COSE_Sign instead of COSE_Sign1 to sign
    > with a PQ algorithm (e.g. LMS) and widely supported algorithm
    > (e.g. ECDSA) (I know someone doing this)

I agree that this is a difficult part.
I'd prefer the EAT said that things that verify EATS (i.e. Verifiers and RPs)
MUST support both COSE_Sign and COSE_Sign1.

    > Time-based freshness - A highly constrained environment has trusted
    > time and wants avoid sending a nonce

Seems like a reasonable thing to be able to say.
I'd still like EAT to offer a clearer palette.

    > X.509-based keys/endorsements - Rather than using a kid, the leaf cert
    > / endorsement is included per draft-ietf-cose-x509

"If kid is absent, but x5c is present, then a verifier may assume ..."

    > Privacy/confidentiality required - The use case requires the encryption
    > of the EAT - Also may want to explicitly disallow UEID because it is
    > PII

That seems both out of scope (the encryption is will need to be bolted on),
and entirely reasonable for the user to list forbidden claims.

    > EAT carried by a tag-using CBOR protocol - The protocol carrying the
    > EAT wishes to use the CWT/COSE tag numbers to identify the item as CWT
    > and the type of protection it wants

Can you give me an example here?
Will this user register then own CBOR Tag?  (What's a CWT Tag?  I think a typo..)

I'm pushing for EAT specifying somewhere between four and ten variations
(with clear names), rather than allowing NxMxPxQxZ combinations to exist.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-