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

[Michael Richardson <[e-mail]>]

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)

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.

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.

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.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-