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

[Carl Wallace <[e-mail]>]

From:  Jeremy O'Donoghue <[e-mail]>
Date:  Tuesday, October 23, 2018 at 1:10 PM
>> On 23 Oct 2018, at 16:14, Carl Wallace <[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").
[CW] I'd not discount CMS not because there aren't mechanisms elsewhere, but
because it's already used in some attestation contexts.
> 
>>> - 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).
> 
> 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.
[CW] My goal is to present an attestation to a CA before a certificate is
issued so the provenance of the key can be confirmed to inform issuance
decisions. I currently do include self-signed X.509 certificates as claims
in attestations, which may be what you meant.
> <snip>
>