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

[Carl Wallace <[e-mail]>]

inline

From:  Giridhar Mandyam <[e-mail]>
Date:  Tuesday, October 23, 2018 at 3:53 PM
To:  Carl Wallace <[e-mail]>, Jeremy O'Donoghue
<[e-mail]>, Michael Richardson <[e-mail]>
Cc:  "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject:  RE: [EAT] [Rats]    Attestation BoF charter updates?

> [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.
[CW] I have not suggested defining new certificate management specs, just
codifying the binding of attestations to one or more certificate management
specs. In my case, I am using SCEP (for legacy installed base purposes).
>  

> -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]>, Sandelman Software Works
>>> -= IPv6 IoT consulting =-
>>> _______________________________________________
>>> EAT mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/eat
>>  
>> _______________________________________________ RATS mailing list
>> [e-mail] https://www.ietf.org/mailman/listinfo/rats