Subject: [EAT] Attestation BoF charter updates?

From: Laurence Lundblade <[email-masked]>
Date: Sat, 6 Oct 2018 13:23:36 +0700

Hi Henk,

Bangkok IETF is getting close, will you be able to update the charter for the attestation BoF to properly include EAT?  I sent you some text that just needs to be pasted along with some comments. It doesn’t look like there’s been any updates. 

LL

---

From: Henk Birkholz <[email-masked]>
Date: Sat, 6 Oct 2018 08:50:57 +0200

Hello Laurance,

the BoF proponents are refactoring the charter based on various inputs, including yours for example. This also includes some quite extensive trimming of charter size. Hence, a tad bit more is done than simply the merging of proposals right now.

We plan to float a new version to the list early next week, including an initial agenda layout.

Viele Grüße,

Henk

On October 6, 2018 8:23:36 AM GMT+02:00, Laurence Lundblade <[email-masked]> wrote:
>Hi Henk,
>
>Bangkok IETF is getting close, will you be able to update the charter
>for the attestation BoF to properly include EAT?  I sent you some text
>that just needs to be pasted along with some comments. It doesn’t look
>like there’s been any updates. 
>
>LL

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 11 Oct 2018 18:49:46 +0200

Hi all,

sorry for the delay. Please find an updated charter proposal here:

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

The BoF proponents tried to merge all comments and proposals on 
keystores, existing solutions, provenance & device characteristics, etc 
that were raised on the list - and align them in homogeneous fashion.

This draft is intended to focus the discussion and improve the wording.

Viele Grüße,

Henk

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Oct 2018 16:07:52 -0400

re: "Information Elements (IE)"

If you have some wiggle room (i.e. you aren't trying to align with some other
pre-existing standards work elsehwere), it might be worth using another term,
as I think that this term is used for layer-2 extensions in 802.15.4
networks. I think that some people will be confused by this.  I think your
usage is very much a layer 6+ (abstract) concept.

I found the introduction to be meaningful only to those who already know what
it is about.  I suggest the following edits.  I make some of them just that
the charter will continue to meaningful in a year or two.

    Introduction
    Remote ATtestation ProcedureS (RATS) are included in network protocols to
    provide the basis for establishing trustworthy exchanges with a device.
    RATS expose trusted claim sets to detailed Attestation Evidence that
    enables a Verifying Party to retrace every step that led to its current
    Operational State. A consequence of this retracing is that it is possible
    to appraise the trustworthiness of a device. Application of RATS
    encompasses infrastructure supporting financial transactions, critical
    infrastructure, constrained-node environments, or the management of
    end-user devices.

    Measured file execution procedures (including the now deprecated term
    Secure Boot) provide the basis for conveying additional device
    characteristics that enable a Verifying Party to assess that a device is
    a Trusted System: one that operates as expected, does what is required,
    and does not do other things. Various Roots of Trust (e.g. for
    Measurement, for Reporting, or for Verification) provide the foundation
    to enable Implicit Attestation (the fact that a secret key is accessible
    implies specific meaning) and Explicit Attestation, which uses the output
    of Measured file execution as Attestation Evidence which along with event
    Log details can be used to can ratify that the device is actually a
    Trusted System.

    Problem Statement
    (1) We need a standard way to establish a sufficient level of confidence that a communication
    partner is with a trustworthy endpoint. This is a fundamental
    challenge.

    a) In 2018, there were 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.

    b) 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 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) In 2018, there are no common, standard ways for Relying Parties to know
    the provenance and characteristics of a device (e.g., an end-user device,
    platform or endpoint, servers, IoT devices, device subsystems and
    sub-modules) that may be requesting services.

    As a result, in 2018, a Relying Party would be unable to tell if a device is
    trying to mimic the identity of another device or
    some of its characteristics.   For instance, distinguishing between a
    secure wallet and INSERT SOMETHING would be relevant for a financial
    transaction.

    In 2018 there are existing domain-specific ways to do this, such as TCG TPM
    Attestation, FIDO Alliance attestation and Android Keystore Attestation.

    (3) Risk engines collect large amounts of information from a device in
    order to determine whether it is allowed access to data, a financial
    transaction or to perform other risk-sensitive operations. Agreement over
    the syntax and semantics of provenance and characteristics is essential
    for interoperability. Attestation provenance and characteristics
    represented via IE require proper definitions as Assertions. Standardized
    assertions promote increased - possibly ubiquitous -
    interoperability. Assertions also must be believable, for example, via
    Evidence that proves Assertion veracity.

...

Goals
    > Syntax for each Assertion in CBOR, JSON, YANG, and potentially others
    > [reintroduce terminology here? TARGET 2 @everyone, please chime in
    > here}

The only two have missed are XML and ASN.1, and I don't see that as a bug.
Writing in YANG, it's all mappable there if someone wants to do this.
I think you will also be using YANG for data at rest (yang-data), rather than
accessed by API.  This seems an increasingly common usage.

>Deliverables
> Attestation information flows, consolidated terminology and corresponding
> taxonomies (overview/architecture to be developed in parallel with solution
> documents; can be separate document or go into 2, 3, 4 below)

In a break from the waterfall method of requirements, use-cases and then
protocols (or rather, in this case, artifact formats), I suggest that that
each be worked on in parallel, and that the terminology and architecture
documents be constrained to be published *LAST*. But, the WG should issue WG
Consensus Calls on the documents at intervals such that the text is in them
can be considered authoritative enough to answer questions in the protocol.

Note that I cut out a bunch of text from the Introduction. It didn't help me
understand the purpose of the group.  Also I note that IE is never used again
after the first paragraph, so I think you could just call them artifacts.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 11 Oct 2018 22:43:12 +0200

On Oct 11, 2018, at 22:07, Michael Richardson <[email-masked]> wrote:
> networks.

I prefer “data item” (about half the number of syllables), but maybe this is too much of a CBOR term.

> each be worked on in parallel,

Absolutely!  (This may now be so obvious to the charter authors that they neglected to state it.)

> and that the terminology and architecture
> documents be constrained to be published *LAST*.

Well, at the same time, because the other documents will want to use the terms.

> But, the WG should issue WG

The charter doesn’t go into a lot of details of how the WG should work — that is normally not part of the IESG-WG contract (which we call charter).  But doing this in a sequence of milestones may be a good suggestion.

> after the first paragraph, so I think you could just call them artifacts.

Works for me, too.

Grüße, Carsten

---

From: Carl Wallace <[email-masked]>
Date: Thu, 11 Oct 2018 13:56:30 -0700

As with the earlier draft, there are many references to verify and
verifier in the lead up to the deliverable but no deliverables describing
verification rules. I'd like to see rules in one of these documents and
think it worth citing in the deliverables. Are bindings to certificate
management protocols out of scope?

On 10/11/18, 9:49 AM, "RATS on behalf of Henk Birkholz"
<[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>RATS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rats

---

From: Denis <[email-masked]>
Date: Fri, 12 Oct 2018 15:33:22 +0200

A quick feedback about charter/ietf-rats-charter.md

  The introduction mentions:
  "In summary, RATS expose trusted claim sets to detailed Attestation
  Evidence enables a Verifying Party
               to retrace every step that led to its current Operational
  State.

  Such set of claims may be useful in some contexts, but not always. In
  many cases, it is sufficient to know that the device supports
  a set of operations/functionalities and that it operates as expected,
  does what is required and does not do other things (e.g. no back door
  is present).
  A typical example is a secure element, like a smart card.

  The "Problem Statement" is currently described as follows:

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

The question is not only whether the device has a trustworthy execution 
environment or not, but whether the device is capable to support a specific
set of functions (obviously using a trustworthy execution environment).

The "Problem Statement" (1)**should be rephrased as:

"Establishing a sufficient level of confidence that some data originates 
from a trustworthy device (e.g., an end-user device, platform or endpoint,
servers, IoT devices, device subsystems and sub-modules) designed to 
support a specific set of operations/functionalities and that it operates
as expected, does what is required and does not do other things that 
could impact the security of that set of operations/functionalities 
(e.g. no back
door is present).

The "Problem Statement" continues as follows:

(2) Today, there is no common, standard way for Relying Parties to know 
the provenance and characteristics of a device (e.g., an end-user device,
platform or endpoint, servers, IoT devices, device subsystems and 
sub-modules) that may be requesting services.

Knowing the provenance of the device is not always necessary. What is 
important is to know that a specific set of functions is (securely) 
supported by the device.
There already exists a common way to know the characteristics of a 
device by issuing to the device a public key certificate which will only 
be issued to the device
if it fulfills an expected set of functionalities. In such a case a 
syntax for a trusted claim sets**is not needed.

The simplest cases should also be part of the framework.

Note: I personally appreciate that privacy is an aspect that will/should 
be taken into consideration.

Denis

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

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Mon, 15 Oct 2018 10:22:04 +0000

On 12 Oct 2018, at 14:33, Denis <[email-masked]<mailto:[email-masked]>> wrote:
The "Problem Statement" continues as follows:

(2) Today, there is no common, standard way for Relying Parties to know the provenance and characteristics of a device (e.g., an end-user device,
platform or endpoint, servers, IoT devices, device subsystems and sub-modules) that may be requesting services.

Knowing the provenance of the device is not always necessary. What is important is to know that a specific set of functions is (securely) supported by the device.
There already exists a common way to know the characteristics of a device by issuing to the device a public key certificate which will only be issued to the device
if it fulfills an expected set of functionalities. In such a case a syntax for a trusted claim sets is not needed.

This is indeed a possible way to address the problem, but suffers from challenges which come down to:

- Who issues such certificates. An option is that there is some form of security certification behind this issuance otherwise it is of very limited value.
- In order to capture the wide variety of different devices (I prefer "entity" here as it is more general than "device"), many different forms of such certificates would be required. This ends up being much the same thing as a set of claims.

Given the multiplicity of entities for which attestation might be useful, it seems to me that having the entity creator/manufacturer provide a set of claims which can be verified is more flexible than requiring a certificate. It seems likely to me that where a formal security certification is needed there will be a certificate issued by the Certifying Body as one of the claims about an entity, but I can think of many cases (supply chain management, to take just one example) where provenance is by far the most useful information.

I'm not in favour of changes to the charter in this direction.

Note: I personally appreciate that privacy is an aspect that will/should be taken into consideration.
Denis

On 10/11/18, 9:49 AM, "RATS on behalf of Henk Birkholz"
<[email-masked] on behalf of [email-masked]><mailto:[email-masked]@sit.fraunhofer.de> wrote:

Hi all,

Viele Grüße,

Henk

Hi Henk,

LL

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

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

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

---

From: Denis <[email-masked]>
Date: Mon, 15 Oct 2018 15:04:35 +0200

Hello Jeremy,

In your reply, you have deleted many of my sentences, in particular you 
have deleted:

I don't deny that complex cases may need to be taken into consideration, 
but simple cases should also be taken into consideration.

You wrote:

    having the entity creator/manufacturer provide a set of claims which
    can be verified is more flexible than requiring a certificate.

May be it might be "more flexible", but certainly more complex to check. 
The provenance of the device is not the most important information to get.
The most important information to get is a guarantee of the support of a 
set of required functions and features.

Denis

>> (2) Today, there is no common, standard way for Relying Parties to 
>> know the provenance and characteristics of a device (e.g., an 
>> end-user device,
>> device by issuing to the device a public key certificate which will 
>> only be issued to the device
> - Who issues such certificates. An option is that there is some form 
> of security certification behind this issuance otherwise it is of very 
> limited value.
> - In order to capture the wide variety of different devices (I prefer 
> "entity" here as it is more general than "device"), many different 
> forms of such certificates would be required. This ends up being much 
> the same thing as a set of claims.
>
> Given the multiplicity of entities for which attestation might be 
> useful, it seems to me that having the entity creator/manufacturer 
> provide a set of claims which can be verified is more flexible than 
> requiring a certificate. It seems likely to me that where a formal 
> security certification is needed there will be a certificate issued by 
> the Certifying Body as one of the claims about an entity, but I can 
> think of many cases (supply chain management, to take just one 
> example) where provenance is by far the most useful information.
>
>> [email-masked] <mailto:[email-masked]>

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 15 Oct 2018 16:53:37 +0200

Hi Jeremy & Denis,

all these points of view have merit, I think.

Please have a look at these quotes:

> knowing the provenance of the device

> having the entity creator/manufacturer provide a set of claims which can be verified

> to know the characteristics of a device by issuing to the device a public key certificate which will only be issued to the device if it fulfills an expected set of functionalities.

To me, these descriptions seem to have different intents, scope or 
audience and require most certainly different work-flows, but 
semantically and in consequence representation-wise they also seem quite 
related.

If you think of an identity document as a set of claims (potentially 
including a public key), that is signed and that can match one or more 
things, maybe all three types highlighted above are actually covered by 
the same identity document concept?

With respect to identity documents, I think it is safe so say that we 
can find common ground here rather easily. That said, the way how these 
identity documents come into existence, when and how they are deployed 
on the thing or associated with multiple things is another question. We 
most certainly do not want to end up with a "signing fool" that does not 
add value to the level of confidence (I am quoting Ned Smith here).

This has to be fleshed out explicitly for each scenario and the parts 
that are reused in every scenario should get special attention in the 
upcoming RATS architecture draft.

Identifying claims aggregated in an identity document most certainly can 
include device characteristics, public key(s), or claims about the 
intended functions and capabilities of the thing. Claims can even 
originate from Claimants that are not the thing itself, but external 
entities providing an assertion (e.g. these things are CC-certified).

All different composites of identifying claims have a specific shared 
intend in this context though, I think: expressing Attestation 
Provenance (again - one for one or more things of the same kind). And 
all of them originate from Claimants and therefore use a root of trust 
of measurement, I think.

That said, establishing trustworthy knowledge about attestation 
provenance is only the first step and provides the foundation for more 
complex attestation procedures. In any case, this seem to be required by 
every scenario that was highlighted so far and therefore will most 
certainly be covered in a deliverable.

IHTH,

Henk

On 10/15/2018 12:22 PM, Jeremy O'Donoghue wrote:
>> know the provenance and characteristics of a device (e.g., an end-user 
>> device,
> - Who issues such certificates. An option is that there is some form of 
> security certification behind this issuance otherwise it is of very 
> limited value.
> "entity" here as it is more general than "device"), many different forms 
> of such certificates would be required. This ends up being much the same 
> thing as a set of claims.
> 
> think of many cases (supply chain management, to take just one example) 
> where provenance is by far the most useful information.
>

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 15 Oct 2018 15:59:35 +0000

I agree with Henk's observation that there is opportunity to find common ground on identity as identity can be a collection of attributes, that if signed, becomes a set of verifiable claims (about identity attributes). Attestation has a similar structure in that it consists of a set of attributes, that if signed becomes a set of verifiable claims. The main difference between identity and attestation attributes is whether the attribute semantically relate to trust (vs. identity). For example, claims of security certification compliance resonates as attestation. 

It may be possible to combine a set of attestation attributes in such a way that the combination uniquely identifies an entity. But that doesn't make it an identity system per se and shouldn't cause a conflict in charter goals with respect to other identity focused efforts in IETF. 

Also, inclusion of attributes that don't have semantics that reasonably relate to trust should not be of interest to a working group focused on attestation.

-Ned

On 10/15/18, 3:53 PM, "EAT on behalf of Henk Birkholz" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Jeremy & Denis,

    

    

    

    
    
    IHTH,
    
    Henk

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 15 Oct 2018 17:49:35 +0000

Here are my 5 cents on the term 'identity'.

I have been working on identity management for many years (partially because of my OAuth co-chair role) and I have noticed that the use of the term "identity" tends to confuse more than it helps (even more so when the term is applied to devices and software rather than humans).

I believe we could get away with describing what we want without ever using the term.

In this context I would argue that we are about identifying different components, such as hardware and software.

Ciao
Hannes

-----Original Message-----
From: EAT <[email-masked]> On Behalf Of Smith, Ned
Sent: Monday, October 15, 2018 9:00 AM
To: Henk Birkholz <[email-masked]>; [email-masked]; Jeremy O'Donoghue <[email-masked]>; Denis <[email-masked]>
Cc: [email-masked]
Subject: Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF charter updates?

-Ned

    Hi Jeremy & Denis,

    IHTH,

    Henk

_______________________________________________
EAT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/eat
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: Denis <[email-masked]>
Date: Mon, 15 Oct 2018 21:30:14 +0200

> In this context I would argue that we are about identifying different components, such as hardware and software.

+1

The single sentence where currently the word "identity" is being used is:

    As a result, in 2018, a Relying Party would be unable to tell if a
    device is trying to mimic the identity of another device or some of
    its characteristics.

This could be rephrased as:

    As a result, in 2018, there is no common way allowing Relying
    Parties to tell if some data originates from a trustworthy device
    designed to support a specific set of operations/functionalities or
    not .

The text currently states:

    2) In 2018, there are no common, standard ways for Relying Parties
    to know the provenance and characteristics of a device
    (e.g., an end-user device, platform or endpoint, servers, IoT
    devices, device subsystems and sub-modules) that may be requesting
    services.

As already said on this list, knowing the provenance of a device is not 
always necessary (but may be useful in some cases).
The key point is to know the characteristics of the device.

This could be rephrased as:

    2) In 2018, there are no common, standard ways for Relying Parties
    to know the characteristics of a device (e.g., an end-user device,
    platform or endpoint,
    servers, IoT devices, device subsystems and sub-modules) that may be
    requesting services.

Probably a typo in the following sentence:

    (1) A standardized way to establish a sufficient level of confidence
    that some data originates from a trustworthy device (e.g.,
    platforms, servers,
    user endpoints, IoT devices, device subsystems or subcomponents)
    designed to support a specific set of operations/functionalities /a
    communication partner is a trustworthy endpoint./

The end of the sentence (i.e. "a communication partner is a trustworthy 
endpoint.") looks odd and should probably be deleted.

The goals are currently limited to the definition of the content of the 
Assertions. A key point is the way to verify/validate an Attestation.
The more complex is the content of an Attestation, the more complex it 
will be to validate it by a RP.

A framework for validating the Attestations should also be part of the 
charter.

Denis

Note:At this stage, I still see no text to address both simple cases 
(e.g. FIDO attestations) and more complex cases.

---

From: Giridhar Mandyam <[email-masked]>
Date: Mon, 15 Oct 2018 19:33:34 +0000

Sorry to switch topics.

Just posted my requested changes at https://github.com/ietf-rats/charter/pull/1.

2 areas to consider:

a) Many resource-constrained devices will not support Internet Connectivity.  This does not mean that remote attestation is not possible.  It just means that this effort will be more broadly applicable if an interoperable format for 'Attestation Evidence' results that can be conveyed over multiple protocols, not just the internet.  EAT was designed with this goal in mind.

b) Local attestation is more than just on-device.  We have seen gateways in the market that allow for remote administration of devices in a local network that may only communicate via short-range protocols such as Bluetooth or Zigbee.  Such gateways may very well also serve as verifiers on behalf of a remote relying party.

-Giri Mandyam

-----Original Message-----
From: EAT <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Monday, October 15, 2018 10:50 AM
To: Smith, Ned <[email-masked]>; Henk Birkholz <[email-masked]>; [email-masked]; Jeremy O'Donoghue <[email-masked]>; Denis <[email-masked]>
Cc: [email-masked]
Subject: Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF charter updates?

Ciao
Hannes

-----Original Message-----
From: EAT <[email-masked]> On Behalf Of Smith, Ned
Sent: Monday, October 15, 2018 9:00 AM
To: Henk Birkholz <[email-masked]>; [email-masked]; Jeremy O'Donoghue <[email-masked]>; Denis <[email-masked]>
Cc: [email-masked]
Subject: Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF charter updates?

-Ned

    Hi Jeremy & Denis,

    IHTH,

    Henk

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 16 Oct 2018 14:24:47 +0200

Hello Giridhar,

I totally agree that attestation procedures do not always use network 
protocols as conveyance methods. In a composite device, e.g. a network 
equipment chassis, there can be a component hierarchy in which each 
component can be associated with an attester role and/or verifier role; 
enabling (mutual) attestation between each component/sub-component 
relationship using various kinds of interconnects (and none of them have 
to be IP). Keeping that in mind when designing data models and 
corresponding serializations is important. For remote attestation via 
network protocols it might not be the most important thing, though.

There are most certainly "on behalf" roles, provided that there is a 
"trusted path" relationship (quoting orange book here) via which the 
attestation procedure could be behave like a local one.
I am not sure, if I see a "verifiers on behalf of a remote relying 
party" scenario, but in general, I'd agree with the concept.

In summary, if the attester and the verifier are connected via a 
"trusted path" then it is essentially local attestation.

Unfortunately, you issued the pull request on master, the current 

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

We are currently trimming the text, refactoring the content by using 
more generic terminology, and cut out about half of the content (wrt to 
the master branch) in order to segregate problem statements and goals 
into phases. The current version referenced above is intended to be 
become phase one.

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 16 Oct 2018 15:11:35 +0200

Hi Denis,

I just pulled in your first proposal as an example in paragraph five.

I am a bit concerned to drop the intent of establishing a believable 
context about attestation provenance. As you referred, for example, to 
FIDO - I think that is the intent there, is it not? Laurence proposed 
the terms "provenance and characteristics" as high level terms and all 
proponents agreed to use these. If this is a relevant disabler for a 
specific usage scenario, we might have to reconsider that.

We cut out differentiating simple cases and more complex cases to reduce 
the complexity of the charter text for now. If that is 
counterproductive, we would like to get more input on that, please.

Viele Grüße,

Henk

On 10/15/2018 09:30 PM, Denis wrote:
>> From: EAT<[email-masked]>  On Behalf Of Smith, Ned
>> To: Henk Birkholz<[email-masked]>;[email-masked]; Jeremy O'Donoghue<[email-masked]>; Denis<[email-masked]>
>> Cc:[email-masked]
>> On 10/15/18, 3:53 PM, "EAT on behalf of Henk Birkholz"<[email-masked] on behalf of [email-masked]>  wrote:
>>
>>      Hi Jeremy & Denis,
>>
>>      > On 12 Oct 2018, at 14:33, Denis<[email-masked] >  <mailto:[email-masked]>> wrote:

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 16 Oct 2018 13:51:57 +0000

Agree with Hannes that identity discussion can lead to confusion as identity is often highly dependent on some sort of context (domain of interpretation). 

In order to have productive conversation about attestation and identity, it may be important to understand that attestation semantics sets the context for identity. 

* Attestation attributes have trust semantics (and trust semantics are interpreted through the eyes of the verifier). Identity attributes may also have trust semantics (in addition to identity semantics) hence can be regarded as playing a role in both identity and attestation. Since RATS should be interested primarily in trust semantics, it makes sense to understand, discuss and consider identity in terms of its trust semantics. Hence identity attributes are only interesting to RATS if they are useful for evaluating trust semantics.

* In a closed ecosystem, the trust characteristics and properties may be implied because there often exists out-of-band processes that ensure the characteristics are applied (for example, if an IT organization sets a policy that all asymmetric keys are to be hardened using a smartcard, they can apply a deployment process where the IT professional verifies the smartcard is used during enrollment.) But in a non-closed ecosystem, there isn't an assumption that out-of-band processes exist. Attestation attempts to make explicit what otherwise is implicit and therefore subject to misinterpretation if the verifier, relying party and attester are not part of the same closed ecosystem. Implicit attestation therefore can lead to semantic confusion if we're not careful. Therefore, the rigor of treating implicit attestation claims (assertions assumed to exist but not explicitly named) should nevertheless be defined explicitly. Then, if there is a need for implicit attestation, the specifications that describe them can describe them in terms of an explicit definition. 

* In the context of asserting trust characteristics, the verifier needs to know that a set of characteristics applies to the instance of the endpoint being evaluated (aka the attester). (Otherwise a MITM could supply characteristics that may be valid, but don’t apply to the specific instance). Consequently, it makes sense to consider that *attestation* keys are needed to authenticate the endpoint being evaluated. This doesn't imply an identity key couldn't double as an attestation key. But if it does, we care about its relevance to the attester endpoint.

-Ned

On 10/15/18, 6:49 PM, "Hannes Tschofenig" <[email-masked]> wrote:

    

    Ciao
    Hannes
    
    -----Original Message-----
    From: EAT <[email-masked]> On Behalf Of Smith, Ned
    Sent: Monday, October 15, 2018 9:00 AM
    To: Henk Birkholz <[email-masked]>; [email-masked]; Jeremy O'Donoghue <[email-masked]>; Denis <[email-masked]>
    Cc: [email-masked]
    Subject: Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF charter updates?

    
    
    -Ned

        Hi Jeremy & Denis,

    

    

    

    
    
        IHTH,
    
        Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 16 Oct 2018 19:43:12 +0530

Hi Henk,

Appreciate the work you are putting into this.  It is getting closer.

EAT and CWT refer to things like a GPS location, SW version or device debug-enable state as “claims”.  I’m not sure what the equivalent in the current charter is. Grabbing every possible string it could be I came up with this list:

Introduction
"trusted claim sets”
"Attestation Evidence”
"information”
"additional device characteristics”
Problem Statement
"some data”
"the evidence”
“Some data”
Goals
"inter-operable, cross-platform Assertions”
“Assertion"
Deliverables
"Information elements for use in evidence-based attestation”
"CWT claim definitions"

Per previous charter:

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.

So what is the equivalent of a “claim” in this charter?

LL

> On Oct 16, 2018, at 6:41 PM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Denis,
> 
> I am a bit concerned to drop the intent of establishing a believable context about attestation provenance. As you referred, for example, to FIDO - I think that is the intent there, is it not? Laurence proposed the terms "provenance and characteristics" as high level terms and all proponents agreed to use these. If this is a relevant disabler for a specific usage scenario, we might have to reconsider that.
> 
> We cut out differentiating simple cases and more complex cases to reduce the complexity of the charter text for now. If that is counterproductive, we would like to get more input on that, please.
> 
> Viele Grüße,
> 
> Henk
> 
>> As already said on this list, knowing the provenance of a device is not always necessary (but may be useful in some cases).
>> The end of the sentence (i.e. "a communication partner is a trustworthy endpoint.") looks odd and should probably be deleted.
>> The goals are currently limited to the definition of the content of the Assertions. A key point is the way to verify/validate an Attestation.
>> The more complex is the content of an Attestation, the more complex it will be to validate it by a RP.
>> A framework for validating the Attestations should also be part of the charter.
>> Denis
>> Note:At this stage, I still see no text to address both simple cases (e.g. FIDO attestations) and more complex cases.

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 16 Oct 2018 16:54:32 +0200

To quote Carsten, there is "the usual terminology problem about identity".

Identifying vs. Identity brings back memories about an extensive 
discussion in SACM that in the end resulted in using Profiles...

Profiles are the "things" that you can aggregate identity claims in (in 
SACM these claims are "Target Endpoint Characteristics", which are 
pretty much the same thing as Device Characteristics) - and you use the 
Profiles to (re-)identify target endpoints.

In the scope of remote attestation procedures, I think that "just not 
calling" claim sets that are composed (amongst others) of identifying 
claims "identity documents" might just end up in making up another name 
for something that is effectively composing identity documents anyways. 
If calling the same thing something else helps in some way, I am all for 
it. But I am really not sure.

That said, Ned's elaboration on the relationship of identity and 
attestation claims and corresponding claim semantics / trust semantics 
is spot on, I think.

Viele Grüße,

Henk

---

From: Giridhar Mandyam <[email-masked]>
Date: Tue, 16 Oct 2018 16:11:49 +0000

Hi Henk,
The RC2 version is certainly more broadly applicable than the Master branch.  I have created another PR.  Note the following:

a) I don't understand why we would say that "secure boot" is deprecated.  I would prefer to avoid any mention of this in the charter.

b) I don't know why we explicitly call out GDPR compliance.  There are many privacy regulations beyond the EU.  I also wonder whether we should even try to address all regulatory privacy regimes - it could easily bog down the work of the group.

-Giri

-----Original Message-----
From: Henk Birkholz <[email-masked]> 
Sent: Tuesday, October 16, 2018 5:25 AM
To: Giridhar Mandyam <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Rats] [EAT] [EXTERNAL] Re: Attestation BoF charter updates?

Hello Giridhar,

I totally agree that attestation procedures do not always use network protocols as conveyance methods. In a composite device, e.g. a network equipment chassis, there can be a component hierarchy in which each component can be associated with an attester role and/or verifier role; enabling (mutual) attestation between each component/sub-component relationship using various kinds of interconnects (and none of them have to be IP). Keeping that in mind when designing data models and corresponding serializations is important. For remote attestation via network protocols it might not be the most important thing, though.

There are most certainly "on behalf" roles, provided that there is a "trusted path" relationship (quoting orange book here) via which the attestation procedure could be behave like a local one.
I am not sure, if I see a "verifiers on behalf of a remote relying party" scenario, but in general, I'd agree with the concept.

In summary, if the attester and the verifier are connected via a "trusted path" then it is essentially local attestation.

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

We are currently trimming the text, refactoring the content by using more generic terminology, and cut out about half of the content (wrt to the master branch) in order to segregate problem statements and goals into phases. The current version referenced above is intended to be become phase one.

Viele Grüße,

Henk

On 10/15/2018 09:33 PM, Giridhar Mandyam wrote:
> To: Smith, Ned <[email-masked]>; Henk Birkholz 
> <[email-masked]>; [email-masked]; Jeremy O'Donoghue 
> <[email-masked]>; Denis <[email-masked]>
> Cc: [email-masked]
> To: Henk Birkholz <[email-masked]>; [email-masked]; 
> Jeremy O'Donoghue <[email-masked]>; Denis 
> <[email-masked]>
> Cc: [email-masked]

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 17 Oct 2018 10:01:15 +0530

I think the TCG has a certain developed notion of identity that is different from others.  A way to get sharper about what a particular identity means is to describe the space and how the identifier selects in the space.  Here’s a few examples:

- The space is physical human beings with fingers. A fingerprint scanner select one of these humans. This is typical biometric auth.
- The space is humans that know a password. A password authenticator selects the humans that know the password. Typical authentication.
- The space is humans as legal entities / citizens with criminal records, passports and such. A national ID selects. 
- The space is physical manufactured devices from one maker.  A serial number narrows it down to one physical device.
- The space is physical devices from one maker. A model number or version, narrows down to a subset of these devices.

My understanding of the TCG world is that identities goes beyond any of the above because they include things like the version of the SW and configuration of the device. The identity is largely a hash of an identifier of the physical device, various SW components and various configuration states.  The point being that a change in any of these is a change in the security characteristics of the device and if it was trusted with a particular key or particular data in the past, that trust should be revoked until re established.

- The space is physical devices from any maker
  + Measurement of the SW (the SW versions)
     + Measurements of some configuration

Changing any of these change the identity of the device. 

I know I hardly need to ask, but TCG folks, did I describe this correctly?

So that said, many, perhaps most, use cases for EAT do not want this kind of device identity. It is not a prerequisite for trusting  claims coming from the device. In some cases this level of identity seems extremely disruptive as small SW upgrades could result in re enrollment of biometrics. We already are annoyed when we have to answer security questions when start using a service from a new device. 

I think this WG needs to address both this very tight TCG-style device identity and the more heuristic EAT-style claims-for-risk-engines. I could see multi-decade evolution where risk engine use cases want more and more of the tight TCG-style device identity as criminals become more adept at forging EAT-style claims. (Today risk engines work off of unsecured browser parameters). 

The Introduction in the charter seems entirely focused on the TCG-based identity use case. I think text should be added for EAT-style attestation. I will write some after some comments on this message.

LL 

> On Oct 16, 2018, at 8:24 PM, Henk Birkholz <[email-masked]> wrote:
> 
> Identifying vs. Identity brings back memories about an extensive discussion in SACM that in the end resulted in using Profiles...
> 
> Profiles are the "things" that you can aggregate identity claims in (in SACM these claims are "Target Endpoint Characteristics", which are pretty much the same thing as Device Characteristics) - and you use the Profiles to (re-)identify target endpoints.
> 
> In the scope of remote attestation procedures, I think that "just not calling" claim sets that are composed (amongst others) of identifying claims "identity documents" might just end up in making up another name for something that is effectively composing identity documents anyways. If calling the same thing something else helps in some way, I am all for it. But I am really not sure.
> 
> That said, Ned's elaboration on the relationship of identity and attestation claims and corresponding claim semantics / trust semantics is spot on, I think.
> 
> Viele Grüße,
> 
> Henk
>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 17 Oct 2018 10:18:20 +0000

Hi,

May be this is a fairly naïve proposal, but if we use "identification" rather than "identity" and therefore avoid the ontological implications of the latter, especially when it comes to the points it touches human-vs-machine issues?

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]
Tel:         +34 913 129 041
Mobile:  +34 682 051 091
----------------------------------

On 17/10/2018, 06:31, "EAT on behalf of Laurence Lundblade" <[email-masked] on behalf of [email-masked]> wrote:

    LL

________________________________

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: Guy Fedorkow <[email-masked]>
Date: Wed, 17 Oct 2018 10:56:05 +0000

Hi Laurence,
  I don't think there's ambiguity in the TCG case...  current work in attestation focuses on using the 802.1AR DevID spec, which corresponds exactly to one of your cases below -- it's a vendor, model and serial number.
  It's true that TCG technology can be used to validate software integrity, but that's hardly the same as identity.
  Considerations of user privacy commonly accepted in TCG would preclude the inclusion of software state as part of identity, practicalities aside.  In general, privacy considerations lead TCG to carefully avoid unauthorized disclosure of either software or hardware based assertions.
  Let me know if I'm missing the point...
Thanks
/guy fedorkow, juniper networks

-----Original Message-----
From: Laurence Lundblade <[email-masked]> 
Sent: Wednesday, October 17, 2018 12:31 AM
To: Henk Birkholz <[email-masked]>
Cc: Smith, Ned <[email-masked]>; Hannes Tschofenig <[email-masked]>; [email-masked]; Jeremy O'Donoghue <[email-masked]>; Denis <[email-masked]>; [email-masked]
Subject: Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF charter updates?

LL 

>>         >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Drats_charter_blob_RC2_ietf-2Drats-2Dcharter.md&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=sebUyXCidr_CEuZObmOub9NX0cE_5cRieGL_7VXhmfk&m=p5eO1iMTXM4ZfeXvFBU57-xCILnJh-EOaxl5AUwyWGM&s=rPzmwhcwy8eob4eMiwWzDg5DY-mcC5HYgQqhUGCZ2RI&e=
>>         >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rats&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=sebUyXCidr_CEuZObmOub9NX0cE_5cRieGL_7VXhmfk&m=p5eO1iMTXM4ZfeXvFBU57-xCILnJh-EOaxl5AUwyWGM&s=xThsQTXgadltVkHTYpOWknadi7puxZt8O6XOIUm_bzo&e=
>>         >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_eat&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=sebUyXCidr_CEuZObmOub9NX0cE_5cRieGL_7VXhmfk&m=p5eO1iMTXM4ZfeXvFBU57-xCILnJh-EOaxl5AUwyWGM&s=N7kKkDdCvl_MNmB3Guyg9HC-kQnMrX1cP5w44SbDsAw&e=
>>         >>
>>         >>
>>         >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_eat&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=sebUyXCidr_CEuZObmOub9NX0cE_5cRieGL_7VXhmfk&m=p5eO1iMTXM4ZfeXvFBU57-xCILnJh-EOaxl5AUwyWGM&s=N7kKkDdCvl_MNmB3Guyg9HC-kQnMrX1cP5w44SbDsAw&e=
>>         >
>>         >
>>         >
>>         > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_eat&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=sebUyXCidr_CEuZObmOub9NX0cE_5cRieGL_7VXhmfk&m=p5eO1iMTXM4ZfeXvFBU57-xCILnJh-EOaxl5AUwyWGM&s=N7kKkDdCvl_MNmB3Guyg9HC-kQnMrX1cP5w44SbDsAw&e=
>>         >
>>         https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_eat&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=sebUyXCidr_CEuZObmOub9NX0cE_5cRieGL_7VXhmfk&m=p5eO1iMTXM4ZfeXvFBU57-xCILnJh-EOaxl5AUwyWGM&s=N7kKkDdCvl_MNmB3Guyg9HC-kQnMrX1cP5w44SbDsAw&e=
>>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_eat&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=sebUyXCidr_CEuZObmOub9NX0cE_5cRieGL_7VXhmfk&m=p5eO1iMTXM4ZfeXvFBU57-xCILnJh-EOaxl5AUwyWGM&s=N7kKkDdCvl_MNmB3Guyg9HC-kQnMrX1cP5w44SbDsAw&e=
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_eat&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=sebUyXCidr_CEuZObmOub9NX0cE_5cRieGL_7VXhmfk&m=p5eO1iMTXM4ZfeXvFBU57-xCILnJh-EOaxl5AUwyWGM&s=N7kKkDdCvl_MNmB3Guyg9HC-kQnMrX1cP5w44SbDsAw&e=

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 17 Oct 2018 16:49:42 +0530

Wasn’t saying there was ambiguity in the TCG case. Not being a TCGer, was just was trying to understand what the TCG definition is. 

Your mentioning 802.1AR DevID helps a lot as I have some knowledge of it.

I see now that my speculation about SW / config version was wrong. That’s fine. I only wrote it to try to get to clarity.

Thanks for help clarifying.

In EAT, we defined a UEID for what TCGer’s mean by “identity":
   UEID's identify individual manufactured entities / devices such as a
   mobile phone, a water meter, a Bluetooth speaker or a networked
   security camera.  It may identify the entire device or a submodule or
   subsystem.  It does not identify types, models or classes of devices.
   It is akin to a serial number, though it does not have to be
   sequential.  

See here <https://tools.ietf.org/html/draft-mandyam-eat-00#section-3.1> for more on UEID.

In EAT there is a strong desire to separate the signing key material from UEID to have flexibility in the signing scheme. For example FIDO and Android both have privacy-preserving schemes were a signing key is shared by 100,000 devices. (Some use cases need privacy, some don’t, perhaps because of legal agreements with customers, and correlation between use cases and privacy schemes can’t be counted on for high-volume devices like mobile phones).

I don’t know what the right answer(s) is(are) in the design yet...

LL

> On Oct 17, 2018, at 4:26 PM, Guy Fedorkow <[email-masked]> wrote:
> 
> Hi Laurence,

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 17 Oct 2018 16:51:12 +0530

I hope we don’t do any work related to identifying humans or accounts here. I only mentioned them for context in trying to figure out what people meant by identity. 

LL

> On Oct 17, 2018, at 3:48 PM, Diego R. Lopez <[email-masked]> wrote:
> 
> Hi,
>

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 17 Oct 2018 14:19:44 +0200

Hi Laurence,

maybe I understand now where the general confusion is originating from.

I dug through some parts of the EAT draft again and could it be that 
UIED are identifier and not an identities? They literally are claims 
(aka assertions) that can be signed as content of a CWT as illustrated in

> https://tools.ietf.org/html/draft-mandyam-eat-00#section-1.4.2

1.4.2. talks about identity documents by mentioning "X.509 certificate 
chains or something similar but different". But as you highlighted 
anything with regard to that is explicitly intended _not_ to go into the 
EAT claim set as content, but is stored on the thing (or maybe on a 
thing that signs "on behalf of" the thing the EAT is about?) and 
consequently is only used to potentially sign the EAT claim set (via 
COSE). Is that correct?

As a result, an EAT would never be able to act as an identity document 
itself, but the key material that comes along with an x.509 certificate 
(as one example of many highlighted) could be used to sign the EAT.

RATS are able to use the "X.509 certificate chains or something similar 
but different" and the corresponding key material comes along with a 
certificate (as one example amongst others) to establish Attestation 
Provenance.

Viele Grüße,

Henk

On 10/17/2018 01:19 PM, Laurence Lundblade wrote:
> Wasn’t saying there was ambiguity in the TCG case. Not being a TCGer, 
> was just was trying to understand what the TCG definition is.
> 
> I see now that my speculation about SW / config version was wrong. 
> That’s fine. I only wrote it to try to get to clarity.
> 
> In EAT there is a strong desire to separate the signing key material 
> from UEID to have flexibility in the signing scheme. For example FIDO 
> and Android both have privacy-preserving schemes were a signing key is 
> shared by 100,000 devices. (Some use cases need privacy, some don’t, 
> perhaps because of legal agreements with customers, and correlation 
> between use cases and privacy schemes can’t be counted on for 
> high-volume devices like mobile phones).
> 
> 
>> On Oct 17, 2018, at 4:26 PM, Guy Fedorkow <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Laurence,
>>  I don't think there's ambiguity in the TCG case...  current work in 
>> attestation focuses on using the 802.1AR DevID spec, which corresponds 
>> exactly to one of your cases below -- it's a vendor, model and serial 
>> number.
>>  It's true that TCG technology can be used to validate software 
>> integrity, but that's hardly the same as identity.
>>  Considerations of user privacy commonly accepted in TCG would 
>> preclude the inclusion of software state as part of identity, 
>> practicalities aside.  In general, privacy considerations lead TCG to 
>> carefully avoid unauthorized disclosure of either software or hardware 
>> based assertions.
>> From: Laurence Lundblade <[email-masked] 
>> <mailto:[email-masked]>>
>> To: Henk Birkholz <[email-masked] 
>> <mailto:[email-masked]>>
>> Cc: Smith, Ned <[email-masked] <mailto:[email-masked]>>; 
>> Hannes Tschofenig <[email-masked] 
>> <mailto:[email-masked]>>; [email-masked] 
>> <mailto:[email-masked]>; Jeremy O'Donoghue <[email-masked] 
>> <mailto:[email-masked]>>; Denis <[email-masked] 
>> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> I think the TCG has a certain developed notion of identity that is 
>> different from others.  A way to get sharper about what a particular 
>> identity means is to describe the space and how the identifier selects 
>> in the space.  Here’s a few examples:
>>
>> - The space is physical human beings with fingers. A fingerprint 
>> scanner select one of these humans. This is typical biometric auth.
>> - The space is humans that know a password. A password authenticator 
>> selects the humans that know the password. Typical authentication.
>> - The space is humans as legal entities / citizens with criminal 
>> records, passports and such. A national ID selects.
>> - The space is physical manufactured devices from one maker.  A serial 
>> number narrows it down to one physical device.
>> - The space is physical devices from one maker. A model number or 
>> version, narrows down to a subset of these devices.
>>
>> My understanding of the TCG world is that identities goes beyond any 
>> of the above because they include things like the version of the SW 
>> and configuration of the device. The identity is largely a hash of an 
>> identifier of the physical device, various SW components and various 
>> configuration states.  The point being that a change in any of these 
>> is a change in the security characteristics of the device and if it 
>> was trusted with a particular key or particular data in the past, that 
>> trust should be revoked until re established.
>>
>> So that said, many, perhaps most, use cases for EAT do not want this 
>> kind of device identity. It is not a prerequisite for trusting  claims 
>> coming from the device. In some cases this level of identity seems 
>> extremely disruptive as small SW upgrades could result in re 
>> enrollment of biometrics. We already are annoyed when we have to 
>> answer security questions when start using a service from a new device.
>>
>> I think this WG needs to address both this very tight TCG-style device 
>> identity and the more heuristic EAT-style claims-for-risk-engines. I 
>> could see multi-decade evolution where risk engine use cases want more 
>> and more of the tight TCG-style device identity as criminals become 
>> more adept at forging EAT-style claims. (Today risk engines work off 
>> of unsecured browser parameters).
>>
>> The Introduction in the charter seems entirely focused on the 
>> TCG-based identity use case. I think text should be added for 
>> EAT-style attestation. I will write some after some comments on this 
>> message.
>>
>> LL
>>
>>
>>
>>
>>
>>> On Oct 16, 2018, at 8:24 PM, Henk Birkholz 
>>> <[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>>
>>> Profiles are the "things" that you can aggregate identity claims in 
>>> (in SACM these claims are "Target Endpoint Characteristics", which 
>>> are pretty much the same thing as Device Characteristics) - and you 
>>> use the Profiles to (re-)identify target endpoints.
>>>
>>> claims "identity documents" might just end up in making up another 
>>> name for something that is effectively composing identity documents 
>>> anyways. If calling the same thing something else helps in some way, 
>>> I am all for it. But I am really not sure.
>>>
>>> attestation claims and corresponding claim semantics / trust 
>>> semantics is spot on, I think.
>>>
>>> Viele Grüße,
>>>
>>> Henk
>>>
>>>> Agree with Hannes that identity discussion can lead to confusion as 
>>>> identity is often highly dependent on some sort of context (domain 
>>>> of interpretation).
>>>> In order to have productive conversation about attestation and 
>>>> identity, it may be important to understand that attestation 
>>>> semantics sets the context for identity.
>>>> * Attestation attributes have trust semantics (and trust semantics 
>>>> are interpreted through the eyes of the verifier). Identity 
>>>> attributes may also have trust semantics (in addition to identity 
>>>> semantics) hence can be regarded as playing a role in both identity 
>>>> and attestation. Since RATS should be interested primarily in trust 
>>>> semantics, it makes sense to understand, discuss and consider 
>>>> identity in terms of its trust semantics. Hence identity attributes 
>>>> are only interesting to RATS if they are useful for evaluating trust 
>>>> semantics.
>>>> * In a closed ecosystem, the trust characteristics and properties 
>>>> may be implied because there often exists out-of-band processes that 
>>>> ensure the characteristics are applied (for example, if an IT 
>>>> organization sets a policy that all asymmetric keys are to be 
>>>> hardened using a smartcard, they can apply a deployment process 
>>>> where the IT professional verifies the smartcard is used during 
>>>> enrollment.) But in a non-closed ecosystem, there isn't an 
>>>> assumption that out-of-band processes exist. Attestation attempts to 
>>>> make explicit what otherwise is implicit and therefore subject to 
>>>> misinterpretation if the verifier, relying party and attester are 
>>>> not part of the same closed ecosystem. Implicit attestation 
>>>> therefore can lead to semantic confusion if we're not careful. 
>>>> Therefore, the rigor of treating implicit attestation claims 
>>>> (assertions assumed to exist but not explicitly named) should 
>>>> nevertheless be defined explicitly. Then, if there is a need for 
>>>> implicit attestation, the specifications that describe them can 
>>>> describe them in terms of an explicit definition.
>>>> * In the context of asserting trust characteristics, the verifier 
>>>> needs to know that a set of characteristics applies to the instance 
>>>> of the endpoint being evaluated (aka the attester). (Otherwise a 
>>>> MITM could supply characteristics that may be valid, but don’t apply 
>>>> to the specific instance). Consequently, it makes sense to consider 
>>>> that *attestation* keys are needed to authenticate the endpoint 
>>>> being evaluated. This doesn't imply an identity key couldn't double 
>>>> as an attestation key. But if it does, we care about its relevance 
>>>> to the attester endpoint.
>>>> -Ned
>>>> On 10/15/18, 6:49 PM, "Hannes Tschofenig" 
>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>         I have been working on identity management for many years 
>>>> (partially because of my OAuth co-chair role) and I have noticed 
>>>> that the use of the term "identity" tends to confuse more than it 
>>>> helps (even more so when the term is applied to devices and software 
>>>> rather than humans).
>>>>         In this context I would argue that we are about identifying 
>>>> different components, such as hardware and software.
>>>>         Ciao
>>>>    Hannes
>>>>    From: EAT <[email-masked] <mailto:[email-masked]>> On 
>>>> Behalf Of Smith, Ned
>>>>    To: Henk Birkholz <[email-masked] 
>>>> <mailto:[email-masked]>>; [email-masked] 
>>>> <mailto:[email-masked]>; Jeremy O'Donoghue <[email-masked] 
>>>> <mailto:[email-masked]>>; Denis <[email-masked] 
>>>> <mailto:[email-masked]>>
>>>>    Cc: [email-masked] <mailto:[email-masked]>
>>>>         I agree with Henk's observation that there is opportunity to 
>>>> find common ground on identity as identity can be a collection of 
>>>> attributes, that if signed, becomes a set of verifiable claims 
>>>> (about identity attributes). Attestation has a similar structure in 
>>>> that it consists of a set of attributes, that if signed becomes a 
>>>> set of verifiable claims. The main difference between identity and 
>>>> attestation attributes is whether the attribute semantically relate 
>>>> to trust (vs. identity). For example, claims of security 
>>>> certification compliance resonates as attestation.
>>>>         It may be possible to combine a set of attestation 
>>>> attributes in such a way that the combination uniquely identifies an 
>>>> entity. But that doesn't make it an identity system per se and 
>>>> shouldn't cause a conflict in charter goals with respect to other 
>>>> identity focused efforts in IETF.
>>>>         Also, inclusion of attributes that don't have semantics that 
>>>> reasonably relate to trust should not be of interest to a working 
>>>> group focused on attestation.
>>>>         -Ned
>>>>         On 10/15/18, 3:53 PM, "EAT on behalf of Henk Birkholz" 
>>>> <[email-masked] <mailto:[email-masked]> on behalf of 
>>>> [email-masked] 
>>>> <mailto:[email-masked]>> wrote:
>>>>             Hi Jeremy & Denis,
>>>>> to know the characteristics of a device by issuing to the device a 
>>>>> public key certificate which will only be issued to the device if 
>>>>> it fulfills an expected set of functionalities.
>>>>> On 12 Oct 2018, at 14:33, Denis <[email-masked] 
>>>>> <mailto:[email-masked]>
>>>>> <mailto:[email-masked]>> wrote:
>>>>> forms
>>>>>>> <[email-masked] <mailto:[email-masked]> on behalf 
>>>>>>> of [email-masked] 
>>>>>>> <mailto:[email-masked]>>  wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>    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: Henk Birkholz <[email-masked]>
Date: Wed, 17 Oct 2018 14:23:08 +0200

This is an interesting point. When I am referring to identity documents, 
the scope and intent is device identity (meaning a single device as well 
as a certain group of devices) - and not other entities, such as humans!

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 18 Oct 2018 18:37:21 +0000

Yes, there has been conversation about the differences between 'identity' and 'identity document' where an identity document may be as subset of identifying attributes that might be attributed to an identity. The purpose for using the term identity document was to avoid the philosophical (even meta-physical) discussion about what constitutes identity. The term 'identification' may serve the same purpose as identity document. If so, both have the same end state. 

However, I don't think there needs to be any significant references to identification or identity document or other synonymous term as the focus should be on trust attributes (characteristics, properties) and provenance. In some scenarios, it is necessary to disambiguate the endpoint (entity?) instance in order to conclude that a set of trust attributes belong to the specific instance. But I don't think we should regard this as an identity, identity document or identifier. We should refer to it as a trustworthiness claim set or trust document, or something along these lines. 

BTW: RFC 875 is apropos. A trustworthiness claim set is a Heffalump. 

On 10/17/18, 11:18 AM, "EAT on behalf of Diego R. Lopez" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    Be goode,

    Dr Diego R. Lopez
    Telefonica I+D

    

    

    

        LL

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 20 Oct 2018 11:24:57 +0530

I’d like to propose this for the Introduction in the charter. I tried pretty hard to write what I wanted through edits to the existing intro, but really couldn’t make it work, so this is mostly new text. Some phrases are re used. Apologies for not finding a better way to do this. I have tried to put all the ideas and concepts in Henk’s original charter intro in here, though I have gone for a more abstract conceptual level. A few more notes below.

RATS enables remote parties communicating with a device to evaluate the trustworthiness, device identity, origin of manufacture, system integrity, configuration, operational state and other characteristics of that device. Conceptually, the remote party ends up knowing a set of claims about the device and using them to make the evaluation. The claims may explicitly be transmitted or implicitly derived from other things known about the device. Various means are used to secure, or prove the security of, claims for the remote party. Signing of the claims is the most important but may not be the only means of securing the claims. These claims can provide evidence that a device supports a certain set of operations and functions and/or that it is actually the exact device it is supposed to be.

RATS includes the measurement of SW running on the device and securely conveying those measurements to the remote party.  These measurements enable tje remote party to evaluate device trustworthiness, that it operates as expected, does what is required and does not do other things.

RATS may include definition of procedures by which a remote party evaluates certain claims. For example, how some measurement or other claims are compared to expected values to evaluate trustworthiness of the device.

RATS may include the definition new protocols and/or definition of secured data structures (e.g., signed) that are carried in existing protocols.

RATS is general purpose and aims to address a broad range of uses cases including on-line banking, payment transactions, critical infrastructure, network security functions, constrained devices, business and government enterprises and management of end-user devices.

Notes:

I have avoided the use of the formally defined terms in the introduction so it can stand more on its own, is easier to understand and is less presumption about architectures and designs. Seems like it is work for the WG to define the terms and create the designs.
My use of the lower case “device”, “claim” and “remote party” are just as broad concepts to be able to get the general idea across. The WG documents should use the more formal and specific definitions.
Hope I’ve covered both EAT and RATS concepts here. It was my goal. 
While I used the term RATS, I still want the WG name change to CREATE.

LL

> On Oct 11, 2018, at 10:19 PM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi all,
> 
> The BoF proponents tried to merge all comments and proposals on keystores, existing solutions, provenance & device characteristics, etc that were raised on the list - and align them in homogeneous fashion.
>

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 20 Oct 2018 11:49:47 +0530

I consider device identity an absolute critical part of our work. It is a critical part of most EAT use cases such as enrollment of IoT devices with IoT management systems. It is the first claim defined in EAT. 

What is the definition of an “identity document”? Maybe you are thinking of it specifically as what was defined for IEEE Dev ID. If I recall, the identification claims for the device are in the subject DN of an X.509 certificate. 

Seems like any EAT with an EUID in it could server well as an identity document too. It provides signed, secured proof of the identity of the device. It can include manufacturer info in addition to the EUID. The EAT style identity could be as tiny as 150 bytes in CBOR syntax. All you need to store on the device is the EUID and the signing key. Maybe they are even deterministically KDF’d from the same seed so you maybe you only need to store 32 bytes on the device.

EAT’s mention of X.509 in 1.4.2 is as one of many ways to establish key material so the remote / relying / verifying party can verify the signature. So yes, I think you have it correct below. (Technically speaking the private key associated with the X.509 cert is used to sign, not the X.509 cert or keys in the cert. The X.509 is only to help the verifier find and verify the verification key. You might even have a means to get it from some service based on a key ID and not even store it on the device).

It is an EAT design goal to keep all the claims in the signed payload. That includes identity of the device, identity of the manufacturer and so on. That way you can use many different signing schemes (ECDAA, symmetric key, non-X.509 public key, X.509 pubic key, simple public key with just a key id…) with the same claims.

LL

> On Oct 17, 2018, at 5:49 PM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Laurence,
> 
> I dug through some parts of the EAT draft again and could it be that UIED are identifier and not an identities? They literally are claims (aka assertions) that can be signed as content of a CWT as illustrated in
> 
> 1.4.2. talks about identity documents by mentioning "X.509 certificate chains or something similar but different". But as you highlighted anything with regard to that is explicitly intended _not_ to go into the EAT claim set as content, but is stored on the thing (or maybe on a thing that signs "on behalf of" the thing the EAT is about?) and consequently is only used to potentially sign the EAT claim set (via COSE). Is that correct?
> 
> As a result, an EAT would never be able to act as an identity document itself, but the key material that comes along with an x.509 certificate (as one example of many highlighted) could be used to sign the EAT.
> 
> RATS are able to use the "X.509 certificate chains or something similar but different" and the corresponding key material comes along with a certificate (as one example amongst others) to establish Attestation Provenance.
> 
> Viele Grüße,
> 
> Henk
> 
>>> On Oct 17, 2018, at 4:26 PM, Guy Fedorkow <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Laurence,
>>> From: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
>>> To: Henk Birkholz <[email-masked] <mailto:[email-masked]>>
>>> Cc: Smith, Ned <[email-masked] <mailto:[email-masked]>>; Hannes Tschofenig <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Jeremy O'Donoghue <[email-masked] <mailto:[email-masked]>>; Denis <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>>>> On Oct 16, 2018, at 8:24 PM, Henk Birkholz <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>>> On 10/15/18, 6:49 PM, "Hannes Tschofenig" <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>    From: EAT <[email-masked] <mailto:[email-masked]>> On Behalf Of Smith, Ned
>>>>>    To: Henk Birkholz <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Jeremy O'Donoghue <[email-masked] <mailto:[email-masked]>>; Denis <[email-masked] <mailto:[email-masked]>>
>>>>>         On 10/15/18, 3:53 PM, "EAT on behalf of Henk Birkholz" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
>>>>>             Hi Jeremy & Denis,
>>>>>> On 12 Oct 2018, at 14:33, Denis <[email-masked] <mailto:[email-masked]>
>>>>>>>> <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>>  wrote:
>>>>>>>> 
>>>>>>>>> Hi all,
>>>>>>>>>

---

From: Henk Birkholz <[email-masked]>
Date: Sat, 20 Oct 2018 11:49:05 +0200

Hello Laurence,

unfortunately, I am traveling at the moment, but let me try to address 
an eclectically chosen topic.

In an attempt to answer your question "What is the definition of an 
“identity document” I will just reference

> https://tools.ietf.org/html/draft-birkholz-core-coid-00#section-1

for now (instead of writing a wall of text again. Sorry, if I do that 
sometimes, that does not always help...)

Based on the reference text, the important principle here is that an 
identity document is signed using secret keys issued by a (sub) 
certificate authority that one or more entities *can* put trust into.

In comparison, if a CWT is signed with key material deployed on the 
device in question, what you provide is proof-of-possession of that 
signing (most likely intended to be secret) key.

Again, you *can* put trust into that proof-of-possession, but the trust 
relationships here can have vastly different semantics. In both cases 
though, putting trust into, for example, CoID (via TVP) or EAT (via PoP) 
is a decision, I think. If you choose to put trust into the signature of 
these CWT, both are Trusted Claim Sets - to you.

This trust has unfortunately nothing to do with the actual 
trustworthiness of the thing in question. As Ned illustrated already, 
"in a closed ecosystem, the trust characteristics and properties may be 
implied". In consequence, if you choose to trust that possession of a 
key provides an appropriate level of confidence in trustworthiness - 
that is a decision you make.

This does not provide actual evidence that a thing is really 
trustworthy. And providing this evidence via interoperable network 
protocols is the gap that RATS intent to address - not only in closed 
ecosystems, but also the Internet in general.

IHTH,

Henk

On 10/20/2018 08:19 AM, Laurence Lundblade wrote:
> I consider /device identity/ an absolute critical part of our work. It 
> is a critical part of most EAT use cases such as enrollment of IoT 
> devices with IoT management systems. It is the first claim defined in EAT.
> 
> What is the definition of an “identity document”? Maybe you are thinking 
> of it specifically as what was defined for IEEE Dev ID. If I recall, the 
> identification claims for the device are in the subject DN of an X.509 
> certificate.
> 
> Seems like any EAT with an EUID in it could server well as an identity 
> document too. It provides signed, secured proof of the identity of the 
> device. It can include manufacturer info in addition to the EUID. The 
> EAT style identity could be as tiny as 150 bytes in CBOR syntax. All you 
> need to store on the device is the EUID and the signing key. Maybe they 
> are even deterministically KDF’d from the same seed so you maybe you 
> only need to store 32 bytes on the device.
> 
> EAT’s mention of X.509 in 1.4.2 is as one of many ways to establish key 
> material so the remote / relying / verifying party can verify the 
> signature. So yes, I think you have it correct below. (Technically 
> speaking the private key associated with the X.509 cert is used to sign, 
> not the X.509 cert or keys in the cert. The X.509 is only to help the 
> verifier find and verify the verification key. You might even have a 
> means to get it from some service based on a key ID and not even store 
> it on the device).
> 
> It is an EAT design goal to keep /all/ the claims in the signed payload. 
> That includes identity of the device, identity of the manufacturer and 
> so on. That way you can use many different signing schemes (ECDAA, 
> symmetric key, non-X.509 public key, X.509 pubic key, simple public key 
> with just a key id…) with the same claims.
> 
> LL
> 
> 
> 
> 
>> On Oct 17, 2018, at 5:49 PM, Henk Birkholz 
>> anything with regard to that is explicitly intended _not_ to go into 
>> the EAT claim set as content, but is stored on the thing (or maybe on 
>> a thing that signs "on behalf of" the thing the EAT is about?) and 
>> itself, but the key material that comes along with an x.509 
>> certificate (as one example of many highlighted) could be used to sign 
>> the EAT.
>>
>> RATS are able to use the "X.509 certificate chains or something 
>> similar but different" and the corresponding key material comes along 
>> with a certificate (as one example amongst others) to establish 
>> Attestation Provenance.
>>
>> Viele Grüße,
>>
>> Henk
>>
>>> See here 
>>> <https://tools.ietf.org/html/draft-mandyam-eat-00#section-3.1> for 
>>> more on UEID.
>>> and Android both have privacy-preserving schemes were a signing key 
>>> is shared by 100,000 devices. (Some use cases need privacy, some 
>>> don’t, perhaps because of legal agreements with customers, and 
>>> correlation between use cases and privacy schemes can’t be counted on 
>>> for high-volume devices like mobile phones).
>>>> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>
>>>> Hi Laurence,
>>>> attestation focuses on using the 802.1AR DevID spec, which 
>>>> corresponds exactly to one of your cases below -- it's a vendor, 
>>>> model and serial number.
>>>> practicalities aside.  In general, privacy considerations lead TCG 
>>>> to carefully avoid unauthorized disclosure of either software or 
>>>> hardware based assertions.
>>>> <mailto:[email-masked]> <mailto:[email-masked]>>
>>>> <mailto:[email-masked]> 
>>>> Cc: Smith, Ned <[email-masked] <mailto:[email-masked]> 
>>>> <mailto:[email-masked]>>; Hannes Tschofenig 
>>>> <[email-masked] <mailto:[email-masked]> 
>>>> <mailto:[email-masked]> <mailto:[email-masked]>; Jeremy O'Donoghue 
>>>> <[email-masked] <mailto:[email-masked]> 
>>>> <mailto:[email-masked]> <mailto:[email-masked]>>; 
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>> identity means is to describe the space and how the identifier 
>>>> selects in the space.  Here’s a few examples:
>>>>
>>>> - The space is physical manufactured devices from one maker.  A 
>>>> serial number narrows it down to one physical device.
>>>> and configuration of the device. The identity is largely a hash of 
>>>> an identifier of the physical device, various SW components and 
>>>> various configuration states.  The point being that a change in any 
>>>> of these is a change in the security characteristics of the device 
>>>> and if it was trusted with a particular key or particular data in 
>>>> the past, that trust should be revoked until re established.
>>>>
>>>> kind of device identity. It is not a prerequisite for trusting 
>>>>  claims coming from the device. In some cases this level of identity 
>>>> seems extremely disruptive as small SW upgrades could result in re 
>>>> I think this WG needs to address both this very tight TCG-style 
>>>> device identity and the more heuristic EAT-style 
>>>> claims-for-risk-engines. I could see multi-decade evolution where 
>>>> risk engine use cases want more and more of the tight TCG-style 
>>>> device identity as criminals become more adept at forging EAT-style 
>>>> claims. (Today risk engines work off of unsecured browser parameters).
>>>>
>>>>> <mailto:[email-masked]> 
>>>>> In the scope of remote attestation procedures, I think that "just 
>>>>> not calling" claim sets that are composed (amongst others) of 
>>>>> identifying claims "identity documents" might just end up in making 
>>>>> up another name for something that is effectively composing 
>>>>> identity documents anyways. If calling the same thing something 
>>>>> else helps in some way, I am all for it. But I am really not sure.
>>>>>
>>>>>> Agree with Hannes that identity discussion can lead to confusion 
>>>>>> as identity is often highly dependent on some sort of context 
>>>>>> (domain of interpretation).
>>>>>> semantics) hence can be regarded as playing a role in both 
>>>>>> identity and attestation. Since RATS should be interested 
>>>>>> primarily in trust semantics, it makes sense to understand, 
>>>>>> discuss and consider identity in terms of its trust semantics. 
>>>>>> Hence identity attributes are only interesting to RATS if they are 
>>>>>> useful for evaluating trust semantics.
>>>>>> may be implied because there often exists out-of-band processes 
>>>>>> that ensure the characteristics are applied (for example, if an IT 
>>>>>> assumption that out-of-band processes exist. Attestation attempts 
>>>>>> to make explicit what otherwise is implicit and therefore subject 
>>>>>> to misinterpretation if the verifier, relying party and attester 
>>>>>> are not part of the same closed ecosystem. Implicit attestation 
>>>>>> needs to know that a set of characteristics applies to the 
>>>>>> instance of the endpoint being evaluated (aka the attester). 
>>>>>> (Otherwise a MITM could supply characteristics that may be valid, 
>>>>>> but don’t apply to the specific instance). Consequently, it makes 
>>>>>> sense to consider that *attestation* keys are needed to 
>>>>>> authenticate the endpoint being evaluated. This doesn't imply an 
>>>>>> identity key couldn't double as an attestation key. But if it 
>>>>>> does, we care about its relevance to the attester endpoint.
>>>>>> -Ned
>>>>>> <[email-masked] <mailto:[email-masked]> 
>>>>>> <mailto:[email-masked]>> wrote:
>>>>>> helps (even more so when the term is applied to devices and 
>>>>>> software rather than humans).
>>>>>>         In this context I would argue that we are about 
>>>>>> identifying different components, such as hardware and software.
>>>>>>         Ciao
>>>>>>    Hannes
>>>>>>    From: EAT <[email-masked] <mailto:[email-masked]> 
>>>>>> <mailto:[email-masked]>> On Behalf Of Smith, Ned
>>>>>> <mailto:[email-masked]> 
>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>; Jeremy O'Donoghue 
>>>>>> <[email-masked] <mailto:[email-masked]> 
>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>>
>>>>>>    Cc: [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>>         I agree with Henk's observation that there is opportunity 
>>>>>> to find common ground on identity as identity can be a collection 
>>>>>> of attributes, that if signed, becomes a set of verifiable claims 
>>>>>> (about identity attributes). Attestation has a similar structure 
>>>>>> in that it consists of a set of attributes, that if signed becomes 
>>>>>> a set of verifiable claims. The main difference between identity 
>>>>>> and attestation attributes is whether the attribute semantically 
>>>>>> relate to trust (vs. identity). For example, claims of security 
>>>>>> attributes in such a way that the combination uniquely identifies 
>>>>>> an entity. But that doesn't make it an identity system per se and 
>>>>>>         Also, inclusion of attributes that don't have semantics 
>>>>>> that reasonably relate to trust should not be of interest to a 
>>>>>> working group focused on attestation.
>>>>>>         -Ned
>>>>>> <[email-masked] <mailto:[email-masked]> 
>>>>>> <mailto:[email-masked]> on behalf of 
>>>>>> <mailto:[email-masked]> 
>>>>>>> to know the characteristics of a device by issuing to the device 
>>>>>>> a public key certificate which will only be issued to the device 
>>>>>>> if it fulfills an expected set of functionalities.
>>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>>>> end-user
>>>>>>> This is indeed a possible way to address the problem, but suffers 
>>>>>>> from
>>>>>>> challenges which come down to:
>>>>>>>
>>>>>>> example)
>>>>>>>>> <[email-masked] <mailto:[email-masked]> 
>>>>>>>>> <mailto:[email-masked]> on behalf of 
>>>>>>>>> <mailto:[email-masked]> 
>>>>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>>>> <mailto:[email-masked]>
>>>>>>    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: Laurence Lundblade <[email-masked]>
Date: Sat, 20 Oct 2018 19:29:26 +0530

Henk,

I think you are grossly misunderstanding EAT. I certainly wouldn’t propose such an insecure system as you assume it is and folks like FIDO, Google and ARM would not be supporting systems that are very similar if it wasn’t a secure model.  

It is true that EAT doesn’t directly specify how the remote party comes to know the key material on the device is authentic, but it leaves this out with foresight and intention so that the EAT claims can be used with key material established by IEEE-802.1AR, ECDAA as deployed by Intel, Googles Attestation Service and others to come. 

I don’t think we can rely solely on IEEE-802.1AR. It has size issues for small devices. It has operational issues.  Maybe even some of the central / hierarchy issues that caused X.500 to fail.

The core picture and system diagram shows how this works and the loop. In this picture the IEEE-802.1AR roots/CAs correspond to the Entity Manufacturer box. EAT certainly doesn’t preclude a group of manufacturers getting together and running a central CA based on IEEE-802.1AR.

If EAT was just proof-of-possesion, then there would only be the one line from the Entity/Device to the Relying Party. There would be no provisioning step of any obtaining of Verification Keys.

LL

> On Oct 20, 2018, at 3:19 PM, Henk Birkholz <[email-masked]> wrote:
> 
> Hello Laurence,
> 
> unfortunately, I am traveling at the moment, but let me try to address an eclectically chosen topic.
> 
> In an attempt to answer your question "What is the definition of an “identity document” I will just reference
> 
> for now (instead of writing a wall of text again. Sorry, if I do that sometimes, that does not always help...)
> 
> Based on the reference text, the important principle here is that an identity document is signed using secret keys issued by a (sub) certificate authority that one or more entities *can* put trust into.
> 
> In comparison, if a CWT is signed with key material deployed on the device in question, what you provide is proof-of-possession of that signing (most likely intended to be secret) key.
> 
> Again, you *can* put trust into that proof-of-possession, but the trust relationships here can have vastly different semantics. In both cases though, putting trust into, for example, CoID (via TVP) or EAT (via PoP) is a decision, I think. If you choose to put trust into the signature of these CWT, both are Trusted Claim Sets - to you.
> 
> This trust has unfortunately nothing to do with the actual trustworthiness of the thing in question. As Ned illustrated already, "in a closed ecosystem, the trust characteristics and properties may be implied". In consequence, if you choose to trust that possession of a key provides an appropriate level of confidence in trustworthiness - that is a decision you make.
> 
> This does not provide actual evidence that a thing is really trustworthy. And providing this evidence via interoperable network protocols is the gap that RATS intent to address - not only in closed ecosystems, but also the Internet in general.
> 
> IHTH,
> 
> Henk
> 
> 
>> I consider /device identity/ an absolute critical part of our work. It is a critical part of most EAT use cases such as enrollment of IoT devices with IoT management systems. It is the first claim defined in EAT.
>> It is an EAT design goal to keep /all/ the claims in the signed payload. That includes identity of the device, identity of the manufacturer and so on. That way you can use many different signing schemes (ECDAA, symmetric key, non-X.509 public key, X.509 pubic key, simple public key with just a key id…) with the same claims.
>> LL
>>> On Oct 17, 2018, at 5:49 PM, Henk Birkholz <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Laurence,
>>> 
>>>>> On Oct 17, 2018, at 4:26 PM, Guy Fedorkow <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>> 
>>>>> Hi Laurence,
>>>>> From: Laurence Lundblade <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>>
>>>>> To: Henk Birkholz <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>>
>>>>> Cc: Smith, Ned <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>>; Hannes Tschofenig <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>; Jeremy O'Donoghue <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>>; Denis <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>> On Oct 16, 2018, at 8:24 PM, Henk Birkholz <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>>> On 10/15/18, 6:49 PM, "Hannes Tschofenig" <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>>>>    From: EAT <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>> On Behalf Of Smith, Ned
>>>>>>>    To: Henk Birkholz <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>; Jeremy O'Donoghue <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>>; Denis <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>>
>>>>>>>         On 10/15/18, 3:53 PM, "EAT on behalf of Henk Birkholz" <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>>>>             Hi Jeremy & Denis,
>>>>>>>> On 12 Oct 2018, at 14:33, Denis <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>>>>>> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>>  wrote:
>>>>>>>>>> 
>>>>>>>>>>> Hi all,
>>>>>>>>>>> 
>>>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>

---

From: Henk Birkholz <[email-masked]>
Date: Sat, 20 Oct 2018 16:56:10 +0200

Hello Laurence,

well... I was actually including this picture as it is the only 
complementary material to the EAT draft that I know of. And I am 
perplexed how you think I was implying that EAT or CoID are insecure. 
How did I make the impression to have suggested that? It seems to me 
that I am unable to convey a very fundamental concept here, of which I 
assumed that it was way more obvious. And I am a bit afraid that our 
dialog is becoming somewhat circular.

I get the step named "provision private keys during manufacturing". In a 
given scope (probably in this case defined by the manufacturer) the 
decision (let's call it design) is to trust the keys deployed (in this 
scenario it seems to be a secret signing key, which is an assumption!), 
right? Where did I dispute that?

Wrt the "verification keys" I am not so sure, what the diagram means by 
that. With an asymmetric key-pair these would probably be public keys to 
check the signature by (I assume)?

My point is that evidence about system integrity (first phase of RATS 
WG) are just something else then putting trust in identity documents, 
deployed keys or signed claim sets - that is all :-)

Further comments in-line:

On 10/20/2018 03:59 PM, Laurence Lundblade wrote:
> Henk,
> 
> I think you are grossly misunderstanding EAT. I certainly wouldn’t 
> propose such an insecure system as you assume it is and folks like FIDO, 
> Google and ARM would not be supporting systems that are very similar if 
> it wasn’t a secure model.

I was not remotely (sorry for the pun) assuming that this 'system' was 
insecure - how should I be able to assess that? I was trying to 
highlight what trust means in the scope of identity documents and 
corresponding key material. That was the question, correct? And:

1.) trust is does not guarantee trustworthiness
2.) trusted claims are not always attestation evidence

It depends on the 'system' to use your wording, and if you trust that 
system or the way it is designed you can derive meaning from that trust.

Could you please explain to me what I got wrong here? I seem to miss 
something very obvious.

> 
> It is true that EAT doesn’t directly specify how the remote party comes 
> to know the key material on the device is authentic, but it leaves this 
> out with foresight and intention so that the EAT claims can be used with 
> key material established by IEEE-802.1AR, ECDAA as deployed by Intel, 
> Googles Attestation Service and others to come.

Our current understanding is also assuming out-of-band mechanisms that 
provide, for example, claim semantics. Still, trusting key material that 
is deployed with foresight and intention is based - obviously... - on 
trust. That is the only point I am trying to make here. RATS require 
similar trust relationships in order to trust Attestation Provenance. 
That is how trust relationships work, right?

> 
> I don’t think we can rely solely on IEEE-802.1AR. It has size issues for 
> small devices. It has operational issues.  Maybe even some of the 
> central / hierarchy issues that caused X.500 to fail.

Correct. That is why we started to incubate the Concise Identity draft.

> 
> The core picture and system diagram shows how this works and the loop. 
> In this picture the IEEE-802.1AR roots/CAs correspond to the Entity 
> Manufacturer box. EAT certainly doesn’t preclude a group of 
> manufacturers getting together and running a central CA based on 
> IEEE-802.1AR.

I also assumed exactly that, how else would you trust the corresponding 
identity documents?

> 
> If EAT was just proof-of-possesion, then there would only be the one 
> line from the Entity/Device to the Relying Party. There would be no 
> provisioning step of any obtaining of Verification Keys.

This is not true. You get the keys from from somewhere (or they are 
create by the thing itself, which requires some type of CSR anyways), 
you get the signed identity documents from somewhere.... I thought it 
was very obvious that I am not implying that there is no provisioning 
step - how would that even work?

Possession has meaning to it. That is the whole point of possessing a 
key as you pointed out above. Trusting that meaning enables you to 
assume a trustworthy devices, but there are additional methods, such as 
explicit attestation, that provide you with more evidence for the 
purpose of assessing device trustworthiness.

Viele Grüße,

Henk

> 
> 
> 
> LL
> 
> 
> 
> 
> 
>> On Oct 20, 2018, at 3:19 PM, Henk Birkholz 
>> Again, you *can* put trust into that proof-of-possession, but the 
>> trust relationships here can have vastly different semantics. In both 
>> cases though, putting trust into, for example, CoID (via TVP) or EAT 
>> (via PoP) is a decision, I think. If you choose to put trust into the 
>> signature of these CWT, both are Trusted Claim Sets - to you.
>>
>> "in a closed ecosystem, the trust characteristics and properties may 
>> be implied". In consequence, if you choose to trust that possession of 
>> a key provides an appropriate level of confidence in trustworthiness - 
>>> I consider /device identity/ an absolute critical part of our work. 
>>> It is a critical part of most EAT use cases such as enrollment of IoT 
>>> What is the definition of an “identity document”? Maybe you are 
>>> thinking of it specifically as what was defined for IEEE Dev ID. If I 
>>> recall, the identification claims for the device are in the subject 
>>> DN of an X.509 certificate.
>>> Seems like any EAT with an EUID in it could server well as an 
>>> identity document too. It provides signed, secured proof of the 
>>> identity of the device. It can include manufacturer info in addition 
>>> to the EUID. The EAT style identity could be as tiny as 150 bytes in 
>>> CBOR syntax. All you need to store on the device is the EUID and the 
>>> signing key. Maybe they are even deterministically KDF’d from the 
>>> same seed so you maybe you only need to store 32 bytes on the device.
>>> EAT’s mention of X.509 in 1.4.2 is as one of many ways to establish 
>>> key material so the remote / relying / verifying party can verify the 
>>> speaking the private key associated with the X.509 cert is used to 
>>> sign, not the X.509 cert or keys in the cert. The X.509 is only to 
>>> help the verifier find and verify the verification key. You might 
>>> even have a means to get it from some service based on a key ID and 
>>> not even store it on the device).
>>> It is an EAT design goal to keep /all/ the claims in the signed 
>>> payload. That includes identity of the device, identity of the 
>>> manufacturer and so on. That way you can use many different signing 
>>> schemes (ECDAA, symmetric key, non-X.509 public key, X.509 pubic key, 
>>> simple public key with just a key id…) with the same claims.
>>> LL
>>>> 1.4.2. talks about identity documents by mentioning "X.509 
>>>> certificate chains or something similar but different". But as you 
>>>> highlighted anything with regard to that is explicitly intended 
>>>> _not_ to go into the EAT claim set as content, but is stored on the 
>>>> thing (or maybe on a thing that signs "on behalf of" the thing the 
>>>> EAT is about?) and consequently is only used to potentially sign the 
>>>> EAT claim set (via COSE). Is that correct?
>>>>
>>>> As a result, an EAT would never be able to act as an identity 
>>>> document itself, but the key material that comes along with an x.509 
>>>> certificate (as one example of many highlighted) could be used to 
>>>> sign the EAT.
>>>>
>>>> similar but different" and the corresponding key material comes 
>>>> along with a certificate (as one example amongst others) to 
>>>> establish Attestation Provenance.
>>>>
>>>> Viele Grüße,
>>>>
>>>> Henk
>>>>
>>>>> Wasn’t saying there was ambiguity in the TCG case. Not being a 
>>>>> TCGer, was just was trying to understand what the TCG definition is.
>>>>> In EAT there is a strong desire to separate the signing key 
>>>>> material from UEID to have flexibility in the signing scheme. For 
>>>>> example FIDO and Android both have privacy-preserving schemes were 
>>>>> a signing key is shared by 100,000 devices. (Some use cases need 
>>>>> privacy, some don’t, perhaps because of legal agreements with 
>>>>> customers, and correlation between use cases and privacy schemes 
>>>>> can’t be counted on for high-volume devices like mobile phones).
>>>>>> <mailto:[email-masked]> <mailto:[email-masked]> 
>>>>>>  I don't think there's ambiguity in the TCG case...  current work 
>>>>>> in attestation focuses on using the 802.1AR DevID spec, which 
>>>>>> <mailto:[email-masked]> <mailto:[email-masked]> 
>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>>; Hannes 
>>>>>> Tschofenig <[email-masked] 
>>>>>> <mailto:[email-masked]> 
>>>>>> <mailto:[email-masked]> 
>>>>>> <mailto:[email-masked]> <mailto:[email-masked]> 
>>>>>> <mailto:[email-masked]>; Jeremy O'Donoghue 
>>>>>> <mailto:[email-masked]> 
>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>> different from others.  A way to get sharper about what a 
>>>>>> particular identity means is to describe the space and how the 
>>>>>> identifier selects in the space.  Here’s a few examples:
>>>>>>
>>>>>> - The space is humans that know a password. A password 
>>>>>> authenticator selects the humans that know the password. Typical 
>>>>>> authentication.
>>>>>> My understanding of the TCG world is that identities goes beyond 
>>>>>> any of the above because they include things like the version of 
>>>>>> the SW and configuration of the device. The identity is largely a 
>>>>>> hash of an identifier of the physical device, various SW 
>>>>>> components and various configuration states.  The point being that 
>>>>>> a change in any of these is a change in the security 
>>>>>> characteristics of the device and if it was trusted with a 
>>>>>> particular key or particular data in the past, that trust should 
>>>>>> be revoked until re established.
>>>>>>
>>>>>> So that said, many, perhaps most, use cases for EAT do not want 
>>>>>> this kind of device identity. It is not a prerequisite for 
>>>>>> trusting  claims coming from the device. In some cases this level 
>>>>>> of identity seems extremely disruptive as small SW upgrades could 
>>>>>> result in re enrollment of biometrics. We already are annoyed when 
>>>>>> we have to answer security questions when start using a service 
>>>>>> from a new device.
>>>>>>
>>>>>> device identity as criminals become more adept at forging 
>>>>>> EAT-style claims. (Today risk engines work off of unsecured 
>>>>>> browser parameters).
>>>>>>
>>>>>> EAT-style attestation. I will write some after some comments on 
>>>>>> this message.
>>>>>>
>>>>>> LL
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Profiles are the "things" that you can aggregate identity claims 
>>>>>>> in (in SACM these claims are "Target Endpoint Characteristics", 
>>>>>>> which are pretty much the same thing as Device Characteristics) - 
>>>>>>> and you use the Profiles to (re-)identify target endpoints.
>>>>>>>
>>>>>>> identifying claims "identity documents" might just end up in 
>>>>>>> making up another name for something that is effectively 
>>>>>>> composing identity documents anyways. If calling the same thing 
>>>>>>> something else helps in some way, I am all for it. But I am 
>>>>>>> really not sure.
>>>>>>>
>>>>>>>> * Attestation attributes have trust semantics (and trust 
>>>>>>>> semantics are interpreted through the eyes of the verifier). 
>>>>>>>> Identity attributes may also have trust semantics (in addition 
>>>>>>>> to identity semantics) hence can be regarded as playing a role 
>>>>>>>> in both identity and attestation. Since RATS should be 
>>>>>>>> interested primarily in trust semantics, it makes sense to 
>>>>>>>> understand, discuss and consider identity in terms of its trust 
>>>>>>>> semantics. Hence identity attributes are only interesting to 
>>>>>>>> RATS if they are useful for evaluating trust semantics.
>>>>>>>> * In a closed ecosystem, the trust characteristics and 
>>>>>>>> properties may be implied because there often exists out-of-band 
>>>>>>>> processes that ensure the characteristics are applied (for 
>>>>>>>> example, if an IT organization sets a policy that all asymmetric 
>>>>>>>> keys are to be hardened using a smartcard, they can apply a 
>>>>>>>> deployment process where the IT professional verifies the 
>>>>>>>> smartcard is used during enrollment.) But in a non-closed 
>>>>>>>> ecosystem, there isn't an assumption that out-of-band processes 
>>>>>>>> exist. Attestation attempts to make explicit what otherwise is 
>>>>>>>> implicit and therefore subject to misinterpretation if the 
>>>>>>>> verifier, relying party and attester are not part of the same 
>>>>>>>> closed ecosystem. Implicit attestation therefore can lead to 
>>>>>>>> semantic confusion if we're not careful. Therefore, the rigor of 
>>>>>>>> treating implicit attestation claims (assertions assumed to 
>>>>>>>> exist but not explicitly named) should nevertheless be defined 
>>>>>>>> explicitly. Then, if there is a need for implicit attestation, 
>>>>>>>> the specifications that describe them can describe them in terms 
>>>>>>>> of an explicit definition.
>>>>>>>> * In the context of asserting trust characteristics, the 
>>>>>>>> verifier needs to know that a set of characteristics applies to 
>>>>>>>> the instance of the endpoint being evaluated (aka the attester). 
>>>>>>>> (Otherwise a MITM could supply characteristics that may be 
>>>>>>>> valid, but don’t apply to the specific instance). Consequently, 
>>>>>>>> it makes sense to consider that *attestation* keys are needed to 
>>>>>>>> <mailto:[email-masked]> 
>>>>>>>>         I have been working on identity management for many 
>>>>>>>> years (partially because of my OAuth co-chair role) and I have 
>>>>>>>> noticed that the use of the term "identity" tends to confuse 
>>>>>>>> more than it helps (even more so when the term is applied to 
>>>>>>>> devices and software rather than humans).
>>>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>> On 
>>>>>>>> Behalf Of Smith, Ned
>>>>>>>> <mailto:[email-masked]> <mailto:[email-masked]> 
>>>>>>>> <mailto:[email-masked]>; Jeremy O'Donoghue 
>>>>>>>> <mailto:[email-masked]> 
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>         I agree with Henk's observation that there is 
>>>>>>>> opportunity to find common ground on identity as identity can be 
>>>>>>>> a collection of attributes, that if signed, becomes a set of 
>>>>>>>> verifiable claims (about identity attributes). Attestation has a 
>>>>>>>> similar structure in that it consists of a set of attributes, 
>>>>>>>> that if signed becomes a set of verifiable claims. The main 
>>>>>>>> difference between identity and attestation attributes is 
>>>>>>>> whether the attribute semantically relate to trust (vs. 
>>>>>>>> identity). For example, claims of security certification 
>>>>>>>> compliance resonates as attestation.
>>>>>>>> attributes in such a way that the combination uniquely 
>>>>>>>> identifies an entity. But that doesn't make it an identity 
>>>>>>>> system per se and shouldn't cause a conflict in charter goals 
>>>>>>>> with respect to other identity focused efforts in IETF.
>>>>>>>> <mailto:[email-masked]> <mailto:[email-masked]> on 
>>>>>>>> behalf of [email-masked] 
>>>>>>>>> to know the characteristics of a device by issuing to the 
>>>>>>>>> device a public key certificate which will only be issued to 
>>>>>>>>> the device if it fulfills an expected set of functionalities.
>>>>>>>>> This is indeed a possible way to address the problem, but 
>>>>>>>>> suffers from
>>>>>>>>>>> <mailto:[email-masked]> <mailto:[email-masked]> 
>>>>>>>>>>> on behalf of [email-masked] 
>>>>>>>>>>>> <mailto:[email-masked]>
>>>>>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>>>> 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: Laurence Lundblade <[email-masked]>
Date: Sat, 20 Oct 2018 20:51:52 +0530

> On Oct 20, 2018, at 8:26 PM, Henk Birkholz <[email-masked]> wrote:
> 
> Hello Laurence,
> 
>  And I am perplexed how you think I was implying that EAT or CoID are insecure. How did I make the impression to have suggested that?

You have characterized EAT as only proof-of-possesion. It is not.

> 
> Wrt the "verification keys" I am not so sure, what the diagram means by that. With an asymmetric key-pair these would probably be public keys to check the signature by (I assume)?

It is an open-ended range of things:
An ECDAA interaction with service (Maybe like Intel’s)
A verification request of an Android Attestation from a Google Service
An IEEE-802.1AR CA and Sub-CAs (mostly standard X.509)
A public key fetch based on any reasonable / useful key ID (e.g. Subject Key ID)
A submission of the EAT token signed by a symmetric key to a service that verifies it (and rather carefully protects the private verification keys with high quality HSMs)
A redirect through a privacy CA
Some custom manufacturer defined scheme

I strongly believe this flexibility is necessary for real deployments especially for the high investment already made by platform and chip vendors.

There is an assumption that the device manufacturer will only put attestation keys in devices that are configured correctly. Typically the attestation key will only be usable to sign attestation if the device booted code that was verified, debug was turned off and such. (I know TCG does this in a more elaborate thorough way, and that is good and well and can be put to use with EAT for appropriate use cases). 

LL

---

From: Henk Birkholz <[email-masked]>
Date: Sat, 20 Oct 2018 16:43:38 +0100

Hello Laurence,

what I understood now, I think, is that the processes that will eventually make use of EATs - "in the bigger picture" - are intended to be based on more than proof-of-possession.
The EAT that is the signed claim set is relying on the "assumption that the device manufacturer will only put attestation keys in devices that are configured correctly".

And that is exactly what I meant. The key material deployed on the thing has meaning: if it is there, you trust the assumption that the thing is configured correctly.

Do we agree on this? :-)

The reoccurring reference to TCG seems to exclude other more thorough approaches on how to conduct remote integrity verification a bit, I think. I am carefully highlighting this, because the reasoning behind an IETF WG is the demand for network protocols that are able to consolidate the different "inbox-api" and "out-of-band" concepts used in various domains.

Viele Grüße,

Henk

On October 20, 2018 4:21:52 PM GMT+01:00, Laurence Lundblade <[email-masked]> wrote:
>>  And I am perplexed how you think I was implying that EAT or CoID are
>insecure. How did I make the impression to have suggested that?
>
>> Wrt the "verification keys" I am not so sure, what the diagram means
>by that. With an asymmetric key-pair these would probably be public
>keys to check the signature by (I assume)?
>
>A submission of the EAT token signed by a symmetric key to a service
>that verifies it (and rather carefully protects the private
>verification keys with high quality HSMs)
>I strongly believe this flexibility is necessary for real deployments
>especially for the high investment already made by platform and chip
>vendors.
>
>There is an assumption that the device manufacturer will only put
>attestation keys in devices that are configured correctly. Typically
>the attestation key will only be usable to sign attestation if the
>device booted code that was verified, debug was turned off and such. (I
>know TCG does this in a more elaborate thorough way, and that is good
>and well and can be put to use with EAT for appropriate use cases). 
>
>LL

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 20 Oct 2018 21:29:57 +0530

> On Oct 20, 2018, at 9:13 PM, Henk Birkholz <[email-masked]> wrote:
> 
> Hello Laurence,
> 

Seems to me that there is always some implied trust in the behavior of some part of the device you put the key in. It might be a tiny bit of HW, but it is something. No matter how many layers of measurement and roots-of-trust there are, the bottom that hold the key has to be trusted to have some behavior before you put the key in during manufacture.

> Do we agree on this? :-)

Well probably, but we haven’t spend enough time together yet to know for sure. :-)

> The reoccurring reference to TCG seems to exclude other more thorough approaches on how to conduct remote integrity verification a bit, I think. I am carefully highlighting this, because the reason…

I added a few lines below. 

Not sure what an inbox-api and such are yet...

LL

>> On Oct 20, 2018, at 8:26 PM, Henk Birkholz <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hello Laurence,
>> 

* A RATS Procedure based on TCG stuff
* A RATS Procedure not using TCG stuff

---

From: Denis <[email-masked]>
Date: Mon, 22 Oct 2018 12:01:41 +0200

Hello  Henk,

draft-birkholz-core-coid-00 states:*
*

    **An identity document - a certificate - can be conveyed to other
    system entities in order to prove the identity of the owner of the
    identity document.

The wording "identity document" should not be used in the charter, since 
the most important characteristic when using attestations is to be able 
to know
the characteristics of a device, i.e.that it operates as expected, does 
what is required and does not do other (bad) things. Knowing the 
identity of a device
(e.g. the name of its manufacturer and a unique serial number given by 
that manufacturer) may certainly be useful in some cases, but it is not 
always necessary,
nor desirable (e.g. because of privacy issues).

draft-birkholz-core-coid-00 then states:

    "Trust in the proof can be established by mutual trust of the
    provider and assessor of the identity in a third party verification
    (TVP) provided,
    for example, by a certificate authority (CA) or its subsidiaries
    (sub CA)".

A trust relationship is always unilateral : someone trusts somebody for 
something. A reciprocity in a trust relationship is never implied.

A given device MAY disclose /more than one/ attestation, for example:

  * an attestation where only the characteristics of the device are
    certified, or
  * an attestation where both the characteristics of the device and the
    manufacturer identity are certified, or
  * an attestation where the characteristics of the device, the
    manufacturer identity and a unique device serial number are certified.

Such a case could be modeled by using a sequence of three claims 
included in the attestation, namely in that order :
(1) the characteristics of the device, (2) the manufacturer identity and 
(3) the device serial number which would be disclosed by the device
to a verifier "when appropriate".

Another example: a given device MAY disclose /more than one/ attestation:

  * an attestation where only the characteristics of the hardware device
    are certified, or
  * an attestation where both the characteristics of the hardware device
    and of the software running on top of that hardware device are
    certified,

In the general case, an ordered set of claims or a SEQUENCE of claims 
can be supported. This is currently not apparent on the current proposals.

Denis

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 22 Oct 2018 12:26:37 +0200

Hello Denis,

I have to admit that I disagree to some degree here. De facto, identity 
documents are used today as a basis for Attestation Provenance - they 
are either deployed with key material on things or they are requested 
based on key material.

That is not always the best solution, it is not a MUST, but it is a 
widely spread common method that we cannot ignore, I am afraid. That 
said, the deployment of key material or identity documents is 
out-of-scope of this phase for now ("may be subject to change"). We have 
to address "what has to be / can be" on the thing, though, in order to 
have a believable source for knowledge about Attestation Provenance.

Also, an IEEE 802.1AR DevID is an example of an identity document that 
is widely used and about device characteristics. I am aware that a lot 
of very... creative things have been done to x.509 in the last decades, 
some of them quite arcane. There might be better ways to address this... 
solution space, CoID is a first step into that direction.

Having said that, CoID is not intended to be a RATS WG document and I 
would very much like to address your general comments with respect to 
that draft - but not in this scope right now. Would that be okay?

Viele Grüße,

Henk

> nor desirable (e.g. because of privacy issues).

Very correct, this will be part of deliverable three. A few stakeholders 
argue that network equipment is not as prone to privacy requirements as 
would be a end-user device. The charter includes to address this topic, 
but is not intended to bias the outcome of an analysis.

>     for example, by a certificate authority (CA) or its subsidiaries

The mutual trust assumption is a tad bit more complex and I cannot go 
into detail right now, but we can and will address comments on this 
later due to start of moratorium at EoD.

>     manufacturer identity and a unique device serial number are certified.

This will eventually be part of the templates that are part of 
deliverable two.

> can be supported. This is currently not apparent on the current proposals.

Claim Semantics will be part of deliverable one (maybe two, due to 
architecture).

Viele Grüße,

Henk

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 22 Oct 2018 13:46:00 +0200

On Oct 22, 2018, at 12:01, Denis <[email-masked]> wrote:
> 
> The wording "identity document" should not be used in the charter, since the most important characteristic when using attestations is to be able to know 
> the characteristics of a device, i.e. that it operates as expected, does what is required and does not do other (bad) things. Knowing the identity of a device 
> (e.g. the name of its manufacturer and a unique serial number given by that manufacturer) may certainly be useful in some cases, but it is not always necessary, 

Henk forecasted that I would say “the usual identity confusion” earlier…

This is indeed the usual identity confusion.

RFC 4949 says:

   $ identity
      (I) The collective aspect of a set of attribute values (i.e., a
      set of characteristics) by which a system user or other system
      entity is recognizable or known. (See: authenticate, registration.
      Compare: identifier.)

In other words: A set of claims.

When I buy cigarettes from a vending machine in Germany (I don’t, so please excuse inaccuracies), it needs an identity document with exactly one claim on it:  age ≥ 18 years.  For a cash buyer, that is the entire identity the vending machine cares about.  (Obviously, the asserter of that claim needs to be authorized to do so by the operator of a vending machine — that set of authorizations is probably something that is honed by a procession of court cases.)

Since even the identity of the entity authorized to make a claim may be subject to privacy, the actual identity may be mixed together through a number of verification services.  It is useful to have a protocol that can be used to convey identities through such a mixer; the actual relying party may not need to understand much about what is happening as long as it trusts the verification services.  Or, in the above example, the vending machine may use a claim from a bank card that I’m ≥ 18yo, without understanding how the bank came to that conclusion.

Maybe we should replace the term “identity” with “set of claims useful for recognizing something or somebody”, hmm, SOCUFRSOS?  “Identity” might be easier to say.

I’m not sure I understand the part about SEQUENCE — I don’t see any (ordered) sequences in the rest of your message.
What I do see is claims that have different kinds; and that is of course important.  It is also sometimes important that we can have multiple claims of the same kind, something that JWTs are not very good at yet (we could fix that in CWT).

Grüße, Carsten

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Mon, 22 Oct 2018 13:14:30 +0000

This is a very useful contribution, Laurence.

The current draft text is too strongly biased towards attestation based on measurement, and does not adequately cover other mechanisms which are already broadly deployed in proprietary form, and which should be supported in an interoperable standards based manner.

From my perspective, there are a number of issues which lead to the need for charter text which is more inclusive of different approaches to attestation:

  *   TPM and systems based on measured file execution procedures have very limited presence in the mobile ecosystem, and any attestation standard of interest needs to be useful in the mobile space and highly constrained (microcontroller-class and smaller) IoT if we are to avoid fragmentation in future. The flexibility of EAT is a great strength here.
  *   In devices where the threat model may include the device owner - such as many mobile and IoT devices - attestation bound to the REE, as is typical in the TPM use-case, has some challenges. https://www.blackhat.com/docs/eu-17/materials/eu-17-Mulliner-Inside-Androids-SafetyNet-Attestation.pdf provides an example which is in the public domain.
  *   Systems based on run-time (as opposed to boot time) integrity measurement address trustworthiness over time - see https://dl.acm.org/citation.cfm?id=2660350. There are commercial examples of such systems in mass production on several different mobile SoCs. Information available to the public includes https://seap.samsung.com/faq/what-knox-tima-keystore. Eric Voit has already shared that such systems are also deployed in the network infrastructure space, so it seems to me that the charter text should cover this case.
  *   As noted in previous mail to the list, there is ongoing work in GlobalPlatform which plans to make use of the approach described in the EAT draft. I also have good reason to believe that other industry bodies are considering this approach, which provides a great opportunity to promote interoperability through the output of the eventual WG.

As it stands, the text is too specific to a particular approach for me to be able to support it. That said, and wishing to be constructive, I have attempted to merge the current charter text (commit 267b166) with Laurence' contribution below. Black text is the current draft; red text is mine and blue text is from Laurence.

Remote ATtestation ProcedureS (RATS) are included in network protocols to provide the basis for establishing claims about a device in a trustworthy manner exchanges with a device, such claims may include, but are not limited to, device identity, manufacturing origin, system integrity, configuration, operational state and measurements of steps which led to the operational state. RATS expose such device characteristics in the form of trusted claim sets which allow remote parties to evaluate (based on Proof-of-Possession) to detailed Attestation Evidence (Proof-of-Protection) that enable a Verifying Parties to retrace every step that led to its current Operational State. A consequence of this retracing is that it is possible to appraise the trustworthiness of a device. RATS provide evidence that a device supports a certain set of operations and functions and/or that it is actually the exact device it is supposed to be (Attestation Provenance) via identity documents or passes. RATS ensure that the information conveyed is unique, complete, and fresh (exposing tampering, replay, and/or relay attacks).

RATS may include definition of procedures by which a remote party evaluates certain claims. For example, how some measurement or other claims are compared to expected values to evaluate the trustworthiness of the device. RATS further supports Various Roots of Trust (e.g. for Measurement, for Reporting, or for Verification) provide the foundation to enable Implicit Remote Attestation (the fact that a secret key is accessible implies a specific meaning and specific defined set of characteristics which therefore need not be supplied explicitly). assertions are optional) and Explicit Remote Attestation, which uses the  output of measured file execution as Attestation Evidence which can be used (along with event log details) to ratify that the device is actually a Trusted System.

RATS may include the definition of new protocols and/or the definition of secured data structures (e.g. signed) that are carried in existing protocols.

RATS is general purpose and aims to address a broad range of use-cases including online banking, payment transactions, critical infrastructure, network security functions, constrained-node devices, business and government enterprises and or the management of end-user devices, including scenarios where device and/or end-user privacy are required.

Like Laurence, I would prefer a new name to reflect the fact that we are merging different contributions, but I have retained RATS in the above to focus on the changes to the text.

Best regards
Jeremy

On 20 Oct 2018, at 06:54, Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:

Notes:

  *   I have avoided the use of the formally defined terms in the introduction so it can stand more on its own, is easier to understand and is less presumption about architectures and designs. Seems like it is work for the WG to define the terms and create the designs.
  *   My use of the lower case “device”, “claim” and “remote party” are just as broad concepts to be able to get the general idea across. The WG documents should use the more formal and specific definitions.
  *   Hope I’ve covered both EAT and RATS concepts here. It was my goal.
  *   While I used the term RATS, I still want the WG name change to CREATE.

LL

On Oct 11, 2018, at 10:19 PM, Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

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

Viele Grüße,

Henk

---

From: Michael Richardson <[email-masked]>
Date: Mon, 22 Oct 2018 17:01:57 -0400

> The current draft text is too strongly biased towards attestation based
    > on measurement, and does not adequately cover other mechanisms which
    > are already

But, it's for the charter, for the WG, it's not a treatise on attestation
itself.

This is all supposed to be *meta* text about attestation, about what we want
to say about attestation in the documents, not about what attestation is.

Please go read some other IETF charters:

https://datatracker.ietf.org/wg/6lo/about/
https://datatracker.ietf.org/wg/6tisch/about/
https://datatracker.ietf.org/wg/suit/about/

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

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Tue, 23 Oct 2018 14:40:26 +0000

On 22 Oct 2018, at 22:01, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Jeremy O'Donoghue <[email-masked]<mailto:[email-masked]>> wrote:
This is a very useful contribution, Laurence.

Fair comment.

We have two existing proposals - EAT and RATS - which address a similar problem space but using different mechanisms. While I believe the RATS and EAT contributors are in broad agreement that there is significant benefit in bringing both work streams under a single umbrella, trying to properly incorporate EAT through incremental modification to the draft RATS WG charter text is proving challenging.

The below probably diverges too far from the current text for some tastes, but it may address your point and provide a basis for discussion (at this point the GitHub draft<https://github.com/ietf-rats/charter/blob/RC2/ietf-rats-charter.md> seems a long way behind the list). It is deliberately significantly shorter than the current draft - I have tried to re-use as much existing text as possible, but it is heavily re-organised and abridged.

I have taken on board the comment from Carsten that perhaps a minimum level of terminology is acceptable in charter text, but deliberately tried to keep the language simple and fairly generic to enable the proper work of terminology definition to take place in the requirements document as you suggest.

Introduction

------------

Remote attestation procedures can be incorporated in network protocols to
provide the basis for establishing claims about an entity in a trustworthy
manner. Such claims may include, but are not limited to, device identity,
manufacturing origin, system integrity, configuration, operational state and
measurements of steps which led to the operational state. Such procedures
expose entity characteristics in the form of claim sets which allow remote
parties to establish the trustworthiness of a device, provide evidence that a
particular set of operations and functions are supported and/or that the
entity is actually what it claims to be.

In the absence of such procedures, while domain-specific attestation
mechanisms such as TCG TPM, FIDO Alliance attestation and Android Keystore
attestation exist, there is no common way for a remote party to tell if data
originates from a trustworthy device (e.g. a Trusted System designed to
support a specific set of operations/functionalities) or not.

The following minimal terminology is defined for the purposes of clarifying the
Working Group charter text:

- attestation: a set of claims which can be verified as originating in an
          entity.

- claim:  as defined in RFC7519.

- entity: a device or device sub-module that can generate a claim or set of
          claims which can be verified by a remote party.

- remote party: an actor remote from an entity that wishes to verify whether
          a claim or set of claims originated in a given entity.

Description of the Working Group

--------------------------------

The Working Group will define:

- Standardized and interoperable mechanisms to establish a sufficient level
  of confidence that data originates from a trustworthy entity designed to
  support a specific set of operations/functionalities.
- Standardized and interoperable mechanisms building on (1) to allow remote
  parties to know the provenance and characteristics of an entity that may be
  requesting services.

The Working Group will identify security goals which it expects a trustworthy
execution context to address, which will assume the presence of Roots of
Trust (as defined by NIST [SP800-164]). The detailed specification of such
contexts is out of scope.

The Working Group will maintain close relationships with bodies undertaking
complementary work streams in the area of remote attestation such as
GlobalPlatform, Trusted Computing Group and FIDO Alliance.

The Working Group will cooperate with the TEEP Working Group, which may
generate requirements for claims relevant to TEE.

Work Items

----------

The Working Group will develop specifications supporting the creation of
interoperable remote attestation procedures for entities which incorporate
Roots of Trust. The main deliverables are as follows.

- Produce a requirements document establishing a common vocabulary for remote
  attestation, identifying mechanisms which will be supported for establishing
  trust between an entity and a remote party, and enumerating sample use-cases
  for remote attestation.

- Produce specification text defining interoperable cross-platform claims which
  provide information about an entity in support of the required use-cases, and
  extending the set of claims defined in RFC7519 and RFC8392. The specification
  will describe the syntax for each claim in at least the following formats:
    - CBOR [RFC7049]
    - JSON [RFC7159]
    - YANG [RFC6020]

- Produce specification text defining procedures and corresponding architectures
  supporting verification of claims within an attestation based on measured file
  execution procedures and supporting:
    - Explicit attestation wherein a set of claims is transported in the attestation;
    - Implicit attestation wherein a set of claims is implied by possession of a secret.

- Produce specification text defining procedures and corresponding architectures
  supporting verification of claims encapsulated in:

    - CBOR Web Token structures [RFC8392]
    - JSON Web Token structures [RFC7519]

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

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

  *   A claims specification common to RATS and EAT with separate RATS and EAT procedure specifications.
  *   A claims specification also incorporating EAT procedures and a separate RATS procedure specification. This would be my preferred option.
     *   I believe there are very few procedures needed for EAT other than the possible need to support a nonce to ensure freshness

Jeremy

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 23 Oct 2018 17:10:32 +0000

SP800-164 is a useful reference for both concepts and terminology. In particular it follows terminology conventions that slightly differ from some terms suggested by this list. In particular,

- attestation: a set of claims which can be verified as originating in an entity.
SP800-164.attest: “Root of Trust for Measurement (RTM)—provides trusted measurement functions to be used by assertions that are protected via the RTI and attested to with the RTR.” [nms] Note: SP800-164.assertion appears to be synonymous with SP800-164.claim and SP800-164.evidence. The discussion on roots-of-trust makes it clear that the claims (evidence | assertions) are verifiable to have originated from a root-of-trust.

- claim:  as defined in RFC7519.
SP800-164.claim: “A device with integrity has the ability to assert specific claims about its configuration, health, or operating status in a way that Information Owners can confidently rely upon to make decisions about interacting with the device and Device Owner.” [nms] The SP800-164.claim doesn’t appear to conflict with RFC7519.claim semantics; although RFC7519.claim also defines a particular encoding scheme. Whereas SP800-164.claim is conceptual (only). It should be possible to allow for the use of “claim” in contexts that chose to define alternative encodings such as ASN.1. Note: SP800-164.assertion appears to be synonymous with SP800-164.claim and SP800-164.evidence.

- entity: a device or device sub-module that can generate a claim or set of
          claims which can be verified by a remote party.
SP800-164.root of trust: “RoTs are security primitives composed of hardware, firmware and/or software that provide a set of trusted, security-critical functions.” [nms] A root of trust appears to be a “sub-module” of a “device”. It might have been more correct for the suggested definition for attestation to have used the term “sub-module” instead of “entity” given SP800-164.root-of-trust term most closely resembles the suggested “sub-module”. Possibly it makes sense to use the term “device” to refer to a device and “root-of-trust” to refer to a “sub-module”?

- entity: a device or device sub-module that can generate a claim or set of
          claims which can be verified by a remote party.
SP800-164.entity: “An Information Owner is an entity whose…” and “a Device Owner is an entity that…” [nms] Since there isn’t a suggested alternative for SP800-164.entity, possibly it makes sense not to overload “entity” with “device” as entity also can refer to a person or organization.

- remote party: an actor remote from an entity that wishes to verify whether
          a claim or set of claims originated in a given entity.
SP800-164 doesn’t use the term “remote party” instead it uses a couple of terms that potentially could be used in place of “remote party”. These are “verifier” and “relying party”.

SP800-164.verifier: “The RTR will apply integrity and non-repudiation protections on the data so that subsequent software agents cannot alter or replay the data without detection. The established identities allow verifiers to verify the source of the data uniquely and without repudiation.”

SP800-164.relying party: “A device has integrity if its software, firmware, and hardware configurations are in a state that is trusted by a relying party.”

Since it makes sense for IETF attestation efforts to be aligned with accepted and cited NIST SP800-164 document. Possibly, the charter can use terminology introduced there and seek not to redefine or clarify. As long as the charter terminology is aligned with that of SP800-164, it should be possible for the Attestation BOF to discuss a WG charter without needless confusion and misinterpretation due to inconsistent and alternative use of terminology.

-Ned

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 23 Oct 2018 18:04:08 +0000

Hi Jeremy,

Thanks for taking a cut at this charter simplification.  There are a few areas covered within the GitHub Goals<https://github.com/ietf-rats/charter/blob/RC2/ietf-rats-charter.md> which I can't easily map to your text below.  Could you talk about how these elements are covered (or not)?   For context, I am working from the perspective of remote attestation application<https://www.cisco.com/c/dam/en/us/td/docs/cloud-systems-management/application-policy-infrastructure-controller-enterprise-module/1-5-x/integrity_verification/user-guide/Cisco_Integrity_Verification_Application_APIC-EM_User_Guide_1_5_0_x.pdf> developer trying to standardize the interfaces between a controller (which is acting as a claim verifier) and a network element (which includes TCG based subsystems.)

For my application to work properly, there are several things needed within a network controller to validate the asserted claims coming out of a router.  These include:

*       How do we expose the attestation evidence which can be used to validate asserted claims?

*       How do we know which root of trust which was used to generate the attestation evidence (e.g., application event logs), and how does a verifier differentiate this from the root-of-trust which asserts claims made upon this evidence?

*       What entities are allowed to read the info asserted claims?  What subset of these can see the raw attestation evidence?

These questions are significant because routers/switches are not monolithic devices.  In fact, they are composed of subsystems with different levels of trustworthiness.  As the IETF often aims at protocol specifications at the inter-device level, I am looking for coverage of such questions in the charter.

Thanks,
Eric

From: Jeremy O'Donoghue, October 23, 2018 10:40 AM

Fair comment.

Introduction
------------

Work Items
----------

Jeremy

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Oct 2018 19:10:13 -0400

Jeremy, that's awesome work.
Thank you very much for these edits.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Oct 2018 19:13:35 -0400

Eric Voit (evoit) <[email-masked]> wrote:
    > Could you talk about how these elements are covered (or not)? For
    > context, I am working from the perspective of remote attestation
    > application developer trying to standardize the interfaces between a
    > controller (which is acting as a claim verifier) and a network element
    > (which includes TCG based subsystems.)

These are good questions, but are they questions that the *CHARTER* of
the *WORKING GROUP* needs to answer?  Sure the *WORKING GROUP* needs to
answer them, but please remember that the charter is META.

    > · How do we know which root of trust which was used to generate the
    > attestation evidence (e.g., application event logs), and how does a

Good question... put it in the Internet Draft.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 23 Oct 2018 23:20:22 +0000

> From: Michael Richardson, October 23, 2018 7:14 PM
> 
> These are good questions, but are they questions that the *CHARTER* of the
> *WORKING GROUP* needs to answer?  Sure the *WORKING GROUP* needs to

If the WG needs to answer them, that is great.  My concern was that I didn't see these types of questions falling under the charter text proposed by Jeremy.  Maybe it is there, but I didn't see it.  Hence my question.

Eric

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Wed, 24 Oct 2018 08:46:18 +0000

Thanks for this analysis.

I agree - it makes sense to use NIST terminology in the charter text proposal. I'll have a go at that shortly (while trying to address some of the other comments as well).

Jeremy

On 23 Oct 2018, at 18:10, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Wed, 24 Oct 2018 11:36:38 +0000

HI Eric,

On 23 Oct 2018, at 19:04, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jeremy,

Thanks for taking a cut at this charter simplification.  There are a few areas covered within the GitHub Goals<https://github.com/ietf-rats/charter/blob/RC2/ietf-rats-charter.md>which I can’t easily map to your text below.  Could you talk about how these elements are covered (or not)?   For context, I am working from the perspective of remote attestation application<https://www.cisco.com/c/dam/en/us/td/docs/cloud-systems-management/application-policy-infrastructure-controller-enterprise-module/1-5-x/integrity_verification/user-guide/Cisco_Integrity_Verification_Application_APIC-EM_User_Guide_1_5_0_x.pdf> developer trying to standardize the interfaces between a controller (which is acting as a claim verifier) and a network element (which includes TCG based subsystems.)

•       How do we expose the attestation evidence which can be used to validate asserted claims?

I think that the need to address this is covered sufficiently for a WG Charter by the statement "Produce a specification defining procedures and corresponding architectures  supporting verification of Claims".

If verification of Claims requires specific forms of attestation evidence (e.g. a set of measurements generated by a TPM), then it is properly a matter for an RFC to specify this, as Michael suggests.

•       How do we know which root of trust which was used to generate the attestation evidence (e.g., application event logs), and how does a verifier differentiate this from the root-of-trust which asserts claims made upon this evidence?

Again, I think this is a matter for specification rather than charter. There are a number of different ways in which Roots of Trust can be realised and many possible device architectures. The EAT draft allows one RoT to include an attestation generated by a different RoT, for example. I believe the RATS draft also provides technical mechanisms by which this can be achieved.

•       What entities are allowed to read the info asserted claims?  What subset of these can see the raw attestation evidence?

I agree with you here as the same issue applies to claims with privacy implications. As an example, I may wish to present a unique device ID to a social media website but not my location.

I have added bullet point 3 to the draft - which I will post separately. Let me know if you think this addresses your concerns sufficiently.

Best regards
Jeremy

Thanks,
Eric

Fair comment.

Introduction
------------

Work Items
----------

Jeremy

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 24 Oct 2018 14:55:41 +0200

Hi all,

based on Jeremy's proposal we did another big refactoring - also tried 
to address everybody's comments, inputs and concerns.

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

Please note that this charter text is intended to be a first phase, 
which is the reason why, for example, there still is no mentioning about 
provisioning, profiles, or more details about out-of-band dependencies.

As Michael highlighted, most types of content belong into drafts. That 
said - on one hand the charter is a kind of "contract" wrt to scope and 
output, on the other hand we do not want to boil the ocean (at least not 
all at once...).

Viele Grüße,

Henk

On 10/24/2018 01:36 PM, Jeremy O'Donoghue wrote:
>> Thanks for taking a cut at this charter simplification.  There are a 
>> few areas covered within theGitHub Goals 
>> <https://github.com/ietf-rats/charter/blob/RC2/ietf-rats-charter.md>which 
>> I can’t easily map to your text below.  Could you talk about how these 
>> elements are covered (or not)?   For context, I am working from the 
>> perspective ofremote attestation application 
>> <https://www.cisco.com/c/dam/en/us/td/docs/cloud-systems-management/application-policy-infrastructure-controller-enterprise-module/1-5-x/integrity_verification/user-guide/Cisco_Integrity_Verification_Application_APIC-EM_User_Guide_1_5_0_x.pdf>developer 
>> trying to standardize the interfaces between a controller (which is 
>> acting as a claim verifier) and a network element (which includes TCG 
>> based subsystems.)
>> For my application to work properly, there are several things needed 
>> within a network controller to validate the asserted claims coming out 
>> of a router.  These include:
>> ·How do we expose the attestation evidence which can be used to 
>> validate asserted claims?
> 
> I think that the need to address this is covered sufficiently for a WG 
> Charter by the statement "Produce a specification defining procedures 
> and corresponding architectures  supporting verification of Claims".
> 
> If verification of Claims requires specific forms of attestation 
> evidence (e.g. a set of measurements generated by a TPM), then it is 
> properly a matter for an RFC to specify this, as Michael suggests.
> 
>> ·How do we know which root of trust which was used to generate the 
>> verifier differentiate this from the root-of-trust which asserts 
>> claims made upon this evidence?
> 
> Again, I think this is a matter for specification rather than charter. 
> There are a number of different ways in which Roots of Trust can be 
> realised and many possible device architectures. The EAT draft allows 
> one RoT to include an attestation generated by a different RoT, for 
> example. I believe the RATS draft also provides technical mechanisms by 
> which this can be achieved.
> 
>> ·What entities are allowed to read the info asserted claims?  What 
>> subset of these can see the raw attestation evidence?
>> These questions are significant because routers/switches are not 
>> monolithic devices.  In fact, they are composed of subsystems with 
>> different levels of trustworthiness. As the IETF often aims at 
>> protocol specifications at the inter-device level, I am looking for 
>> coverage of such questions in the charter.
> 
> I agree with you here as the same issue applies to claims with privacy 
> implications. As an example, I may wish to present a unique device ID to 
> a social media website but not my location.
> 
> I have added bullet point 3 to the draft - which I will post separately. 
> Let me know if you think this addresses your concerns sufficiently.
> 
> Best regards
> Jeremy
> 
>> Thanks,
>> Eric
>> *From:*Jeremy O'Donoghue, October 23, 2018 10:40 AM
>>
>>     Jeremy O'Donoghue <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>> We have two existing proposals - EAT and RATS - which address a 
>> similar problem space but using different mechanisms. While I believe 
>> the RATS and EAT contributors are in broad agreement that there is 
>> significant benefit in bringing both work streams under a single 
>> umbrella, trying to properly incorporate EAT through incremental 
>> modification to the draft RATS WG charter text is proving challenging.
>> The below probably diverges too far from the current text for some 
>> tastes, but it may address your point and provide a basis for 
>> discussion (at this point the GitHub draft 
>> <https://github.com/ietf-rats/charter/blob/RC2/ietf-rats-charter.md> seems 
>> a long way behind the list). It is deliberately significantly shorter 
>> than the current draft - I have tried to re-use as much existing text 
>> as possible, but it is heavily re-organised and abridged.
>> I have taken on board the comment from Carsten that perhaps a minimum 
>> level of terminology is acceptable in charter text, but deliberately 
>> tried to keep the language simple and fairly generic to enable the 
>> proper work of terminology definition to take place in the 
>> requirements document as you suggest.
>>
>> Introduction
>>
>> ------------
>>
>> It seems to me that there are two ways to produce the main 
>> specification deliverables. I have deliberately left the text above 
>> slightly vague on this.
>>
>>   * A claims specification also incorporating EAT procedures and a
>>     separate RATS procedure specification. This would be my preferred
>>     option.
>>
>>       o I believe there are very few procedures needed for EAT other
>>         than the possible need to support a nonce to ensure freshness
>>
>> Jeremy
>>
>>
>>     Michael Richardson <[email-masked]
>>     <mailto:[email-masked]>>, Sandelman Software Works

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Wed, 24 Oct 2018 12:58:19 +0000

Thanks for the feedback on my text. The text below makes the following changes, addressing comments from list contributors:

  *   aligns more closely with NIST terminology - note that NIST does not have a clear set of definitions for all of the terminology used, so some of the text is my interpretation of the content of SP 800-64, aided by the input from Ned.
  *   adds text addressing the possible need to protect come claims from unauthorised disclosure for privacy or security reason
  *   adds text supporting ASN.1 as a syntax for claims.

I have used some simple markup to identify the changes.

Introduction
------------

Remote Attestation procedures can be incorporated in network protocols to
provide the basis for establishing Claims about a Device in a trustworthy 
manner. Such Claims may include, but are not limited to, device identity, 
manufacturing origin, system integrity, configuration, operational state and 
measurements of steps which led to the operational state. Such procedures 
expose Device characteristics in the form of Claim sets which allow a Relying 
Party, using a Verifier, to establish the trustworthiness of a Device, provide
evidence that a  particular set of operations and functions are supported and/or
that the Device is actually what it declares itself to be.

In the absence of such procedures, while domain-specific attestation mechanisms
such as TCG TPM, FIDO Alliance attestation and Android Keystore attestation
exist, there is no common way for a Relying Party to tell if Claims originate
from a trustworthy device (e.g. a trusted system designed to support a specific
set of operations/functionalities) or not.

Terminology from NIST [SP800-64] is used with the following definitions in this
charter.

- Attestation: a set of Claims for which a Verifier can establish the source
  uniquely and without repudiation.
- Claim: A reliable assertion about the trusted state of a Device such as
  its configuration, health, or operating status. Also used in [RFC7519].
- Device: an object having some specific purpose, or a sub-module of such an
  object, that can generate a Claim or set of  Claims whose source and integrity
  can be established by a Verifier.
- Relying Party: an actor remote from a Device that wishes to verify whether a
  Claim or set of Claims originated in a given Device.
- Verifier: an actor trusted by the Relying Party to establish the source of a
  Claim or set of Claims uniquely and without repudiation,
- Root of Trust: a security primitive providing a set of trusted,
  security-critical functions.

1. Standardized and interoperable mechanisms to establish a sufficient level of
   confidence that Claims originate from a trustworthy Device designed to 
   support a specific set of operations/functionalities. 
2. Standardized and interoperable mechanisms building on (1) to allow Relying
   Parties to know the provenance and characteristics of a Device that may be 
   requesting services.
3. Standardized and interoperable mechanisms to protect Claims which may need to
   be protected from unauthorised disclosure for privacy and/or security
   reasons.

The Working Group will identify security goals which it expects a trustworthy
execution context to address, which will assume the presence of one or more
Roots of Trust. The detailed specification of such contexts is out of scope.

The Working Group will maintain close relationships with bodies undertaking 
complementary work streams in the area of remote Attestation such as 
GlobalPlatform, Trusted Computing Group and FIDO Alliance.

The Working Group will cooperate with the TEEP Working Group, which may generate
requirements for Claims relevant to TEE.

The Working Group will identify use-cases for interoperability with PKI
infrastructure and will work with the editor of SCEP and the ACME Working Group
to address technical solutions for these.

Work Items
----------

The Working Group will develop specifications supporting the creation
of  interoperable Remote Attestation procedures for devices which incorporate
at  least one Root of Trust.

- Produce a requirements document establishing a common vocabulary for remote 
  Attestation, identifying mechanisms which will be supported for establishing 
  trust between a Device and a Relying Party, and enumerating sample use-cases 
  for Remote Attestation.
- Produce a specification defining interoperable cross-platform Claims which 
  provide information about a Device in support of the required use-cases, and 
  extending the set of Claims defined in RFC7519 and RFC8392. The specification 
  will describe the syntax for each Claim in at least the following formats: 
  - CBOR [RFC7049] 
  - JSON [RFC7159] 
  - YANG [RFC6020]
  - ASN.1
- Produce a specification defining procedures and corresponding architectures 
  supporting verification of Claims within an Attestation based on measured
  file  execution procedures and supporting: 
  - Explicit Attestation wherein a set of Claims is transported in the
    Attestation; 
  - Implicit Attestation wherein a set of Claims is implied by possession of a
    secret.
- Produce a specification defining procedures and corresponding architectures 
  supporting verification of Claims encapsulated in:
  - CBOR Web Token structures [RFC8392] 
  - JSON Web Token structures [RFC7519]
- Perform privacy analysis of both Claims and the cryptographic procedures used
  to  establish trust. This information will be included as appropriate in the 
  deliverable specifications, and may imply extension of procedures defined in 
  other specifications in support of privacy goals.

On 24 Oct 2018, at 12:36, Jeremy O'Donoghue <[email-masked]<mailto:[email-masked]>> wrote:

HI Eric,

Hi Jeremy,

Best regards
Jeremy

Thanks,
Eric

Fair comment.

Introduction
------------

Work Items
----------

Jeremy

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Oct 2018 10:18:50 -0400

Henk Birkholz <[email-masked]> wrote:
    > based on Jeremy's proposal we did another big refactoring - also tried to
    > address everybody's comments, inputs and concerns.

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

Well done!
I can live with this text.

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Wed, 24 Oct 2018 14:27:44 +0000

I can also live with the new text.

It may be worth double checking the mail I sent a couple of hours back (e-mail crossed Henk's contribution, unfortunately) which addressed comments on my text, although I think you have captured everything except:

I would be OK leaving that out of the charter although it would certainly be a technical goal of the work on EAT - others may disagree.

Jeremy

On 24 Oct 2018, at 15:18, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:
based on Jeremy's proposal we did another big refactoring - also tried to
address everybody's comments, inputs and concerns.

Well done!

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 24 Oct 2018 14:53:53 +0000

I am good with the text as well.   

> From: Michael Richardson, October 24, 2018 10:19 AM
> 
> Michael Richardson <[email-masked]>, Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Oct 2018 11:28:06 -0400

Jeremy O'Donoghue <[email-masked]> wrote:
    > on my text, although I think you have captured everything except:

    > be protected from unauthorised disclosure for privacy and/or security

That sounds like a friendly amendment.

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 24 Oct 2018 17:31:18 +0000

Agree. Hence the need for the charter scope to include terminology definition / clarification work (which it does).
+1 on the proposed markup/markdown changes.
-Ned

On 10/24/18, 5:59 AM, "EAT on behalf of Jeremy O'Donoghue" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

·         aligns more closely with NIST terminology - note that NIST does not have a clear set of definitions for all of the terminology used, so some of the text is my interpretation of the content of SP 800-64, aided by the input from Ned.