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

[Henk Birkholz <[e-mail]>]

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 <[e-mail]> wrote:
>>
>>
>> There is some discussion in private, on github and in the architecture DT
>> calls around the question of Endorsements.
>>
>> There is a pull request at:
>>    https://github.com/ietf-rats-wg/architecture/pull/94
>> text.  The text is
>>    https://github.com/ietf-rats-wg/architecture/pull/94/files,
>> and I suggest that new readers go to the three dots and unselect "Show comments"
>>
>> But, I include the text:
>>
>>   - An Endorsement is a secure statement that some entity (e.g., a
>>   - manufacturer) vouches for the integrity of the
>>   - device's signing capability.  For example, if the signing capability is in hardware, then
>>   - an Endorsement might be a manufacturer certificate that signs a public key whose corresponding
>>   - private key is only known inside the device's hardware.
>>
>>   + An Endorsement input to a Verifier is always required. An Endorsement is
>>   + what allows a Verifier to trust an Attester and in turn to trust the Evidence
>>   + produced by an Attester. Without Endorsements a Verifier cannot function.
>>   + Said another way, an Attester for which there is no Endorsement is not
>>   + useful since there is no good basis by which a Verifier can trust it.
>>
>>   + One of the Endorsements for an Attester will just about always contain
>>   + cryptographic key material.
>>   + This key material will correspond to key material that is put in the Attester.
>>   + The key material is the basis for the Verifier trusting the Attester.
>>   + This architecture does not dictate any particular cryptographic protocol
>>   + for establishing this trust, hence the key material can be symmetric or
>>   + asymmetric, a single key, multiple keys, key hierarchies, X.509 cert or
>>   + chains or other.
>>
>> I think that we get into conflict immediately on the first sentence.
>>
>> There ARE many use cases in which we WILL need input to the
>> Verifier from a variety of manufacturers in a signed artifact form.(A)
>>
>> 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?

> The one and only input from the Manufacturer/Endorser to the Verifier is the Endorsement. If there is a configuration file (with keys) transferred from the Manufacturer/Endorser to the Verifier, it would be going over the arc labeled Endorser in the diagram.
> 
> I think this is true of every arrow/arc in Figure 1. I don’t think are alternate channels. It seems confusing to tacitly expect the reader to assume them.
> 
> Even if it weren’t true, the key material is critical and fundamental to attestation that its transfer needs to upfront and clear. You can do attestation with just a key and a nonce and nothing else. You can’t do attestation without a key and nonce. We have pages of discussion on nonces.
> 
> The most important thing transferred from Manufacturer/Endorser to the Verifier is the verification key material. It should be characterized clearly and should allow for all types of keys and transfer scenarios.
> 
>>
>> When I read the changes above, it seems to me that it contains aspirational
>> text that intends to make case (A) universal.
>>
>> I think that a number of us believe that an Endorsement is the name for a
>> signed artifact.  This may be the basis for our disagreement: I'm not entirely sure.
>> Our definition of "Endorsement" does not say that, so it may be that I read
>> too much into the proposed changes.
> 
> Endorsement being a “signed artifact” seems like common understanding in the TCG world to me.
> 
> If we want to stick with that definition, that is fine, but that excludes Endorsements as a means to convey symmetric keys, databases of keys and the operation of a key look up service and a hash verification service. So then we need to switch to a term like Verifier Input with Endorsements being one form of Verifier Input.
> 
> 
>>
>> I firmly believe that we will need an Architecture for Distributed Endorsements.
>> I also think that we can do this separately, and that there are probably
>> reasons for some industrial verticals to do this on their own.
> 
> Agree with that.
> 
> I’m only after a few paragraphs of high-level characterization. Nothing as detailed as the nonce discussion.
> 
>>
>> It could be that this is not the goal of the above text.
>>
>> I do not think we need this level of detail in this part of the architecture.
>> It's not wrong, it's just not helpful, I think.
> 
> What’s different about the Endorser-Verifer-Attester trust relationship is that it is transitive in a unique and important way for attestation. I think bringing that to light in a clear way is necessary.
> 
> LL
> 
> 
>>
>> --
>> Michael Richardson <[e-mail]>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>>
>>
>> _______________________________________________
>> RATS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rats
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>