Subject: [Rats] Scope, Goals & Background for RATS

From: Henk Birkholz <[email-masked]>
Date: Tue, 18 Sep 2018 10:26:54 +0200

Hi all,

we pushed an initial document to the RATS github in order to focus the 
discussion about remote attestation procedures a bit.

> https://github.com/ietf-rats/charter/blob/master/ietf-rats-charter.md

We included a background section to better highlight the meaning of the 
term "attestation" in general. Hence, there is a trade-off between 
clarity and conciseness, which is one of the things we would like to get 
feedback about.

Naturally, we are also very interested in feedback about the illustrated 
difference between explicit attestation and implicit attestation.

Viele Grüße,

Henk

---

From: Denis <[email-masked]>
Date: Tue, 18 Sep 2018 12:41:48 +0200

Hi Henk,

I browsed through the document and I am a bit puzzled. I was expecting 
some words about the attestation certificates that FIDO is using, but I 
found none.

In FIDO, the concept of an attestation certificate is that a batch of 
devices from the same model have the same attestation private key and 
thus the same certificate.

In this WG, such a restriction should not necessarily be made and when 
the certificate is different for each device model the question is how 
we should name it.

Let me attempt a proposal:

    "shared attestation certificates" to designate attestation
    certificates that are specific to a batch of devices from the same
    model (like in FIDO),
    "individual attestation certificates" to designate attestation
    certificates that are specific to each device.

The introduction section states:

    Authentication presumes some protection: e.g., that there is not an
    illicit copy of the private key available to anyone other than the
    intended subject.

This is insufficient, it also assumes that a legitimate client does not 
perform all the cryptographic computations that another client needs:
preventing the export of private keys does not prevent a client to use a 
private key for the benefits of another client.

The background section states:

    Generally speaking, attestation is applied before data is exchanged
    to avoid disclosure to insufficiently trusted environments.

I don't believe so. There is the need to demonstrate that a data 
exchange really originates from a secure device, acting as a client,
and that that device has some well known properties.

In the terminology section, I would expect to find a definition for an 
attestation certificate.

I read the definition of an "Attestation Evidence" in the terminology 
section several times and I have difficulties to understand it.
I wonder if such a concept really exists. In particular, within this 
definition, the text states:

    Attestation Evidence veracity may be augmented by Claimant
    signatures over portions of the Attestation Evidence.

I don't believe so.  If I am assuming the use of Attestation 
Certificates, there is an attestation private key associated to the 
public that is in it.
The authentication exchange performed by a client should be 
counter-signed by the attestation private key corresponding to the 
public key
placed within the Attestation Certificate.

In the background section, the concept of a remote attestation is the 
following:

    /Remote Attestation/ is where the Attester conveys Attestation
    Evidence to a Verifier that compares it with Reference Values
    (in order for it to be considered, for example, healthy). A Relying
    Party (or the Verifier acting as a Relying Party) appraises the
    verification result
    to assess device trustworthiness and to manage security risk.

Since I could not grasp the concept of Attestation Evidence, I couldn't 
grasp the concept of a Remote Attestation which is based on it.
The goal is not simply to "assess device trustworthiness" but to make 
sure that some data exchange is really coming from a device
that has specific properties. Such properties are going beyond the 
protection, the non-export and the non-import of private keys.

I could not understand either the value of local attestations. IMO, the 
WG should only focus on remote attestations.

Finally, the following invitation was raised:

    Naturally, we are also very interested in feedback about the
    illustrated difference between explicit attestation and implicit
    attestation.

The current definition for Explicit Attestation is:

    /Explicit Attestation/ is where the Attestation Claims/Evidence is
    conveyed authentically (e.g. signed) by the Attester to the Verifier
    where a root-of-trust enumerates the Attestation Claims/Evidence
    associated with an execution environment.

I would rephrase it in the following way:

    /Direct Attestation/ is when a verifier can be confident that some
    data originating from a client originates in practice from a secure
    device
    that has specific *functional and security* properties.

The current definition for Explicit Attestation is:

    /Implicit Attestation/ is where the Attester conveys evidence of the
    availability of an authenticating credential that allows the Verifier
    to infer the Attestation Claims/Evidence associated with an
    execution environment. The Verifier knows that the availability of
    the authenticating credential is bound to certain Attestation
    Claims/Evidence. Inferred knowledge may further be conveyed as
    Attestation Evidence
    by a Trusted Third Party via a credential certificate or other
    out-of-band method.

It is quite hard to understand the concept since three sentences are 
being used.

Let me attempt to define a different but, maybe, close concept:

    /Inferred Attestation/is when a Trusted Third Party (TTP) testifies
    to a verifier that some data originating from a client originated in
    practice from a secure device
    that has specific functional and security properties.

Denis

> We included a background section to better highlight the meaning of 
> the term "attestation" in general. Hence, there is a trade-off between 
> clarity and conciseness, which is one of the things we would like to 
> get feedback about.
>
> Naturally, we are also very interested in feedback about the 
> illustrated difference between explicit attestation and implicit 
> attestation.
>
> Viele Grüße,
>
> Henk
>
>
>
>
>
> _______________________________________________
> EAT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eat

---

From: "Fuchs, Andreas" <[email-masked]>
Date: Tue, 18 Sep 2018 12:37:34 +0000

Hi Denis,

I think that the attestation certificates of FIDO (as far as I understand them from your description) are a prime example for implicite attestation.
Reason: you validate a signature and from the accompanying "shared attestation certificate" you can infer the signing device's property of being a FIDO thingy.
Thus, I'd see this being covered within the current draft, but the charter does not refer to any specific technologies.

Regarding the naming, IMHO we should stick with implicite/explicite attestation, because these are well established terms, other than inferred/direct.
Some evidence on google: https://www.google.com/search?q=Implicit+Attestation vs https://www.google.com/search?q=Inferred+Attestation

The difference between explicite and implicite is also not what you are proposing in you new definitions. To put it is simpler words:
- Explicite is a signature over a statement of claims originating from the platform.
- Implicite is a signature with the augmented information that the private key is usage-restricted to certain claims (e.g. being a FIDO token)

There could be an additional dimension for direct (from the device itself) vs indirect (from a third party, i.e. hear-say) orthogonally to ex-/implicite, leading to the terms explicite direct, explicite indirect, implicite direct, implicite indirect.
I've thought about this in the past, but I did not see practical applications beyond the direct ones. But maybe that would be something to discuss in the formed WG.

Bests,
Andreas

________________________________
From: RATS [[email-masked]] on behalf of Denis [[email-masked]]
Sent: Tuesday, September 18, 2018 12:41
To: [email-masked]; [email-masked]
Subject: Re: [Rats] [EAT] Scope, Goals & Background for RATS

Hi Henk,

I browsed through the document and I am a bit puzzled. I was expecting some words about the attestation certificates that FIDO is using, but I found none.

In FIDO, the concept of an attestation certificate is that a batch of devices from the same model have the same attestation private key and thus the same certificate.

In this WG, such a restriction should not necessarily be made and when the certificate is different for each device model the question is how we should name it.

Let me attempt a proposal:
"shared attestation certificates" to designate attestation certificates that are specific to a batch of devices from the same model (like in FIDO),
"individual attestation certificates" to designate attestation certificates that are specific to each device.
The introduction section states:
Authentication presumes some protection: e.g., that there is not an illicit copy of the private key available to anyone other than the intended subject.
This is insufficient, it also assumes that a legitimate client does not perform all the cryptographic computations that another client needs:
preventing the export of private keys does not prevent a client to use a private key for the benefits of another client.

The background section states:
Generally speaking, attestation is applied before data is exchanged to avoid disclosure to insufficiently trusted environments.
I don't believe so. There is the need to demonstrate that a data exchange really originates from a secure device, acting as a client,
and that that device has some well known properties.

In the terminology section, I would expect to find a definition for an attestation certificate.

I read the definition of an "Attestation Evidence" in the terminology section several times and I have difficulties to understand it.
I wonder if such a concept really exists. In particular, within this definition, the text states:
Attestation Evidence veracity may be augmented by Claimant signatures over portions of the Attestation Evidence.
I don't believe so.  If I am assuming the use of Attestation Certificates, there is an attestation private key associated to the public that is in it.
The authentication exchange performed by a client should be counter-signed by the attestation private key corresponding to the public key
placed within the Attestation Certificate.

In the background section, the concept of a remote attestation is the following:
Remote Attestation is where the Attester conveys Attestation Evidence to a Verifier that compares it with Reference Values
(in order for it to be considered, for example, healthy). A Relying Party (or the Verifier acting as a Relying Party) appraises the verification result
to assess device trustworthiness and to manage security risk.
Since I could not grasp the concept of Attestation Evidence, I couldn't grasp the concept of a Remote Attestation which is based on it.
The goal is not simply to "assess device trustworthiness" but to make sure that some data exchange is really coming from a device
that has specific properties. Such properties are going beyond the protection, the non-export and the non-import of private keys.

I could not understand either the value of local attestations. IMO, the WG should only focus on remote attestations.

Finally, the following invitation was raised:
Naturally, we are also very interested in feedback about the illustrated difference between explicit attestation and implicit attestation.
The current definition for Explicit Attestation is:
Explicit Attestation is where the Attestation Claims/Evidence is conveyed authentically (e.g. signed) by the Attester to the Verifier
where a root-of-trust enumerates the Attestation Claims/Evidence associated with an execution environment.
I would rephrase it in the following way:
Direct Attestation is when a verifier can be confident that some data originating from a client originates in practice from a secure device
that has specific functional and security properties.
The current definition for Explicit Attestation is:
Implicit Attestation is where the Attester conveys evidence of the availability of an authenticating credential that allows the Verifier
to infer the Attestation Claims/Evidence associated with an execution environment. The Verifier knows that the availability of
the authenticating credential is bound to certain Attestation Claims/Evidence. Inferred knowledge may further be conveyed as Attestation Evidence
by a Trusted Third Party via a credential certificate or other out-of-band method.
It is quite hard to understand the concept since three sentences are being used.
Let me attempt to define a different but, maybe, close concept:
Inferred Attestation is when a Trusted Third Party (TTP) testifies to a verifier that some data originating from a client originated in practice from a secure device
that has specific functional and security properties.
Denis

Hi all,

we pushed an initial document to the RATS github in order to focus the discussion about remote attestation procedures a bit.

We included a background section to better highlight the meaning of the term "attestation" in general. Hence, there is a trade-off between clarity and conciseness, which is one of the things we would like to get feedback about.

Naturally, we are also very interested in feedback about the illustrated difference between explicit attestation and implicit attestation.

Viele Grüße,

Henk

_______________________________________________
EAT mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eat

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 18 Sep 2018 16:18:01 +0200

Hi Denis,

there are a lot of topics addressed by your reply. First of all, thank 
you for the the feedback!

We attempted to create a document that is as inclusive as possible - 
within reason. Hence, it is also solution agnostic.

As Andreas just said, Proof-of-Possession of a secret key is intended to 
be captured by Implicit Attestation. In other words: if you are able to 
use that secret key to sign something, it implies (that is the 
"implicitness" here) that "that device has some well known properties".
The definition of implicit attestation might require some improvement, I 
assume (and I don't mean by adding even more words).

I am a bit confused by the use of "attestation certificate", "private 
key" and "origin of data exchange" in your reply.

> "individual attestation certificates" to designate attestation certificates that are specific to each device.

means identity document, the concepts of "Singular Identity", "Shared 
Identity", and "Group Identity" are already subsumed in the IETF by the 
definition of "Identity" in RFC4949. Maybe that fact is a little bit too 
hidden at the end of the Background section that refers to 
"cryptographic identities". Highlighting that more up front and 
referencing RFC4949 explicitly could address that issue.

Correspondingly, the same secret key can be enrolled on multiple 
devices, but that is not the same thing as enrolling the same 
(group/shared) identity document on multiple devices.

The smallest identity document I can think of would be a signed public 
key. More commonly today, it would be an ASN.1-based identity document, 
I assume.

Jumping a bit to the end:

Local Attestation is described in the Background section and is referred 
to again in the Scope section as out-of-scope.
That said, as Local Attestation can be a prerequisite for Remote 
Attestation and it also might require some provisioning (via network 
protocols) in order to work, provisioning protocols that enable local 
attestation are currently considered in-scope.

The fact that the definition of Attestation Evidence is difficult to 
understand could be the biggest issue here, I think. Especially, because 
it is the basis for the definition of Remote Attestation, as you 
highlighted. I will come back to this topic as soon as I have a few more 
free cycles :)

Viele Grüße,

Henk

---

From: Denis <[email-masked]>
Date: Tue, 18 Sep 2018 17:56:20 +0200

Hi Henk,

I fear that we don't understand each other.

> As Andreas just said, Proof-of-Possession of a secret key is intended 
> to be captured by Implicit Attestation. In other words:
> if you are able to use that secret key to sign something, it implies 
> (that is the "implicitness" here) that "that device has some well 
> known properties".

No. If you are able to use a secret key to sign something, it does not 
mean that you are using a device.
If a device is able to sign something, it does not necessarily mean that 
what is signed really comes from the device, unless "that device has 
some well known properties".

> The definition of implicit attestation might require some improvement, 
> I assume (and I don't mean by adding even more words).
>
> Identity", and "Group Identity" are already subsumed in the IETF by 
> the definition of "Identity" in RFC4949.
> Maybe that fact is a little bit too hidden at the end of the 
> Background section that refers to "cryptographic identities". 
> Highlighting that more up front and referencing RFC4949
> explicitly could address that issue.

It does not mean anything from the above list. My arguments have nothing 
to do with "Identity". Typically, an Attestation Certificate it is an 
X509 certificate, as in FIDO.

> (group/shared) identity document on multiple devices.

The private key of a device is never enrolled but is placed in the 
device by the manufacturer of the device (or the entity that 
personalizes it before making it available to an end-user);

> key. More commonly today, it would be an ASN.1-based identity 
> document, I assume.

My arguments are fully unrelated to "identity documents".

> Local Attestation is described in the Background section and is 
> referred to again in the Scope section as out-of-scope.

This is fine.

> protocols) in order to work,
> provisioning protocols that enable local attestation are currently 
> considered in-scope.
>
> understand could be the biggest issue here, I think. Especially, 
> because it is the basis for
> the definition of Remote Attestation, as you highlighted. I will come 
> back to this topic as soon as I have a few more free cycles :)
>
> Viele Grüße,
>
> Henk

Denis

>> I browsed through the document and I am a bit puzzled. I was 
>> expecting some words about the attestation certificates that FIDO is 
>> using, but I found none.
>>
>> In this WG, such a restriction should not necessarily be made and 
>> when the certificate is different for each device model the question 
>> is how we should name it.
>>
>> This is insufficient, it also assumes that a legitimate client does 
>> not perform all the cryptographic computations that another client 
>> needs:
>> preventing the export of private keys does not prevent a client to 
>> use a private key for the benefits of another client.
>>
>> Since I could not grasp the concept of Attestation Evidence, I 
>> couldn't grasp the concept of a Remote Attestation which is based on it.
>> I could not understand either the value of local attestations. IMO, 
>> the WG should only focus on remote attestations.
>>
>>> we pushed an initial document to the RATS github in order to focus 
>>> the discussion about remote attestation procedures a bit.
>>>
>>> the term "attestation" in general. Hence, there is a trade-off 
>>> between clarity and conciseness, which is one of the things we would 
>>> like to get feedback about.
>>>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 18 Sep 2018 19:49:24 +0200

> I fear that we don't understand each other. 

I think this is the usual terminology problem about “identity”.

Identity is a set of claims.

In the example, the device can prove possession of a key.

The manufacturer provides a signed claim (“certificate”) that possession of that key implies a certain set of protection properties.

That claim (together with the proven possession of the key) becomes the identity of the device that Henk was talking about.  The X.509 certificate that carries the manufacturer’s claim can therefore be called an “identity document”.

It is an identity that thousands of devices share (just as I share the identity that allows me to buy cigarettes from a vending machine in Germany, i.e. I’m 18 or older).  Note that identity can be limited and directed (which makes it somewhat different from identification).

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Sep 2018 14:08:26 -0400

> clarity and conciseness, which is one of the things we would like to

1) RATS is not expanded anywhere near the top of the document!
2) I think that this document is okay as a working document going towards a
   BOF,  but in general it is too big.
   Bulky things like the Terminology and most of the problem statement
   probably need to go into IDs.

I understand why you have put them here at this point.
As Mark Twain(%) was alleged to have said, "I didn't have time to write a
shorter letter"... thus the length of your document.
Statements like:

    (4) The lack of generic models and commonly understood terminology that
    would allow for semantic interoperability and a...

absolutely go into the charter to explain what the goals are.
This needs to be reworded into a positive action.... i.e. "We will develop
generic models with commonly understood terminology..."

    > illustrated difference between explicit attestation and implicit

(%) apparently, he didn't say that first, and may never have said it.
But I think he would have liked to have said it.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Sep 2018 14:09:45 -0400

> some words about the attestation certificates that FIDO is using, but I

Because it's a charter, not a bibliography.
And arguing over a bunch of text that needs to be condensed/removed isn't
helpful.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 18 Sep 2018 18:10:20 +0000

Hi Denis,

On the exchange below...

Henk >> Generally speaking, attestation is applied before data
Henk >> is exchanged to avoid disclosure to insufficiently trusted environments.

Denis > I don't believe so. There is the need to demonstrate that a data exchange
Denis > really originates from a secure device, acting as a client,
Denis > and that that device has some well known properties.

For attestation on a router/switch, some people treat the router/switch as only partially trusted.  With such an approach, certain attested PCRs will only be updated by restricted/protected root-of-trust-for-measurements, and perhaps only when certain conditions are met.

Such an approach allows us freedom to use resulting signed TPM quotes many ways.  We could use these quotes for local router/switch attestation (perhaps out of scope).  We could also pass the quotes to an SDN controller (which is in scope).

While I do agree that we need to ensure that the originating device of attested evidence is the same as the generating device, it is important to define attested data independent of device or client/server boundaries.

Eric

From: Denis, September 18, 2018 6:42 AM

Hi Henk,

Denis
Hi all,

Viele Grüße,

Henk

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 18 Sep 2018 22:52:56 +0200

>   probably need to go into IDs.

Hi Michael,

that is indeed the objective.  But, first, the charter needs to be clear.
It can’t really point to I-Ds for the definitions relevant to its own scope because that would mean the scope changes with each revision of those I-Ds (yes, I ran into that with previous charter proposals for other groups).
So, until there is more solid consensus on some of the terms, a terminology section will be required right in the charter.
(And let’s hope we can get rid of that then with the first rechartering.)

Grüße, Carsten

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 20 Sep 2018 01:20:49 +0000

[nms] See my comments inline. - Ned.

On 9/18/18, 3:42 AM, "EAT on behalf of Denis" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi Henk,

[nms]--- some text deleted ---

[nms]The concept of associating security properties to data is described in more detail in https://datatracker.ietf.org/doc/draft-birkholz-attestation-terminology/ We struggle with knowing how much terminology to include in a charter vs. save for a terminology draft. The basic idea is data inherits security properties of the environment (loosely defined term) that contains it. Sometimes people describe a communication path as a channel with ‘endpoints’. Lots of environments can be an ‘endpoint’ and endpoints have data-at-rest security properties. A goal of attestation should be to communicate the security properties of the endpoint that originated the data in the channel. Additionally, the channel has data-in-motion security properties. Often these properties are defined in terms of cryptography. A consideration for data-in-motion extends to the endpoint environment that protects the keys. These are subtly different concepts that could be conflated if our terminology is imprecise. In terms of the charter discussion, attestation of the endpoint environment that encompasses data-at-rest as well as endpoint environments that encompass keys used to protect data-in-motion are relevant to ‘remote attestation’.

I could not understand either the value of local attestations. IMO, the WG should only focus on remote attestations.
[nms] I believe the charter focus is only remote attestation. Local attestation is (should be) out of scope. Note: Since the charter distinguishes a focus on remote attestation it becomes necessary to acknowledge the existence of local attestation.
[nms]--- some text deleted ---
Explicit Attestation is where the Attestation Claims/Evidence is conveyed authentically (e.g. signed) by the Attester to the Verifier
where a root-of-trust enumerates the Attestation Claims/Evidence associated with an execution environment.
I would rephrase it in the following way:
Direct Attestation is when a verifier can be confident that some data originating from a client originates in practice from a secure device
that has specific functional and security properties.
[nms] It may be important to avoid overloading terminology too much as there already is a term “direct anonymous attestation” (DAA) that refers to a group signature scheme that is also an ISO standard.
[nms]--- some text deleted ---

Denis
Hi all,

Viele Grüße,

Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 20 Sep 2018 13:18:42 -0700

It’s a bit buried, but I see you do intend that this include the EAT work. Thus the work would not be TPM/TCG centric. It would include use cases like FIDO and Android Keystore attestation that are often based on TrustZone. It could also include EPID-related use cases. Please confirm.

My preference would be to choose another name for the group that is neither EAT or RATS to help make this clear. I don’t really think there is a “procedure” with EAT. To be honest, I don’t really like “RATS” as a name. My suggestions are “RA” for Remote Attestation or “CAT” for Common Attestation Technology (and besides cats caused us to invent the Internet so we share pictures of them (securely)). 

I propose a more high-level intro with examples:

The purpose of RA/CAT is to allow a Relying Party (e.g. a web service, network management center...) to securely receive Claims from an Entity requesting service (e.g. a phone, router, IoT device...) that allow the Relying Party to determine if and how that entity is trusted.  For example:
An IoT management back-end receives a signed nonce that proves the IoT device is the genuine article manufactured by the expected OEM and is not a Linux box or such emulating such a device.
A network management center receives a set of measurement claims from a router to know that the configuration has not been tampered with.
An online banking service receives many claims about the device including location, SW versions and measurements and determines that it will allow a higher-than-usual value transaction.
A government online document server receives claims indicating manufacture and location of the device, determines they are from the correct country and grants access to classified documents.
There are protocols for determining and securing the identity of a server or service (TLS and IPsec). There are many protocols for authenticating end users (SASL, TLS client auth, EAP…). There are no general protocols for managing the characteristics, security and identity of an end client device (an Entity). RA/CAT aims to address that gap. 

There is no goal here to set criteria for what is trustworthy or not as that is an impossible task as it will vary widely from use case to use case. The goal here is to securely provide information (Claims) to the Relying Party so it can make that determination based on its own criteria and needs.

I don’t think the intro should mention public key crypto. I know of attestation solutions that do not use it.

I tend to prefer “attestation” when the goal is whether and how a device is to be trusted and “authentication” when the goal is how a human is to be identified. FIDO, OAuth, SASL are all about users and use the word authentication. 

LL

> On Sep 18, 2018, at 1:26 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 20 Sep 2018 14:29:47 -0700

Forking the discussion here to focus on implicit/explicit attestation. That seems to be a new term invented in this WG Charter as I haven’t seen it elsewhere. I’m not sure what it means yet. It seems to have something to do with how the loop is closed in the Attestation Model below. In particular the role of the Entity Manufacturer.

The obvious way to do this (kind of like TLS certs, but flipped): 
- The Entity Manufacturer puts a private key + X.509 certificate in each Entity (device) it makes
- This Entity (device) X.509 certificate is signed by the Entity Manufactures Root Key
- The Entity uses its private key to sign some Claims 
- The Entity sends the signed claims and its X.509 cert to the Relying Party
- The Relying Party gets the Entity Manufacturers Root Cert in a one time operation and saves it
- The Relying Party chains the device X.509 per to the Entity Root Cert
- The Relying Party uses the public key in the device X.509 to verify the signature on the Claims

One of my guesses for what implicit attestation is — The RP (Relying Party) does not get any root keys or such from the Entity Manufacturer or a CA or a trusted third party. They verify the signature solely based on what is in the signed token they received. The RP probably did send a nonce and the Entity signed it, so there is proof-of-posession of the Entity's key, but that key and device could be any device so little is proved. The RP can remember the Entity’s key and expect it to be the same next time to give it some value. This is called self-attestation of surrogate attestation in FIDO. It not considered very secure. The loop is not closed. 

Another one of my guesses — The RP does get key material with which to perform verification, but it is not directly from the Entity Manufacturer. Instead there is some CA or trusted 3rd party in the loop. This is a realistic scenario. The loop is closed so it is secure.

I see this as a topic for technical discussion, not something for definite in the charter.

LL

> On Sep 18, 2018, at 8:56 AM, Denis <[email-masked]> wrote:
> 
> Hi Henk,
> 
>> there are a lot of topics addressed by your reply. First of all, thank you for the the feedback! 
>> 
>> We attempted to create a document that is as inclusive as possible - within reason. Hence, it is also solution agnostic. 
>> 
>> As Andreas just said, Proof-of-Possession of a secret key is intended to be captured by Implicit Attestation. In other words: 
>> if you are able to use that secret key to sign something, it implies (that is the "implicitness" here) that "that device has some well known properties". 
> 
> No. If you are able to use a secret key to sign something, it does not mean that you are using a device. 
> If a device is able to sign something, it does not necessarily mean that what is signed really comes from the device, unless "that device has some well known properties".   
> 
>> The definition of implicit attestation might require some improvement, I assume (and I don't mean by adding even more words). 
>> 
>> I am a bit confused by the use of "attestation certificate", "private key" and "origin of data exchange" in your reply. 
>> 
>> means identity document, the concepts of "Singular Identity", "Shared Identity", and "Group Identity" are already subsumed in the IETF by the definition of "Identity" in RFC4949. 
>> Maybe that fact is a little bit too hidden at the end of the Background section that refers to "cryptographic identities". Highlighting that more up front and referencing RFC4949 
> It does not mean anything from the above list. My arguments have nothing to do with "Identity". Typically, an Attestation Certificate it is an X509 certificate, as in FIDO.
> 
>> 
>> Correspondingly, the same secret key can be enrolled on multiple devices, but that is not the same thing as enrolling the same (group/shared) identity document on multiple devices. 
> 
> The private key of a device is never enrolled but is placed in the device by the manufacturer of the device (or the entity that personalizes it before making it available to an end-user);
> 
>> 
>> The smallest identity document I can think of would be a signed public key. More commonly today, it would be an ASN.1-based identity document, I assume.
> 
>> Local Attestation is described in the Background section and is referred to again in the Scope section as out-of-scope. 
> 
> This is fine.
> 
>> That said, as Local Attestation can be a prerequisite for Remote Attestation and it also might require some provisioning (via network protocols) in order to work, 
>> provisioning protocols that enable local attestation are currently considered in-scope. 
>> 
>> The fact that the definition of Attestation Evidence is difficult to understand could be the biggest issue here, I think. Especially, because it is the basis for 
>> the definition of Remote Attestation, as you highlighted. I will come back to this topic as soon as I have a few more free cycles :) 
>> 
>> Viele Grüße, 
>> 
>> Henk 
> ...

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 20 Sep 2018 22:27:20 +0000

Hi,

I agree with you in the fact that the proposal is intended to address the proposed EAT work, and I think we agree in that this is a good way to go. Regarding the name, and given my dislike for cats, I’d propose to use CRAT, as in aristo-crat or demo-crat… (coming from the Greek god of strength and power)

And I tend to agree in your two final comments on public key, and the fact that circumscribing attestation to devices (of any nature, physical or virtual) need to be clearly stated.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: [email-masked]<mailto:[email-masked]>
Tel:         +34 913 129 041
Mobile:  +34 682 051 091
----------------------------------

On 20/09/2018, 16:18, "EAT on behalf of Laurence Lundblade" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

The purpose of RA/CAT is to allow a Relying Party (e.g. a web service, network management center...) to securely receive Claims from an Entity requesting service (e.g. a phone, router, IoT device...) that allow the Relying Party to determine if and how that entity is trusted.  For example:
o    An IoT management back-end receives a signed nonce that proves the IoT device is the genuine article manufactured by the expected OEM and is not a Linux box or such emulating such a device.
o    A network management center receives a set of measurement claims from a router to know that the configuration has not been tampered with.
o    An online banking service receives many claims about the device including location, SW versions and measurements and determines that it will allow a higher-than-usual value transaction.
o    A government online document server receives claims indicating manufacture and location of the device, determines they are from the correct country and grants access to classified documents.
There are protocols for determining and securing the identity of a server or service (TLS and IPsec). There are many protocols for authenticating end users (SASL, TLS client auth, EAP…). There are no general protocols for managing the characteristics, security and identity of an end client device (an Entity). RA/CAT aims to address that gap.

LL

On Sep 18, 2018, at 1:26 AM, Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

https://github.com/ietf-rats/charter/blob/master/ietf-rats-charter.md<https://github.com/ietf-rats/charter/blob/master/ietf-rats-charter..md>

Viele Grüße,

Henk

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 20 Sep 2018 16:14:46 -0700

Here’s my comments / suggestion for simplifying and clarifying the terminology.  The fewer terms the better.

> Assertion: Defined by the ITU in X.1252 as "a statement made by an entity without accompanying evidence of its validity”.
Seems like we can do without this definition entirely. Trying to be simpler...

> Attestation Claim: Information about some characteristics or attributes that affect device trustworthiness.
Would just prefer to use “Claim”.  Add examples: measurements of running SW, GPS location, boot state, HW and SW Versions.

A Claim is used by the Relying Party to evaluate device trustworthiness. Saying it affects device trustworthiness is confusing. Claims do not change the device.

> Attestation Evidence: Proof for one or more Attestation Claims (characteristics, attributes, ...) that affect device trustworthiness, such as its hardware identity, firmware, software, configuration or composition, compliance status and runtime state. Attestation Evidence may be consolidated through the use of cryptographic hash and key generation algorithms. Attestation Evidence veracity may be augmented by Claimant signatures over portions of the Attestation Evidence. Note that Claims are non-proven assertions as opposed to Attestation Evidence.
How about just “Signed Claims” or “Secure Claims". Same comment about “affect” as above. Definition can be just “Claims that have been signed or similarly secured for Conveyance.” 

> Attester: An endpoint that has a root-of-trust for reporting (RTR) and implements a conveyance protocol, authenticates using an Attestation credential, collects Attestation Evidence about itself and presents it to a consumer of evidence (e.g. a Relying Party or a Verifier).
> Claimant: An entity that make an assertion to a certain property regarding the trustworthiness of an entity. This may be the binding of an Attester to an RTR or any other kind of property.
Commenting on Attester and Claimant together. We need a term for the “subject” of the Claims, so I propose replacing “Claimant” with “Entity”

Entity: that about which the Claims are made. Often referred to as a device. Examples are a phone, IoT Device or Router. It can also be a submodule of a device. 
Attester: the part of an Entity that secures the claims (securing is typically done by signing). It turns “Claims” into “Signed Claims”.  A TPM is an example of this.

Think we should avoid the term “authentication” as seems more for protocols like SASL and EAP.. 

> Conveyance: The transfer of Attestation Evidence between Attester and Verifier, facilitated by network protocols that are reliable, secure and can prove the freshness of Evidence, if required.

> Reference Values: Information that can be matched with collected Attestation Evidence to determine if the device's operational state complies with an intended/expected operational state (e.g. Reference Integrity Measurements).
Prefer "Reference Claims" so they are clearly tied to the term Claim. I could live without definition entirely if we really wanted to be simple.

> Relying party: An entity that consumes and assesses Verifier results for the purpose of improved risk management, operational efficiency, security, privacy (natural or legal person) or safety. The Verifier and Relying Party functions may be tightly integrated.
I think the common and general definition is any server / service like an online bank, e-commerce site, enterprise document server and such whether or not the asses Claims.  I propose:

Relying Party: More generally any server or service like an online bank or e-commerce site. Here a server or service that consumes and assesses Verifier results for the purpose of improved risk management, operational efficiency, security, privacy (natural or legal person) or safety. The Verifier and Relying Party functions may be tightly integrated.

> Remote Attestation: The procedure of supplying Attestation Evidence to a communication partner via an Attester using network protocols for Conveyance.
I’d kind of prefer to leave this out as the whole document is about it. If it is kept in, I think it should refer to the whole end-end process.

> Root of Trust: The base entity for a chain of trusts that builds up trust in an overall system.
Some people think roots-of-trust are the boot ROM, embedded secret keys and such in a device.  Other people think they are X.509 root certificates published by CAs used for verifying chains.  It’s not clear which you are referring to. That said, I think we should just remove this definition from the charter. It doesn’t seem essential.

> Verifier: An endpoint that has a root-of-trust for verification and implements a conveyance protocol, verifies Attestation credentials and may authenticate using Attestation Evidence or other credentials, appraises Attestation Evidence against Reference Values or policies and makes verification results available to Relying Parties.
I propose: 
Verifier: A server or service that receives Signed Claims and processes them by verifying the signature and possibly comparing to Reference Claims. 

Finally, I’d like to add:
Token: a collection of Signed Claims that is Conveyed from the Attester to the Verifier
Entity Manufacturer: The company that made the Entity. The Entity Manufacturer configures the Attester with signing keys. It may also be the Verifier or supply signature verification keys to the Verifier.

LL

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 21 Sep 2018 15:09:04 +0200

Hello Laurence,

please find replies and comments in-line:

On 09/21/2018 01:14 AM, Laurence Lundblade wrote:
>>   * Assertion: Defined by the ITU in X.1252 as "a statement made by an
>>     entity without accompanying evidence of its validity”.

True. To scope the discussion we pulled in a terminology section to 
agree upon what we mean and create a common understanding of the scope.

Assertion was pulled in, as not every claim (sets) are essentially 
assertions and they can be elevated in expressiveness via signing to 
become Attestation Claims, but not every Attestation Claim is 
Attestation Evidence. E.g. GPS coordinates cannot typically be verified 
via reference values (which is already a term abstracted for discussion 
- reference integrity measurement manifests - RIMM - would be more 
precise), unless the system is supposed to stay, for example, in exactly 
on place, or city, or country, I'd assume. Typically RIMM provide values 
that have to match. Reference values that define a scope that would 
match I have yet to encounter.

> 
>>   * Attestation Claim: Information about some characteristics or
>>     attributes that affect device trustworthiness.
> Would just prefer to use “Claim”.  Add examples: measurements of running 
> SW, GPS location, boot state, HW and SW Versions.
> 
> A Claim is used by the Relying Party to evaluate device trustworthiness. 
> Saying it /affects/ device trustworthiness is confusing. Claims do not 
> change the device.

Trustworthiness is a characteristic assessed by the Verifier (root of 
trust for verification) based on Attestation Evidence. In different 
domains, the trustworthiness of the exact same thing using RATS can be 
assessed differently (depending of the policies, e.g. critical 
infrastructure domain vs. eCommerce . In general, the creation of 
Attestation Claims of course do not change the device :)

> 
> 
>>   * Attestation Evidence: Proof for one or more Attestation Claims
>>     (characteristics, attributes, ...) that affect device
>>     trustworthiness, such as its hardware identity, firmware,
>>     software, configuration or composition, compliance status and
>>     runtime state. Attestation Evidence may be consolidated through
>>     the use of cryptographic hash and key generation algorithms.
>>     signatures over portions of the Attestation Evidence. Note that
>>     Claims are non-proven assertions as opposed to Attestation Evidence.
> How about just “Signed Claims” or “Secure Claims". Same comment about 
> “affect” as above. Definition can be just “Claims that have been signed 
> or similarly secured for Conveyance.”

As stated above, a signed claim (set) is not automatically a semantic 
equivalent to evidence. Attestation Evidence can only be produced by a 
RoT of Reporting, while (signed) claim sets are produced by a RoT of 
Measurement.

tl;dr very specific and detailed example on software component integrity 
in this comment

To give a very concrete common example: In the domain of software 
component integrity, where (Co)SWID can be used as RIMM, a Linux-based 
OS is capable of producing IMA (Integrity Measurement Architecture) logs 
(other OS have equivalent capabilities). In a nutshell, the OS creates 
hash values about every software component executed (typically from FS, 
with smaller things these are blockdevice identifier, addresses/offsets) 
in the order of execution over time. Measured/Verified Boot procedures 
(formerly called Secure Boot, a now deprecated term) allow the same kind 
of measurements of Computing Contexts started before the OS (prominent 
examples include UEFI/BIOS or Bootloaders). The point is, these staged 
Computing Contexts all have their own Claimants, none of them can create 
CWT today or in the foreseeable future, but in a Measured Boot 
architecture, they are able to take on the role of root of trust of 
measurement (RTM) and can create Attestation Claims.

At some point, an "inbox-API" for a root of trust for reporting (RTR) is 
available in a Computing Context. This can be a, for example, a specific 
proto-enclave, a CC-certified trust-zone, or a TPM Trusted Software 
Stack - the exact technology underneath does not matter, but a set of 
specific capabilities are required, e.g. including but not limited to: 
based on root of trusts, a physical coupling to the system that is 
"measured", protection of execution, and a shielded location. 
Attestation Claims (in this example the IMA logs) can be consumed by a 
RTR "inbox-API" - in the temporal sequence they were created in - in 
order to produce a very specific hash value that can only be created, if 
these exact Attestation Claims in that order are measured by the RTMs 
and then available to the RTR. Wrt Software Component Integrity, the 
output of the RTR is Attestation Evidence that can only be created, if 
the correct software components are executed in the intended order - and 
no other software component is executed. Consumer of that Attestation 
Evidence is a Verifier (root of trust of verification). On the Verifier 
side: A corresponding RIM wrt to the Attestation Evidence would be the 
expected hash values that are created by the RTR (Attester). A 
corresponding RIMM wrt to the Attestation Claims would be an appropriate 
Manifest of (Co)SWIDs.

Typically, there are points in time at which especially interesting 
Attestation Evidence (in our example the RTR hash values) can be 
created: after each staged Computing Context, for example (and in this 
example, this would be the already mentioned UEFI, bootloader, kernel, 
etc.).

If the RTR does not produce the exact Attestation Evidence that is 
expected, the Attestation Claims (e.g. secure audit logs) can provide 
more insight into which software component was "out of line".

In summary - in this example there are multiple Claimants that create 
Attestation Claims, are RTMs, and cannot create tokens. There is also a 
hardware RTR that consumes (a large volume of) Attestation Claims in 
order to create very specific Attestation Evidence about the current 
integrity of software components that are or were in execution.

Interoperable network protocols are required to convey Attestation 
Claims, Attestation Evidence, RIM(M)s, and the policies of local 
attestation (see Andrea's and Monty's replies before) in a way that a 
verifier can create an assessment of a communication partners 
trustworthiness.

> 
> 
>>   * Attester: An endpoint that has a root-of-trust for reporting (RTR)
>>     and implements a conveyance protocol, authenticates using an
>>     Attestation credential, collects Attestation Evidence about itself
>>     and presents it to a consumer of evidence (e.g. a Relying Party or
>>     a Verifier).
>>
>>   * Claimant: An entity that make an assertion to a certain property
>>     regarding the trustworthiness of an entity. This may be the
>>     binding of an Attester to an RTR or any other kind of property.
> Commenting on Attester and Claimant together. We need a term for the 
> “subject” of the Claims, so I propose replacing “Claimant” with “Entity”

Measurment's about a different system than yourself or "on behalf" of 
another system is a gap that we did not address explicitly in the text 
yet. But I think that is a very good proposal. As implied by the example 
above, I'd strongly recommend to retain the role of Claimant, but add 
the "subject" of the Claim as a term. Entity though is one of the most 
generic term right after "thing" - and I would like to see a little more 
specialized term.

> 
>   * Entity: that about which the Claims are made. Often referred to as a
>     device. Examples are a phone, IoT Device or Router. It can also be a
>     submodule of a device.
>   * Attester: the part of an Entity that secures the claims (securing is
>     typically done by signing). It turns “Claims” into “Signed Claims”.
>       A TPM is an example of this.
> 
> 

I see your point. We were struggling about "authentication" a lot, as 
attestation is often misinterpreted to scoped to enable "stronger 
authentication". Remote Attestation Procedures include the scope of 
establishing trust in the identity of the communication partner and also 
the endorsement of capabilities of, for example, a component that is an 
Attester (RTR). But Remote Attestation is not limited to this specific 
subset of capabilities/semantics. We should try to word-smith text that 
avoids the term authentication, I think.

> 
> 
>>   * Conveyance: The transfer of Attestation Evidence between Attester
>>     and Verifier, facilitated by network protocols that are reliable,
>>     secure and can prove the freshness of Evidence, if required.
> 
>>   * Reference Values: Information that can be matched with collected
>>     Attestation Evidence to determine if the device's operational
>>     state complies with an intended/expected operational state (e.g.
>>     Reference Integrity Measurements).
> Prefer "Reference Claims" so they are clearly tied to the term Claim. I 
> could live without definition entirely if we really wanted to be simple.

As, for example, signed (Co)SWID can be Reference Values (in that case 
RIMM) and as those exceed the semantic of a single claim, I really am 
not comfortable with reducing the scope of Reference Values to Claims.

The Creation of Attestation Evidence ranges from simple to rather 
complex, I think. That is why creating appropriate network protocols 
also requires a lot of running code and modularity.

> 
> 
>>   * Relying party: An entity that consumes and assesses Verifier
>>     results for the purpose of improved risk management, operational
>>     efficiency, security, privacy (natural or legal person) or safety.
>>     The Verifier and Relying Party functions may be tightly integrated.
> I think the common and general definition is any server / service like 
> an online bank, e-commerce site, enterprise document server and such 
> whether or not the asses Claims.  I propose:

As the role of Relying Party can, but does not have to be coupled with 
the role of Verifier (appraisal of Attestation Claims can be a very 
computing intensive task and can require a large volume of Reference 
Values), I'd still recommend to make a distinction between entities that 
consume Attestation Claims and Attestation Evidence.

The assumption here is that a relying party can process Attestation 
Claims that do not have to be appraised, but are considered trusted due 
to implicit attestation.

> 
>   * Relying Party: More generally any server or service like an online
>     bank or e-commerce site. Here a server or service that consumes and
>     assesses Verifier results for the purpose of improved risk
>     management, operational efficiency, security, privacy (natural or
>     legal person) or safety. The Verifier and Relying Party functions
>     may be tightly integrated.
> 
> 
>>   * Remote Attestation: The procedure of supplying Attestation
>>     Evidence to a communication partner via an Attester using network
>>     protocols for Conveyance.
> I’d kind of prefer to leave this out as the whole document is about it. 
> If it is kept in, I think it should refer to the whole end-end process.

I am unsure about this. A concise definition might really help, but I 
assume this one can be worded better? How do other individuals think 
about this?

> 
>>   * Root of Trust: The base entity for a chain of trusts that builds
>>     up trust in an overall system.
> Some people think roots-of-trust are the boot ROM, embedded secret keys 
> and such in a device.  Other people think they are X.509 root 
> certificates published by CAs used for verifying chains.  It’s not clear 
> which you are referring to. That said, I think we should just remove 
> this definition from the charter. It doesn’t seem essential.

This point of view I do not share. Roots of trusts (the last "s" is 
intentional) are an essential part of this effort, I think. If they are 
often mistaken (as are, for example certificates and identities), I 
think we should rather make the effort and create standards that (at 
least in the RATS domain) make very precisely clear what intent, scope 
and audience are.

> 
>>   * Verifier: An endpoint that has a root-of-trust for verification
>>     and implements a conveyance protocol, verifies Attestation
>>     credentials and may authenticate using Attestation Evidence or
>>     other credentials, appraises Attestation Evidence against
>>     Reference Values or policies and makes verification results
>>     available to Relying Parties.
> I propose:
> 
>   * Verifier: A server or service that receives Signed Claims and
>     processes them by verifying the signature and possibly comparing to
>     Reference Claims. 

Please see the example above and the intended separation of duty 
("offloading the burden of appraisal").

>   * Token: a collection of Signed Claims that is Conveyed from the
>     Attester to the Verifier

If I am not mistaken, EA-Tokens do not have to be signed (which is good, 
as some specific technologies deployed for the foreseeable future cannot 
sign a CWT). Also, I think the separation of Attestation Claim and 
Attestation Evidence is a necessity and mandated by their disjunct semantic.

>   * Entity Manufacturer: The company that made the Entity. The Entity
>     Manufacturer configures the Attester with signing keys. It may also
>     be the Verifier or supply signature verification keys to the Verifier.

I agree that an endorsement of the capability of an entity (or system 
component - entity is quite generic, see RFC4949. I am an entity, I 
think, and my parents have nothing to do with this) is very important. 
If that is your intent here, I totally agree, but think that more 
word-smithing will be required.

Viele Grüße,

Henk

> 
> 
> 
>> On Sep 18, 2018, at 1:26 AM, Henk Birkholz 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi all,
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 21 Sep 2018 17:44:35 +0200

Hello Laurence,

please find replies and comments in-line (and sorry for replying in the 
wrong order...).

On 09/20/2018 11:29 PM, Laurence Lundblade wrote:
> Forking the discussion here to focus on implicit/explicit attestation. 
> That seems to be a new term invented in this WG Charter as I haven’t 
> seen it elsewhere. I’m not sure what it means yet. It seems to have 
> something to do with how the loop is closed in the Attestation Model 
> below. In particular the role of the Entity Manufacturer.

The term "explicit attestation" wrt to remote attestation is actually 
"new" in a sense that "implicit attestation" got a sharper focus and is 
now used in open documents. In consequence, specializing "explicit" 
attestation next to implicit attestation (wrt to remote attestation) was 
the smallest and most intuitive semantic step - terminology-wise.

Google'ing for (implicit) attestation protocols, I found these TCG 
documents.
The first one uses "implicit attestation" for "strong Device Identity" 
(same approach as the EAT). The second one is 7 years older and (to my 
surprise, actually), defines both Attestation and - in fact- Attestation 
Evidence. I have to admit that we have not taken these definition into 
account, but will in the next iteration. There does not seem to be a 
conflict. Also, the semantic equivalent to RIMM seems to be Template 
Reference Manifest in the second document.
https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation-v1-rev93.pdf> 
https://www.trustedcomputinggroup.org/wp-content/uploads/IFM_PTS_v1_0_r28.pdf

> the signature on the Claims

This is, in essence, _the_ reference work-flow of implicit attestation, 
I think. Please note that here the signatures are verified (which is the 
implicitness) in contrast to appraising the signed (temper-evident, 
amongst other characteristics) claim sets via reference values (which an 
Verifier is capable to do wrt explicit attestation).

> 
> One of my guesses for what implicit attestation is — The RP (Relying 
> Party) does not get any root keys or such from the Entity Manufacturer 
> or a CA or a trusted third party. They verify the signature solely based 
> on what is in the signed token they received. The RP probably did send a 
> nonce and the Entity signed it, so there is proof-of-posession of the 
> Entity's key, but that key and device could be any device so little is 
> proved. The RP can remember the Entity’s key and expect it to be the 
> same next time to give it some value. This is called self-attestation of 
> surrogate attestation in FIDO. It not considered very secure. The loop 
> is not closed.

I assume that the key remembered by the Relying Party is a public key - 
inside the x.509? Very likely it is not the private key you did the 
proof-of-possession for. In any case, please see above wrt implicit 
attestation.

I am not sure what to make of "verify the signature solely based
on what is in the signed token they received" - I assume that is 
different from verifying the signature, as the RP did not get anything 
from the corresponding CA?

I am also assuming that the "RP can expect the same key again" via the 
accompanying x.509 and therefore can infer characteristics on how the 
claims should be composed (again)?

As the current (wordy) charter text illustrates proof-of-possession is 
the basis for implicit attestation and in that regard I think we are 
actually in alignment here.

> 
> Another one of my guesses — The RP does get key material with which to 
> perform verification, but it is not directly from the Entity 
> Manufacturer. Instead there is some CA or trusted 3rd party in the loop. 
> This is a realistic scenario. The loop is closed so it is secure.

This is a work-flow that I would very much like to flesh out, homogenize 
and include more... explicitly :)

> I see this as a topic for technical discussion, not something for 

Well, apparently we are under the impression of... yes and no. In order 
to get goals/deliverables and scope right we have to agree on what term 
has which technical meanings, implications and dependencies. Assuming 
that background and terminology could be pruned from the charter at some 
point of consensus and then be... and that is my problem here... 
maintained without changing their meaning (and therefore not implicitly 
changing the charter).
Carsten highlighted the problems with that approach, so while these 
definitions may go down to a technical level, they are essential to the 
meaning of the charter. It is a bit of a hen & egg problem, I am afraid, 
due to the terminology document (evolving into an architecture document) 
being in flux.

Viele Grüße,

Henk

> 
> LL
> 
> 
> 
> 
> 
>> On Sep 18, 2018, at 8:56 AM, Denis <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Henk,
>>
>> If a device is able to sign something, it does not necessarily mean 
>> that what is signed really comes from the device, unless "that device 
>> has some well known properties".
>>
>>> The definition of implicit attestation might require some 
>>> improvement, I assume (and I don't mean by adding even more words).
>>>
>> It does not mean anything from the above list. My arguments have 
>> nothing to do with "Identity". Typically, an Attestation Certificate 
>> it is an X509 certificate, as in FIDO.
>>
>>>
>>> The smallest identity document I can think of would be a signed 
>>> public key. More commonly today, it would be an ASN.1-based identity 
>>> document, I assume.
>>

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 21 Sep 2018 18:24:08 +0200

Hello Laurence,

On 09/20/2018 10:18 PM, Laurence Lundblade wrote:
> It’s a bit buried, but I see you do intend that this include the EAT 
> work. Thus the work would not be TPM/TCG centric. It would include use 
> cases like FIDO and Android Keystore attestation that are often based on 
> TrustZone. It could also include EPID-related use cases. Please confirm.

I am not sure, if I am the authority to confirm this, as kickstarting 
RATS is a group effort. What I can do is to agree with the statement 
that RATS is abstracting from specific hardware solutions that provide, 
for example trust anchors and shielded locations (which keystores are a 
subset of, I think), or restrict secret key access (protection of 
execution, I think) based on system status (or more generic - system 
health).

Conveyance of Attestation Claims is a big part of implicit attestation 
and the comparison of (amongst other information) claims wrt to 
appraisal of Attestation Evidence in explicit attestation. As EAT 
provides a data format to express these claim sets in a state-of-the art 
representation (and, if signed, via a state-of-the-art COSE envelope) 
they are compose a perfect option to address the data model part of 
conveyance.

> 
> My preference would be to choose another name for the group that is 
> neither EAT or RATS to help make this clear. I don’t really think there 
> is a “procedure” with EAT. To be honest, I don’t really like “RATS” as a 
> name. My suggestions are “RA” for Remote Attestation or “CAT” for Common 
> Attestation Technology (and besides cats caused us to invent the 
> Internet so we share pictures of them (securely)).
> 
>     The purpose of RA/CAT is to allow a Relying Party (e.g. a web
>     service, network management center...) to securely receive Claims
>     from an Entity requesting service (e.g. a phone, router, IoT
>     device...) that allow the Relying Party to determine if and how that
>     entity is trusted.  For example:
> 
>       o An IoT management back-end receives a signed nonce that proves
>         the IoT device is the genuine article manufactured by the
>         expected OEM and is not a Linux box or such emulating such a device.
>       o A network management center receives a set of measurement claims
>         from a router to know that the configuration has not been
>         tampered with.
>       o An online banking service receives many claims about the device
>         including location, SW versions and measurements and determines
>         that it will allow a higher-than-usual value transaction.
>       o A government online document server receives claims indicating
>         manufacture and location of the device, determines they are from
>         the correct country and grants access to classified documents.
> 
>     There are protocols for determining and securing the identity of a
>     server or service (TLS and IPsec). There are many protocols for
>     authenticating end users (SASL, TLS client auth, EAP…). There are no
>     general protocols for managing the characteristics, security and
>     identity of an end client device (an Entity). RA/CAT aims to address
>     that gap.
> 
>     There is no goal here to set criteria for what is trustworthy or not
>     as that is an impossible task as it will vary widely from use case
>     to use case. The goal here is to securely provide information
>     (Claims) to the Relying Party so it can make that determination
>     based on its own criteria and needs.

RATS addresses a vital domain that I feel is missing here: critical 
infrastructure or safety critical systems.

Examples given: voting machines, rail-road object controllers, air plane 
cabin and avionic control systems & corresponding airports, cell-phone 
towers, or domains with high levels of confidentiality, in general.

Of course, there is the high demand to convey information to assess a 
system's trustworthiness in a trusted and resilient way coming from 
network equipment (or network function services) vendors. But managing 
the integrity (and actual composition) of a large number of end-user 
devices is also a requirement with continuously growing importances - 
not only for governments, but also for enterprises.

The scope of numbers of devices expanding due to encompassing 
constrained-node environments will render RATS a very interesting effort 
(that is why "offloading the burden of appraisal" and differentiating 
the roles of Verifier, Relying Party & "measured system (component)" is 
so vital, I think).

> 
> 
> 
> I don’t think the intro should mention public key crypto. I know of 
> attestation solutions that do not use it.
> 

This is a good point, we added proof-of-possession to enable readers to 
better intuitively grasp the context in the IETF. Could you reference 
some of the solutions? I think that would help address that comment.

> I tend to prefer “attestation” when the goal is whether and how a device 
> is to be trusted and “authentication” when the goal is how a human is to 
> be identified. FIDO, OAuth, SASL are all about users and use the word 
> authentication.

Yes - I think we are in agreement here. I am not sure if we can skip the 
term entirely, but the focus is on more than "stronger authentication".

Viele Grüße,

Henk

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 21 Sep 2018 16:26:00 +0000

[nms] See inline below.

On 9/20/18, 4:15 PM, "RATS on behalf of Laurence Lundblade" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
[nms] --- snip ---
·         Attestation Claim: Information about some characteristics or attributes that affect device trustworthiness.
Would just prefer to use “Claim”.  Add examples: measurements of running SW, GPS location, boot state, HW and SW Versions.

[nms] Agree claims do not change the device. Claims are referring to immutable(?) properties of the device. Properties that influence a verifier to trust the device to some degree or purpose different than if the claims were not made known. If ‘affect’ is too strong maybe ‘influence’ is better?

[nms] --- snip ---

·         Attester: An endpoint that has a root-of-trust for reporting (RTR) and implements a conveyance protocol, authenticates using an Attestation credential, collects Attestation Evidence about itself and presents it to a consumer of evidence (e.g. a Relying Party or a Verifier).
·         Claimant: An entity that make an assertion to a certain property regarding the trustworthiness of an entity. This may be the binding of an Attester to an RTR or any other kind of property.
Commenting on Attester and Claimant together. We need a term for the “subject” of the Claims, so I propose replacing “Claimant” with “Entity”

·         Entity: that about which the Claims are made. Often referred to as a device. Examples are a phone, IoT Device or Router. It can also be a submodule of a device.
·         Attester: the part of an Entity that secures the claims (securing is typically done by signing). It turns “Claims” into “Signed Claims”.  A TPM is an example of this.
[nms] This seems to be conflating different entities into a single entity (which should not be an objective). Attester is the entity that assembles claims about the attesting environment. Claimants often are entities in the manufacturing and supply chain that do something to indeed ‘affect the trustworthiness’ of the device. It may be some form of packaging, hardening, validation or compliance tests. There may be multiple disparate entities involved. When those entities construct a claim (aka verifiable claim) they become known as a ‘claimant’ – or at least that is the intent of the use here. An attester assembles the various claims (authored by multiple claimants) and even provide its own self-asserted claims and present them as evidence in the context of a conveyance.

[nms] --- snip ---

·         Reference Values: Information that can be matched with collected Attestation Evidence to determine if the device's operational state complies with an intended/expected operational state (e.g. Reference Integrity Measurements).
Prefer "Reference Claims" so they are clearly tied to the term Claim. I could live without definition entirely if we really wanted to be simple.

[nms] Agree it may not be needed. The motivation for not calling them reference claims is that the verifier should apply a policy to reference claims that determines how to respond to the verification step. For example, if a claim states that the device is common criteria certified to level 3. A reference claim from the CC evaluation lab may assert the device meets level 3+. If a verifier policy specifies a range of acceptable CC reference values (e.g. 2 – 3+) then the reference claim (3+) isn’t the same as the attested claim (3) nor is it the same as the reference values (range: 2, 2+, 3, 3+).

[nms] --- snip ---
·         Root of Trust: The base entity for a chain of trusts that builds up trust in an overall system.
Some people think roots-of-trust are the boot ROM, embedded secret keys and such in a device.  Other people think they are X.509 root certificates published by CAs used for verifying chains.  It’s not clear which you are referring to. That said, I think we should just remove this definition from the charter. It doesn’t seem essential.

[nms] Agree that definition of root-of-trust could be reserved for a terminology draft.

·         Verifier: An endpoint that has a root-of-trust for verification and implements a conveyance protocol, verifies Attestation credentials and may authenticate using Attestation Evidence or other credentials, appraises Attestation Evidence against Reference Values or policies and makes verification results available to Relying Parties.
I propose:
·         Verifier: A server or service that receives Signed Claims and processes them by verifying the signature and possibly comparing to Reference Claims.
[nms] Aside from the subtle differences between reference claims and reference values and that a verifier doesn’t need to be a server/service (as it could be a client or peer), the proposed definition is simpler and easier to comprehend.

Finally, I’d like to add:
·         Token: a collection of Signed Claims that is Conveyed from the Attester to the Verifier
[nms] I don’t object to a definition of token, but there is already a definition and use context in the form of JWT and CWT. This definition differs slightly. To avoid re-defining an existing IETF term. It might make sense to move this to a terminology draft. I’m not sure it is essential for inclusion in a charter document.
·         Entity Manufacturer: The company that made the Entity. The Entity Manufacturer configures the Attester with signing keys. It may also be the Verifier or supply signature verification keys to the Verifier.
[nms] I think this definition conflates ‘device’ with ‘entity’. Entity can refer to a manufacturer or other participant of a supply chain. The term ‘entity’ is intended to be an abstraction that avoids having to enumerate the complexities of supply chains and deployment architectures.

LL

Hi all,

Viele Grüße,

Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 21 Sep 2018 10:01:34 -0700

RATS folks: Henk, Ned, Monty and Eric,

EAT has deployment scenarios and goals that are distinct from RATS. They don’t need new protocols in the same way as that RATS does. They will not be rooted in TCG and TPM work. There is precedence in the industry for these use as can be seen in FIDO and Android Keystore Attestation. EAT can not just be a subordinate part of RATS as you seem to imply below. 

Even if our deployment goals and use cases are not the same, I would think we can have separate documents where we need to and do the work in one WG.

I think it would be bad to have two attestation working groups in the IETF, one for EAT and one for RATS.  Thus, I think the charter of this WG must explicitly include the EAT use cases and goals. 

LL

> On Sep 21, 2018, at 9:24 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hello Laurence,
> 
> I am not sure, if I am the authority to confirm this, as kickstarting RATS is a group effort. What I can do is to agree with the statement that RATS is abstracting from specific hardware solutions that provide, for example trust anchors and shielded locations (which keystores are a subset of, I think), or restrict secret key access (protection of execution, I think) based on system status (or more generic - system health).
> 
> Conveyance of Attestation Claims is a big part of implicit attestation and the comparison of (amongst other information) claims wrt to appraisal of Attestation Evidence in explicit attestation. As EAT provides a data format to express these claim sets in a state-of-the art representation (and, if signed, via a state-of-the-art COSE envelope) they are compose a perfect option to address the data model part of conveyance.
>

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 21 Sep 2018 23:06:26 +0200

Hello Laurence,

splintering emerging work on attestation in the IETF at the very 
beginning does not seem to be very productive to me, too. I 
wholeheartedly agree with that notion.

I hear your assessment that EAT and RATS have distinct goals and -  as 
our slowly improving convergence of approaches shows - that is true to 
some extend, I think. But I also think that there is significant overlap 
and creating synergy via this overlap, while also creating a shared 
consistent terminology, is vital and I'd optimistically consider that 
achievable.

I really am interested in the deployment scenarios that you envision for 
EAT. I am rather certain that we could identify more overlap there. The 
RATS charter covers deployment only in very specific detail at the 
moment. Some scoping had to be done to create a tangible set of 
realistic goals for chartering. That said, deployment is also an 
important aspect for RATS, just not at this very beginning.

I am also rather certain that EAT can be used in a lot of places. I 
really like the approach, as I am a proponent of CWT. I also was under 
the impression that EAT does not exclude the option to be rooted in TPM? 
While that might only be a technical detail, I bring that up because the 
"non-exclusiveness" of both EAT and RATS wrt to specific hardware 
solutions was an overlap. But maybe I missed something obvious here.

In summary, creating a common "middle ground" and working in concert in 
these shared domains (manifested in drafts) seems to be the optimal way 
to move forward, I think.

My only actual concern remains to be the creation of a shorter charter 
:) Merging goals does not really sound like making it shorter - well, at 
least initially.

Viele Grüße,

Henk

---

From: "Diego R. Lopez" <[email-masked]>
Date: Fri, 21 Sep 2018 22:08:03 +0000

Regarding the length, we could always aim at using the intersection rather than the union...

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:         +34 913 129 041
Mobile:  +34 682 051 091
----------------------------------

On 21/09/2018, 17:06, "EAT on behalf of Henk Birkholz" <[email-masked] on behalf of [email-masked]> wrote:

    Hello Laurence,

    Viele Grüße,

    Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 23 Sep 2018 17:05:34 -0700

From the TCG paper <https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation-v1-rev93.pdf>  it looks to me that implicit refers to use of a deterministic process for creating an attestation key and device ID from a seed (the UDS) rather than explicitly putting an attestation private key and X.509 certificate (e.g., IEEE Device ID) in each device. That is a fine thing to do. No objection to that. 

By inference, then I’d guess that IEEE Device ID is an example of explicit attestation. 

From an attestation taxonomic view, I don’t think we can divide into implicit vs explicit.  There are many more variants such as EPID, other variants of ECDAA, other ways to set pub key crypto and IDs, attestation based on symmetric keys and so on. I haven’t read enough TCG documents to know for sure, but I doubt that the TCG taxonomy is sufficient to cover all of them. 

EAT’s approach to this is to just say that tokens are signed using the COSE format (and probably JOSE too) and to focus on the definition of claims with the idea that the claims can be used with lots of different ways of signing and attestation key set up. This seems like clear achievable work.

I think it is OK to work on standardization of the attestation key and signing set up. We will probably need several such efforts as one size definitely won’t fit all. 

So I propose we replace the internal / external intro sentence and bullets with this:

There are many ways to provision / store / derive / establish the key material used by the Attester to digitally sign claims that are transmitted to the Verifier. These might include EPID, some variant of ECDAA, IEEE DeviceID, TC Implicit Identity Based Device Attestation, other public key based schemes and schemes using symmetric keys. They might also include a privacy proxy or privacy CA.

The standardization of claims is to be largely independent of these different ways. Any such way of setting up this key material must be able to secure claims expressed in CBOR or JSON directly or indirectly (e.g., a hash of the claims). 

The WG may choose to standardize some of the ways to provision / store / derive / establish the key material. 

I know the last sentence is a bit wishy washy for a charter. Personally, I was interested in punting that work until EAT is done and there is more operational experience and practice. If there’s a few specific scheme we want to go after, maybe we do that. One or two might be TCG/TPM oriented. Another that works for Android Key Store and FIDO attestation. 

LL

> On Sep 21, 2018, at 8:44 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hello Laurence,
> 
> please find replies and comments in-line (and sorry for replying in the wrong order...).
> 
> 
> The term "explicit attestation" wrt to remote attestation is actually "new" in a sense that "implicit attestation" got a sharper focus and is now used in open documents. In consequence, specializing "explicit" attestation next to implicit attestation (wrt to remote attestation) was the smallest and most intuitive semantic step - terminology-wise.
> 
> Google'ing for (implicit) attestation protocols, I found these TCG documents.
> The first one uses "implicit attestation" for "strong Device Identity" (same approach as the EAT). The second one is 7 years older and (to my surprise, actually), defines both Attestation and - in fact- Attestation Evidence. I have to admit that we have not taken these definition into account, but will in the next iteration. There does not seem to be a conflict. Also, the semantic equivalent to RIMM seems to be Template Reference Manifest in the second document.
> > https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation-v1-rev93.pdf> https://www.trustedcomputinggroup.org/wp-content/uploads/IFM_PTS_v1_0_r28.pdf
> 
> 
> This is, in essence, _the_ reference work-flow of implicit attestation, I think. Please note that here the signatures are verified (which is the implicitness) in contrast to appraising the signed (temper-evident, amongst other characteristics) claim sets via reference values (which an Verifier is capable to do wrt explicit attestation).
> 
> I assume that the key remembered by the Relying Party is a public key - inside the x.509? Very likely it is not the private key you did the proof-of-possession for. In any case, please see above wrt implicit attestation.
> 
> on what is in the signed token they received" - I assume that is different from verifying the signature, as the RP did not get anything from the corresponding CA?
> 
> I am also assuming that the "RP can expect the same key again" via the accompanying x.509 and therefore can infer characteristics on how the claims should be composed (again)?
> 
> As the current (wordy) charter text illustrates proof-of-possession is the basis for implicit attestation and in that regard I think we are actually in alignment here.
> 
> This is a work-flow that I would very much like to flesh out, homogenize and include more... explicitly :)
> 
> Well, apparently we are under the impression of... yes and no. In order to get goals/deliverables and scope right we have to agree on what term has which technical meanings, implications and dependencies. Assuming that background and terminology could be pruned from the charter at some point of consensus and then be... and that is my problem here... maintained without changing their meaning (and therefore not implicitly changing the charter).
> Carsten highlighted the problems with that approach, so while these definitions may go down to a technical level, they are essential to the meaning of the charter. It is a bit of a hen & egg problem, I am afraid, due to the terminology document (evolving into an architecture document) being in flux.
> 
> Viele Grüße,
> 
> Henk
> 
>> LL
>>> On Sep 18, 2018, at 8:56 AM, Denis <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Henk,
>>>

---

From: "Fuchs, Andreas" <[email-masked]>
Date: Mon, 24 Sep 2018 08:37:39 +0000

Hi Laurence,

the distinction between explicite and implicite (in the TC(G) community) is a different one:

- Explicite Attestation is where an Attestation Claim (or statement of properties) is represented as a data structure and signed (e.g. by the TPM). Thus the verifier will verify that the signature originates from the device's shielded reporting component (e.g. a TPM) and will consume the Claims / properties.

- Implicite Attestation is where only a nonce is signed (by the TPM or in DICE). The verifier however knows (e.g. by a Certificate) that the private key for this signature can only be used if certain Attestation Claims (certain properties) are fulfilled. In case of a TPM-based implicite attestation this may be certain PCRs (those that the explicite attestation just signs and transfers) have a certain value. In case of DICE the key for implicite attestation is derived from the currently running software, thus knowledge of the key (and thus usage) is restricted to the trusted software configuration of the device.

I hope this makes the division into implicite vs explicite a little better understandable from a taxonomic view.

Regarding IEEE Device ID: This is first and foremost a authentication method. If however the DeviceID was extended such that the access to its private key was restricted e.g. by a TPM to a certain software configuration and this was described in an extension of the DevID certificate, then this would be implicite attestation.

Let me know if this makes sense to you or let's discuss this a little further.

Best regards,
Andreas

________________________________
From: RATS [[email-masked]] on behalf of Laurence Lundblade [[email-masked]]
Sent: Monday, September 24, 2018 02:05
To: Birkholz, Henk
Cc: [email-masked]; Denis; [email-masked]
Subject: Re: [Rats] [EAT] Implicit vs Explicit Attestation (was Re: Scope, Goals & Background for RATS)

>From the TCG paper<https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation-v1-rev93.pdf>  it looks to me that implicit refers to use of a deterministic process for creating an attestation key and device ID from a seed (the UDS) rather than explicitly putting an attestation private key and X.509 certificate (e.g., IEEE Device ID) in each device. That is a fine thing to do. No objection to that.

LL

On Sep 21, 2018, at 8:44 AM, Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:

Hello Laurence,

Viele Grüße,

Henk

LL
On Sep 18, 2018, at 8:56 AM, Denis <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

Hi Henk,

Hi Denis,

This is fine.

Viele Grüße,

Henk
...

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 24 Sep 2018 13:06:55 +0200

Hello Laurence,

please find as my reply a general question up front and specific 
comments in-line.

The gap addressed by your proposed text is about keys and claims, I 
think. In essence:

* provision / store / derive / establish the key material, and
* standardization of claims

Is that correct?

I think that is not resembling the complete picture about EAT. Is that 
also correct?
If so, could you provide us with an abstract problem statement and a 
corresponding description of the gap the EAT scope intends to address? 
What is missing in my very short summery above? (maybe there is an email 
I did not find ad-hoc that does address these gaps already)

A single comment in-line.

On 09/24/2018 02:05 AM, Laurence Lundblade wrote:
>  From the TCG paper 
> <https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation-v1-rev93.pdf>  
> it looks to me that implicit refers to use of a deterministic process 
> for creating an attestation key and device ID from a seed (the UDS) 
> rather than explicitly putting an attestation private key and X.509 
> certificate (e.g., IEEE Device ID) in each device. That is a fine thing 
> to do. No objection to that.
> 
>  From an attestation taxonomic view, I don’t think we can divide into 
> implicit vs explicit.  There are many more variants such as EPID, other 
> variants of ECDAA, other ways to set pub key crypto and IDs, attestation 
> based on symmetric keys and so on. I haven’t read enough TCG documents 
> to know for sure, but I doubt that the TCG taxonomy is sufficient to 
> cover all of them.

Implicit vs. explicit attestation is the most prominent facet of 
attestation procedures we intended to differentiate at the beginning. 
There are more facets and details to the concept, of course. Maybe it is 
of use, if we try to abstract the intent and meaning a bit more in this 
context:

1.) _Key Availability_: The availability of keys can have different 
meanings.

If a private key can only be used, if a system has a specific status 
(please see the comments of Andreas in this thread), there is "more 
meaning" to the signature. A Verifier has to have an understanding of 
this meaning - and network protocols can provide this context via the 
remote attestation or from a TTP - there are different procedures how to 
provide that context information.

There are more facets to this concept. For example, a Claimant create 
signatures using an available private key for the system it resides on 
or on behalf of another system, if I understand the ongoing discourse 
correctly.

2.) _Claim Intent_: Claims (signed or not, the EAT draft does not 
mandate signing, which is useful, I think) also can have different intents.

Currently, I think, we are talking about:

2a.) _trusted claims_, in general, that are signed or accompanied by 
signature claims, that are not necessarily intended to be verified (not 
used as Attestation Claims), and that are of interest to post-processes 
(e.g. age or location claims).

2b.) _claims enabling the assessment of trustworthiness_ that are 
intended to create trust in the trustworthiness of a system (used as 
Attestation Claims) by appraisal of the Attestation Evidence they 
compose (e.g. comparison of a quote generate by an eSE/HSM or a list of 
executed software components with Reference Values).

Laurence, do you find the complete scope of EAT fitting into this very 
high level description? Or is something vital missing, maybe even wrong, 
conceptually?

Viele Grüße,

Henk

> 
> EAT’s approach to this is to just say that tokens are signed using the 
> COSE format (and probably JOSE too) and to focus on the definition of 
> claims with the idea that the claims can be used with lots of different 
> ways of signing and attestation key set up. This seems like clear 
> achievable work.
> 
> I think it is OK to work on standardization of the attestation key and 
> signing set up. We will probably need several such efforts as one size 
> definitely won’t fit all.
> 
>     There are many ways to provision / store / derive / establish the
>     key material used by the Attester to digitally sign claims that are
>     transmitted to the Verifier. These might include EPID, some variant
>     of ECDAA, IEEE DeviceID, TC Implicit Identity Based Device
>     Attestation, other public key based schemes and schemes using
>     symmetric keys. They might also include a privacy proxy or privacy CA.
> 
>     The standardization of claims is to be largely independent of these
>     different ways. Any such way of setting up this key material must be
>     able to secure claims expressed in CBOR or JSON directly or
>     indirectly (e.g., a hash of the claims).

I think it is a good idea to include both CWT and JWT.

> 
>     The WG may choose to standardize some of the ways to provision /
>     store / derive / establish the key material. 
> 
> 
> I know the last sentence is a bit wishy washy for a charter. Personally, 
> I was interested in punting that work until EAT is done and there is 
> more operational experience and practice. If there’s a few specific 
> scheme we want to go after, maybe we do that. One or two might be 
> TCG/TPM oriented. Another that works for Android Key Store and FIDO 
> attestation.
> 
> LL
> 
> 
> 
> 
>> On Sep 21, 2018, at 8:44 AM, Henk Birkholz 
>>> Forking the discussion here to focus on implicit/explicit 
>>> attestation. That seems to be a new term invented in this WG Charter 
>>> as I haven’t seen it elsewhere. I’m not sure what it means yet. It 
>>> seems to have something to do with how the loop is closed in the 
>>> Attestation Model below. In particular the role of the Entity 
>>> Manufacturer.
>>
>> "new" in a sense that "implicit attestation" got a sharper focus and 
>> is now used in open documents. In consequence, specializing "explicit" 
>> attestation next to implicit attestation (wrt to remote attestation) 
>> was the smallest and most intuitive semantic step - terminology-wise.
>>
>> surprise, actually), defines both Attestation and - in fact- 
>> Attestation Evidence. I have to admit that we have not taken these 
>> definition into account, but will in the next iteration. There does 
>> not seem to be a conflict. Also, the semantic equivalent to RIMM seems 
>> to be Template Reference Manifest in the second document.
>> > 
>> This is, in essence, _the_ reference work-flow of implicit 
>> attestation, I think. Please note that here the signatures are 
>> verified (which is the implicitness) in contrast to appraising the 
>> signed (temper-evident, amongst other characteristics) claim sets via 
>> reference values (which an Verifier is capable to do wrt explicit 
>> attestation).
>>
>>> Party) does not get any root keys or such from the Entity 
>>> Manufacturer or a CA or a trusted third party. They verify the 
>>> signature solely based on what is in the signed token they received. 
>>> The RP probably did send a nonce and the Entity signed it, so there 
>>> is proof-of-posession of the Entity's key, but that key and device 
>>> could be any device so little is proved. The RP can remember the 
>>> Entity’s key and expect it to be the same next time to give it some 
>>> value. This is called self-attestation of surrogate attestation in 
>>> FIDO. It not considered very secure. The loop is not closed.
>>
>> I assume that the key remembered by the Relying Party is a public key 
>> - inside the x.509? Very likely it is not the private key you did the 
>>> Another one of my guesses — The RP does get key material with which 
>>> to perform verification, but it is not directly from the Entity 
>>> Manufacturer. Instead there is some CA or trusted 3rd party in the 
>>> loop. This is a realistic scenario. The loop is closed so it is secure.
>>
>> This is a work-flow that I would very much like to flesh out, 
>> homogenize and include more... explicitly :)
>>
>> Well, apparently we are under the impression of... yes and no. In 
>> order to get goals/deliverables and scope right we have to agree on 
>> what term has which technical meanings, implications and dependencies. 
>> Assuming that background and terminology could be pruned from the 
>> charter at some point of consensus and then be... and that is my 
>> problem here... maintained without changing their meaning (and 
>> therefore not implicitly changing the charter).
>> definitions may go down to a technical level, they are essential to 
>> the meaning of the charter. It is a bit of a hen & egg problem, I am 
>> afraid, due to the terminology document (evolving into an architecture 
>> document) being in flux.
>>
>> Viele Grüße,
>>
>> Henk
>>
>>> LL
>>>> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>
>>>> Hi Henk,
>>>>
>>>>> We attempted to create a document that is as inclusive as possible 
>>>>> - within reason. Hence, it is also solution agnostic.
>>>>>
>>>>> As Andreas just said, Proof-of-Possession of a secret key is 
>>>>> intended to be captured by Implicit Attestation. In other words:
>>>>> if you are able to use that secret key to sign something, it 
>>>>> implies (that is the "implicitness" here) that "that device has 
>>>> that what is signed really comes from the device, unless "that 
>>>> device has some well known properties".
>>>>
>>>>> I am a bit confused by the use of "attestation certificate", 
>>>>> "private key" and "origin of data exchange" in your reply.
>>>>>
>>>>> means identity document, the concepts of "Singular Identity", 
>>>>> "Shared Identity", and "Group Identity" are already subsumed in the 
>>>>> IETF by the definition of "Identity" in RFC4949.
>>>>> public key. More commonly today, it would be an ASN.1-based 
>>>>> identity document, I assume.
>>>>
>>>>> Attestation and it also might require some provisioning (via 
>>>>> network protocols) in order to work,
>>>>> The fact that the definition of Attestation Evidence is difficult 
>>>>> to understand could be the biggest issue here, I think. Especially, 
>>>>> the definition of Remote Attestation, as you highlighted. I will 
>>>>> come back to this topic as soon as I have a few more free cycles :)
>>>>>
>>>>> Viele Grüße,
>>>>>
>>>>> Henk
>>>> ...
>>

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 24 Sep 2018 15:06:21 -0700

That’s super clear. Thanks! A few comments:

In EAT, many claims are dynamic and vary over time. For example GPS location can be a claim. The public key of a newly created key pair stored in a (Android) Key Store can be a claim. Obviously these can only be carried using explicit attestation. (Also, by my understanding it is hard to get a TPM to sign such things).

EAT is more focused on standardizing bits-on-the-wire and their meaning rather than the device architecture implementing it and particularly the way the keys are securely stored and managed. For example, EAT is mostly mum about TPM vs DICE. I’ve been using IEEE DeviceID as an example of a scheme built on an X.509 hierarchy as viewed from the wire. Perhaps that is somewhat incorrect since it is oriented to a particular device key storage architecture. When EAT uses X.509, the bits-on-the-wire shouldn’t really reflect if the keys were stored in a DICE, TPM, TrustZone or an eSE.

I’m curious if RATS is interested involving device side architectures, or is just interested in bits-on-the wire?  Maybe IETF should just do bits-on-the-wire, leaving the device architectures to TCG and IEEE?

LL

> On Sep 24, 2018, at 1:37 AM, Fuchs, Andreas <[email-masked]> wrote:
> 
> Hi Laurence,
> 
> From: RATS [[email-masked] <mailto:[email-masked]>] on behalf of Laurence Lundblade [[email-masked] <mailto:[email-masked]>]
> Cc: [email-masked] <mailto:[email-masked]>; Denis; [email-masked] <mailto:[email-masked]>
>> On Sep 21, 2018, at 8:44 AM, Henk Birkholz <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hello Laurence,
>> 
>> > https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation-v1-rev93.pdf <https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation-v1-rev93.pdf>> https://www.trustedcomputinggroup.org/wp-content/uploads/IFM_PTS_v1_0_r28.pdf <https://www.trustedcomputinggroup.org/wp-content/uploads/IFM_PTS_v1_0_r28.pdf>
>> 
>> 
>>>> On Sep 18, 2018, at 8:56 AM, Denis <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>> 
>>>> Hi Henk,
>>>> 
>> https://www.ietf.org/mailman/listinfo/eat <https://www.ietf.org/mailman/listinfo/eat>

---

From: "Wheeler, David M" <[email-masked]>
Date: Mon, 24 Sep 2018 22:21:58 +0000

One thing I think we should discuss is the claimant versus the attestor. I say this in the context of SGX Attestation.
In SGX, the Quoting Enclave signs the attestation, which is attesting to the code running in the enclave matches the attached hash (Mr.Enclave) and its signature was verified by a particular signing key (Mr.Signer).

The attestation signature cover an included a hash – this hash is of an accompanying structure created by the enclave code.

The attestor in this case is the Quoting Enclave. And the attestation is that the code is actually running inside an SGX enclave.

The accompanying structure could have GPS coordinates, another public key, a blockchain transaction, etc.
But it was created by the enclave code, and NOT DIRECTLY attested by the signature.
By extension, it could only be created by the enclave, however, and so if the enclave code can be trusted (via evidence of the attestation), “appropriate security policy decisions can be made regarding the attached data.”

I believe this is in line with Andreas’ comment on implicit attestation.
The enclave attributes (Mr.Enclave & Mr.Signer, along with other attributes of the system, like microcode version, patches, etc.) are Explicitly attested by the signature.
The other things added by the enclave code are implicitly attested.

I think it is important for EAT to have these two different structures in the token (in some form), because I believe you cannot have an Implicit Attestation without some (perhaps small) Explicit Attestation.
And thus, we should be talking about (within EAT) the concept of Claimant and Attestor.

Thoughts?

-- Dave Wheeler

From: EAT [mailto:[email-masked]] On Behalf Of Laurence Lundblade
Sent: Monday, September 24, 2018 3:06 PM
To: Fuchs, Andreas <[email-masked]>
Cc: [email-masked]; Denis <[email-masked]>; Birkholz, Henk <[email-masked]>; [email-masked]
Subject: Re: [EAT] [Rats] Implicit vs Explicit Attestation (was Re: Scope, Goals & Background for RATS)

LL

On Sep 24, 2018, at 1:37 AM, Fuchs, Andreas <[email-masked]<mailto:[email-masked]>> wrote:

Hi Laurence,

Best regards,
Andreas

________________________________
From: RATS [[email-masked]<mailto:[email-masked]>] on behalf of Laurence Lundblade [[email-masked]<mailto:[email-masked]>]
Sent: Monday, September 24, 2018 02:05
To: Birkholz, Henk
Cc: [email-masked]<mailto:[email-masked]>; Denis; [email-masked]<mailto:[email-masked]>
Subject: Re: [Rats] [EAT] Implicit vs Explicit Attestation (was Re: Scope, Goals & Background for RATS)
From the TCG paper<https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation-v1-rev93.pdf>  it looks to me that implicit refers to use of a deterministic process for creating an attestation key and device ID from a seed (the UDS) rather than explicitly putting an attestation private key and X.509 certificate (e.g., IEEE Device ID) in each device. That is a fine thing to do. No objection to that.

LL

Hello Laurence,

Viele Grüße,

Henk

LL

Hi Henk,

Hi Denis,

This is fine.

Viele Grüße,

Henk
...

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 24 Sep 2018 15:46:57 -0700

Hi Henk,

Just commenting on your comments below. Will write later for suggested text about EAT for the BoF.

The intent is that EATs ARE always signed just like CWTs are always signed. The EAT draft just says "No particular signing algorithm or signing scheme is required” which means that the signing could be ECDAA, ECDSA, SHA-256 HMAC or anything you can fit into COSE.  There’s two reasons for this:

1) Claims must be defined independent of the signing scheme, so they work with lots of different signing schemes and become universal
2) To have flexibility in signing schemes in the short run, to let the market decide, to later standardize them when they are better understood

Maybe unsigned EATs are useful, but I’m not sure how or where. 

With EAT I typically see the HW manufacturer and such offering a web service to very EATs from their devices. The relying party gets a token from the devices and goes to the HW manufacturer for verification. Intel, Qualcomm, Google and maybe others have this now in some form or other.  This makes it less important to standardize the signing scheme.

However the claims are to be processed by thousands of relying parties making trust decisions on a payment by payment basis, so they need to be standardized. 

When the relying party interacts with the verification service, they will be told how much meaning the token carries. It will probably be at a relatively coarse level (e.g., HLOS, TEE, TPM or SE) like FIDO does. The typical relying party probably won’t want much more than that.

I’d say all claims are for evaluating trustworthiness and that trustworthiness is subjective. Different relying parties and different risk engines are going to process things differently. Some if it will be on an actuarial basis. 41st Parameter <http://www.experian.com/decision-analytics/41st-parameter.html> (now owned by Experian) is an example of a company that does risk engine. They probably base it on more than 41 parameters now (a claim and a parameter are similar).

Agree that some claims need to be evaluated against Reference Values.  However geographic location might be a better indicator of fraud for a particular type of transaction than failure to match a particular Reference Value. Personally, I don’t feel a need to taxonmize the difference.

LL

> On Sep 24, 2018, at 4:06 AM, Henk Birkholz <[email-masked]> wrote:
> 
>> From the TCG paper <https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation-v1-rev93.pdf <https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation-v1-rev93.pdf>>  it looks to me that implicit refers to use of a deterministic process for creating an attestation key and device ID from a seed (the UDS) rather than explicitly putting an attestation private key and X.509 certificate (e.g., IEEE Device ID) in each device. That is a fine thing to do. No objection to that.
> Implicit vs. explicit attestation is the most prominent facet of attestation procedures we intended to differentiate at the beginning. There are more facets and details to the concept, of course. Maybe it is of use, if we try to abstract the intent and meaning a bit more in this context:
> 
> 1.) _Key Availability_: The availability of keys can have different meanings.
> 
> If a private key can only be used, if a system has a specific status (please see the comments of Andreas in this thread), there is "more meaning" to the signature. A Verifier has to have an understanding of this meaning - and network protocols can provide this context via the remote attestation or from a TTP - there are different procedures how to provide that context information.
> 
> There are more facets to this concept. For example, a Claimant create signatures using an available private key for the system it resides on or on behalf of another system, if I understand the ongoing discourse correctly.
> 
> 2.) _Claim Intent_: Claims (signed or not, the EAT draft does not mandate signing, which is useful, I think) also can have different intents.
> 
> 2a.) _trusted claims_, in general, that are signed or accompanied by signature claims, that are not necessarily intended to be verified (not used as Attestation Claims), and that are of interest to post-processes (e.g. age or location claims).
> 
> 2b.) _claims enabling the assessment of trustworthiness_ that are intended to create trust in the trustworthiness of a system (used as Attestation Claims) by appraisal of the Attestation Evidence they compose (e.g. comparison of a quote generate by an eSE/HSM or a list of executed software components with Reference Values).
> 
> Laurence, do you find the complete scope of EAT fitting into this very high level description? Or is something vital missing, maybe even wrong, conceptually?
> 
> 
> Viele Grüße,
> 
> Henk

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 24 Sep 2018 23:20:03 +0000

It is important to understand the semantics of different types of attestation because when we get to defining tokens, the token semantics should correspond to the security state(s) of the computing context (aka Mr. Enclave) and whether or not the claimant (aka Mr. Signer) is authoritatively able to know the claimed security states are actually true.

That said, it appears there isn’t a well-established definition of ‘implicit attestation’ and we’re in a position of having to describe parts of an elephant.

One more part of the elephant of implicit attestation can exist when a VMM or OS is loaded according to a trusted boot scenario using TPM PCRs to explicitly capture VMM/OS measurements. The VMM/OS then creates keys, loads software and otherwise creates an environment that isn’t measured into PCRs. This environment isn’t directly attested by the TPM quoting key. But nevertheless [By extension, it could only be created by the VMM/OS, however; and so if the environment code can be trusted (via evidence of the attestation), “appropriate security policy decisions can be made regarding the attached data.”]

A further extrapolation of the elephant part: if keys created in the implicitly attested environment are created following a DICE-inspired convention where a hash of the VMM/OS code is used to seed the key gen function, then it can be asserted that the implicitly attested application using that key would not have access to said key unless the hash value again matched. Use of that key also implicitly attests the data it has signed.

If the subtlety of attestation semantics are important and need explicit representation in a CWT or JWT token. Then some sort of token that distinguishes the type of attestation is needed in addition to a token that asserts, for example, a location attribute.  It may be good enough to define attestation claims structure as a collection of tokens. Then if appropriate, the a token identifying the type of attestation can accompany any other tokens needed.

Jumping into solution space for clarity: Inside tokens may be signed (by claimants) and the collection is signed by the attester.

-Ned

On 9/24/18, 3:22 PM, "RATS on behalf of Wheeler, David M" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Thoughts?

-- Dave Wheeler

LL

Hi Laurence,

Best regards,
Andreas

LL

Hello Laurence,

Viele Grüße,

Henk

LL

Hi Henk,

Hi Denis,

This is fine.

Viele Grüße,

Henk
...

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 25 Sep 2018 11:10:34 -0700

One more attempt: CREAT — Common Remote Entity Attestation Technology

LL

> On Sep 20, 2018, at 3:27 PM, Diego R. Lopez <[email-masked]> wrote:
> 
> Hi,
>  
> https://www.linkedin.com/in/dr2lopez/ <https://www.linkedin.com/in/dr2lopez/> 
>  
> e-mail: [email-masked] <mailto:[email-masked]>
> Tel:         +34 913 129 041
> Mobile:  +34 682 051 091
> On 20/09/2018, 16:18, "EAT on behalf of Laurence Lundblade" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
>  
>> On Sep 18, 2018, at 1:26 AM, Henk Birkholz <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Hi all,
>> 
>>> https://github.com/ietf-rats/charter/blob/master/ietf-rats-charter.md <https://github.com/ietf-rats/charter/blob/master/ietf-rats-charter..md>

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 25 Sep 2018 11:32:04 -0700

Here’s my changes for the charter to bring EAT in. The big things are rewrite of (4) and addition of (5). 

Also combined (Program Work) and (Goals)

Some edits to first program of (Program Work).

The diffs are in the attached PDF.

LL

(Problem statement)

The problem statement addressed by the working group can be segregated into five inter-connected problems:

(1) Establishing a sufficient level of confidence that a communication partner is a trustworthy endpoint. This is a fundamental challenge. Currently, there are no agreed upon standards that define a minimal set of Reference Values and Attestation Evidence that distinguishes a trustworthy execution environment over one that isn't. There isn't agreement on how to convey it appropriately, how to appraise evidence and how to present the appraisal results in an interoperable fashion. In essence, there is increasing vendor demand for an overall communication, trust and assurance model to establish trust in potentially lying endpoints that is not currently met by other standards.

(2) Current and emerging protocols oftentimes do not contain interfaces for trust establishment in the communication endpoints. Some protocols may contain extensibility features that could serve this purpose, but have not yet been defined.

(3) There is no central alignment process or place for resolving issues related to the application of remote attestation techniques to existing and emerging IETF protocols, e.g. Initial Implicit Attestation via TLS Token Binding, complementary Attestation in OSCORE, YANG modules for conveying Explicit Attestation Evidence about composite devices (e.g. I-D.birkholz-yang-basic-remote-attestation), the Attestation procedures for virtualized network security functions in I2NSF (I-D.pastor-i2nsf-nsf-remote-attestation), or Time-Based Uni-Directional Attestation procedures (e.g. I-D.birkholz-i2nsf-tuda).

(4) Today, there is no common, standard way for Relying Parties to know the provenance and characteristics of the end-user devices that are requesting services of them. For example, there is no common, standard, secure way for a Relying Party to tell if an end-user device is a Linux box pretending to be a phone that is presenting and confirming a financial transaction or not. There are several domain-specific ways to do this such as the various attestation formats used by FIDO and the Android Keystore Attestation format.  Today, risk engines collect large amounts of information from end-user device that are used to determine whether an access to data, a financial transaction or such will be allowed. That data, defined as Claims here, is not standardized for interoperability, is poorly secured in transit and there are few means to prove the provenance of it. Thus, the problems to be solved are:

Definition of a set of interoperable, cross-platform Claims that can be made by Entities (end-user devices, IoT devices, device subsystems and submodules)
Syntax for each Claim in CBOR, JSON and YANG
A framework for securing (e.g., signing) Claims Conveyed to the Relying Party
The Claims and means to secure them should be general and interoperable and as platform and technology neutral as possible (e.g., minimally tied to TPM, TrustZone, JavaCard…).
The definition of the Claims should be largely independent of how they are secured. That is, it should be possible to secure each Claim in different ways without affecting the semantics of the Claim.
The definition of the Claims should be independent of the means of Conveyance (e.g., independent of the transport protocol)
Privacy and GDPR compliance should be considered for each Claim. While not possible for many, Claims should be defined to be privacy preserving.
(5) It is often the case that the manufacturer of an Entity (e.g., a chip, a phone, a tablet) puts some base private key in each device they make. That base key material can then be used to establish key material for specific use cases. Some Entities will host a plethora of use cases and it will be very enabling and efficient to be able to reuse this base private key material over and over (e.g., the Android KeyStore). It is also very beneficial to receive detailed Claims about the Entity’s trustworthiness when establishing use case specific keys. The base private key mentioned here is the key material used to perform the attestation. They problem to be solved then is the definition of Claims that carry use case specific public keys, possibly including proof of possession of those keys (e.g., a Certificate Signing Request).

 (Program of work)

This working group will consolidate the various methods for creating and conveying Attestation Evidence using network protocols created in the IETF to enable semantic interoperability. This solutions created by this working group will consider extant and related technologies from these: the IETF I2NSF WG, Global Platform, the Trusted Computing Group, the Cloud Native Computing Foundation, the Open Connectivity Foundation, the Alliance for Telecommunications Industry Solutions, and the ETSI NFV Industry Specification Group. There should be reuse of, and interoperability with, these when possible.

The following is within this working group's scope:

Architectural components, such as roles, relationships, work-flows and actions
Data formats and protocols for Remote, Explicit, and Implicit Attestation
Protocols and new bindings of protocols (e.g. CoAP) to supply Attestation Policies to a Verifier or Relying Party
Terminology and the interconnected relationships of existing solutions (also as a basis for identifying gaps and new applications)
Attestation procedures for authentication that are based on the operational state of the Attester
The following is outside this working group's scope:

Local Attestation and corresponding "in-box" APIs.
Attestation Policy Formats
Authentication procedure extension that do not convey Attestation Evidence.
As Attestation has acquired many definitions, an early goal for this working group will be a document defining the terms used by attestation, coordinating terminology with the groups and organizations listed above. This provides the various standards a consistent set of terms for their subjects, objects and their relationships.

Architectural Documents (informational):

(1.1) Terminology & Architecture
(1.2) Reference Interaction Models
Solution Documents (standards-track):

(1.3) Definition of a Common set of Claims for Semantic Interoperability 
(2.1) YANG Module for Explicit Attestation
(2.2) Explicit Attestation Extension to the I2NSF Architecture using EAT
(2.3) Time-Based Uni-Directional Attestation

---

From: Suresh Marisetty <[email-masked]>
Date: Tue, 25 Sep 2018 19:31:12 +0000

Hi Laurence,

So, it appears that the charter and scope of the CREAT/EAT does not include (Attestation Key Options and Zero Touch Device Onboarding with ownership transfers across entities in the supply chain).

It would be good to mention this as in/out of scope in the charter and refer to other relevant standards/specs for it as appropriate.

For example, IETF has the following for onboarding:

  1.  BRSKI ( Bootstrapping Remote Secure Key Infrastructures)
  2.  SZTP (secure zero touch provisioning - Juniper)

Thanks
Suresh Marisetty

From: EAT <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Tuesday, September 25, 2018 11:32 AM
To: Henk Birkholz <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: [EAT] EAT additions to Charter (was Re: Scope, Goals & Background for RATS)

LL

(Problem statement)

  *   Definition of a set of interoperable, cross-platform Claims that can be made by Entities (end-user devices, IoT devices, device subsystems and submodules)
  *   Syntax for each Claim in CBOR, JSON and YANG
  *   A framework for securing (e.g., signing) Claims Conveyed to the Relying Party
  *   The Claims and means to secure them should be general and interoperable and as platform and technology neutral as possible (e.g., minimally tied to TPM, TrustZone, JavaCard…).
  *   The definition of the Claims should be largely independent of how they are secured. That is, it should be possible to secure each Claim in different ways without affecting the semantics of the Claim.
  *   The definition of the Claims should be independent of the means of Conveyance (e.g., independent of the transport protocol)
  *   Privacy and GDPR compliance should be considered for each Claim. While not possible for many, Claims should be defined to be privacy preserving.

 (Program of work)

  *   Architectural components, such as roles, relationships, work-flows and actions
  *   Data formats and protocols for Remote, Explicit, and Implicit Attestation
  *   Protocols and new bindings of protocols (e.g. CoAP) to supply Attestation Policies to a Verifier or Relying Party
  *   Terminology and the interconnected relationships of existing solutions (also as a basis for identifying gaps and new applications)
  *   Attestation procedures for authentication that are based on the operational state of the Attester

  *   Local Attestation and corresponding "in-box" APIs.
  *   Attestation Policy Formats
  *   Authentication procedure extension that do not convey Attestation Evidence.

  *   (1.1) Terminology & Architecture
  *   (1.2) Reference Interaction Models

  *   (1.3) Definition of a Common set of Claims for Semantic Interoperability
  *   (2.1) YANG Module for Explicit Attestation
  *   (2.2) Explicit Attestation Extension to the I2NSF Architecture using EAT
  *   (2.3) Time-Based Uni-Directional Attestation

Hi all,

Viele Grüße,

Henk

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 25 Sep 2018 21:35:20 +0000

What if we add an E at the end (that could fit as “Enhancements”)?

Dr Diego R. Lopez
Telefonica I+D

On 25/09/2018, 20:10, "Laurence Lundblade" <[email-masked]<mailto:[email-masked]>> wrote:

LL

On Sep 20, 2018, at 3:27 PM, Diego R. Lopez <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Be goode,

Dr Diego R. Lopez
Telefonica I+D

LL

Hi all,

Viele Grüße,

Henk

---

From: Carl Wallace <[email-masked]>
Date: Wed, 26 Sep 2018 09:08:07 -0400

From:  EAT <[email-masked]> on behalf of Laurence Lundblade
<[email-masked]>
Date:  Tuesday, September 25, 2018 at 2:32 PM
To:  Henk Birkholz <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  [EAT] EAT additions to Charter (was Re:  Scope, Goals & Background
for RATS)

> <snip>
> Thus, the problems to be solved are:
> * Definition of a set of interoperable, cross-platform Claims that can be made
> by Entities (end-user devices, IoT devices, device subsystems and submodules)
> * The Claims and means to secure them should be general and interoperable and
> as platform and technology neutral as possible (e.g., minimally tied to TPM,
> TrustZone, JavaCard…).
> * The definition of the Claims should be largely independent of how they are
> secured. That is, it should be possible to secure each Claim in different ways
> without affecting the semantics of the Claim.
> * The definition of the Claims should be independent of the means of
> Conveyance (e.g., independent of the transport protocol)
> * Privacy and GDPR compliance should be considered for each Claim. While not
> possible for many, Claims should be defined to be privacy preserving.
I'd include defining of verification rules to the list of problems to solve.
The term verifier appears once in the charter text, but nothing is included
to inform how verification is performed. Maybe: A framework for securing
(e.g., signing) Claims Conveyed to the Relying Party and corresponding rules
for verifying attestations to establish trust in claims
> (5) It is often the case that the manufacturer of an Entity (e.g., a chip, a
> phone, a tablet) puts some base private key in each device they make. That
> base key material can then be used to establish key material for specific use
> cases. Some Entities will host a plethora of use cases and it will be very
> enabling and efficient to be able to reuse this base private key material over
> and over (e.g., the Android KeyStore). It is also very beneficial to receive
> detailed Claims about the Entity’s trustworthiness when establishing use case
> specific keys. The base private key mentioned here is the key material used to
> perform the attestation. They problem to be solved then is the definition of
> Claims that carry use case specific public keys, possibly including proof of
> possession of those keys (e.g., a Certificate Signing Request).
I'd include specification of attributes for use in certificate request
protocols as a standards track deliverable.
> <snip>

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 26 Sep 2018 13:07:07 -0700

Either way is good for me. Like either a lot. Figured CREAT was OK because the UNIX system call (“man 2 creat; friend of open) left off the “e” too.

LL

> On Sep 25, 2018, at 2:35 PM, Diego R. Lopez <[email-masked]> wrote:
> 
> On 25/09/2018, 20:10, "Laurence Lundblade" <[email-masked] <mailto:[email-masked]>> wrote:
>  
>> On Sep 20, 2018, at 3:27 PM, Diego R. Lopez <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Hi,
>>