Subject: Re: [Rats] Verifier Input instead of Endorsement?

From: Laurence Lundblade <[email-masked]>
Date: Wed, 1 Jul 2020 18:46:58 -0700

Here’s rough proposed text and diagram. Not sure where it would go in the doc yet.

LL

          *******************   ************     ****************
          * Manufacturer(s) *   * Verifier *     * Relying Party*
          *******************   *  Owner   *     *  Owner       *
                       |        ************     ****************
                       |              |                 |
          Manufacturer |              |                 |
              Verifier |              |Owner            |
                Input  |              |Verifier         |
                       |              |Input            | Appraisal
                       |              |                 | Policy for
                       |              |                 | Attestation
                       |              |                 |  Result
                       v              v                 |
                     .-----------------.                |
              .----->|     Verifier    |------.         |
              |      '-----------------'      |         |
              |                               |         |
              |                    Attestation|         |
              |                    Results    |         |
              | Evidence                      |         |
              |                               |         |
              |                               v         v
        .----------.                      .-----------------.
        | Attester |                      | Relying Party   |
        '----------'                      '————————‘

Conceptually there are four main inputs to the Verifier aside from the Attestation Evidence. They are:

   - Key material for verifying trust in the Attester
   - Known-good/reference values for comparison with Claims in the Attestation Evidence
   - Static implicit claims for the particular Attester that are pass to the Relying Party in Attestation Results
   - Policy Configuration

Any of these four can come from either the Manufacturer as Manufacturer Verifier Input or from the Verifier Owner as Owner Verifier Input. They key material usually always comes from the manufacturer and the policy from the Verifier Owner, but there is no strict requirement for this. The known-good/reference values and static implicit claims often come from either or both. 

There is no strict separation between Manufacturer and Verifier Owner. They could be the same. There could also be 3rd party intermediaries between the Manufacturer and the Verifier.

An Endorsement is one established format for some of these inputs. It usually comes from an Endorser that is usually the Manufacturer. It is usually a signed document. Alternatively, the Verifier may perform queries against a database, perhaps one maintained by a Manufacturer, to get inputs. Alternatively, the root key of a key hierarchy may be transferred in a one-time physical ceremony. This architecture sets no protocol or procedure for this input.

The transfer of all these inputs to the Verifier does need to be secured. For all cases, authenticity of the Manufacturer and Verifier Owner and their inputs are required. Without authentic inputs, the Verifier will not do its job correctly. In some cases confidentiality of the inputs is required. Finally, in some cases the Manufacturer and Verifier Owner will authenticate the Verifier.

This architecture sets no requirement for a particular protocol or security mechanism. For example, TLS could be used, but it is not the only protocol that could be used,

> On Jun 29, 2020, at 8:56 PM, Dave Thaler <dthaler=[email-masked]> wrote:
> 
> I don’t like the term “Verifier Input” since “Appraisal Policy for Evidence” is also Verifier Input, so I would find it confusing.
> I think that the rules for what to put in Attestation Results (bullet 3), as well as “known-good/reference values” if such exist
> (and there can be valid policies where they may not exist, or rather where the policies use more complex rules than
> a simple test for equality against a constant) are conceptually part of Appraisal Policy.
>  
> I do agree that Appraisal Policy can be conveyed to the Verifier in many different ways, and may be composed
> of different things from different sources.
>  
> Dave
>  
> From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
> Sent: Monday, June 29, 2020 11:34 AM
> To: [email-masked]
> Subject: [Rats] Verifier Input instead of Endorsement?
>  
> Stepping back a bit on the definition of an Endorsement, I think the four inputs to a Verifier are these:
>   - Key material for verifying trust in the Attester
>   - Known-good/Reference values for comparison with claims
>   - Static implicit claims that are passed to RP's via Attestation Results
>   - Appraisal Policy
>  
> These can and will be conveyed to the Verifier in many different ways:
>   - X.509 certs with extensions
>   - Signed documents
>   - HTTP queries against the Attester/device manufacturer
>   - Remote SQL or some other sort of database access to manufacturer(s)
>   - Data storage like flash drives the are hand carried into the Verifier's site
>   - One-time special file transfers
>   - Ceremonial procedures with M out of N people physical present approving transfer
>  
> It seems like shoe-horning all of the above (except policy) into an Endorsement, like I’ve tried to do <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Farchitecture%2Fpull%2F94&data=02%7C01%7Cdthaler%40microsoft.com%7Cf15ace6e8b4b447eebc008d81c5b1f33%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290524986365098&sdata=2NktPX%2B3LJXjMEjEFoM8kpUIy6yOxte%2BuhFYr1ETN4g%3D&reserved=0>  is too much. I tried this shoe-horning because I think the architecture document needs to cover all this and Endorsements was what was in it. A typical Endorsement seems to be just the first two mentioned, X.509 and signed documents expanding its definition to include database access is a stretch.
>  
> Rather than defining Endorsement, I’d like to define Verifier Input:
>  
>           *******************   ************     ****************
>           * Manufacturer(s) *   * Verifier *     * Relying Party*
>           *******************   *  Owner   *     *  Owner       *
>                        |        ************     ****************
>                        |              |                 |
>          Verifier Input|              |                 |
>                        |              |Appraisal        |
>                        |              |Policy           |
>                        |              |for              | Appraisal
>                        |              |Evidence         | Policy for
>                        |              |                 | Attestation
>                        |              |                 |  Result
>                        v              v                 |
>                      .-----------------.                |
>               .----->|     Verifier    |------.         |
>               |      '-----------------'      |         |
>               |                               |         |
>               |                    Attestation|         |
>               |                    Results    |         |
>               | Evidence                      |         |
>               |                               |         |
>               |                               v         v
>         .----------.                      .-----------------.
>         | Attester |                      | Relying Party   |
>         '----------'                      '————————‘
>  
>  
> 
> Endorsements must still be mentioned, but as one form of Verifier input just like EAT is one form of Attestation Evidence.
>  
> Verifier Input would be defined as:
>   - Key material for verifying trust in the Attester
>   - Known-good/Reference values for comparison with claims
>   - Static implicit claims that are passed to RP's via Attestation Results
>  
> To do this, I’d replace the current PR <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Farchitecture%2Fpull%2F94&data=02%7C01%7Cdthaler%40microsoft.com%7Cf15ace6e8b4b447eebc008d81c5b1f33%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290524986365098&sdata=2NktPX%2B3LJXjMEjEFoM8kpUIy6yOxte%2BuhFYr1ETN4g%3D&reserved=0> and issue <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Farchitecture%2Fissues%2F65&data=02%7C01%7Cdthaler%40microsoft.com%7Cf15ace6e8b4b447eebc008d81c5b1f33%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290524986375092&sdata=GfM5qElO4teNdjfABlmVayeGXuYHWBDqHTVtpeeew7g%3D&reserved=0> I have on Endorsements with a new PR. It will be a fair bit of work, so I want to see if there is some consensus first.
>  
> LL
>  
>  
>  
>  
>  
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 2 Jul 2020 15:31:02 +0200

Hi Laurence,

while I think that I understand where you are coming from here, I have 
to say that I also think that:

* "manufacturer(s)" is a too arbitrarily restricting term, which is why 
we agreed on endorser
* every arrow is of course "input/output", but we are not calling 
evidence "Attester Output". So, Verifier Input is in contrast a too 
ambiguous category (it does not add any semantics to the arrow)
* the itemized list that starts with key material provides a very 
intuitive example and maybe we could use that kind of list as a more 
prominent example in the arch I-D

The question, if reference values are endorsements or appraisal policies 
or a third item is... probably okay and I am interested in an answer - 
but that is a detail, I think. As long as they are also mentioned, I can 
follow all three lines of thought.

Also, I am in strong doubt that the following statement is always 
correct: "The transfer of all these inputs to the Verifier does need to 
be secured.". I am confused by the exceptions that follow that statement 
which basically say, I think: in some cases they have to be secured. 
Maybe we mean different things by "secured"?

Viele Grüße,

Henk

On 02.07.20 03:46, Laurence Lundblade wrote:
>     - Static implicit claims for the particular Attester that are pass 
> to the Relying Party in Attestation Results
>     - Policy Configuration
> 
> Any of these four can come from either the Manufacturer as Manufacturer 
> Verifier Input or from the Verifier Owner as Owner Verifier Input. They 
> key material usually always comes from the manufacturer and the policy 
> from the Verifier Owner, but there is no strict requirement for this. 
> The known-good/reference values and static implicit claims often come 
> from either or both.
> 
> There is no strict separation between Manufacturer and Verifier Owner. 
> They could be the same. There could also be 3rd party intermediaries 
> between the Manufacturer and the Verifier.
> 
> An Endorsement is one established format for some of these inputs. It 
> usually comes from an Endorser that is usually the Manufacturer. It is 
> usually a signed document. Alternatively, the Verifier may perform 
> queries against a database, perhaps one maintained by a Manufacturer, to 
> get inputs. Alternatively, the root key of a key hierarchy may be 
> transferred in a one-time physical ceremony. This architecture sets no 
> protocol or procedure for this input.
> 
> The transfer of all these inputs to the Verifier does need to be 
> secured. For all cases, authenticity of the Manufacturer and Verifier 
> Owner and their inputs are required. Without authentic inputs, the 
> Verifier will not do its job correctly. In some cases confidentiality of 
> the inputs is required. Finally, in some cases the Manufacturer and 
> Verifier Owner will authenticate the Verifier.
> 
> This architecture sets no requirement for a particular protocol or 
> security mechanism. For example, TLS could be used, but it is not the 
> only protocol that could be used,
> 
> 
> 
> 
>> On Jun 29, 2020, at 8:56 PM, Dave Thaler 
>> <dthaler=[email-masked] 
>> <mailto:dthaler=[email-masked]>> wrote:
>>
>> I don’t like the term “Verifier Input” since “Appraisal Policy for 
>> Evidence” is also Verifier Input, so I would find it confusing.
>> I think that the rules for what to put in Attestation Results (bullet 
>> 3), as well as “known-good/reference values” if such exist
>> (and there can be valid policies where they may not exist, or rather 
>> where the policies use more complex rules than
>> *From:*RATS <[email-masked] <mailto:[email-masked]>>*On 
>> Behalf Of*Laurence Lundblade
>> *Sent:*Monday, June 29, 2020 11:34 AM
>> *To:[email-masked] <mailto:[email-masked]>
>> *Subject:*[Rats] Verifier Input instead of Endorsement?
>> It seems like shoe-horning all of the above (except policy) into an 
>> Endorsement, like I’ve tried to do 
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Farchitecture%2Fpull%2F94&data=02%7C01%7Cdthaler%40microsoft.com%7Cf15ace6e8b4b447eebc008d81c5b1f33%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290524986365098&sdata=2NktPX%2B3LJXjMEjEFoM8kpUIy6yOxte%2BuhFYr1ETN4g%3D&reserved=0>  
>> is too much. I tried this shoe-horning because I think the 
>> architecture document needs to cover all this and Endorsements was 
>> what was in it. A typical Endorsement seems to be just the first two 
>> mentioned, X.509 and signed documents expanding its definition to 
>> include database access is a stretch.
>> Endorsements must still be mentioned, but as one form of Verifier 
>> input just like EAT is one form of Attestation Evidence.
>> To do this, I’d replace the current PR 
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Farchitecture%2Fpull%2F94&data=02%7C01%7Cdthaler%40microsoft.com%7Cf15ace6e8b4b447eebc008d81c5b1f33%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290524986365098&sdata=2NktPX%2B3LJXjMEjEFoM8kpUIy6yOxte%2BuhFYr1ETN4g%3D&reserved=0> and 
>> issue 
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Farchitecture%2Fissues%2F65&data=02%7C01%7Cdthaler%40microsoft.com%7Cf15ace6e8b4b447eebc008d81c5b1f33%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290524986375092&sdata=GfM5qElO4teNdjfABlmVayeGXuYHWBDqHTVtpeeew7g%3D&reserved=0> I 
>> have on Endorsements with a new PR. It will be a fair bit of work, so 
>> I want to see if there is some consensus first.
>> LL
>> [email-masked] <mailto:[email-masked]>

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 2 Jul 2020 10:51:57 -0700

> On Jul 2, 2020, at 6:31 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Laurence,
> 
> while I think that I understand where you are coming from here, I have to say that I also think that:
> 
> * "manufacturer(s)" is a too arbitrarily restricting term, which is why we agreed on endorser

The problem with Endorser is that they produce Endorsements and I think there are problems with Endorsements:
 - In Berlin you told me they don’t have keys in them. So then how do keys get into the Verifier?
 - Endorsements seem to be small signed documents of attributes so they’re not so good for:
     - Representing a database of millions of keys
     - Representing HTTP access to a manufacturers database of known-good/reference values
     - One-time physical / ceremonial transfer of a root key
- Endorsements seem like a somewhat narrowed, specific way of providing verifier input
- Endorsements imply signing as the security mechanism, which is too narrow.
     
Maybe we can find a term other than manufacturer?  What I want to avoid is the general use of the term Endorsement for the above reasons. Using the term Endorsement to me is like using the protocol-specific term EAT instead of conceptual term Attestation Evidence. Use of the term Endorser implies Endorsement, but maybe it is OK if we don’t use the term Endorsement.

> * every arrow is of course "input/output", but we are not calling evidence "Attester Output". So, Verifier Input is in contrast a too ambiguous category (it does not add any semantics to the arrow)

Maybe the non-specificity of “Verifier Input” seems useful? It allows the list of four (keys, ref values, static claims, policy) to be used and for them to be variable. It is just a grouping.

Maybe we can find a better term? Here’s a few:
   Verifier Criteria
   Verifier Data
   Attester Verification Criteria
   Attester Trust Materials

> * the itemized list that starts with key material provides a very intuitive example and maybe we could use that kind of list as a more prominent example in the arch I-D

I’d prefer the list of four to be explicit architecture, not just an example.

> 
> The question, if reference values are endorsements or appraisal policies or a third item is... probably okay and I am interested in an answer - but that is a detail, I think. As long as they are also mentioned, I can follow all three lines of thought.

We should assume our audience knows little to nothing about TCG work (like me) and little about attestation, so I’d prefer they not be details, but rather up front and clear.

> 
> Also, I am in strong doubt that the following statement is always correct: "The transfer of all these inputs to the Verifier does need to be secured.". I am confused by the exceptions that follow that statement which basically say, I think: in some cases they have to be secured. Maybe we mean different things by "secured"?

Let me try again:
- The Verifier must always establish the authenticity of the Manufacturer
- All input from the Manufacturer must be integrity protected
- The Verifier must always establish the authenticity of the Verifier Owner
- All input from the Verifier Owner must be integrity protected
- In some cases the Manufacturer may wish to establish the authenticity of the Verifier before giving inputs
- In some cases the Owner may wish to establish the authenticity of the Verifier before giving inputs
- In some cases confidentiality of the inputs is required

LL

>>> On Jun 29, 2020, at 8:56 PM, Dave Thaler <dthaler=[email-masked] <mailto:dthaler=[email-masked]> <mailto:dthaler=[email-masked] <mailto:dthaler=[email-masked]>>> wrote:
>>> 
>>> *From:*RATS <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>*On Behalf Of*Laurence Lundblade
>>> *To:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>> It seems like shoe-horning all of the above (except policy) into an Endorsement, like I’ve tried to do <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Farchitecture%2Fpull%2F94&data=02%7C01%7Cdthaler%40microsoft.com%7Cf15ace6e8b4b447eebc008d81c5b1f33%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290524986365098&sdata=2NktPX%2B3LJXjMEjEFoM8kpUIy6yOxte%2BuhFYr1ETN4g%3D&reserved=0 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Farchitecture%2Fpull%2F94&data=02%7C01%7Cdthaler%40microsoft.com%7Cf15ace6e8b4b447eebc008d81c5b1f33%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290524986365098&sdata=2NktPX%2B3LJXjMEjEFoM8kpUIy6yOxte%2BuhFYr1ETN4g%3D&reserved=0>>  is too much. I tried this shoe-horning because I think the architecture document needs to cover all this and Endorsements was what was in it. A typical Endorsement seems to be just the first two mentioned, X.509 and signed documents expanding its definition to include database access is a stretch.
>>> To do this, I’d replace the current PR <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Farchitecture%2Fpull%2F94&data=02%7C01%7Cdthaler%40microsoft.com%7Cf15ace6e8b4b447eebc008d81c5b1f33%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290524986365098&sdata=2NktPX%2B3LJXjMEjEFoM8kpUIy6yOxte%2BuhFYr1ETN4g%3D&reserved=0 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Farchitecture%2Fpull%2F94&data=02%7C01%7Cdthaler%40microsoft.com%7Cf15ace6e8b4b447eebc008d81c5b1f33%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290524986365098&sdata=2NktPX%2B3LJXjMEjEFoM8kpUIy6yOxte%2BuhFYr1ETN4g%3D&reserved=0>> and issue <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Farchitecture%2Fissues%2F65&data=02%7C01%7Cdthaler%40microsoft.com%7Cf15ace6e8b4b447eebc008d81c5b1f33%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290524986375092&sdata=GfM5qElO4teNdjfABlmVayeGXuYHWBDqHTVtpeeew7g%3D&reserved=0 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Farchitecture%2Fissues%2F65&data=02%7C01%7Cdthaler%40microsoft.com%7Cf15ace6e8b4b447eebc008d81c5b1f33%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290524986375092&sdata=GfM5qElO4teNdjfABlmVayeGXuYHWBDqHTVtpeeew7g%3D&reserved=0>> I have on Endorsements with a new PR. It will be a fair bit of work, so I want to see if there is some consensus first.
>>> LL
>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
>> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
> 
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Jul 2020 16:57:41 -0400

> keys get into the Verifier?

Well, first, I thought we agreed that the arcs above Verifier were out of
scope for the architecture.  The WG might recharter to include that, but I
thought we agreed that the concerns were seperable.  HOWEVER...

So in some cases the Verifier will be configured entirely by some proprietary
mechanism.  Those mechanisms could consist of pasting a configuration file
full of keys (trust anchors probably), along with Known Good Values.
Or, they could consist of a bunch of EATs of a semi-proprietary nature.
Semi, because we haven't standardized them yet, but conceptually they are
bang-on.

Maybe you want to start a personal ID that deals with an architecture for
Endorsement?
To the extent that I think you want to use EAT for many of things, maybe it
would be a good repository of non-Evidence/non-Attestation-Result uses of
EAT.

---

So, when you say "keys", I think you mostly mean Trust Anchors, right?
These would things like Manufacturer IDevID anchors.
These would allow a Verifiers to know that is dealing with authentic units
from Mfg X, and therefore the Manufacturer X-signed Endorsement that were
published somewhere can be applied.

    > - Representing HTTP access to a manufacturers database of known-good/reference values

I don't quite understand this.
The database of keys could be a single trust anchor if the keys are all
signed in some way.  That doesn't have to be PKIX if you (like me) hate that.
EAT can be used, CoID, PGP, etc.
PGP has replicating keyserver technology that could be applied here, btw.

I don't quite understand "Representing HTTP access"... part.
I guess this is more than just having a URL.
It seems that when/if we come to standardizing the Endorsement arc, that we
might need to standardizing a way of accessing the database, even if that
is just about describing how a URL fragment can be extended with a firmware
version number.
We'd need to say how that URL fragment is communicated. I can think of a few
ways, some good, some less good.

    > - One-time physical / ceremonial transfer of a root key

Please explain how this would be used.
I'm very interested.

    > Maybe we can find a term other than manufacturer?  What I want to avoid
    > is the general use of the term Endorsement for the above reasons. Using
    > the term Endorsement to me is like using the protocol-specific term EAT
    > instead of conceptual term Attestation Evidence. Use of the term
    > Endorser implies Endorsement, but maybe it is OK if we don’t use the
    > term Endorsement.

"Terms of Endorsement" <-- staring Shirley, Debra, Jack and Apple.com?

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

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

---

From: Simon Frost <[email-masked]>
Date: Fri, 3 Jul 2020 09:28:58 +0000

I’ve just tried to catch up on the thinking on this via this thread and github#94 and realise that the conversation has become highly detailed and that some very precise definitions are emerging for concepts that originally were quite general (e.g. endorsement). Perhaps there’s a risk that the architecture may be overly constraining as a result.

Trying to avoid using any term that may now be overloaded…
It seems that the important information to capture is that the Verifier is a means of providing transitive trust between the relying party and a potentially complex Supply Chain from which the attesting endpoint originated. The RP to Verifier relationship must be securable and trustworthy in some achievable way such that an RP can trust the attestation results received. Similarly that creates an expectation that the Verifier has established securable & trustworthy relationships with the supply chain in order to receive appropriate proofs / testimonies of items that the Verifier can identify within the attestation evidence. The Verifier to Supply Chain relationships aren’t just technical, they require contractual relationships as well which can bring a strong influence into the details of how the information gets to the Verifier.  If we have the relationships sketched out and an exploration of the types of information that may be required, is it necessary to go into further detail?

Thanks
Simon

From: Laurence Lundblade <[email-masked]>
Sent: 02 July 2020 18:52
To: Henk Birkholz <[email-masked]>
Cc: Dave Thaler <dthaler=[email-masked]>; [email-masked]
Subject: Re: [Rats] Verifier Input instead of Endorsement?

On Jul 2, 2020, at 6:31 AM, Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:

Hi Laurence,

Let me try again:

LL

Viele Grüße,

Henk

On Jun 29, 2020, at 8:56 PM, Dave Thaler <dthaler=[email-masked]<mailto:dthaler=[email-masked]> <mailto:dthaler=[email-masked]>> wrote:

*From:*RATS <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>*On Behalf Of*Laurence Lundblade
*To:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

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

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 4 Jul 2020 10:22:32 -0700

Hi Simon,

Appreciate you jumping in here. 

> On Jul 3, 2020, at 2:28 AM, Simon Frost <[email-masked]> wrote:
> 

I am after greater generality (and clarity) than I think we have now with Endorsements. Endorsements are (in my understanding) a somewhat specific representation of data and protocol. 

I am giving a lot of examples to try to communicate clearly, no to specify anything.

I would like the list-of-four in the document because I think it is highly informative (even Henk’s thinks they are so), but not as a prescription or requirement. 

> It seems that the important information to capture is that the Verifier is a means of providing transitive trust between the relying party and a potentially complex Supply Chain from which the atte…

I think this is a possible approach. To take this, I think Endorsements have to be either removed or redefined in some very general way to side-step the ideas people have about them.

LL

>  
> Thanks
> Simon
>  
> From: Laurence Lundblade <[email-masked] <mailto:[email-masked]>> 
> Sent: 02 July 2020 18:52
> To: Henk Birkholz <[email-masked] <mailto:[email-masked]>>
> Cc: Dave Thaler <dthaler=[email-masked] <mailto:dthaler=[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On Jul 2, 2020, at 6:31 AM, Henk Birkholz <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Laurence,
> 
> 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. _______________________________________________
> RATS mailing list

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 4 Jul 2020 10:54:48 -0700

> On Jul 2, 2020, at 1:57 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

If that’s the approach, then Endorsements should be removed from the document, both in the text and diagram.

> So, when you say "keys", I think you mostly mean Trust Anchors, right?

No, I don’t. 

This is far past TCG, IDevID, X.509 and public key.

> published somewhere can be applied.

Here’s an example (nothing to be standardized; just an illustration).

- A unique 256-bit symmetric key and key ID is put in each device by the Manufacturer.
- COSE_Mac0 (HMAC) is used to sign the EAT
- The EAT is conveyed to the Verifier
- The Verifier parses the EAT to get the key ID
- The Verifier makes a private HTTPS connection to the Manufacturer (presumably set up to be very secure)
- The Verifier sends the key ID and gets back the symmetric key
- The Verifier verifies

In another version, the Verifier sends the key ID and the to-be-signed bytes to the Manufacturer. The Manufacturer verifies the HMAC and sends back a yeah or yeah. The Verifier does the rest of the work on reference values and such.

> PGP has replicating keyserver technology that could be applied here, btw.

Yes, that’s all true, but still only a subset of what is possible. Also, I don’t know that this fits typical notion of an Endorsement.

> ways, some good, some less good.

Yes. That make sense.

Just not sure that this set up fits the typical notion of an Endorsement.

> Please explain how this would be used.

Here’s a symmetric key example. All the keys COSE_MAC0 keys are created by doing a KDF from a root symmetric key. This symmetric root is just 256 very important bits that need to be kept very secret. The KDF input is a key ID and the symmetric root.

The way the Verifier figures out the key for each device is by receiving the key id in the COSE_MAC0 and running the KDF on the symmetric root. The Verifier is probably doing this inside an HSM to keep the symmetric root very safe.

To get the symmetric root from the Manufacturer to the Verifier safely, a team of people from the Manufacturer physically travel to the location of the Verifier hand carrying the HSM(s) they’ve configured with the keys. It is a team so one doesn’t run off with it or make copies.

(Last century, when Qualcomm had one of the first app download systems ever built, Verizon’s Get It Now, we did physical transfers like this with VeriSign for the root keys for app signing (though asymmetric crypto was used)).

To be clear, I don’t want to standardize this stuff. 

The point is that RATS architecture must allow for this and I don’t think Endorsements work this way.

LL

---

From: Michael Richardson <[email-masked]>
Date: Sat, 04 Jul 2020 19:18:28 -0400

> document, both in the text and diagram.

That makes no sense to me.

It is perfectly reasonable to define something just well enough in order to make it
clear what is out of scope for standardization.

We can come up with many different ways to standardize Endorsements (or
Verifier Inputs), and it shouldn't matter at all to the protocol between
Attester and Verifier.

That's what makes it seperable.
Do you agree?

---

From: Simon Frost <[email-masked]>
Date: Mon, 6 Jul 2020 11:55:03 +0000

Hi Laurence,

> I am after greater generality (and clarity) than I think we have now with Endorsements. Endorsements are (in my understanding) a somewhat specific representation of data and protocol.
I agree with your aim. I’m suggesting that we relax that definition to allow ‘Endorsements’ to cover all the categories of data originating from the supply chain that the Verifier may need to consult. I’m not aware that Endorsement has a specific industry definition. (I’m aware of Endorsement Certificates for TPMs, but that’s a more specialised term). I’m happy to have a definition pointed out or equally if Endorsement just has excessive connotations for the WG then the architecture can adopt another, descriptive, term. I agree that more information would then be needed and your 4 categories could form the basis of a set of examples for types of data in that category.

As you say on a separate reply:
> Well, first, I thought we agreed that the arcs above Verifier were out of scope for the architecture…
I remember having a discussion locally when the WG charter was defined in which we agreed that keeping it out of scope was exactly the correct approach, just because there were so many ways in which the relationships may need to be satisfied.

HTH
Simon

From: Laurence Lundblade <[email-masked]>
Sent: 04 July 2020 18:23
To: Simon Frost <[email-masked]>
Cc: Henk Birkholz <[email-masked]>; Dave Thaler <dthaler=[email-masked]>; [email-masked]
Subject: Re: [Rats] Verifier Input instead of Endorsement?

Hi Simon,

On Jul 3, 2020, at 2:28 AM, Simon Frost <[email-masked]<mailto:[email-masked]>> wrote:

LL

Thanks
Simon

From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Sent: 02 July 2020 18:52
To: Henk Birkholz <[email-masked]<mailto:[email-masked]>>
Cc: Dave Thaler <dthaler=[email-masked]<mailto:dthaler=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Rats] Verifier Input instead of Endorsement?

Hi Laurence,

Let me try again:

LL

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 6 Jul 2020 14:19:23 +0200

Hi all,

quick comment below

On 06.07.20 13:55, Simon Frost wrote:
> Hi Laurence,
> 
>> I am after greater generality (and clarity) than I think we have now 
> with Endorsements. Endorsements are (in my understanding) a somewhat 
> specific representation of data and protocol.
> 
> I agree with your aim. I’m suggesting that we relax that definition to 
> allow ‘Endorsements’ to cover all the categories of data originating 
> from the supply chain that the Verifier may need to consult. I’m not 
> aware that Endorsement has a specific industry definition. (I’m aware of 
> Endorsement Certificates for TPMs, but that’s a more specialised term). 
> I’m happy to have a definition pointed out or equally if Endorsement 
> just has excessive connotations for the WG then the architecture can 
> adopt another, descriptive, term. I agree that more information would 
> then be needed and your 4 categories could form the basis of a set of 
> examples for types of data in that category.
> 
> I remember having a discussion locally when the WG charter was defined 
> in which we agreed that keeping it out of scope was exactly the correct 
> approach, just because there were so many ways in which the 
> relationships may need to be satisfied.

In fact we agreed on "out-of-scope" for the first phase of the charter 
in order to acknowledge the fact that this is part of the "Attestation 
Provisioning Workflow" (an old term that we used to use to draw the 
demarcation line for the RATS WG phasing).

Viele Grüße,

Henk

> 
> HTH
> 
> Simon
> 
> *From:*Laurence Lundblade <[email-masked]>
> *Sent:* 04 July 2020 18:23
> *To:* Simon Frost <[email-masked]>
> *Cc:* Henk Birkholz <[email-masked]>; Dave Thaler 
> <dthaler=[email-masked]>; [email-masked]
> *Subject:* Re: [Rats] Verifier Input instead of Endorsement?
> 
> Hi Simon,
> 
>     I’ve just tried to catch up on the thinking on this via this thread
>     and github#94 and realise that the conversation has become highly
>     detailed and that some very precise definitions are emerging for
>     concepts that originally were quite general (e.g. endorsement).
>     Perhaps there’s a riskthat the architecture may be overly
>     constraining as a result.
> 
> I am after greater generality (and clarity) than I think we have now 
> with Endorsements. Endorsements are (in my understanding) a somewhat 
> specific representation of data and protocol.
> 
> I would like the list-of-four in the document because I think it is 
> highly informative (even Henk’s thinks they are so), but not as a 
> prescription or requirement.
> 
>     It seems that the important information to capture is that the
>     Verifier is a means of providing transitive trust between the
>     relying party and a potentially complex Supply Chain from which the
>     attesting endpoint originated. The RP to Verifier relationship must
>     be securable and trustworthy in some achievable way such that an RP
>     can trust the attestation results received. Similarly that creates
>     an expectation that the Verifier has established securable &
>     trustworthy relationships with the supply chain in order to receive
>     appropriate proofs / testimonies of items that the Verifier can
>     identify within the attestation evidence. The Verifier to Supply
>     Chain relationships aren’t just technical, they require contractual
>     relationships as well which can bring a strong influence into the
>     details of how the information gets to the Verifier.  If we have the
>     relationships sketched out and an exploration of the types of
>     information that may be required, is it necessary to go into further
>     detail?
> 
> I think this is a possible approach. To take this, I think Endorsements 
> have to be either removed or redefined in some very general way to 
> side-step the ideas people have about them.
> 
> LL
> 
> 
> 
>     Thanks
> 
>     Simon
> 
>     *From:*Laurence Lundblade <[email-masked]
>     <mailto:[email-masked]>>
>     *Sent:*02 July 2020 18:52
>     *To:*Henk Birkholz <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:*Dave Thaler <dthaler=[email-masked]
>     <mailto:dthaler=[email-masked]>>;[email-masked]
>     <mailto:[email-masked]>
>     *Subject:*Re: [Rats] Verifier Input instead of Endorsement?
> 
>         On Jul 2, 2020, at 6:31 AM, Henk Birkholz
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
> 
>         Hi Laurence,
> 
> 
>     The problem with Endorser is that they produce Endorsements and I
>     think there are problems with Endorsements:
> 
>     Maybe we can find a term other than manufacturer?  What I want to
>     avoid is the general use of the term Endorsement for the above
>     reasons. Using the term Endorsement to me is like using the
>     protocol-specific term EAT instead of conceptual term Attestation
>     Evidence. Use of the term Endorser implies Endorsement, but maybe it
>     is OK if we don’t use the term Endorsement.
> 
> 
> 
> 
>         * every arrow is of course "input/output", but we are not
>         calling evidence "Attester Output". So, Verifier Input is in
>         contrast a too ambiguous category (it does not add any semantics
>         to the arrow)
> 
>     Maybe the non-specificity of “Verifier Input” seems useful? It
>     allows the list of four (keys, ref values, static claims, policy) to
>     be used and for them to be variable. It is just a grouping.
> 
>         * the itemized list that starts with key material provides a
>         very intuitive example and maybe we could use that kind of list
>         as a more prominent example in the arch I-D
> 
>         The question, if reference values are endorsements or appraisal
>         policies or a third item is... probably okay and I am interested
>         in an answer - but that is a detail, I think. As long as they
>         are also mentioned, I can follow all three lines of thought.
> 
>     We should assume our audience knows little to nothing about TCG work
>     (like me) and little about attestation, so I’d prefer they not be
>     details, but rather up front and clear.
> 
> 
> 
> 
> 
>         Also, I am in strong doubt that the following statement is
>         always correct: "The transfer of all these inputs to the
>         Verifier does need to be secured.". I am confused by the
>         exceptions that follow that statement which basically say, I
>         think: in some cases they have to be secured. Maybe we mean
>         different things by "secured"?
> 
>     Let me try again:
> 
>     - In some cases the Manufacturer may wish to establish the
>     authenticity of the Verifier before giving inputs
> 
>                                     |              |Input            |
>             Appraisal
>             Policy for
>             Attestation
>               Result
>             Conceptually there are four main inputs to the Verifier
>             aside from the Attestation Evidence. They are:
>                 - Static implicit claims for the particular Attester
>             that are pass to the Relying Party in Attestation Results
>                 - Policy Configuration
>             Any of these four can come from either the Manufacturer as
>             Manufacturer Verifier Input or from the Verifier Owner as
>             Owner Verifier Input. They key material usually always comes
>             from the manufacturer and the policy from the Verifier
>             Owner, but there is no strict requirement for this. The
>             known-good/reference values and static implicit claims often
>             come from either or both.
>             There is no strict separation between Manufacturer and
>             Verifier Owner. They could be the same. There could also be
>             3rd party intermediaries between the Manufacturer and the
>             Verifier.
>             An Endorsement is one established format for some of these
>             inputs. It usually comes from an Endorser that is usually
>             the Manufacturer. It is usually a signed document.
>             Alternatively, the Verifier may perform queries against a
>             database, perhaps one maintained by a Manufacturer, to get
>             inputs. Alternatively, the root key of a key hierarchy may
>             be transferred in a one-time physical ceremony. This
>             architecture sets no protocol or procedure for this input.
>             The transfer of all these inputs to the Verifier does need
>             to be secured. For all cases, authenticity of the
>             Manufacturer and Verifier Owner and their inputs are
>             required. Without authentic inputs, the Verifier will not do
>             its job correctly. In some cases confidentiality of the
>             inputs is required. Finally, in some cases the Manufacturer
>             and Verifier Owner will authenticate the Verifier.
>             This architecture sets no requirement for a particular
>             protocol or security mechanism. For example, TLS could be
>             used, but it is not the only protocol that could be used,
> 
> 
>                 <mailto:dthaler=[email-masked]><mailto:dthaler=[email-masked]>>
>                 wrote:
> 
>                 I don’t like the term “Verifier Input” since “Appraisal
>                 Policy for Evidence” is also Verifier Input, so I would
>                 find it confusing.
>                 I think that the rules for what to put in Attestation
>                 Results (bullet 3), as well as “known-good/reference
>                 values” if such exist
>                 (and there can be valid policies where they may not
>                 exist, or rather where the policies use more complex
>                 rules than
>                 I do agree that Appraisal Policy can be conveyed to the
>                 Verifier in many different ways, and may be composed
>                 *From:*RATS <[email-masked]
>                 <mailto:[email-masked]><mailto:[email-masked]>>*On
>                 *To:[email-masked]
>                 <mailto:[email-masked]><mailto:[email-masked]>
>                 Stepping back a bit on the definition of an Endorsement,
>                 I think the four inputs to a Verifier are these:
>                 It seems like shoe-horning all of the above (except
>                 policy) into an Endorsement, like I’ve tried to do
>                   is too much. I tried this shoe-horning because I think
>                 the architecture document needs to cover all this and
>                 Endorsements was what was in it. A typical Endorsement
>                 seems to be just the first two mentioned, X.509 and
>                 signed documents expanding its definition to include
>                 database access is a stretch.
>                                         |              |for            
>                   | Appraisal
>                                         |              |Evidence        
>                 | Policy for
>                                         |              |                
>                 | Attestation
>                                         |              |                
>                 |  Result
>                 Endorsements must still be mentioned, but as one form of
>                 Verifier input just like EAT is one form of Attestation
>                 Evidence.
>                 have on Endorsements with a new PR. It will be a fair
>                 bit of work, so I want to see if there is some consensus
>                 first.
>                 LL
>                 [email-masked] <mailto:[email-masked]><mailto:[email-masked]>
>     IMPORTANT NOTICE: The contents of this email and any attachments are
>     confidential and may also be privileged. If you are not the intended
>     recipient, please notify the sender immediately and do not disclose
>     the contents to any other person, use it for any purpose, or store
>     or copy the information in any medium. Thank
>     you._______________________________________________
>     RATS 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.

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 7 Jul 2020 07:51:30 -0700

> On Jul 4, 2020, at 4:18 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

Sorry, didn’t say that right. 

If we’re going to minimize description of what is above the Verifier, then the term “Endorsement” should be replaced with a more general term like “Verifier Input” or “Attester Trust Criteria” or other.

I think there are three problems with the term “Endorsement":
- It implies a specific style of input (a signed document) that is too narrow for a general architecture
- It is ambiguous and/or not clear it is even correct. The room in Berlin of experts agreed that Endorsement can’t have keys in them, but there must be a key input to the Verifier.
- It is TCG-specific. The term is not used in FIDO, Android and TEE-based projects that I’ve worked on.

Some text like this?

Verifier Input

Inputs used by the Verifier to establish trust in Attester, evaluate Attestation Evidence and produce Attestation results. It may include cryptographic keys, known-good/reference values, static implicit claims and policy configuration.

LL

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 7 Jul 2020 17:29:51 +0200

Hi Laurence,

at first, I thought I get your line of thought, but now I am confused 
again. Sorry! Comments in-line.

On 07.07.20 16:51, Laurence Lundblade wrote:
> 
> 
>> On Jul 4, 2020, at 4:18 PM, Michael Richardson <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>> Laurence Lundblade <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>>> Laurence Lundblade <[email-masked] 
>>>> <mailto:[email-masked]>> wrote:
> If we’re going to minimize description of what is above the Verifier, 
> then the term “Endorsement” should be replaced with a more general term 
> like “Verifier Input” or “Attester Trust Criteria” or other.
> 

If that is what a reader gets from the document we have to do better. An 
endorsement does not have to be signed in the way that a UCCS does not 
have to be signed. It has to be tamper-evident though, because the 
Verifier relies on its integrity. That's the point and I think that is 
not too narrow.

> - It is ambiguous and/or not clear it is even correct. The room in 
> Berlin of experts agreed that Endorsement can’t have keys in them, but 
> there must be a key input to the Verifier.

Well, my recollection of that room of experts does not include any 
opinions on key material for Endorsements as defined for IETF RATS. The 
TCG defines (I just looked that up) four specific terms around and 
"Endorsement Key", so I am relatively sure that key material is involved 
in all cases, as these are the only terms that make use of the phrase 
endorsement.

> TEE-based projects that I’ve worked on.

And this confuses me. I'll do a self-quote here: "Endorsements as 
defined for IETF RATS". We are defining that term here in the RATS 
architecture. The TCG does not define it in any document that I could 
google just now. Maybe I have missed something there. But that is beside 
the point anyways. The point is that we are defining it here.

Viele Grüße,

Henk

> 
> 
> Some text like this?
> 
>     Verifier Input
> 
>     Inputs used by the Verifier to establish trust in Attester, evaluate
>     Attestation Evidence and produce Attestation results. It may include
>     cryptographic keys, known-good/reference values, static implicit
>     claims and policy configuration.
> 
> 
> LL
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Jul 2020 13:06:41 -0400

> like “Verifier Input” or “Attester Trust Criteria” or other.

I comprehend your point.

    > narrow for a general architecture

I don't agree that it has to be a signed document.
I think it could well be configuration information.
But, it might be that, being largely TCG-ignorant, I like the term because I view
it without TCG-approved-eyewear.

    > there must be a key input to the Verifier.

I would appreciate if Henk, or Dave could clarify this comment.
I can't see why it can't list a set of trust anchors to be used to verify
Evidence.  I assume that's the kind of keys you speak of.

    > cryptographic keys, known-good/reference values, static implicit claims
    > and policy configuration.

I'm okay with this description, but I don't understand the dislike for
endorsement.

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 7 Jul 2020 11:33:02 -0700

> On Jul 7, 2020, at 8:29 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Laurence,
> 
> at first, I thought I get your line of thought, but now I am confused again. Sorry! Comments in-line.
> 
>>> On Jul 4, 2020, at 4:18 PM, Michael Richardson <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>> 
>>> 
>>> Laurence Lundblade <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>>> Laurence Lundblade <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> If that is what a reader gets from the document we have to do better. An endorsement does not have to be signed in the way that a UCCS does not have to be signed. It has to be tamper-evident though, because the Verifier relies on its integrity. That's the point and I think that is not too narrow.

If you want to define an Endorsement as a *protocol*, not just a signed/unsigned document, then the term might work.

Endorsement Protocol:
 - A one-time transfer or a multiple requests/responses for each and every Verification or anything in between
 - Must provide integrity
 - May have to provide confidentiality, particularly for symmetric keys

> Well, my recollection of that room of experts does not include any opinions on key material for Endorsements as defined for IETF RATS. The TCG defines (I just looked that up) four specific terms around and "Endorsement Key", so I am relatively sure that key material is involved in all cases, as these are the only terms that make use of the phrase endorsement.

My slide in Berlin said “Endorsements have key material”. You that wasn’t right. I said “sorry for my mistake”. The room tacitly agreed with you.

This says to me that at least one of these is true:
 - There is some pre conceived idea for what Endorsements are, seemingly from the the TCG world
 - There is confusion about what Endorsements are (you said no keys in Berlin, now you say there are keys)
 - RATS architecture is not clear about how verification key material gets to the Verifier.

I don’t mind being wrong here. My trouble is the lack of clarity, common understanding and gap in the RATS architecture.

> And this confuses me. I'll do a self-quote here: "Endorsements as defined for IETF RATS". We are defining that term here in the RATS architecture. The TCG does not define it in any document that I could google just now. Maybe I have missed something there. But that is beside the point anyways. The point is that we are defining it here.

Seems to me there are semantics associated with the term “Endorsement” from the TCG and that seems to be of a relatively static document that is transferred once. It seems like adopting a definition in RATS that is beyond that is confusing (e.g., confusion between now and Berlin).  If we must use the term Endorsement, then I think it should Endorsement Protocol to separate from the previous.

I still think this is simple and could work:

Verifier Input

LL

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 7 Jul 2020 21:31:28 +0200

On 07.07.20 20:33, Laurence Lundblade wrote:
> 
> 
>> On Jul 7, 2020, at 8:29 AM, Henk Birkholz 
>>>> <mailto:[email-masked]><mailto:[email-masked]>> wrote:
>>>>
>>>>
>>>> <mailto:[email-masked]><mailto:[email-masked]>> wrote:
>>>>>> <mailto:[email-masked]><mailto:[email-masked]>> wrote:
>>> then the term “Endorsement” should be replaced with a more general 
>>> term like “Verifier Input” or “Attester Trust Criteria” or other.
>> If that is what a reader gets from the document we have to do better. 
>> An endorsement does not have to be signed in the way that a UCCS does 
>> not have to be signed. It has to be tamper-evident though, because the 
> If you want to define an Endorsement as a *protocol*, not just a 
> signed/unsigned document, then the term might work.
> 
> Endorsement Protocol:
>   - A one-time transfer or a multiple requests/responses for each and 
> every Verification or anything in between
>   - Must provide integrity

I'd think that would be a little bit too much for an architecture, but 
to generally associate attributes, such as authentic and tamper-evident, 
with conceptual messages that are endorsements sounds fine for me at 
first glance.

Solution I-Ds can build on that as is the intent of the architecture 
document.

>>> Berlin of experts agreed that Endorsement can’t have keys in them, 
>>> but there must be a key input to the Verifier.
>>
>> opinions on key material for Endorsements as defined for IETF RATS. 
>> The TCG defines (I just looked that up) four specific terms around and 
>> "Endorsement Key", so I am relatively sure that key material is 
>> involved in all cases, as these are the only terms that make use of 
>> the phrase endorsement.
> 
> My slide in Berlin said “Endorsements have key material”. You that 
> wasn’t right. I said “sorry for my mistake”. The room tacitly agreed 
> with you.

Maybe we were talking past each other? Going back to the examples I 
looked up: TCG EK-Certs, for example, can include pub-keys, of course. 
If you remember the openssl output of my screen - there were some 
pub-key structures in there. But then again, I would not focus on these 
kinds of certificates here - that seems way to niche'ish. I would rather 
like to focus on what we create here, currently (which allows for 
multiple types of Endorsements already).

> I don’t mind being wrong here. My trouble is the lack of clarity, common 
> understanding and gap in the RATS architecture.

I am little bit at a loss why you think that the definition here:

> https://tools.ietf.org/html/draft-ietf-rats-architecture-04#section-2

and the associated expositional text here:

> https://tools.ietf.org/html/draft-ietf-rats-architecture-04#section-8.2

is leaving any confusion to what Endorsements are?

Key Provisioning is a separate topic, I think. And I am now growing more 
certain that you are missing text about key provisioning in the RATS 
architecture document, yes?

For me that represent a tangible issue. The architecture document does 
not directly address key provisioning - that is certainly true. But I am 
not sure, if there is any intent to add text about that to a RATS 
document. Are there opinions on the list about this?

Viele Grüße,

Henk

>> google just now. Maybe I have missed something there. But that is 
>> beside the point anyways. The point is that we are defining it here.
> 
> Seems to me there are semantics associated with the term “Endorsement” 
> from the TCG and that seems to be of a relatively static document that 
> is transferred once. It seems like adopting a definition in RATS that is 
> beyond that is confusing (e.g., confusion between now and Berlin).  If 
> we must use the term Endorsement, then I think it should Endorsement 
> Protocol to separate from the previous.
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Jul 2020 19:59:27 -0400

> - RATS architecture is not clear about how verification key material

The RATS architecture is INTENTIONALLY unclear, as it's out of scope for this
(charter) round.