Re: [Rats] More use cases for draft-richardson-rats-usecases-00

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

See inline [nms]

On 6/14/19, 11:46 AM, "Michael Richardson" <[e-mail]> wrote:

    
    Smith, Ned <[e-mail]> wrote:
        > Anders refers to session-based attestation in the TEEP archive which
        > points to several sources including a TCG source. This may be referring
        > to a public specification known as DICE - Device Identifier Composition
        > Engine.
        > https://trustedcomputinggroup.org/wp-content/uploads/Hardware-Requirements-for-Device-Identifier-Composition-Engine-r78_For-Publication.pdf
    
        > TCG terminology for TEEP's "Static" attestation is "Explicit
        > Attestation" and TEEP's term "Session Based" attestation is "Implicit
        > Attestation" by TCG.
    
    I have included these translations into the document.
    
        > The EAT draft defines an attestation approach that seems close to (i)
        > if you ignore the nonce that is returned as a static claim / assertion
        > and if you rule out of scope the definition of how the signing key is
        > created / persisted.
    
        > The tokbind draft seems closely resemble (ii).
    
    I want to be sure you mean: draft-mandyam-tokbind-attest-07 ?
[nms] Yes.
    
        > The TUDA draft seems to
        > resemble (i). (Henk can correct me).
    
        > The yang draft seems to resemble
        > (ii). (Henk can correct me).
    
    I'm trying to figure out what to do this statement.
[nms] If there is value in categorizing the attestation approach taken by various proposed RATS drafts in terms of (i) implicit attestation and (ii) explicit attestation then it seems TUDA (https://datatracker.ietf.org/doc/draft-birkholz-rats-tuda/ ) may be classified as implicit attestation. Since TUDA is also using time-based exchanges Henk may think it doesn't fit well into this categorization. The YANG module draft https://datatracker.ietf.org/doc/draft-birkholz-rats-basic-yang-module/ appears to me to be a case of explicit attestation.

The basic definition of implicit attestation is that evidence isn't exchanged directly between attester to verifier. Rather only a handle, keyid or use of the attestation key is sufficient to signal the verifier which context to reference for evaluating trust properties. The details of the trust properties is communicated out-of-band (the out-of-band path is out of scope for RATS currently). 

Explicit attestation conveys the evidence directly from attester to verifier. 

Obviously, real world attestation deployments likely will use a hybrid of implicit and explicit attestation approaches.
-Ned
    
    --
    ]               Never tell me the odds!                 | ipv6 mesh networks [
    ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
    ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
    
    
    --
    Michael Richardson <[e-mail]>, Sandelman Software Works
     -= IPv6 IoT consulting =-