Re: [Rats] Call for charter consensus

[Carl Wallace <[e-mail]>]

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

>>