Subject: Re: [Rats] should base architecture mandate a distributed structure for Endorsements

From: "Smith, Ned" <[email-masked]>
Date: Fri, 4 Sep 2020 15:57:41 +0000

Conveyance of verification keying material would be included given the expectation that the Endorsement arrow is intended to be inclusive (“exhaustive”) of everything an Endorser (mfg, supplyer, vendor) might convey to a Verifier. Given that as a starting condition, there isn’t anything that someone can come up with that this version of the architecture filters / restricts.

Are we OK with the wording in rev 6 of the architecture draft in this regard?
-Ned

From: RATS <[email-masked]> on behalf of Laurence Lundblade <[email-masked]>
Date: Tuesday, August 4, 2020 at 1:07 PM
To: Henk Berkholz <[email-masked]>
Cc: Michael Richardson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Rats] should base architecture mandate a distributed structure for Endorsements

below.

On Aug 3, 2020, at 10:44 PM, Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:

A single vital comment in-line:

On 01.08.20 21:37, Laurence Lundblade wrote:

On Aug 1, 2020, at 8:48 AM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

...

There are other use cases in which the Verifier will be configured with all
the information that it needs.  Is a configuration file, loaded by a trusted
operator, a "secure statement"?
I think so, and this is why we used this wording. (B)
My view is that the arrows in the diagram show the complete and exhaustive inputs of relevance to attestation.

Probably adjusting the expectations of the arrows in the diagrams wrt to "completeness" can mitigate this issue at it's root?

Not sure what you’re thinking.

My main thought is that verification key material is one of the most important things in the architecture. It should be explicitly discussed in the architecture (like nonces) and it must be go over the arrow between the Endorser/Manufacturer and the Verifier.

LL