Re: [Rats] Call for charter consensus

[Benjamin Kaduk <[e-mail]>]

On Sat, Jan 19, 2019 at 07:29:30AM -0500, Carl Wallace wrote:
> Inline...
> 
> 
> On 1/18/19, 8:23 PM, "Benjamin Kaduk" <[e-mail]> wrote:
> 
> >On Fri, Jan 18, 2019 at 06:54:44PM -0500, Carl Wallace wrote:
> >> Inline...
> >> 
> >> > On Jan 18, 2019, at 6:27 PM, Nancy Cam-Winget (ncamwing)
> >><[e-mail]> wrote:
> >> > 
> >> > 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.
> >> 
> >> 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.
> 
> [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.
> 
> 
> >
> >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.
> 
> [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,
> >> > 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. 
> >
> >Yup, we want to bite off a manageable chunk for the initial round, and add
> >on later as needed.
> 
> [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.

Understood, and thanks.

-Ben