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

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

See inline [nms].

On 10/23/18, 10:10 AM, "EAT on behalf of Jeremy O'Donoghue" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:


On 23 Oct 2018, at 16:14, Carl Wallace <[e-mail]<mailto:[e-mail]>> wrote:
<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?

None I can technically justify. It seems sensible to have ASN.1 in scope, at least in terms of defining the syntax of claims in ASN.1. I am less sure whether it makes sense to define signing procedures for ASN1. (since these are presumably defined elsewhere), but I could be persuaded (e.g. by the statement "no they aren't defined elsewhere - at least not for this important use-case").
[nms] The relevant question to consider is whether or not the semantics of elsewhere defined ASN.1 equal that of the CBOR | JSON | YANG definitions. Since it is often the case that semantics are inferred through tribal understanding and/or human readable documents, the data model descriptions could disagree unless documented as the data model bindings of an information model representation (where the information model likely is accompanied by human readable text that captures intended semantics).

- 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.
[nms] Note: the SP800-164.verifier must rely on some form of out-of-bands communication from the SP800-154.entity that is knowledgeable regarding the claimable claims asserted by the SP800-164.root-of-trust for the SP800-164.verifier to know which claims semantics to ascribe to the 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).

It would be interesting to understand your thinking a bit further. At one level it is fairly straightforward to define a claim whose value contains an X.509 certificate, but I suspect that binding may imply more than that.
[nms] It is also reasonable to consider an X.509 certificate as being an object that contains a set of claims (rather than the other way around).

- 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.
o    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