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

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 10 Aug 2021 21:00:23 +0000

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.

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 16 Aug 2021 21:29:00 +0200

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:
> 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:
> 
> 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.
> 
> 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 
> (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.
> 
> generated claims low, and to retain the complexity in the Verifier 
> rather than the RP.   We followed these design principles in 
> 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.
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 16 Aug 2021 21:53:58 +0000

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,
> 
> 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.
> 
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
> number must be suitable small, unambiguously actionable by Relying Parties
and
> they must, of course, be Verifier generated and never Attester generated.
> 
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.
> > During the RATS IETF 111 sessions, we both shared views of how to
> > encode Attestation Results (AR).   From the perspective of
> > 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:
> >
> > (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.
> >
> > 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.
> >
> > 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 :-).
> >
> > 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

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 16 Aug 2021 22:28:26 -0700

Hi Eric,

Really glad we’re having a discussion on attestation results now. Kind of a coincidence we both focused on it at 111.

> On Aug 10, 2021, at 2:00 PM, Eric Voit (evoit) <evoit=[email-masked]> 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.

I assume these claims would be in the CWT and JWT registry like other claims and that they have no special status in those registries. We’re not creating a new registry for these, nor are we going to modify the CWT or JWT registries so they can have special status, right?

I also assume we should clarify that EAT profiles apply to attestation results and/or evidence and that is the mechanism used to keep a handle on the number of claims in attestation results.

I would like to add this important design principle:

(5) Cover the full range of use cases, device types and security levels. Use cases may include letting a device on the network, a financial transaction, a biometric authentication and more. Device types may include complex mobile phones, simple IoT sensors, laptops and network equipment. Security levels may range from EAL 5 certified secure element, to a TEE, to entirely simple minimal devices with no special security properties.

>  
> 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 think there may be more than one model for constructing attestation results.  Your draft is one. Another might be based on machine learning, in which case the RP just wants every data item possible. I think a single  “trust me” boolean is OK for some use cases. Maybe the boolean is implied because attestation results were generated.

This also fans out by submodule for complex devices, even with draft-voit-rats-attestation-results (there is no inheritance with submodules).

> 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?

Swresults was intended as a flexible way to report what ever SW measurement results need to be reported. It is intended to cover all possible cases. I would expect many use cases to use very little of it. Many, hopefully, most could be very simple using it.

Swresults also can be in attestation evidence when one subsystem like a TEE can measure and evaluate another subsystem.

I’m not sure the principles above should be applied to swresults as I think it is for a different model for reporting attestation results. Open to discussion on this.

Swresults is kind of a first proposal. Would appreciate lots of discussion around it. Seems to me that we’re just getting started on this topic.

>  
> I know this is a complex question which might only be worked in an upcoming interim. 

Probably more than just one interim :-)

LL

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 17 Aug 2021 15:13:56 +0000

Hi Laurence,

From: Laurence Lundblade, August 17, 2021 1:28 AM

Hi Eric,

Really glad we’re having a discussion on attestation results now. 

<eric> Yes, this is good and necessary.

Kind of a coincidence we both focused on it at 111.

<eric> Actually, core of the Verifier generated AR is the " trustworthiness-level" of draft-voit-rats-trusted-path-routing-00  (Feb 2020   :-).   At the interim, I would love to show off some production code.  We didn't have time for it in IETF 111.

On Aug 10, 2021, at 2:00 PM, Eric Voit (evoit) <evoit=[email-masked] <mailto:evoit=[email-masked]> > wrote:

Hi Laurence,

*	the Verifier asserts that the Attester has only known good software loaded     
*	the Verifier asserts Attester's configuration doesn't expose security holes

<eric> I believe the claims can go into the registry without any special status.  As the claims will need to be encoded in other contexts such as YANG and EAP/TLS  the authoritative object definitions should be defined in drafts/RFCs which then get imported to the necessary registries.

<eric> As long as the WG has a firm hand on specific standardized claim definitions, and there is space for vendor defined claims, I am good.

<eric> Works for me.   Each device will need to specify which claims are realistically supportable based on the underlying hardware.

<eric> For a couple years Boolean seemed sufficient to me.   However just a month ago Thomas Fossati convinced me that a boolean was not as flexible as a signed integer, and various integer values other than "1" can be used to express standard and non-standardized failure reason codes.  A new draft should be posted by the Attestation Results authors on this in ~1 week.

<eric> Routers can get very complex, with multiple control/supervisory cards and dozens of line cards.  Each have their own Attesting Environments.   My experience is that as the Attester gets more complex, the interfacing Relying Party device depends more-and-more on a single summary result for the device before deciding whether to trust.   From there, specific claims from submodules might be useful, but at least in the Routing/Switching world I haven't seen that yet beyond specific hardware protected identities.   (Note: the Verifier developers have always wanted to provide voluminous details on how smart they are.  But the Relying Party has consistently said that it is up the Verifier to make these hard decisions.  And it is the Relying Party which gets to choose if they use the Attestation concept at all.)

<eric> I will be interested in where this goes, as I see it as a way of potentially documenting supporting evidence beyond the Trustworthiness Vector.  I moved Thomas F to the 'to' as I know he has been thinking about this as well.

<eric> Agree.

Eric

LL

Thanks,

Eric

Eric Voit 

Principal Engineer

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

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 17 Aug 2021 20:03:52 -0700

AR = Attestation Results
AE = Attestation Evidence

See below.

> On Aug 17, 2021, at 8:13 AM, Eric Voit (evoit) <evoit=[email-masked]> wrote:
> 
> Hi Laurence,
>  
> On Aug 10, 2021, at 2:00 PM, Eric Voit (evoit) <evoit=[email-masked] <mailto:evoit=[email-masked]>> wrote:
> <removed discussion that mentioned AR claims>
>  

Just focusing in on the claim encoding formats (CBOR, JSON, YANG…) for AR here.

Thus far we have some AE in CDDL -> CBOR/JSON and some different AE in YANG and some thought of CDDL -> ASN.1. 

Looks like there’s some CBOR embedded in YANG in raft-voit-rats-trusted-path-routing (it says CDDL in YANG, but I expect you mean CBOR).

What is your thinking for AR?

Would YANG ever be used to convey AR?

Are you planning to use CDDL to define claims? If not how will you define a claim in CBOR, JSON and YANG (and ASN.1)?

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 18 Aug 2021 14:24:28 +0000

Hi Laurence,

From: Laurence Lundblade, August 17, 2021 11:04 PM

AR = Attestation Results

See below.

On Aug 17, 2021, at 8:13 AM, Eric Voit (evoit) <evoit=[email-masked] <mailto:evoit=[email-masked]> > wrote:

Hi Laurence,

<eric> There are RFCs/drafts documenting how the YANG modeling language is encoded in JSON, XML, CBOR.

<eric> YANG is massively verbose.  CDDL is intentionally the opposite.  Both are modeling languages.

While YANG can be described with CBOR (see draft-ietf-core-yang-cbor), the implementers I know tend to stick to tooling ecosystems aligned to one of those modeling languages.  Therefore to maximize object portability the YANG constructs shown are mapped to CDDL before then being encoded in CBOR.  This allows an easy 1:1 integration of objects between the two tooling ecosystems.  (I will tweak the draft to make this linkage explicit.) 

<eric> The Verifier must generate its content in whatever format the Relying Party can consume/understand.  

<eric> It already is.

<eric> We already do.  The stamped passport of draft-voit-rats-trustworthy-path-routing section 4.2.4 is shown modeled in YANG.  We have done an equivalent mapping to CDDL for the reasons described above.  The results is encoded in a combination of CBOR with certain substructures encoded using raw definitions coming out of the TPM.  And that combination itself may need to be inserted into ASN.1 structures in order to work with embedded RADIUS Authentication.  

Having multiple types of encoding used in one structure is not for fun, it is because we are integrating a diverse set of embedded developer ecosystems.    Note: this is one of the reasons that we recently split out draft-voit-rats-attestation-results.   It allows the exposure of conceptual AR structures without depending on a specific encoding or the constraints of a developer ecosystem.

Eric

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 25 Aug 2021 18:11:55 +0000

A few observations about Attestation Results are summarized here.

  1.  AR standards should make it easy for simple results. If Boolean is too simple, then something close like true, false and inconclusive.
  2.  Some RPs are auditors and care about voluminous details for forensic purposes. The ARs might also include all of the Claims asserted by Attester / Attesting Environments, Endorsers and the Verifier. Possibly it makes sense to archive these results and pass a pointer to the archive to a RP?
     *   It may be helpful to partition claims according to who is speaking (Attester, Endorser, Verifier).
     *   Attester can assert Claims as Evidence (that should be compared with Reference Values. It can also assert Claims that it makes on its own authority (as a trustworthy entity).
  3.  Verifiers can assert Claims that are meaningful to RPs that involve some form of inference beyond (2) but less than (1). These Claims likely are use-case / RP specific. Maybe it doesn’t make sense to define appropriate extension points rather than drive for definitions right now?
See also comments in green <nms> below.

From: RATS <[email-masked]> on behalf of "Eric Voit (evoit)" <evoit=[email-masked]>
Date: Tuesday, August 17, 2021 at 8:14 AM
To: Laurence Lundblade <[email-masked]>, Thomas Fossati <[email-masked]>
Cc: rats <[email-masked]>, vincent r scarlata <[email-masked]>, Henk Berkholz <[email-masked]>, Thomas Hardjono <[email-masked]>
Subject: Re: [Rats] Minimizing the Attestation Results objects which can represent overall Attester trustworthiness

Hi Laurence,

On Aug 10, 2021, at 2:00 PM, Eric Voit (evoit) <evoit=[email-masked]<mailto:evoit=[email-masked]>> wrote:

Hi Laurence,

  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.
<nms> +1

  1.  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.
<nms> +1 with a preference for AR structures that focus first on Ned’s (1) and (2) with extension points for (3) above.

  1.  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.
<nms> This could be understood in terms of Ned’s (2) and (3) above. Maybe helpful to avoid conflation.

  1.  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.
<nms> +1 If the AR structure comprehends which Claims are appraised and accepted, appraised and not accepted, inconclusive, inferred (created by the Verifier) or passed through, then RPs will have the proper context for doing auditing / cross-checking appraisals.

I also assume we should clarify that EAT profiles apply to attestation results and/or evidence and that is the mechanism used to keep a handle on the number of claims in attestation results.
<eric> As long as the WG has a firm hand on specific standardized claim definitions, and there is space for vendor defined claims, I am good.
<nms> I don’t think Claims should be stereotyped as Evidence, Endorsement, AR etc… They should focus on describing an informational content. Who (attestation role) asserts the Claim is what makes it Evidence, Endorsement or AR. Since vendors often invent new things, it is appropriate for them to name them too. The RATS Arch refers to Target and Attesting ‘Environments’ which can be named things. Claims can (and should) describe environments in addition to trustworthiness properties of those environments.

(5) Cover the full range of use cases, device types and security levels. Use cases may include letting a device on the network, a financial transaction, a biometric authentication and more. Device types may include complex mobile phones, simple IoT sensors, laptops and network equipment. Security levels may range from EAL 5 certified secure element, to a TEE, to entirely simple minimal devices with no special security properties.
<eric> Works for me.   Each device will need to specify which claims are realistically supportable based on the underlying hardware.
<nms> Profiles seem appropriate for this objective.

I think there may be more than one model for constructing attestation results.  Your draft is one. Another might be based on machine learning, in which case the RP just wants every data item possible. I think a single  “trust me” boolean is OK for some use cases. Maybe the boolean is implied because attestation results were generated.
<eric> For a couple years Boolean seemed sufficient to me.   However just a month ago Thomas Fossati convinced me that a boolean was not as flexible as a signed integer, and various integer values other than "1" can be used to express standard and non-standardized failure reason codes.  A new draft should be posted by the Attestation Results authors on this in ~1 week.
<nms> tri-state result is a simple but not too simple expression. E.g. (a) accepted claims, (b) not accepted claims and (c) inconclusive / ignored claims. A profile can define which claims MUST be in (a) and MAY be in (b) or (c).

This also fans out by submodule for complex devices, even with draft-voit-rats-attestation-results (there is no inheritance with submodules).
<eric> Routers can get very complex, with multiple control/supervisory cards and dozens of line cards.  Each have their own Attesting Environments.   My experience is that as the Attester gets more complex, the interfacing Relying Party device depends more-and-more on a single summary result for the device before deciding whether to trust.   From there, specific claims from submodules might be useful, but at least in the Routing/Switching world I haven't seen that yet beyond specific hardware protected identities.   (Note: the Verifier developers have always wanted to provide voluminous details on how smart they are.  But the Relying Party has consistently said that it is up the Verifier to make these hard decisions.  And it is the Relying Party which gets to choose if they use the Attestation concept at all.)
<nms> the concept of claims inheritance should be better defined / explained. Transitive trust could be described as a form of ‘inheritance’. There is pretty good math on transitive trust properties and notation for describing sequences of transitivity. Most often trust is all or nothing in normal circumstances.

Swresults also can be in attestation evidence when one subsystem like a TEE can measure and evaluate another subsystem.
<nms> Agree. Once a node is determined to be trustworthy (via attestation or otherwise) it can make new Claims that are acceptable without Reference Values. We don’t have terminology for this in RATS Arch (I think), but the closest to this is AR and Endorsements but we don’t say that an Attester (Attesting Env) can assert AR or Endorsements. I think it’s a gap in the arch but others may disagree.

<eric> Agree.

Eric

LL

Thanks,
Eric

Eric Voit
Principal Engineer

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 25 Aug 2021 19:47:45 +0000

Hi Ned,

Thanks for this.  Some thoughts in-line...

From: Smith, Ned, August 25, 2021 2:12 PM

<eric2> This makes sense, you and Thomas have shown good reasons to move away from Boolean.  

Building from your tri-state suggestion, what do you think about general Trustworthiness Claims which are given a value indicating:

*	Trustworthy: The Verifier affirms the Attester support for this aspect of trustworthiness  (instead of True)
*	Warning: The Verifier warns about this aspect of trustworthiness (expands on Inconclusive)
*	Contraindicated: The Verifier does not support this aspect of trustworthiness (instead of False)
*	None: There simply is no claim asserted. (is a special case of Inconclusive)

<eric2> I agree we need to support Relying Parties that wants simplicity, as well as Verifiers, Auditing RPs, and more robust RPs that want details.   Thomas suggested doing this with a signed 8 bit integer.   The integer meaning would be the same across any encoding type.  And the integer space could be broken down something like the following:

*	Trustworthy:   Values 1-31: Each value provides a single standards enumerated reason for affirming the Trustworthiness Claim, values -1 to -32 can indicate a non-standard reason for affirming.
*	Warning:   Values 32-63: A standards enumerated reason for the warning, values -33 to -64: a non-standard reason for the warning.
*	Contraindicated:  Values 64-127: A standards enumerated reason for the contraindication,  values -65 to -128: a non-standard reason for the contraindication.
*	None: Value 0, which is interpreted identically to the Trustworthiness Claim not being present.  

The benefits of such a scheme include:

*	A simple RP can have a Policy for Attestation Results which is as simple as: "Only allow connectivity where the set of provided Trustworthiness Claim values are 'Trustworthy' ".
*	A more robust RP can work from a specific reason encoded in the value ranges above.
*	An auditing RP gets standard values, and each value can then act as a hook for extended details which might be includes in the Attestation Results.

a.	It may be helpful to partition claims according to who is speaking (Attester, Endorser, Verifier).

<eric2> Agree.   At this point the draft has just aimed at Verifier Claims.  Certainly we need provenance provably understood for all elements in the AR.

b.	Attester can assert Claims as Evidence (that should be compared with Reference Values. It can also assert Claims that it makes on its own authority (as a trustworthy entity). 

<eric2> Agree.  And these Claims would be even more believable when the Verifier vouches for general aspects of the Attester :-).

<eric2> Ok.  But if we start from Thomas F's thinking, we might have a workable approach for both.  Pending any objections/suggestions, look for a draft-voit-rats-attestation-results revision shortly which makes an attempt at both.

 

From: RATS < <mailto:[email-masked]> [email-masked]> on behalf of "Eric Voit (evoit)" < <mailto:evoit=[email-masked]> evoit=[email-masked]>
Date: Tuesday, August 17, 2021 at 8:14 AM
To: Laurence Lundblade < <mailto:[email-masked]> [email-masked]>, Thomas Fossati < <mailto:[email-masked]> [email-masked]>
Cc: rats < <mailto:[email-masked]> [email-masked]>, vincent r scarlata < <mailto:[email-masked]> [email-masked]>, Henk Berkholz < <mailto:[email-masked]> [email-masked]>, Thomas Hardjono < <mailto:[email-masked]> [email-masked]>
Subject: Re: [Rats] Minimizing the Attestation Results objects which can represent overall Attester trustworthiness

Hi Laurence,

Hi Eric,

 

 

Hi Laurence,

<nms> +1

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.

<eric2> Agree.  

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.

<eric2> Works for me.

 

<eric2> Yes, the new proposal above is based on tri-state :-).

<eric2> This does seem a meaningful space for submissions.  The need is certainly highlighted in draft-ietf-rats-architecture, Figure 4.

<eric2> Agree it is a gap.  What you are talking about above is the interplay of specific instances or classes of claims.  Only now are we even in a position to have that conceptual discussion.

/Eric2

 

<eric> Agree.

Eric

LL

 

Thanks,

Eric

Eric Voit 

Principal Engineer

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 25 Aug 2021 23:46:25 +0000

See inline <nms2>

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wednesday, August 25, 2021 at 12:49 PM
To: "Smith, Ned" <[email-masked]>, Laurence Lundblade <[email-masked]>, Thomas Fossati <[email-masked]>
Cc: rats <[email-masked]>, vincent r scarlata <[email-masked]>, Henk Berkholz <[email-masked]>, Thomas Hardjono <[email-masked]>
Subject: RE: [Rats] Minimizing the Attestation Results objects which can represent overall Attester trustworthiness

Hi Ned,

<nms2> An error state might make sense which always implies ‘None’

  1.  Some RPs are auditors and care about voluminous details for forensic purposes. The ARs might also include all of the Claims asserted by Attester / Attesting Environments, Endorsers and the Verifier. Possibly it makes sense to archive these results and pass a pointer to the archive to a RP?
<eric2> I agree we need to support Relying Parties that wants simplicity, as well as Verifiers, Auditing RPs, and more robust RPs that want details.   Thomas suggested doing this with a signed 8 bit integer.   The integer meaning would be the same across any encoding type.  And the integer space could be broken down something like the following:

<nms2> The profile context is also needed. Profiles can indicate which Appraisal Policies for Evidence (APE) are to be applied. An APE might be broken into several statements. The warning / contradicted states might justify listing the APE statements that were not satisfied. APE statements could be OIDs or UUIDs or actual policy expressions. The integer result code ranges Thomas F. proposed seem like a form of APE statements that are commonly understood and standardized. I don’t know that it satisfies “non-standard” or Owner defined results however as these will require some form of additional contextualization. If the profile is identified as part of the Attestation Results, then this goes a long way toward contextualizing the APE statements. APE statements have to be fairly concretely defined and the output is likely tri/multi-state as well. The Verifier can easily have a built in ‘all-or-nothing’ policy for ‘Trustworthy’ and ‘None’ (i.e., where all APE statements are accepted or none are) while ‘Warning’ and ‘Contraindicated’ will be cases where some of the APE statements were satisfied while others were not. Note: It would be possible to put a fine point on ‘contraindicated’ as APE statements that satisfied a deny condition.

If there is consensus over a set of ‘standard’ APE statements then mapping them to an integer field is a fine way to represent it and seems to align semantically with what Thomas F. is describing. But otherwise, the AR should include the profile(s) and APE statements as context for the quad/pent-state result.

  1.  Verifiers can assert Claims that are meaningful to RPs that involve some form of inference beyond (2) but less than (1). These Claims likely are use-case / RP specific. Maybe it doesn’t make sense to define appropriate extension points rather than drive for definitions right now?
<eric2> Ok.  But if we start from Thomas F's thinking, we might have a workable approach for both.  Pending any objections/suggestions, look for a draft-voit-rats-attestation-results revision shortly which makes an attempt at both.

From: RATS <[email-masked]<mailto:[email-masked]>> on behalf of "Eric Voit (evoit)" <evoit=[email-masked]<mailto:evoit=[email-masked]>>
Date: Tuesday, August 17, 2021 at 8:14 AM
To: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>, Thomas Fossati <[email-masked]<mailto:[email-masked]>>
Cc: rats <[email-masked]<mailto:[email-masked]>>, vincent r scarlata <[email-masked]<mailto:[email-masked]>>, Henk Berkholz <[email-masked]<mailto:[email-masked]>>, Thomas Hardjono <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Minimizing the Attestation Results objects which can represent overall Attester trustworthiness

Hi Laurence,

Hi Laurence,

/Eric2

<eric> Agree.

Eric

LL

Thanks,
Eric

Eric Voit
Principal Engineer

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 26 Aug 2021 16:16:18 +0000

Hi Ned, see inline  <eric3>

From: Smith, Ned, August 25, 2021 7:46 PM

See inline <nms2>

From: "Eric Voit (evoit)" < <mailto:[email-masked]> [email-masked]>
Date: Wednesday, August 25, 2021 at 12:49 PM
To: "Smith, Ned" < <mailto:[email-masked]> [email-masked]>, Laurence Lundblade < <mailto:[email-masked]> [email-masked]>, Thomas Fossati < <mailto:[email-masked]> [email-masked]>
Cc: rats < <mailto:[email-masked]> [email-masked]>, vincent r scarlata < <mailto:[email-masked]> [email-masked]>, Henk Berkholz < <mailto:[email-masked]> [email-masked]>, Thomas Hardjono < <mailto:[email-masked]> [email-masked]>
Subject: RE: [Rats] Minimizing the Attestation Results objects which can represent overall Attester trustworthiness

Hi Ned,

<eric3> Makes sense, will add.

<eric3> will make Error value = -1

<nms2> The profile context is also needed. Profiles can indicate which Appraisal Policies for Evidence (APE) are to be applied. An APE might be broken into several statements. The warning / contradicted states might justify listing the APE statements that were not satisfied. APE statements could be OIDs or UUIDs or actual policy expressions. 

<eric3> I can see that for some use cases the Relying Party might take a different action based on what Verifier APE was performed.  Before things get that evolved, the Relying Party might only take action based Verifier assigned result value for one or more Trustworthiness Claims (with the instance of the APE included as supplemental Evidence.)

The integer result code ranges Thomas F. proposed seem like a form of APE statements that are commonly understood and standardized. 

<eric3> I don't think they are intended to explicitly/directly reference an APE instance.  But instead the resulting output/finding of a specific APE could be one of these code values.  (And per above, an identifier for the APE which was executed could reference this code could be added as supplemental evidence within the AR.)

I don’t know that it satisfies “non-standard” or Owner defined results however as these will require some form of additional contextualization. If the profile is identified as part of the Attestation Results, then this goes a long way toward contextualizing the APE statements. APE statements have to be fairly concretely defined and the output is likely tri/multi-state as well. The Verifier can easily have a built in ‘all-or-nothing’ policy for ‘Trustworthy’ and ‘None’ (i.e., where all APE statements are accepted or none are) while ‘Warning’ and ‘Contraindicated’ will be cases where some of the APE statements were satisfied while others were not. Note: It would be possible to put a fine point on ‘contraindicated’ as APE statements that satisfied a deny condition.

<eric3> This makes sense to me. 

<eric3> I would say the text above attempts to standardize the results of some APE statements.  And it might be interesting for people who want to design the APE languages to assert how they are constructed and referenced between Verifier and Relying Party.  Are you good with this interpretation?

/Eric3

 

Hi Laurence,

Hi Eric,

 

 

Hi Laurence,

<nms> +1

<eric2> Agree.  

<eric2> Works for me.

 

 

/Eric2

 

<eric> Agree.

Eric

LL

 

Thanks,

Eric

Eric Voit 

Principal Engineer