Re: [EAT] Device Identity (was Re: [EXTERNAL] Re: [Rats] Attestation BoF charter updates?)

[Henk Birkholz <[e-mail]>]

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 
>> <[e-mail] 
>> <mailto:[e-mail]>> 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
>>
>>> 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 
>>>> <[e-mail] 
>>>> <mailto:[e-mail]> 
>>>> <mailto:[e-mail]>> wrote:
>>>>
>>>> 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.
>>>>> 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 <[e-mail] 
>>>>>> <mailto:[e-mail]> <mailto:[e-mail]> 
>>>>>> <mailto:[e-mail]>> 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.
>>>>>>  Let me know if I'm missing the point...
>>>>>> Thanks
>>>>>> /guy fedorkow, juniper networks
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Laurence Lundblade <[e-mail] 
>>>>>> <mailto:[e-mail]> <mailto:[e-mail]> 
>>>>>> <mailto:[e-mail]>>
>>>>>> Sent: Wednesday, October 17, 2018 12:31 AM
>>>>>> To: Henk Birkholz <[e-mail] 
>>>>>> <mailto:[e-mail]> 
>>>>>> <mailto:[e-mail]> 
>>>>>> <mailto:[e-mail]>>
>>>>>> Cc: Smith, Ned <[e-mail] <mailto:[e-mail]> 
>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>>; Hannes 
>>>>>> Tschofenig <[e-mail] 
>>>>>> <mailto:[e-mail]> 
>>>>>> <mailto:[e-mail]> 
>>>>>> <mailto:[e-mail]>>; [e-mail] 
>>>>>> <mailto:[e-mail]> <mailto:[e-mail]> 
>>>>>> <mailto:[e-mail]>; Jeremy O'Donoghue 
>>>>>> <[e-mail] <mailto:[e-mail]> 
>>>>>> <mailto:[e-mail]> 
>>>>>> <mailto:[e-mail]>>; Denis <[e-mail] 
>>>>>> <mailto:[e-mail]> <mailto:[e-mail]> 
>>>>>> <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> 
>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>>> Subject: Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF charter 
>>>>>> updates?
>>>>>>
>>>>>> 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 
>>>>>>> <[e-mail] 
>>>>>>> <mailto:[e-mail]> 
>>>>>>> <mailto:[e-mail]> 
>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>> On 10/16/2018 03:51 PM, Smith, Ned wrote:
>>>>>>>> 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" 
>>>>>>>> <[e-mail] <mailto:[e-mail]> 
>>>>>>>> <mailto:[e-mail]> 
>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>>    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 <[e-mail] <mailto:[e-mail]> 
>>>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>> On 
>>>>>>>> Behalf Of Smith, Ned
>>>>>>>>    Sent: Monday, October 15, 2018 9:00 AM
>>>>>>>>    To: Henk Birkholz <[e-mail] 
>>>>>>>> <mailto:[e-mail]> 
>>>>>>>> <mailto:[e-mail]> 
>>>>>>>> <mailto:[e-mail]>>; [e-mail] 
>>>>>>>> <mailto:[e-mail]> <mailto:[e-mail]> 
>>>>>>>> <mailto:[e-mail]>; Jeremy O'Donoghue 
>>>>>>>> <[e-mail] <mailto:[e-mail]> 
>>>>>>>> <mailto:[e-mail]> 
>>>>>>>> <mailto:[e-mail]>>; Denis <[e-mail] 
>>>>>>>> <mailto:[e-mail]> <mailto:[e-mail]> 
>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>    Cc: [e-mail] <mailto:[e-mail]> <mailto:[e-mail]> 
>>>>>>>> <mailto:[e-mail]>
>>>>>>>>    Subject: Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF 
>>>>>>>> charter updates?
>>>>>>>>         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" 
>>>>>>>> <[e-mail] <mailto:[e-mail]> 
>>>>>>>> <mailto:[e-mail]> <mailto:[e-mail]> on 
>>>>>>>> behalf of [e-mail] 
>>>>>>>> <mailto:[e-mail]> 
>>>>>>>> <mailto:[e-mail]> 
>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>>             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:
>>>>>>>>> On 12 Oct 2018, at 14:33, Denis <[e-mail] 
>>>>>>>>> <mailto:[e-mail]> <mailto:[e-mail]> 
>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>> <mailto:[e-mail]>> 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.
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>> 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"
>>>>>>>>>>> <[e-mail] <mailto:[e-mail]> 
>>>>>>>>>>> <mailto:[e-mail]> <mailto:[e-mail]> 
>>>>>>>>>>> on behalf of [e-mail] 
>>>>>>>>>>> <mailto:[e-mail]> 
>>>>>>>>>>> <mailto:[e-mail]> 
>>>>>>>>>>> <mailto:[e-mail]>>  wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> sorry for the delay. Please find an updated charter proposal 
>>>>>>>>>>>> here:
>>>>>>>>>>>>
>>>>>>>>>>>>> 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=
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>> On 10/06/2018 08:23 AM, Laurence Lundblade 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
>>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> RATS mailing list
>>>>>>>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]> 
>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>> 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=
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> EAT mailing list
>>>>>>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]> 
>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>> 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=
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> EAT mailing list
>>>>>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]> 
>>>>>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>>>>>>> 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=
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> EAT mailing list
>>>>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]> 
>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>> 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=
>>>>>>>>>
>>>>>>>>             _______________________________________________
>>>>>>>>        EAT mailing list
>>>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]> 
>>>>>>>> <mailto:[e-mail]>
>>>>>>>> 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=
>>>>>>>>              _______________________________________________
>>>>>>>>    EAT mailing list
>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>> 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=
>>>>>>>>    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.
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> EAT mailing list
>>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]> 
>>>>>>> <mailto:[e-mail]>
>>>>>>> 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=
>>>>>>
>>>>>> _______________________________________________
>>>>>> EAT mailing list
>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]> 
>>>>>> <mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/eat
>>>>
>>>> _______________________________________________
>>>> EAT mailing list
>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/eat
>>
>> _______________________________________________
>> EAT mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/eat
>