Re: [EAT] [Rats] Attestation BoF charter updates?

[Giridhar Mandyam <[e-mail]>]

[CW] As noted before, I'd like to see binding to certificate enrollment protocols included here as well. This is something we are doing today, without standards grounding (as illustrated in pile of attestations shared via Github a few weeks back).

Why isn’t ACME applicable  (https://datatracker.ietf.org/wg/acme/about/)?   Granted, it is optimized for the web currently.  But from a message format perspective I don’t think we need to re-invent the wheel.

-Giri Mandyam, Qualcomm

From: EAT <[e-mail]> On Behalf Of Carl Wallace
Sent: Tuesday, October 23, 2018 8:15 AM
To: Jeremy O'Donoghue <[e-mail]>; Michael Richardson <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [EAT] [Rats] Attestation BoF charter updates?


<snip>
Work Items
----------
The Working Group will develop specifications supporting the creation of
interoperable remote attestation procedures for entities which incorporate
Roots of Trust. The main deliverables are as follows.
- Produce a requirements document establishing a common vocabulary for remote
  attestation, identifying mechanisms which will be supported for establishing
  trust between an entity and a remote party, and enumerating sample use-cases
  for remote attestation.
- Produce specification text defining interoperable cross-platform claims which
  provide information about an entity in support of the required use-cases, and
  extending the set of claims defined in RFC7519 and RFC8392. The specification
  will describe the syntax for each claim in at least the following formats:
    - CBOR [RFC7049]
    - JSON [RFC7159]
    - YANG [RFC6020]
[CW] ASN.1 is already player for a number of attestation formats. Any reason to exclude it?

- Produce specification text defining procedures and corresponding architectures
  supporting verification of claims within an attestation based on measured file
  execution procedures and supporting:
    - Explicit attestation wherein a set of claims is transported in the attestation;
    - Implicit attestation wherein a set of claims is implied by possession of a secret.
- Produce specification text defining procedures and corresponding architectures
  supporting verification of claims encapsulated in:
    - CBOR Web Token structures [RFC8392]
    - JSON Web Token structures [RFC7519]
[CW] As noted before, I'd like to see binding to certificate enrollment protocols included here as well. This is something we are doing today, without standards grounding (as illustrated in pile of attestations shared via Github a few weeks back).

- Perform privacy analysis of both claims and the cryptographic procedures used to
  establish trust. This information will be included as appropriate in the
  deliverable specifications, and may imply extension of procedures defined in
  other specifications in support of privacy goals.

It seems to me that there are two ways to produce the main specification deliverables. I have deliberately left the text above slightly vague on this.

  *   A claims specification common to RATS and EAT with separate RATS and EAT procedure specifications.
  *   A claims specification also incorporating EAT procedures and a separate RATS procedure specification. This would be my preferred option.

     *   I believe there are very few procedures needed for EAT other than the possible need to support a nonce to ensure freshness

Jeremy

Notice how by about the second paragraph (6tisch takes a bit longer), each
gets into what the WG will do?

--
Michael Richardson <[e-mail]<mailto:[e-mail]>>, Sandelman Software Works
-= IPv6 IoT consulting =-
_______________________________________________
EAT mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/eat

_______________________________________________ RATS mailing list [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/rats