Subject: Re: [Rats] Call for charter consensus

From: Carl Wallace <[email-masked]>
Date: Fri, 18 Jan 2019 10:12:25 -0500

From:  RATS <[email-masked]> on behalf of "Nancy Cam-Winget
(ncamwing)" <[email-masked]>
Date:  Thursday, January 17, 2019 at 10:38 PM
To:  "[email-masked]" <[email-masked]>
Subject:  [Rats] Call for charter consensus

> Hello RATS participants:
>  
> At the virtual meeting on 1/16/2019, there was consensus [1] that we should
> pursue chartering a Working Group with the text reflected in [2].
>  
> We need to continue this discussion on the email list as well as gauge
> continued interest in participating in this work.  Please do so by responding
> to the following questions:

Do you support this charter text (full text also provided at the end of
email or at [1])?  Or do you have objections or blocking concerns?
[CW] I dislike that the goals do not include verifying or using
attestations. Verification was cast as "mundane" during the meeting earlier
this week, but historically interop pain often arises at the
verification/usage point. This is independent of comparing values extracted
from an attestation to a reference value, which is deemed out of scope.
Perhaps: "This WG will standardize formats for describing assertions/claims
about system components and associated evidence; procedures and protocols to
convey these assertions/claims to the relying parties; and procedures to
establish trust in attestations/claims. Assessment of assertions/claims,
such as via reference values, is outside the scope for this WG."

Are you willing to author or participate in the development of the drafts of
this WG?
[CW] Possibly, though limited to defining some conveyance mechanisms most
likely.

Are you willing to help review the drafts of this WG?
[CW] Yes

Are you interested in implementing drafts of this WG?
[CW] As a relying party, yes.

> Please provide comments including proposed text changes ASAP to provide ample
> time for discussion.  This call for consensus ends on February 1, 2019.
>  
> Thanks, Roman and Nancy
>  
> [1] Minutes sent:
> https://mailarchive.ietf.org/arch/msg/rats/xEwczqnoNgyBYlRTKg35Yo4ccWY
> <https://mailarchive.ietf.org/arch/msg/rats/xEwczqnoNgyBYlRTKg35Yo4ccWY>
> [2] Updated charter sent:
> https://mailarchive.ietf.org/arch/msg/rats/MQLZIkIK23ZlSBMB5wJjo71bOr0
> <https://mailarchive.ietf.org/arch/msg/rats/MQLZIkIK23ZlSBMB5wJjo71bOr0>
>  
> _______________________________________________ RATS mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/rats

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Fri, 18 Jan 2019 23:27:19 +0000

Hi Carl,
<Chair hat-off>
It is my experience in the IETF that we focus more in the definition of data models and transfer/transport mechanisms for information (e.g. yang, netconf, radius, nea) but how the information is applied is typically out of scope.

<Chair hat-on>
As to the consensus of the group and the charter during the call, there was no consensus to the last item (the assessment of claims).  Additionally,
I don’t believe we have permanently omitted the “assessment” portion.  The understanding is that we need to charter to a scope that we can achieve and if and when in that process we need to recharter to include other work items we can certainly do so.

Warm regards, Nancy

From: Carl Wallace <[email-masked]>
Date: Friday, January 18, 2019 at 07:12
To: "Nancy (ncamwing)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Rats] Call for charter consensus

From: RATS <[email-masked]<mailto:[email-masked]>> on behalf of "Nancy Cam-Winget (ncamwing)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 17, 2019 at 10:38 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Rats] Call for charter consensus

Hello RATS participants:

At the virtual meeting on 1/16/2019, there was consensus [1] that we should pursue chartering a Working Group with the text reflected in [2].

We need to continue this discussion on the email list as well as gauge continued interest in participating in this work.  Please do so by responding to the following questions:

Do you support this charter text (full text also provided at the end of email or at [1])?  Or do you have objections or blocking concerns?
[CW] I dislike that the goals do not include verifying or using attestations. Verification was cast as "mundane" during the meeting earlier this week, but historically interop pain often arises at the verification/usage point. This is independent of comparing values extracted from an attestation to a reference value, which is deemed out of scope. Perhaps: "This WG will standardize formats for describing assertions/claims about system components and associated evidence; procedures and protocols to convey these assertions/claims to the relying parties; and procedures to establish trust in attestations/claims. Assessment of assertions/claims, such as via reference values, is outside the scope for this WG."

Are you willing to author or participate in the development of the drafts of this WG?
[CW] Possibly, though limited to defining some conveyance mechanisms most likely.

Please provide comments including proposed text changes ASAP to provide ample time for discussion.  This call for consensus ends on February 1, 2019.

Thanks, Roman and Nancy

[1] Minutes sent: https://mailarchive.ietf.org/arch/msg/rats/xEwczqnoNgyBYlRTKg35Yo4ccWY
[2] Updated charter sent: https://mailarchive.ietf.org/arch/msg/rats/MQLZIkIK23ZlSBMB5wJjo71bOr0

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

---

From: Carl Wallace <[email-masked]>
Date: Fri, 18 Jan 2019 18:54:44 -0500

Inline...

> On Jan 18, 2019, at 6:27 PM, Nancy Cam-Winget (ncamwing) <[email-masked]> wrote:
> 
> Hi Carl,
> <Chair hat-off>

Many verifiable data models (e.g., X509, CMS, JOSE, COSE, etc.) include verification rules. 

> I don’t believe we have permanently omitted the “assessment” portion. 
> The understanding is that we need to charter to a scope that we can achieve and if and when in that process we need to recharter to include other work items we can certainly do so.
>  
OK. 

> From: RATS <[email-masked]> on behalf of "Nancy Cam-Winget (ncamwing)" <[email-masked]>
> _______________________________________________ RATS mailing list [email-masked] https://www.ietf.org/mailman/listinfo/rats

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 18 Jan 2019 19:23:35 -0600

> Many verifiable data models (e.g., X509, CMS, JOSE, COSE, etc.) include verification rules. 

I attempted (probably poorly) on the call to make a point that in some
sense there are two different types of thing in the RATS workflow we're
thinking about, that could be called "verification".  On the one hand,
there's the raw crypto bits of "this is what signature validation/MIC
verification/etc. you have to do in order to get the cryptographic
validation that key X generated data Y [at time Z]", but once you've done
that, the decision of verifying that Y and Z are something you find
trustworthy to perform action W is not really something we can standardize.

My understanding is that we plan to talk about the crypto but not, at least
at first, what you do after confirming that the crypto has not been
tampered with.

> > The understanding is that we need to charter to a scope that we can achieve and if and when in that process we need to recharter to include other work items we can certainly do so.

Yup, we want to bite off a manageable chunk for the initial round, and add
on later as needed.

-Ben

> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Carl Wallace <[email-masked]>
Date: Sat, 19 Jan 2019 07:29:30 -0500

Inline...

On 1/18/19, 8:23 PM, "Benjamin Kaduk" <[email-masked]> wrote:

>> > It is my experience in the IETF that we focus more in the definition
>>of data models and transfer/transport mechanisms for information (e.g.
>>yang, netconf, radius, nea) but how the information is applied is
>>typically out of scope.
>> 

[CW] Depending on where you are drawing the "decision" line, I don't
disagree with any of this. However, as a relying party of several
currently available attestation types, I can say that all I have
encountered are broken in one or more ways related to verification,
including: misapplication of security specifications, poor definition of
trust establishment practices, misuse of structures relevant to trust
establishment, misencoding of structures relevant for assessment of
attestation contents, unstable structure definitions, "interesting" use of
extensibility mechanisms. Each complicates interoperability and code reuse
without even considering that each is different. Most of these issues are
at the intersection of proprietary attestation structures and standard
security layers, i.e., the procedures that appear to be missing in the
charter goals.

While it may be fair to simply write this all off as implementation
errors, my hope is that RATS will help greatly improve the landscape with
a solid set of standards accompanied by sample artifacts for testing.

>at first, what you do after confirming that the crypto has not been

[CW] The relevance of what one does during/after crypto will vary with the
nature of the claim and likely can't be avoided in all cases.

>
>> >  
>> > <Chair hat-on>
>> > As to the consensus of the group and the charter during the call,
>>there was no consensus to the last item (the assessment of claims).
>>Additionally,
>> > The understanding is that we need to charter to a scope that we can
>>achieve and if and when in that process we need to recharter to include
>>other work items we can certainly do so.
>> >  
>> OK. 
>

[CW] As noted, I don't think omitting procedures for verification and use
of the structures is a good idea but won't belabor the point further as a
charter point.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 19 Jan 2019 09:25:11 -0600

> of the structures is a good idea but won't belabor the point further as a

Understood, and thanks.

-Ben

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 19 Jan 2019 12:30:38 -0800

> On Jan 19, 2019, at 4:29 AM, Carl Wallace <[email-masked]> wrote:
> 

Nice list! :-)

I suspect it is going to take a long while to get to the level of interop you have in mind, but I think it is a good goal. I hope you can stay involved and continue to point out things from this perspective.

I also think we’ll end up keeping comparison to KGV in mind for lots of claim definition work even though it is out of scope. 

LL

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 24 Jan 2019 17:53:58 +0100

On Jan 19, 2019, at 02:23, Benjamin Kaduk <[email-masked]> wrote:
> On the one hand,
> validation that key X generated data Y [at time Z]”,

I would call that “verification” (related to “authentication”).

> but once you've done

I would call that “policy realization” (related to “authorization”).

> at first, what you do after confirming that the crypto has not been

That is also my understanding: we enable verification, but we don’t do the policy.

Grüße, Carsten

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 24 Jan 2019 15:59:02 -0800

> On Jan 24, 2019, at 8:53 AM, Carsten Bormann <[email-masked]> wrote:
> 

agree

> I would call that “policy realization” (related to “authorization”).

This could split finer into:
- check against known good value (KGV)
- actual policy

Recently I have been doing some thinking about claims about SW components that includes measurements of those components. In that thinking the question about how you compare those measurements comes up when considering versions of the SW components and variations over time on how those measurements are performed (e.g. upgrading to new hash algs, measuring code in a file vs execute-in-place code…)

How you check against KGV probably needs to be taken into account when we design the claim data model.

> That is also my understanding: we enable verification, but we don’t do the policy.

Agreed that we don’t do policy, but maybe we should at least consider implications for checks against KGV.

LL