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

Giridhar Mandyam <mandyam@qti.qualcomm.com> Tue, 23 October 2018 19:53 UTC

Return-Path: <mandyam@qti.qualcomm.com>
X-Original-To: eat@ietfa.amsl.com
Delivered-To: eat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1D8130E71; Tue, 23 Oct 2018 12:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwEENaq0O1e1; Tue, 23 Oct 2018 12:53:47 -0700 (PDT)
Received: from alexa-out-sd-02.qualcomm.com (alexa-out-sd-02.qualcomm.com [199.106.114.39]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0999130E5C; Tue, 23 Oct 2018 12:53:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1540324427; x=1571860427; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UacNYVRoQfV7q3QtpdTDBb3YLv6ndUIQHlfL3c2hzaw=; b=zhbe2K/DfbtGkqFE+4FS5VhUrre9ThIPqaTCxf4vON4aMz+vPZPAT372 4cp9YXoSSlM/xCKoT0/g+1MLHuPh9Ch7z/4WW08Rinih3U3bFLnGJvAE9 tij7otUdbjDMqQxRZgIb7Z3K+hgBQQf7mfZbtadptLXtfLxLPPQ10zkZe A=;
X-IronPort-AV: E=Sophos; i="5.54,417,1534834800"; d="scan'208,217"; a="14632882"
Received: from unknown (HELO ironmsg05-sd.qualcomm.com) ([10.53.140.145]) by alexa-out-sd-02.qualcomm.com with ESMTP; 23 Oct 2018 12:53:47 -0700
Received: from nasanexm01a.na.qualcomm.com ([10.85.0.81]) by ironmsg05-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 23 Oct 2018 12:53:46 -0700
Received: from eusanexr01e.eu.qualcomm.com (10.85.0.100) by nasanexm01a.na.qualcomm.com (10.85.0.81) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 23 Oct 2018 12:53:46 -0700
Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by eusanexr01e.eu.qualcomm.com (10.85.0.100) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 23 Oct 2018 12:53:44 -0700
Received: from NASANEXM01C.na.qualcomm.com ([10.85.0.83]) by NASANEXM01C.na.qualcomm.com ([10.85.0.83]) with mapi id 15.00.1365.000; Tue, 23 Oct 2018 12:53:44 -0700
From: Giridhar Mandyam <mandyam@qti.qualcomm.com>
To: Carl Wallace <carl@redhoundsoftware.com>, Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>, Michael Richardson <mcr+ietf@sandelman.ca>
CC: "rats@ietf.org" <rats@ietf.org>, "eat@ietf.org" <eat@ietf.org>
Thread-Topic: [EAT] [Rats] Attestation BoF charter updates?
Thread-Index: AQHUauMzAcwRL3H0NUa/M9uJc0mqOqUtPSyA
Date: Tue, 23 Oct 2018 19:53:43 +0000
Message-ID: <e0c3f17f709140b7a546eeced55d522b@NASANEXM01C.na.qualcomm.com>
References: <D7F4B1E4.C3BF8%carl@redhoundsoftware.com>
In-Reply-To: <D7F4B1E4.C3BF8%carl@redhoundsoftware.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [199.106.107.6]
Content-Type: multipart/alternative; boundary="_000_e0c3f17f709140b7a546eeced55d522bNASANEXM01Cnaqualcommco_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/u75Kh9etz19k2iMboRuuZrdUtgY>
Subject: Re: [EAT] [Rats] Attestation BoF charter updates?
X-BeenThere: eat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EAT - Entity Attestation Token <eat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eat>, <mailto:eat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eat/>
List-Post: <mailto:eat@ietf.org>
List-Help: <mailto:eat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eat>, <mailto:eat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Oct 2018 19:53:51 -0000

[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).

Why isn’t ACME applicable  (https://datatracker.ietf.org/wg/acme/about/)?   Granted, it is optimized for the web currently.  But from a message format perspective I don’t think we need to re-invent the wheel.

-Giri Mandyam, Qualcomm

From: EAT <eat-bounces@ietf.org>; On Behalf Of Carl Wallace
Sent: Tuesday, October 23, 2018 8:15 AM
To: Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>;; Michael Richardson <mcr+ietf@sandelman.ca>;
Cc: rats@ietf.org; eat@ietf.org
Subject: Re: [EAT] [Rats] Attestation BoF charter updates?


<snip>
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?

- 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).

- 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

Jeremy

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

--
Michael Richardson <mcr+IETF@sandelman.ca<mailto:mcr+IETF@sandelman.ca>>, Sandelman Software Works
-= IPv6 IoT consulting =-
_______________________________________________
EAT mailing list
EAT@ietf.org<mailto:EAT@ietf.org>
https://www.ietf.org/mailman/listinfo/eat

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