Re: [Rats] Call for adoption (after draft rename) for Yang module draft

Given the architecture supports hybrids of passport and background check models, it seems there could be a rich combination of attesters, verifiers and relying parties where partial results could be supplied by Verifier A to RP B who in turn verifies as Verifier B and produces results B etc... If so, then possibly a TPM encapsulated "claim" gets passed on to multiple verifiers until one that can parse a TPM encapsulation is found. Maybe this is a contrived use case, but it seems reasonable based on what has been discussed so far. By not allowing a TPM encapsulation, it implies there is some other encapsulation besides a "Token" that carries the TPM produced Evidence. 

-Ned

On 11/11/19, 10:23 AM, "RATS on behalf of Henk Birkholz" <rats-bounces@ietf.org on behalf of henk.birkholz@sit.fraunhofer.de> wrote:

    Laurence provided options as a basis for discussion a while ago.

    He highlighted that CWT must be signed and illustrated pro & con wrt:

    * null cipher,
    * an "unsigned" flavor of CWT
    * an "arbitrary signature"

    It might be a valid assumotion that a single "tpm Claim" would have no 
    significant added value, but multiple Claims in a message bundle might 
    (although this might be a solution looking for a problem?).

    Viele Grüße,

    Henk

    On 11.11.19 19:11, Smith, Ned wrote:
    > Right. This implies the RATS “token” should support existing “binary” 
    > formats as an encapsulation (signed by a second TA where the TPM is a 
    > first TA) or as a conveyance (unsigned?) token. Possibly, the only added 
    > value of the latter is a tag that identifies it as a TPM binary format?
    > 
    > On 11/10/19, 23:21 PM, "RATS on behalf of Oliver, Ian (Nokia - 
    > FI/Espoo)" <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org> on 
    > behalf of ian.oliver@nokia-bell-labs.com 
    > <mailto:ian.oliver@nokia-bell-labs.com>> wrote:
    > 
    >> Remote TPM attestations are useful and necessary the short run, but are of very limited capability. I believe that > EAT will replace TPM attestations  in the long run (maybe decades) because they are far more expressive. 
    > I know > others believe that too.
    > 
    > I would disagree with the statement of "short run" ... TPM is 
    > practically the only existing standardised (hardware, software, 
    > firmware, measurement - x86 only etc) hardware root of trust in common 
    > use, ie: practically all x86 machines,  The attestation mechanisms 
    > provided are going to be around for a very long time.
    > 
    >  From telco experience, 30 years ago we said SS7 would only be around in 
    > the short term.
    > 
    >> Thus, I am opposed to adoption with the current TPM-only draft. I’d be OK with the current draft and a promise > to add EAT to it.
    > 
    > Agree
    > 
    > Ian
    > 
    > -- 
    > 
    > Dr. Ian Oliver
    > 
    > Cybersecurity Research
    > 
    > Distinguished Member of Technical Staff
    > 
    > Nokia Bell Labs
    > 
    > +358 50 483 6237
    > 
    > ------------------------------------------------------------------------
    > 
    > *From:*Laurence Lundblade <lgl@island-resort.com>
    > *Sent:* 11 November 2019 00:44
    > *To:* Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com>
    > *Cc:* Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; rats@ietf..org 
    > <rats@ietf.org>
    > *Subject:* Re: [Rats] Call for adoption (after draft rename) for Yang 
    > module draft
    > 
    >     On Nov 10, 2019, at 2:20 PM, Nancy Cam-Winget (ncamwing)
    >     <ncamwing@cisco.com <mailto:ncamwing@cisco.com>> wrote:
    > 
    >     So, Laurence, are you still OK with the adoption of the current
    >     draft with a rename for now?
    >     Thanks, Nancy
    > 
    > I think the value add to the larger RATS effort of adding EAT support to 
    > this YANG protocol is really high. It a core thing to do that helps 
    > bring together the two attestation worlds and make the TPM and EAT work 
    > here less like ships in the night.
    > 
    > Remote TPM attestations are useful and necessary the short run, but are 
    > of very limited capability. I believe that EAT will replace TPM 
    > attestations in the long run (maybe decades) because they are far more 
    > expressive. I know others believe that too.
    > 
    > If we don’t include EAT in the YANG mode it is sort of like defining 
    > HTTP to only convey HTML to the exclusion of PDF. We’re defining an 
    > attestation protocol that can only move one kind of attestation even 
    > though we have consensus on what the other one looks like.
    > 
    > It seems relatively simple to add EAT support (or promise to add EAT 
    > support). Pretty sure I heard Henk agree to add it.
    > 
    > Thus, I am opposed to adoption with the current TPM-only draft. I’d be 
    > OK with the current draft and a promise to add EAT to it.
    > 
    > LL
    > 

    _______________________________________________
    RATS mailing list
    RATS@ietf.org
    https://www.ietf.org/mailman/listinfo/rats