Re: [EAT] [Rats] Attestation BoF charter updates?

Jeremy O'Donoghue <> Tue, 23 October 2018 17:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA778130F90; Tue, 23 Oct 2018 10:10:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J_EGVqNEIRAw; Tue, 23 Oct 2018 10:10:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F174C130F62; Tue, 23 Oct 2018 10:10:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1540314617; x=1571850617; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MQsDFz3H2oFKpvg47wXienkM7OEie/7TG61ZfMW0qdc=; b=Lz0F0wyMAu/DJWYV1hE+zEHGXWB8OFN4AzNhc18+WJfosx5wH4ABtkiu zyxjtTH5AI50IORH0Zhh/uEMhi3Oh8qLi00FyOO1CK0NXqy4M+RnfwL6j 6Vpq5iZMKCtsphemPOJEVB/nGR53Zp2lqbZxrP9UHXBqHWkxt8yfZ29g0 A=;
X-IronPort-AV: E=Sophos;i="5.54,416,1534802400"; d="scan'208,217";a="1382484"
Received: from ([]) by with ESMTP; 23 Oct 2018 19:10:15 +0200
X-IronPort-AV: E=McAfee;i="5900,7806,9055"; a="6099004"
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 23 Oct 2018 19:10:15 +0200
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 23 Oct 2018 19:10:07 +0200
Received: from ([]) by ([]) with mapi id 15.00.1365.000; Tue, 23 Oct 2018 19:10:06 +0200
From: Jeremy O'Donoghue <>
To: Carl Wallace <>
CC: Michael Richardson <>, "" <>, "" <>
Thread-Topic: [Rats] [EAT] Attestation BoF charter updates?
Thread-Index: AQHUauM1YZGxqVPSIk2WRVqX8pXQ8KUs7y8A
Date: Tue, 23 Oct 2018 17:10:06 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3445.9.1)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D0C08E47DBB64AAD95EFF952155D3152qtiqualcommcom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [EAT] [Rats] Attestation BoF charter updates?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EAT - Entity Attestation Token <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Oct 2018 17:10:24 -0000

On 23 Oct 2018, at 16:14, Carl Wallace <<>> wrote:


Work Items


The Working Group will develop specifications supporting the creation of
interoperable remote attestation procedures for entities which incorporate
Roots of Trust. The main deliverables are as follows.

- Produce a requirements document establishing a common vocabulary for remote
  attestation, identifying mechanisms which will be supported for establishing
  trust between an entity and a remote party, and enumerating sample use-cases
  for remote attestation.

- Produce specification text defining interoperable cross-platform claims which
  provide information about an entity in support of the required use-cases, and
  extending the set of claims defined in RFC7519 and RFC8392. The specification
  will describe the syntax for each claim in at least the following formats:
    - CBOR [RFC7049]
    - JSON [RFC7159]
    - YANG [RFC6020]

[CW] ASN.1 is already player for a number of attestation formats. Any reason to exclude it?

None I can technically justify. It seems sensible to have ASN.1 in scope, at least in terms of defining the syntax of claims in ASN.1. I am less sure whether it makes sense to define signing procedures for ASN1. (since these are presumably defined elsewhere), but I could be persuaded (e.g. by the statement "no they aren't defined elsewhere - at least not for this important use-case").

- Produce specification text defining procedures and corresponding architectures
  supporting verification of claims within an attestation based on measured file
  execution procedures and supporting:
    - Explicit attestation wherein a set of claims is transported in the attestation;
    - Implicit attestation wherein a set of claims is implied by possession of a secret.

- Produce specification text defining procedures and corresponding architectures
  supporting verification of claims encapsulated in:

    - CBOR Web Token structures [RFC8392]
    - JSON Web Token structures [RFC7519]

[CW] As noted before, I'd like to see binding to certificate enrollment protocols included here as well. This is something we are doing today, without standards grounding (as illustrated in pile of attestations shared via Github a few weeks back).

It would be interesting to understand your thinking a bit further. At one level it is fairly straightforward to define a claim whose value contains an X.509 certificate, but I suspect that binding may imply more than that.

- Perform privacy analysis of both claims and the cryptographic procedures used to
  establish trust. This information will be included as appropriate in the
  deliverable specifications, and may imply extension of procedures defined in
  other specifications in support of privacy goals.

It seems to me that there are two ways to produce the main specification deliverables. I have deliberately left the text above slightly vague on this.

  *   A claims specification common to RATS and EAT with separate RATS and EAT procedure specifications.
  *   A claims specification also incorporating EAT procedures and a separate RATS procedure specification. This would be my preferred option.
     *   I believe there are very few procedures needed for EAT other than the possible need to support a nonce to ensure freshness


Notice how by about the second paragraph (6tisch takes a bit longer), each
gets into what the WG will do?

Michael Richardson <<>>, Sandelman Software Works
-= IPv6 IoT consulting =-
EAT mailing list<>

_______________________________________________ RATS mailing list<>