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

["Smith, Ned" <[e-mail]>]

See inline [nms]

On 9/17/22, 10:15 AM, "RATS on behalf of Michael Richardson" <[e-mail] on behalf of [e-mail]> wrote:


    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?
[nms] Since a profile is a URI it would be more correct terminology to say "a URI that expresses a color". The point is the URI doesn't tell the Verifier how to process the profile. Something more is required such as a CDDL description of the profile or a human who reads the profile and writes code that implements the profile. I don't think it makes sense to define a profile (which is specific to a use case, user, vendor) in the EAT spec which is trying to be a building block specification.

    > 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.
[nms] This comes down to two lines in the EAT spec regarding the scope of profiles which on their surface seem contradictory. One line indicates a profile is a subset or constraint on EAT. The next line says a profile could be a superset of EAT essentially. While I can find arguments for supporting both statements, they seem contradictory as a way of constraining the scope to facilitate interoperability. The profile is the last word on interoperability while the EAT draft promises some degree of code resuse.

        > 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.
[nms] The rationale being, that a Verifier that can support multiple profiles (specifically one that requires COSE_Sign the other COSE_Sign1) would need to support both. If Verifiers are specialized to a particular use case (say the "blue" profile that only needs COSE_Sign1), then why should they be required to include code for COSE_Sign if it's never exercised?
If interoperability is the primary focus of profiles, then interoperability guarantees in EAT should be backpedaled or at least aligned with CWT and JWT (which don't guarantee interop of something not in the RFC). 
[nms] Additionally, it is possible that an unsigned token or even disparate EAT claims are incorporated into a structure that is signed by some other signed object such as XMLDSIG, X.509 cert, conveyance protocols etc... A requirement to mandate use of COSE_x would alienate these alternative forms which are anticipated by the RATS Architecture.

        > 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.
[nms] +1 - it is reasonable for a conveyance mechanism to apply confidentiality

        > 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.
[nms] Terminology like "CBOR protocol" is ambiguous and should be reworded. 
[nms] The CBOR RFC defines tagging (e.g., #6.xyz) which seems different than what is being described above. Maybe "CWT/COSE tag" is ambiguous wording.

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