Re: [Rats] New Version Notification for draft-voit-rats-trusted-path-routing-02

[Benjamin Kaduk <[e-mail]>]

Hi Eric,

On Mon, Jun 15, 2020 at 10:26:36PM +0000, Eric Voit (evoit) wrote:
> Hi Ben,
> 
> > From: Benjamin Kaduk. June 14, 2020 5:30 PM
> > 
> > On Wed, Jun 10, 2020 at 08:13:15PM +0000, Eric Voit (evoit) wrote:
> > > Of general interest in this draft the definition of a Trustworthiness
> > > Vector
> > > <https://tools.ietf.org/html/draft-voit-rats-trusted-path-routing-02#s
> > > ection-3.2> which contains a ordered list of Trustworthiness Levels.
> > > This vector is returned within Attestation Results, and is actionable
> > > by a Relying Party.
> > 
> > I wonder if this usage could be syncrhonized with the RFC 8485 "Vector of
> > Trust".
> 
> Thanks for pointing this out, I had not seen it. And it is interesting.  A
> few initial thoughts...
> 
> (1) The universe of RFC8485 Component Dimensions does have a partial overlap
> with my draft beyond the reuse of the 'vector'.   For example Identity
> proofing and assertion presentation are things RATS cares about.  RATS also
> cares about 'credential' lifecycle.  
> 
> (2) There are many significant domain of claims related to attestation which
> are not covered in RFC8485.    E.g.:
> (a) whole categories of appraisal assertions such as 'hw-authentic',
> 'boot-verified' or 'file-blacklisted' would need brand new 'component
> dimensions'.   (Note: RFC8485 does allow other RFCs to grow additional
> contexts, so perhaps this would be ok, this is of assuming someone is
> willing to steward this language across many domains.)

>From memory, I think it even encourages such growth, not just allowing them.

> (b) The lifecycle of Attestation Results beyond credentials quite important
> with RATS.
> 
> (3) RFC8485 suggests formal codes for the level of assurance of assertions
> being made.  This would mean that the language of Attestation Results should
> be very rich.  In fact it should be far richer that the small handful of
> simple human-understandable identities which I proposed in my draft.
> 
> With this in mind, I have generalized your question to be: how formal should
> the language of Attestation Results be?   In the end, it wouldn't be too
> hard to map my draft's YANG identities into *new/extended* RFC8485 vector
> constructs.   But I am not yet able to see lots of immediate value.  

That's fair.  I certainly don't have an answer in mind, myself :)

> The first question I need to look at from the perspective of
> routers/switches is how useful it would be to have an expandable standard
> taxonomy and encoding for Appraisal Results.  An early guess would be that
> someone who has open source code/expertise in formally expressing Appraisal
> Results would be better positioned to see if this might be worthy of a draft
> submission.  
> 
> Or said another way: if somebody has the expertise and desire to drive an
> IETF-wide appraisal results language beyond the RFC8485 starting point, I
> would happily map my very simple constructs into that language.

Understood.  Thanks for reading and thinking about it!

-Ben