Re: [Rats] Minimizing the Attestation Results objects which can represent overall Attester trustworthiness

["Eric Voit (evoit)" <[e-mail]>]

Hi Henk,

Yes.   To me, the Verifier is interesting because it is responsible for the
*hard* problem: can I trust you at all?  Only when general aspects of
trustworthiness established are specific claim sets actually
helpful/actionable.

If the WG accepts this premise, then how do we (as a community) converge on
the general aspects of trustworthiness?   That is that the conversation the
design principles below is attempting to start. 

Eric

> From: Henk Birkholz, August 16, 2021 3:29 PM
> 
> Hi Eric,
> 
> what you are highlighting here, I think, is an important distinction.
> There are two "layers" of Attestation Result Claims here. (1) Attestation
Results
> about the intrinsic trustworthiness characteristics of an Attester and (2)
> Attestation Results that a Relying Party can trust, because they are about
an
> Attester associated with such trustworthiness characteristics.
> 
> I-D.voit-rats-attestation-results I believe is strictly scoped to the
former set (1)
> of Attestation Result Claims. These Attestation Results (the
Trustworthiness
> Claims) MUST always be generated by a Verifier's appraisal procedure. It
is
> virtually impossible that only a signature (or secure channel)
verification will be
> enough to allow for the generation of Trustworthiness Claims (basically
the only
> assurance generated by that would be a proof-of-possession that implies
"trust
> everything I do, because it is 'I, the key holder' doing it").
> 
> To enable interoperable "understanding" of Trustworthiness Claims, their
> number must be suitable small, unambiguously actionable by Relying Parties
and
> they must, of course, be Verifier generated and never Attester generated.
> 
> Set (2) of Attestation Results can be vastly more refined, specific,
expressive or
> voluminous, I think (and potentially also even Attester generated). The
swresult
> Claim highlighted, I think is an excellent example of a highly versatile
Verifier
> generated Claim that conveys additional context information to a Relying
Party.
> 
> Viele Grüße,
> 
> Henk
> 
> On 10.08.21 23:00, Eric Voit (evoit) wrote:
> > Hi Laurence,
> >
> > During the RATS IETF 111 sessions, we both shared views of how to
> > encode Attestation Results (AR).   From the perspective of
> > draft-voit-rats-attestation-results, the AR in scope are Verifier
> > generated claims* about trustworthiness of the Attester itself.   Some
> > examples of such claims include:
> >
> >   * the Verifier asserts that the Attester has only known good software
> >     loaded
> >   * the Verifier asserts Attester's configuration doesn't expose
> >     security holes
> >
> > We are now beginning to standardize these Verifier generated claims
> > (and associated AR object definitions).   We need to do this with the
> > stated objective of maximally simplifying the interworking of
> > different types of Attesters, Verifiers, and Relying Parties.  That
> > maximal simplification is essential as we diverse group of RATS roles
> > and developers spanning different industries.  And to accomplish this,
> > I suggest we adopt the following set of design principles:
> >
> > (1) We should only have a small number of Verifier trustworthiness
> > claims standardized at this time.  Reason: a plethora of similar
> > trustworthiness claims will result in divergent choices made between
> > different Verifiers.  This would place a lot of complexity in the
> > Relying Party as it would be up to the RP (and its policy language) to
> > enable normalization across rich incompatible Verifier object
definitions.
> >
> > (2) Any objects from (1) which we do standardize should only include
> > specific enumerated states that could viably result in a different
> > action from the applied Policy for Attestation Results.   Reason: by
> > explicitly disallowing the standardization of any enumerated states
> > which cannot easily be connected to a use case, we avoid forcing
> > implementers making incompatible guesses on what could happen.  This
> > will eliminate many types of errors.
> >
> > (3) Verifier and RP developers need explicit definitions of *each*
> > state in order to accomplish the goals of (1) and (2).  Without such
> > guidance, the Verifier will send plenty of raw info, as it relieves
> > the Verifier of making the hard decisions.  Of course, this raw info
> > will be mostly non-interpretable and therefore non-actionable by the RP.
> >
> > (4) We do need extensibility for this type of Verifier generated claim.
> > But Verifier generated claims should be worked in the WG and managed
> > via the RFC process, rather than being in a separately maintained
> > Attester Claims list.  This will keep a tight lid on extensions which
> > must be considered by the RP's policy language.
> >
> > These design principles are important to keep the number of Verifier
> > generated claims low, and to retain the complexity in the Verifier
> > rather than the RP.   We followed these design principles in
> > draft-voit-rats-attestation-results.   Consequently, the next version
> > of draft-voit-rats-attestation-results will include a total of 9
> > Verifier generated Trustworthiness Claims supporting a total of 18
> > enumerated states.   18 enumerated states feels like an easily
> > digestible number for the developers of RP policy language :-).
> >
> > I am hoping we can connect this thinking to your swresult object from
> > your IETF 111 slides.   Looking at your slide on the swresult claim,
> > *each* software measurement could include a large array of results.  I
> > believe this unbounds the complexity of the RP policy language.
> > Effectively, the Evidence to the Relying Party may often be richer
> > than that originally sent by the Verifier.  In what scenarios do you
> > see Relying Party applying such a rich language?   And at least from
> > the perspective of deciding whether Attester itself is trustworthy, do
> > you see ways for just a few Verifier generated claims to expose key
> > trustworthiness attributes and states evaluated for the Attester?
> >
> > I know this is a complex question which might only be worked in an
> > upcoming interim.  But I figured I would start the dialog now.
> >
> > Thanks,
> >
> > Eric
> >
> > * Note from above: these Verifier generated claims are not the same
> > thing as a Verifier ratifying specific claims generated within the
> > Attester (such as UEID, location, software manifest, etc.)   Many of
> > your AR definitions within the swresult appear aimed at this context.
> > So there might not be an explicit overlap between our drafts.
> >
> > Eric Voit
> >
> > Principal Engineer
> >
> > *.:|:.:|:. *Cisco Systems, Inc.
> >