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

[Henk Birkholz <[e-mail]>]

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]>> 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]>> 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]>>
>>>> Sent: Wednesday, October 17, 2018 12:31 AM
>>>> To: Henk Birkholz <[e-mail] 
>>>> <mailto:[e-mail]> 
>>>> <mailto:[e-mail]>>
>>>> Cc: Smith, Ned <[e-mail] <mailto:[e-mail]> 
>>>> <mailto:[e-mail]>>; Hannes Tschofenig 
>>>> <[e-mail] <mailto:[e-mail]> 
>>>> <mailto:[e-mail]>>; [e-mail] 
>>>> <mailto:[e-mail]> <mailto:[e-mail]>; Jeremy O'Donoghue 
>>>> <[e-mail] <mailto:[e-mail]> 
>>>> <mailto:[e-mail]>>; Denis <[e-mail] 
>>>> <mailto:[e-mail]> <mailto:[e-mail]>>; 
>>>> [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]>> 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]>> 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]>> On Behalf Of Smith, Ned
>>>>>>    Sent: Monday, October 15, 2018 9:00 AM
>>>>>>    To: Henk Birkholz <[e-mail] 
>>>>>> <mailto:[e-mail]> 
>>>>>> <mailto:[e-mail]>>; [e-mail] 
>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>; Jeremy O'Donoghue 
>>>>>> <[e-mail] <mailto:[e-mail]> 
>>>>>> <mailto:[e-mail]>>; Denis <[e-mail] 
>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>>
>>>>>>    Cc: [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]> on behalf of 
>>>>>> [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]>> 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]> on behalf of 
>>>>>>>>> [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]>
>>>>>>>>>> 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]>
>>>>>>>>> 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]>
>>>>>>> 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]>
>>>>>> 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]>
>>>>> 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]>
>>>> https://www.ietf.org/mailman/listinfo/eat
>>
>> _______________________________________________
>> EAT mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/eat
>