[Rats] interaction model and token opacity was Re: Call for adoption (after draft rename) for Yang module draft

["Smith, Ned" <[e-mail]>]

Changing the name since the thread seems to have diverged.

There seems to be a requirement that a YANG expression could contain a RATS 'token' since the wire-format structure (bits that are signed) would not be YANG. YANG would treat the 'token' as an opaque structure.

Also, YANG can be used to model protocol or message flow interactions. Since YANG is a modeling language, there is an encoding (XML?) output that is input into an interpreter(?) that implements the protocol state machine. I presume RESTCONF or NETCONF are examples of protocol state machines that accept encodings of a YANG protocol expression?

The RATS 'token' is opaque to the protocol state machine except as a block used to construct a payload for a RESTCONF or NETCONF defined protocol frame.

If the attestation 'token' is obtained from a TPM, it is still meaningful to refer to is as a 'token' since it continues to be an opaque structure in the above context. (???)

The architecture should be able to disambiguate between tokens that are realized using a TPM vs. tokens realized as a JWT or CWT encoding. This requirement may expand to other vendor specific token encodings in order to satisfy compatibility needs - at least as they exist between Attester and Verifier.

However, it may be appropriate for the architecture to limit the Verifier to Relying Party interaction to a single token encoding such as CWT.  (???)

-Ned

On 11/13/19, 3:32 AM, "RATS on behalf of Schönwälder, Jürgen" <[e-mail] on behalf of [e-mail]> wrote:

    On Wed, Nov 13, 2019 at 07:24:10PM +0800, Michael Richardson wrote:
    > 
    > 
    > On 2019-11-13 7:14 p.m., Schönwälder, Jürgen wrote:
    > > On Wed, Nov 13, 2019 at 07:04:40PM +0800, Michael Richardson wrote:
    > >>
    > >> On 2019-11-13 1:56 a.m., Laurence Lundblade wrote:
    > >>> Got that one totally wrong. I even knew everything you describe about YANG.
    > >>>
    > >>> I still think it is better if we just stick to EAT / CWT / JWT claims described with CDDL as the way we define claims in RATS, except for a few TPM-specific claims. 
    > >> Nothing I've said is opposed to that.
    > >> I rather agree.  I don't think that EAT is complex enough to require a
    > >> definition in YANG.
    > >>
    > >> But, that also has nothing to do with whether we'd need a YANG signing
    > >> standard if we defined them in YANG.
    > >> We wouldn't, because we'd be signing JSON, CBOR (or XML if someone
    > >> insisted) using JSOE and COSE.
    > >>
    > > I am still confused but so far for me it may make sense to have the
    > > following:
    > >
    > > - A YANG defined transport for "tokens" which likely treats tokens as
    > >   opaque objects.
    > 
    > okay, and we need this in the same document (the same model?) as the TPM
    > stuff?
    
    Likely not.
     
    > I think that the process works okay for TPM, because we don't really
    > expect the system that hosts the RESTCONF interface to actually use the
    > RESTCONF interface to talk to the TPM.  We are just providing a gateway
    > to it.
    
    So which applications are using this RESTCONF interface? Can I somehow
    relate this back to the architecture models? Henk's doc seems to be
    telling me that the idea is that $something likes to retrieve
    "evidence" by invoking YANG RPCs. So what is $something and why is
    the evidence TPM specific?
    
    /js
    
    -- 
    Juergen Schoenwaelder           Jacobs University Bremen gGmbH
    Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
    Fax:   [phone]         <https://www.jacobs-university.de/>
    
    _______________________________________________
    RATS mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/rats