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

"Smith, Ned" <> Thu, 18 October 2018 18:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9135130E3E; Thu, 18 Oct 2018 11:37:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wq2vyF6sj2Eo; Thu, 18 Oct 2018 11:37:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9B4EF130E12; Thu, 18 Oct 2018 11:37:23 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2018 11:37:23 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.54,397,1534834800"; d="scan'208";a="242418503"
Received: from ([]) by with ESMTP; 18 Oct 2018 11:37:22 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 18 Oct 2018 11:37:22 -0700
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Thu, 18 Oct 2018 11:37:22 -0700
From: "Smith, Ned" <>
To: "Diego R. Lopez" <>, Laurence Lundblade <>, Henk Birkholz <>
CC: Hannes Tschofenig <>, Jeremy O'Donoghue <>, "" <>, "" <>, Denis <>
Thread-Topic: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF charter updates?
Date: Thu, 18 Oct 2018 18:37:21 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [EAT] [EXTERNAL] Re: [Rats] Attestation BoF charter updates?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EAT - Entity Attestation Token <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Oct 2018 18:37:36 -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" < on behalf of>; wrote:

    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
    Tel:         +34 913 129 041
    Mobile:  +34 682 051 091
    On 17/10/2018, 06:31, "EAT on behalf of Laurence Lundblade" < on behalf of>; wrote:
        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.
        > On Oct 16, 2018, at 8:24 PM, Henk Birkholz <>; 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" <>; 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 <>; On Behalf Of Smith, Ned
        >>     Sent: Monday, October 15, 2018 9:00 AM
        >>     To: Henk Birkholz <>;;; Jeremy O'Donoghue <>;; Denis <>;
        >>     Cc:
        >>     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" < on behalf of>; 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 <
        >>         > <>> 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"
        >>         >>> < on behalf of>;  wrote:
        >>         >>>
        >>         >>>> Hi all,
        >>         >>>>
        >>         >>>> sorry for the delay. Please find an updated charter proposal here:
        >>         >>>>
        >>         >>>>>
        >>         >>>> 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
        >>         >>>>
        >>         >>>>
        >>         >>> _______________________________________________
        >>         >>> EAT mailing list
        >>         >>>
        >>         >>>
        >>         >>
        >>         >>
        >>         >> _______________________________________________
        >>         >> EAT mailing list
        >>         >> <>
        >>         >>
        >>         >
        >>         >
        >>         >
        >>         > _______________________________________________
        >>         > EAT mailing list
        >>         >
        >>         >
        >>         >
        >>              _______________________________________________
        >>         EAT mailing list
        >>               _______________________________________________
        >>     EAT mailing list
        >>     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
        EAT mailing list
    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
    EAT mailing list