Subject: [Rats] Endorsements

From: Laurence Lundblade <[email-masked]>
Date: Tue, 3 Mar 2020 11:12:24 -0800

Closing the loop on trust between the Attester and Verifier has always seemed critical to me in Rats architecture. It is in all my diagrams. There has to be some out-of-band interaction akin to CA’s giving certificates to browser vendors or it doesn’t work. From conversations in Berlin, I now understand this is through Endorsements. Here’s how I think it works. Does this seem right?

Endorsements are critical and integral in the Rats architecture. An Endorsement is the Verifier’s sole basis for trusting the Attester. 

A minimal endorsement includes a key to verify signatures on the Attestation Evidence and some information about the vendor backing the endorsement, the Endorser, perhaps just the name of the vendor or perhaps a lot more.

In some use cases the Endorser may operate the Verifier. For example, a chip vendor may operate an only verification service for attestations from its chip.

Endorsements and Endorsers are of interest to the Relying Party because it tells them something about how they might trust the Evidence. For example, if the Endorser is a highly reputable chip vendor, they may trust it quite a lot. If it is an unknown SW vendor, they may not trust it much at all.

The Endorser will be the manufacturer of the Attester in some cases. This manufacturer will make the HW and SW that make up the Attester. They will put the signing keys into the Attester. They will build a database of the corresponding public keys that are eventually supplied to the Verifier in the form of Endorsements.

In other cases the Endorser might be an independent trust broker and/or certification house. They don’t make the Attester, but they know who did and qualify them in some way. They may do this for many Attester vendors as an aggregation service.

The Relying Party comes to trust the Endorser through some out-of-band process that is not specified in the Rats architecture. It is most likely transitive through the Verifier. The Relying Party decided to trust the Verifier and the Verifier decides to trust the Endorser.

The mechanisms of out-of-band trust establishment is likely to be through X.509 certificates, perhaps with TLS. The policy basis for trust establishment may involve business decisions, legal agreements and reputations. For example, a Relying Party may decide to trust prominent chip vendors or device just by their reputation. In another example, a Verification service may accept click-through legal agreements set up Endorsements for a particular vendor.

In Android Attestation, Google is the Endorser. The Attester manufacturers are the handset vendors and their suppliers. Google makes the attestation keys and distributes them one to handset manufacturers that generally comply with Google’s requirements. Google is also the Verifier because they provide an only verification service. The trust establishment between Endorser and Verifier is trivial because they are the same.  The Relying Party trusts Google because they are so well known through TLS certificates.

For FIDO, the FIDO Alliance is the Endorser. Individual FIDO Authenticator manufacturers (e.g. handset vendors) generate the attestation keys, sign them into X.509 certificates and perhaps form a certificate hierarchy. They send the root of this certificate hierarchy to the FIDO Alliance which publishes them on their web site. In FIDO, the Verifier is typically the Relying Party, so they take in all necessary X.509 certificates to be able to verify all the way down to the key uses to sign the Attestation Evidence. The FIDO Alliance also supplies other information in the Endorsement, such as certification status and various Authenticator characteristics (I’m equating the FIDO Metadata service to an Endorsement service).

Assuming this is right, it seems more could be added architecture draft on Endorsements.

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 3 Mar 2020 20:04:24 +0000

I agree with most of what Laurence has captured below. I also agree with the call to action that the architecture should say something about Endorsement. It was important for some people that the WG charter exclude Endorsement but the architecture exempted itself from that restriction in order to build a complete picture. Given the WG doesn't want to spend effort defining Endorsement but wants to understand Endorsement, the arch team should discuss how much is appropriate (for now) vs. later (once the WG charter officially adopts Endorsement as part of its charter). 

-Ned

On 3/3/20, 11:12 AM, "RATS on behalf of Laurence Lundblade" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    

    
    LL

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

---

From: Giridhar Mandyam <[email-masked]>
Date: Tue, 3 Mar 2020 20:08:03 +0000

Thanks Laurence.

Going back to the discussion on the virtual interim, I believe my usage of the term "Unendorsed" Token is correct assuming that the architecture document adopts the description provided below.  An unsigned token is by extension unendorsed.  A signed token can be unendorsed as well, e.g. https://www.w3.org/TR/webauthn/#self-attestation.  It seems that a verifier would not distinguish between the two types of tokens under most appraisal policies.

-Giri

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Tuesday, March 3, 2020 11:12 AM
To: [email-masked]
Subject: [Rats] Endorsements

-------------------------------------------------------------------------
CAUTION: This email originated from outside of the organization.
-------------------------------------------------------------------------

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 3 Mar 2020 21:06:50 +0000

Referring to Giri's statement: "It seems that a verifier would not distinguish between the two types of tokens under most appraisal policies"

I'm not sure this interpretation is correct. The Verifier depends on appraisal policy that identifies trust anchors (public keys) that are deemed "trusted". Trust anchor policies could identify a public key pair that was embedded in a device as the anchor. Or it could identify a supply chain entity that claims to have embedded a key pair (and the Verifier policy doesn't yet know / trust the embedded key). 

Endorsement is the ability for a supply chain entity to assert more claims about the Attesting device than could be asserted by the Attester. Clearly, the Endorsement would need to be signed by the supply chain entity and the Verifier would need to have a policy that trusts the supply chain entity in order for it to adopt endorsements (claims about the device not included in the Evidence) into the verification step. 

Endorsement claims could be applied even if no attestation Evidence is supplied. The Verifier has to be confident the endpoint is a device that matches the supply chain entity asserted claims. The Verifier might build reputation in a device key over time or it might require use of a key that was embedded by a manufacturer. How the Verifier becomes convinced that the key is bound to the device is an open question. There are many possibilities. However, a way that industry seems to be following is for the device mfg to embed the key and issue a certificate. There are lots of names for this: IDevID, mfg certificate, endorsement key credential etc... 

The term "un|endorsed token" can be misleading because the operation that links the mfg (endorser) to the token is the embedded signing key and the device in which it was embedded. It makes more sense to say the 'device' or the 'embedded key' is/isn't endorsed than to say the token is/isn't endorsed. 

An "endorsed token" could be easily confused with an Endorsement (claims expressed as a CWT) signed by an "Endorser" aka supply chain entity / manufacturer. This is also an 'endorsed token' but the architecture would call it "Endorsements" not "Evidence". The thread on "un|endorsed token" could (if I understand it correctly) also refer to Evidence where the CWT is signed by a key that was/wasn't embedded by a manufacturer but protected by the device? 

Given it is out of scope to define a format/encoding in RATS for Endorsements, the term "endorsed token" that refers to an Endorsement flow would never reasonably be a topic of discussion. But the architecture doesn't artificially restrict Endorsement formats from being CWT or JWT. If "endorsed" means "signed by an Endorser" then claims un|signed by a mfg and encoded as a CWT/JWT could be referred to as an "un|endorsed token". But that would conflict with its current usage as Evidence. 

Since the Verifier treats Evidence and Endorsements differently it doesn't make sense to equate them.

If the semantics of the term "endorsed token" means a token that was signed by a key that was embedded in a device by a manufacturer that is trusted based on its PKI trust anchor (public key). Then I agree the term can be useful. But I don't (at present) believe it makes sense to make it a part of the terminology in the architecture. An expression like this is a statement of policy that a Verifier might seek to enforce. The architecture should remain policy neutral IMHO. 

-Ned

On 3/3/20, 12:08 PM, "RATS on behalf of Giridhar Mandyam" <[email-masked] on behalf of [email-masked]> wrote:

    Thanks Laurence.

    -Giri
    
    -----Original Message-----
    From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
    Sent: Tuesday, March 3, 2020 11:12 AM
    To: [email-masked]
    Subject: [Rats] Endorsements

    

    

    

    
    LL

---

From: Giridhar Mandyam <[email-masked]>
Date: Tue, 3 Mar 2020 21:38:22 +0000

Sorry, should have been more clear.  2 things:

a) When I said a signed token can be unendorsed, I was specifically focused on FIDO's concept of self-attestation.  I cannot see why an appraisal policy would distinguish between evidence signed with a self-generated key by the attester with no accompanying endorsement, versus an unsigned token.  But maybe there are corner cases of which I am not aware.

b) I don't think the architecture document should mention any kind of practices around appraisal policy.

That being said, the terms "endorsed token" and "unendorsed token" are being used in the broader community, and I don't think the arch. document should stay silent on the topic.  We are trying to arrive at a common terminology that underlies the efforts in this WG, so it is reasonable to put forward a definition.  How such tokens are assessed by a verifier/RP however can be considered out-of-scope.

-Giri

-----Original Message-----
From: Smith, Ned <[email-masked]>
Sent: Tuesday, March 3, 2020 1:07 PM
To: Giridhar Mandyam <[email-masked]>; Laurence Lundblade <[email-masked]>; [email-masked]
Subject: Re: [Rats] Endorsements

-Ned

    Thanks Laurence.

    -Giri

    -----Original Message-----
    From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
    Sent: Tuesday, March 3, 2020 11:12 AM
    To: [email-masked]
    Subject: [Rats] Endorsements

    LL

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 4 Mar 2020 09:17:59 -0800

> On Mar 3, 2020, at 1:06 PM, Smith, Ned <[email-masked]> wrote:
> 

I think Endorsement is the primary way a Verifier knows to trust an Attester. It does allow for more claims to about the device (implied claims) but it more fundamental than just adding claims.

I also don’t think Endorsements need to be signed. They just have to be conveyed to the Verifier in a secure way. If the Verifier and Endorser are the same company, the chip vendor, it might just be because some system admin manually types them into the Verifier.

> Endorsement claims could be applied even if no attestation Evidence is supplied. The Verifier has to be confident the endpoint is a device that matches the supply chain entity asserted claims. The…

This is interesting. 

A self-signed token might have somewhat more value than an unsigned token. If you assume that the signing key is at least somewhat protected, you can decide you trust it on first use (TOFU) or build up trust in it over time, or have your machine learning system take it into account.

> The term "un|endorsed token" can be misleading because the operation that links the mfg (endorser) to the token is the embedded signing key and the device in which it was embedded. It makes more se…

Agreed. 

I prefer endorsed / unendorsed attester and sign / unsigned token. No use of "unendorsed token” in Rats.

I would really like to see a strong relation between Endorser and Attester expressed in the architecture document. 

The Attester is Endorsed. Then the Attester Collects Claims to create Evidence about the Target / Device. The Verify only knows to trust the Attester based receiving and Endorsement for the Attester. Once the trusts the Attester, then it trusts the Claims in the Evidence created by said Attester. 

Or if you have an Attester doing self-signed, then there is no Endorsement and you rely on TOFU or ML for trust.

Or if you have an Attester producing unsigned tokens, then there you are on your own as to how they are secured and how you figure out the Endorsement.

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 4 Mar 2020 20:39:27 +0000

Nms> inline below

From: Laurence Lundblade <[email-masked]>
Date: Wednesday, March 4, 2020 at 9:18 AM
To: "Smith, Ned" <[email-masked]>
Cc: Giridhar Mandyam <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Rats] Endorsements

On Mar 3, 2020, at 1:06 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

I think Endorsement is the primary way a Verifier knows to trust an Attester. It does allow for more claims to about the device (implied claims) but it more fundamental than just adding claims.
Nms> Is this using the RATS Arch definition of “Endorsement”?
If the entity implementing the Verifier is different from the entity implementing the Endorser (aka supply chain entity), then the Verifier must establish a trust relationship with the Endorser. If in a PKI context, then the supply chain entity obtains an identity cert. The entity implementing the Verifier obtains the trust anchor for the Endorser and adds it to its list of trusted trust anchors.

The Endorser could issue a device cert to the device entity that implements the Attester. When the Verifier receives a certificate path to the key that signs Evidence, it observes the Endorser entity’s trust anchor is in its list of trusted trust anchors. Therefore, the entity implementing the Verifier trusts the entity implementing the Endorser. (Sorry to be pedantic about the difference between Role and Entity but it can be a source of confusion / talking past one another).

I also don’t think Endorsements need to be signed. They just have to be conveyed to the Verifier in a secure way. If the Verifier and Endorser are the same company, the chip vendor, it might just be because some system admin manually types them into the Verifier.
Nms> Agree. This is a case where the entity implementing the Endorser is the same entity that implements the Verifier. Since the entity trusts itself, the trust relationship semantic is uninteresting. The RATS architecture expects multiple RATS Roles can be implemented on the same entity.

This is interesting.

A self-signed token might have somewhat more value than an unsigned token. If you assume that the signing key is at least somewhat protected, you can decide you trust it on first use (TOFU) or build up trust in it over time, or have your machine learning system take it into account.
Nms> The self-signed token is a case where the signing key can be used to build a reputation. The Verifier needs to maintain a history of transactions involving the key. The main challenge with key reputation systems is they assume the private key isn’t shared with an attacker. The very next transaction could be the one the attacker chooses to implement the attack. Verifier is assuming past performance determines future performance; which may be a fallacy.

Agreed.

I prefer endorsed / unendorsed attester and sign / unsigned token. No use of "unendorsed token” in Rats.
Nms> I’m still not sure I know what “unendorsed token” means in a RATS context. If a token is a CWT or a JWT then they have to be digitally signed (or not). The idea of an unsigned CWT/JWT is the topic of a draft you are writing correct?

I would really like to see a strong relation between Endorser and Attester expressed in the architecture document.
Nms> What does “strong” refer to? I think the architecture already tries to say that multiple RATS roles can be implemented by the same entity. This means an Endorser and an Attester could exist on the same entity. There is intuition that the entity implementing the Attester Role is a ‘device’. There is also intuition that the entity implementing the Endorser role is a supply chain entity. The idea that a single entity that implements both roles is non-intuitive IMO. The supply chain entity and device entity are almost always different. Possibly virtualization is an intuitive case where the hypervisor ‘manufactures’ guest VMs. However, the hypervisor doesn’t write the guest VM code and I assume it isn’t using self-modifying code. There is still a supply chain entity that writes the VM code using a development device that is different from the hypervisor/VM device. ASLR is possibly another intuitive case where the in-memory representation of the code differs from the COFF/ELF representation shipped by a supply chain entity. The loader/driver/OS implementing ASLR could be thought of as an Endorser that produced the in-memory representation the Attester. Even in this example, the loader depends on a supply chain entity for the code image it randomizes. But a measurement of the pre-image would be of no use to a Verifier. The loader would need to produce ‘Endorsements’ of the in-memory image in order to compare with measurements of in-memory image by an Attester. Do you have different intuition for what it means when the entity implementing both Endorser and Attester roles is the same?

The Attester is Endorsed.
Nms> I’m not sure what this means.
Then the Attester Collects Claims to create Evidence about the Target / Device.
Nms> Agree.
The Verify Nms> (Verifier?) only knows to trust the Attester based receiving and Endorsement for the Attester.
Nms> I don’t understand this sentence.

Once the trusts the Attester,
Nms> sentence is missing the subject.
then it trusts the Claims in the Evidence created by said Attester.
Nms> I think this is trying to say that the device that has a key that signs Evidence protects the key such that some other device couldn’t posses the key and masquerade as the first device. ???
Nms> If “Endorsed Attester” means the manufacturer that implemented the device made sure that the key in the device is unique; only bound to one device. And that the key is used to sign Evidence. Then that aligns with the RATS Arch text that says “an Endorsement might be a manufacturer certificate that signs a public key whose corresponding private key is only known inside the device's hardware”.   Note, however that the focus is on the private key and its device rather than on the RATS Role (Attester) or a RATS message encoding format (Token, Certificate). The trustworthiness property is the way the private key is bound to the device. The Endorsement is a device-key-binding message (aka token, certificate, …) containing the public key, device identifier(s) and implicit or explicit statements about how the private key was bound to the device. A signature of the supply chain entity identifies who is asserting these endorsement claims. The endorsement message doesn’t necessarily have to be conveyed using the device. The supply chain entity could convey it directly to the Verifier; e.g. via a web service.

Or if you have an Attester doing self-signed, then there is no Endorsement and you rely on TOFU or ML for trust.
Nms> Agree. Trust is based on Verifier building a reputation about the key.

Or if you have an Attester producing unsigned tokens, then there you are on your own as to how they are secured and how you figure out the Endorsement.
Nms> Agree. Trust is baseless.

LL

-Ned

On 3/3/20, 12:08 PM, "RATS on behalf of Giridhar Mandyam" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

   Thanks Laurence.

   -Giri

   -----Original Message-----
   From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Laurence Lundblade
   Sent: Tuesday, March 3, 2020 11:12 AM
   To: [email-masked]<mailto:[email-masked]>
   Subject: [Rats] Endorsements

   LL

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

---

From: Giridhar Mandyam <[email-masked]>
Date: Wed, 4 Mar 2020 21:47:26 +0000

I would agree, if “self-signed” is not equivalent to FIDO’s concept of self-attestation.  Based on my interpretation - in the FIDO case, a domain-specific credential generated by the authenticator is used to sign the attestation.  The RP would have no information on provenance or protection of the signing key, and could not rely on any potential endorsers (e.g. FIDO Metadata Service) to provide such information.

I guess TOFU along with some risk-based authentication is possible, but such approaches do not seem to be contemplated in the architecture document.  Moreover – this could be done with an unsigned token too.

-Giri

From: RATS <[email-masked]> On Behalf Of Smith, Ned
Sent: Wednesday, March 4, 2020 12:39 PM
To: Laurence Lundblade <[email-masked]>
Cc: [email-masked]; Giridhar Mandyam <[email-masked]>
Subject: Re: [Rats] Endorsements

From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 4, 2020 at 9:18 AM
To: "Smith, Ned" <[email-masked]<mailto:[email-masked]>>
Cc: Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Endorsements

This is interesting.

Agreed.

LL

-Ned

   Thanks Laurence.

   -Giri

   -----Original Message-----
   From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Laurence Lundblade
   Sent: Tuesday, March 3, 2020 11:12 AM
   To: [email-masked]<mailto:[email-masked]>
   Subject: [Rats] Endorsements

   LL

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 4 Mar 2020 22:27:19 +0000

From: RATS <[email-masked]> on behalf of Giridhar Mandyam <[email-masked]>
Date: Wednesday, March 4, 2020 at 1:48 PM
To: "Smith, Ned" <[email-masked]>, Laurence Lundblade <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Rats] Endorsements

I would agree, if “self-signed” is not equivalent to FIDO’s concept of self-attestation.  Based on my interpretation - in the FIDO case, a domain-specific credential generated by the authenticator is used to sign the attestation.
Nms> I’m not that familiar with FIDO attestation to know if I’m interpreting terminology correctly. But if “domain-specific credential” refers to a key that comes into existence at the time a device is deployed into the ‘domain’ then ‘self-signed’ could refer to something like a CSR that results in a domain issued certificate where the domain CA trusts the ‘self-signed’ request as proof that the key belongs to the device on the opposite end of the currently connected CSR session.
The RP would have no information on provenance or protection of the signing key, and could not rely on any potential endorsers (e.g. FIDO Metadata Service) to provide such information.
Nms> If Verifiers are external to the domain that created the Attester credentials (I’m assuming X.509 e.g. LDevID) then the domain entity is a RATS Endorser. The LDevID cert is an Endorsement (but as you say, it doesn’t have device-key-binding-provenance claims linking to the device manufacturer. Therefore, the Verifier that has a policy that expects mfg provenance claims will determine the LDevID cert / Endorsement won’t satisfy the policy. (Note: Appraisal Policy for Evidence determines which Endorsements are valid and whether Evidence matches valid Endorsements).

I guess TOFU along with some risk-based authentication is possible, but such approaches do not seem to be contemplated in the architecture document.
Nms> My response above explains how the current arch contemplates a TOFU scenario.
Moreover – this could be done with an unsigned token too.
Nms> In a case where the Attester and Verifier are hosted on the same entity. An unsigned token could be used because (a) the trust semantics are uninteresting (an entity trusts itself). If they are different entities then (b) trust could be based on conveyance protocol’s use of security or (c) trust is baseless. I’m not sure which of the three cases you might be referring to when describing an “unsigned token” scenario.

-Giri

This is interesting.

Agreed.

LL

-Ned

   Thanks Laurence.

   -Giri

   -----Original Message-----
   From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Laurence Lundblade
   Sent: Tuesday, March 3, 2020 11:12 AM
   To: [email-masked]<mailto:[email-masked]>
   Subject: [Rats] Endorsements

   LL

---

From: Giridhar Mandyam <[email-masked]>
Date: Thu, 5 Mar 2020 00:30:42 +0000

FIDO has a concept of a scoped-credential, where an authenticator credential is allocated for exclusive use by an authenticated domain (e.g. example.com).  To be more specific – the credential is scoped to an RP ID (https://www.w3.org/TR/webauthn/#rp-id) – which is derived from the authenticated domain.  An authenticator should not use the same credential for multiple domains.  There is no CSR operation, and the authentication credential is used to sign the attestation in the self-signed case.  Maybe this use case is out-of-scope for the RATS architecture.

-Giri

From: RATS <[email-masked]<mailto:[email-masked]>> on behalf of Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 4, 2020 at 1:48 PM
To: "Smith, Ned" <[email-masked]<mailto:[email-masked]>>, Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Endorsements

-Giri

From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Smith, Ned
Sent: Wednesday, March 4, 2020 12:39 PM
To: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Endorsements

This is interesting.

Agreed.

LL

-Ned

   Thanks Laurence.

   -Giri

   -----Original Message-----
   From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Laurence Lundblade
   Sent: Tuesday, March 3, 2020 11:12 AM
   To: [email-masked]<mailto:[email-masked]>
   Subject: [Rats] Endorsements

   LL

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Thu, 5 Mar 2020 07:09:00 +0000

Hi
Please see inline:

夏靓 （Frank Xia）
IP安全标准专家  -  数据通信标准专利部
华为技术有限公司
Tel : +86 25 56624539  /  139138 40549
Email : [email-masked]

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

发件人: RATS [mailto:[email-masked]] 代表 Laurence Lundblade
发送时间: 2020年3月5日 1:18
收件人: Smith, Ned <[email-masked]>
抄送: [email-masked]; Giridhar Mandyam <[email-masked]>
主题: Re: [Rats] Endorsements

I also don’t think Endorsements need to be signed. They just have to be conveyed to the Verifier in a secure way. If the Verifier and Endorser are the same company, the chip vendor, it might just be because some system admin manually types them into the Verifier.
[Frank]: I agree with Laurence here, I do not think the Endorsement should be related with specific claims.

B.R.
Frank

This is interesting.

Agreed.

LL

-Ned

   Thanks Laurence.

   -Giri

   -----Original Message-----
   From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Laurence Lundblade
   Sent: Tuesday, March 3, 2020 11:12 AM
   To: [email-masked]<mailto:[email-masked]>
   Subject: [Rats] Endorsements

   LL

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 5 Mar 2020 08:26:07 -0800

Here’s an attempt at more clear definitions; hopefully a big improvement over my terse grammatically incorrect comments below.

I didn’t go into it below, but I think Endorsements can contain implicit claims that can go into the Attestation Result. I think there are actually two poles for the way implicit and explicit claims work and how they get into the Attestation Result. In one case, more TPM-like, just about all the claims are implicit and come from the Endorser via the Endorsement. In the opposite case, more TEE-like, just about all the claims are explicit and the Endorsement isn’t much more than a verification key.

Pretty sure the architecture document needs to cover how implicit and explicit claims work. Seems like a critical part of Rats architecture.

LL

Endorser
The primary function of an Endorser is to endorse an Attester so that a Verifier can know to trust that Attester. The Endorser does this by creating an Endorsement and conveying it securely to the Verifier. The primary basis for a Verifier trusting an Attester is the Endorsement.

There is thus an existential relationship between Attesters and Endorsers.  An Attester with no Endorsement is not worth very much since there is no good basis by which a Verifier can trust it so every Attester needs an Endorser. The Endorser’s primary function is to endorse Attesters so an Endorser doesn’t have anything to do without some Attesters to endorse.

A Verify cannot do its job without Endorsements. It must have an Endorsement for each Attester from which it received Attestation Evidence. Without this, the Attester is not trusted and there is no basis for trusting the Evidence it produces.

There is a trust triangle between the Endorser, Attester and Verifier. The Endorser tells the Verifier that an Attester is trustworthy.

Endorsement
Ultimately an Endorsement must be realized as some input bytes to a Verifier and they must be conveyed securely from the Endorser to the Verifier. RATS architecture does not impose any limit or restriction on the formats of these bytes or the conveyance mechanism.  In practice they are expected to vary quite widely.

In most cases the Endorsement will include the key material that is used to verify signatures on the Evidence. Since the Evidence will contain a nonce, this signature verification serves to authenticate the attester. The Endorsement may also contain information about the Attester such as its type, version, manufacturer and such.

In one example, the Endorser and the Verifier are the same legal organization, so secure conveyance is entirely an internal issue for the organization. It may consist of one employee copying a set of public keys from computer in the company to another.

In another example, the Endorsement may take the form of a PKI hierarchy. The Endorser conveys a root certificate to the Verifier. The Endorser also creates per-attester certificates under that root. Those per-attester certificates are programmed into Attesters. The Attester sends them to the  Verifier attached to the Evidence. There may be several levels of certificates in the PKI hierarchy. The Verifier walks the certificate chain to determine trust.  Note in the case the abstract notion of Endorsement comes to the Verifier in two parts, one in an out-of-band secure conveyance or a root certificate and the other as the signed (self-securing) certificates from the Attester.

Unendorsed Attesters
The use of unendorsed Attesters is discouraged because there is no good basis for establishing trust in them. An unendorsed Attester may still have a signing key and produce signed evidence. A Verifier may choose to have some trust in the Evidence they produce by assuming they are trusted on first use (TOFU), building up trust over time after seeing a lot of presumably good attestation evidence, or because it is fed into a machine learning algorithm that correlates to known fraud.  Rats architecture include any facilities, details or designs for this mode of use and explicitly considers it insecure.

> On Mar 4, 2020, at 12:39 PM, Smith, Ned <[email-masked]> wrote:
> 
> Nms> inline below
>  
> From: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
> To: "Smith, Ned" <[email-masked] <mailto:[email-masked]>>
> Cc: Giridhar Mandyam <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> On Mar 3, 2020, at 1:06 PM, Smith, Ned <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> On 3/3/20, 12:08 PM, "RATS on behalf of Giridhar Mandyam" <[email-masked] <mailto:[email-masked]> on behalf [email-masked] <mailto:[email-masked]>> wrote:
>> 
>>    Thanks Laurence.
>> 
>>    Going back to the discussion on the virtual interim, I believe my usage of the term "Unendorsed" Token is correct assuming that the architecture document adopts the description provided below.  An unsigned token is by extension unendorsed.  A signed token can be unendorsed as well, e.g. https://www.w3.org/TR/webauthn/#self-attestation <https://www.w3.org/TR/webauthn/#self-attestation>.  It seems that a verifier would not distinguish between the two types of tokens under most appraisal policies.
>> 
>>    -Giri
>> 
>>    From: RATS <[email-masked] <mailto:[email-masked]>> On Behalf Of Laurence Lundblade
>>    To: [email-masked] <mailto:[email-masked]>
>>    [email-masked] <mailto:[email-masked]>
>>    https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
>>    [email-masked] <mailto:[email-masked]>
>>    https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
>> 
> 
> 
>

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 5 Mar 2020 08:29:58 -0800

> On Mar 4, 2020, at 4:30 PM, Giridhar Mandyam <[email-masked]> wrote:
> 
> FIDO has a concept of a scoped-credential, where an authenticator credential is allocated for exclusive use by an authenticated domain (e.g. example.com <http://example.com/>).  To be more specific – the credential is scoped to an RP ID (https://www.w3.org/TR/webauthn/#rp-id <https://www.w3.org/TR/webauthn/#rp-id>) – which is derived from the authenticated domain.  An authenticator should not use the same credential for multiple domains.  There is no CSR operation, and the authentication credential is used to sign the attestation in the self-signed case.  Maybe this use case is out-of-scope for the RATS architecture.
>  
> -Giri
>  
> 

I don’t think of keys scoped to RP IDs as attestation keys. I think the are authentication keys. Attestation keys are always about the device, never about the user, the RP or other non-device entities.

For sure, attestation is a great way to set up such keys, but I don’t think they relate to endorsement.

LL

---

From: Giridhar Mandyam <[email-masked]>
Date: Thu, 5 Mar 2020 18:51:16 +0000

> I don’t think of keys scoped to RP IDs as attestation keys. I think the are authentication keys. Attestation keys are always about the device, never about the user, the RP or other non-device entit…

That certainly is a valid opinion, but it does not appear to be consistent with FIDO.

In the FIDO case, the attestation is for the auth credential – not the device.  It so happens that certain FIDO attestations may include information on the OS (Android SafetyNet), protection of credential in the device (Android Keystore), device itself (FIDO TPM). And then there is FIDO self attestation, where the attestation key and credential are the same.   In all cases for FIDO the credential is scoped, but the attestation key may or may not be.

> For sure, attestation is a great way to set up such keys, but I don’t think they relate to endorsement.

That will limit applicability to existing uses of attestation (see above).  This will limit the value of the architecture document.

-Giri

From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Thursday, March 5, 2020 8:30 AM
To: Giridhar Mandyam <[email-masked]>
Cc: [email-masked]; Smith, Ned <[email-masked]>
Subject: Re: [Rats] Endorsements

On Mar 4, 2020, at 4:30 PM, Giridhar Mandyam <[email-masked]<mailto:[email-masked]>> wrote:

FIDO has a concept of a scoped-credential, where an authenticator credential is allocated for exclusive use by an authenticated domain (e.g. example.com<http://example.com/>).  To be more specific – the credential is scoped to an RP ID (https://www.w3.org/TR/webauthn/#rp-id) – which is derived from the authenticated domain.  An authenticator should not use the same credential for multiple domains.  There is no CSR operation, and the authentication credential is used to sign the attestation in the self-signed case.  Maybe this use case is out-of-scope for the RATS architecture.

-Giri

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 5 Mar 2020 19:47:34 +0000

Nms> inline

Date: Thursday, March 5, 2020 at 8:26 AM

LL

Endorser

Endorsement

Unendorsed Attesters

On Mar 4, 2020, at 12:39 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

Nms> inline below

This is interesting.

Agreed.

LL

-Ned

On 3/3/20, 12:08 PM, "RATS on behalf of Giridhar Mandyam" <[email-masked]<mailto:[email-masked]> on behalf [email-masked]<mailto:[email-masked]>> wrote:

   Thanks Laurence.

   -Giri

   -----Original Message-----
   From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Laurence Lundblade
   Sent: Tuesday, March 3, 2020 11:12 AM
   To: [email-masked]<mailto:[email-masked]>
   Subject: [Rats] Endorsements

   LL