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

Jeremy O'Donoghue <jodonogh@qti.qualcomm.com> Wed, 24 October 2018 12:47 UTC

Return-Path: <jodonogh@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 13C79128DFD; Wed, 24 Oct 2018 05:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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] 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 ILiK_aqHGHJL; Wed, 24 Oct 2018 05:47:20 -0700 (PDT)
Received: from alexa-out-ams-02.qualcomm.com (alexa-out-ams-02.qualcomm.com [185.23.61.163]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95770127332; Wed, 24 Oct 2018 05:47:19 -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=1540385240; x=1571921240; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5NrvUKpdcQHSRC9NkLvxcNTByOY/znrLyV5u/Z+qyHM=; b=AKyhIdrNSl1Yr+ojVWoxSfJeseiZ8+g4kswvXDtGbFUM0xUgUby0ncfG Key0RbFm01LpCARYPUYUac0sADHV38S926uyYBFdfb0YaIDEL+ZL1mjHR Glz+N8vq/23yHRZwW6y00ZEpiXG4MJhvCKKnIsknN+kZ45hxWTHK8jOQ+ Q=;
X-IronPort-AV: E=Sophos;i="5.54,420,1534802400"; d="scan'208,217";a="1387166"
Received: from ironmsg02-ams.qualcomm.com ([10.251.56.3]) by alexa-out-ams-02.qualcomm.com with ESMTP; 24 Oct 2018 14:46:23 +0200
X-IronPort-AV: E=McAfee;i="5900,7806,9055"; a="6117362"
Received: from euamsexm01a.eu.qualcomm.com ([10.251.127.40]) by ironmsg02-ams.qualcomm.com with ESMTP/TLS/AES256-SHA; 24 Oct 2018 14:46:23 +0200
Received: from euamsexm01a.eu.qualcomm.com (10.251.127.40) by euamsexm01a.eu.qualcomm.com (10.251.127.40) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 24 Oct 2018 14:46:21 +0200
Received: from euamsexm01a.eu.qualcomm.com ([10.251.127.40]) by euamsexm01a.eu.qualcomm.com ([10.251.127.40]) with mapi id 15.00.1365.000; Wed, 24 Oct 2018 14:46:21 +0200
From: Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>
To: Carl Wallace <carl@redhoundsoftware.com>
CC: "Smith, Ned" <ned.smith@intel.com>, Michael Richardson <mcr+ietf@sandelman.ca>, "eat@ietf.org" <eat@ietf.org>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [EAT] [Rats] Attestation BoF charter updates?
Thread-Index: AQHUavXP5xlM3Oo/GUa0I+2fOxOmhqUs9bMAgAAVBwCAAARWgIAADiwAgAAAmYCAARnZgA==
Date: Wed, 24 Oct 2018 12:46:21 +0000
Message-ID: <8340B1B8-775D-4932-B432-29B715A3B45D@qti.qualcomm.com>
References: <D7F4B1E4.C3BF8%carl@redhoundsoftware.com> <D0C08E47-DBB6-4AAD-95EF-F952155D3152@qti.qualcomm.com> <581DD29C-85D9-4BD8-A0EE-41761ED773B4@intel.com> <D7F4D350.C3CFF%carl@redhoundsoftware.com> <FFA0BB14-48AB-45CE-8D7A-53D43821FC7D@intel.com> <D7F4E84F.C3D97%carl@redhoundsoftware.com> <FCF1711D-4936-4D35-A75D-84B88C076151@intel.com> <D7F4F54C.C3DB8%carl@redhoundsoftware.com>
In-Reply-To: <D7F4F54C.C3DB8%carl@redhoundsoftware.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.9.1)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.251.52.12]
Content-Type: multipart/alternative; boundary="_000_8340B1B8775D4932B43229B715A3B45Dqtiqualcommcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/Enin30olvuVFf65C_Eq1TSDj2WY>
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: Wed, 24 Oct 2018 12:47:23 -0000

I have the following understanding (possibly misunderstood) from this thread:


  *   It is desirable to have syntax for incorporating sets of Claims in structures that are defined in ASN.1. At the surface level this may be straightforward because claims are essentially (key, value) pairs - the key potentially being implicit in some cases, but there could be important semantic differences in the meaning of signing in Attestation formats vs legacy formats, and there may be challenges in mapping some CBOR or JSON constructions to ASN.1.
  *   The main use-case under discussion is to address mechanisms to enable an attestation to be presented to a CA in the context of a certificate request protocol. If I have correctly understood this, it means that a direct mapping of the Claims in an attestation to an X.509 certificate is a non-goal as the CA would be responsible for correctly interpreting the semantics of the Claims and incorporating them into an issued certificate in ways that make sense in the X.509 world.

I think we need to take care to limit the scope of work items in this area as there exists a considerable existing body of specifications in this area. Girl has mentioned ACME, and Carl mentioned SCEP, for which a new version appears to be nearing publication.

My suggestion is that it should be in scope to define a syntax for describing attestations which which could be transported via certificate request protocols such as ACME and SCEP, but that the question of how the semantics of attestations are managed in their use-cases is a question for the WGs owning those specifications.

Looking at the current SCEP draft<https://datatracker.ietf.org/doc/draft-gutmann-scep/?include_text=1>;, it might be sufficient for the CRIAttributes definition (from RFC2986) to include the ASN.1 encoding of an attestation. ACME seems to encode the CSR in RFC2986 for as well, so this might be workable.

In terms of the charter text (which is what is really in scope here) we could add text to the WG description indicating that the WG will work with relevant WGs to identify where attestations may be useful in PKI infrastructures. I think the existing charter text already covers the possibility of defining Claims to enable transport of an X.509 certificate as part of an attestation.

Please let me know if I have misunderstood. I will be posting an update to the text shortly which I believe covers this.

Jeremy

On 23 Oct 2018, at 20:57, Carl Wallace <carl@redhoundsoftware.com<mailto:carl@redhoundsoftware.com>> wrote:

<snip>
[nms] Right. In order for the CA (verifier) to distinguish the certifying key is an ‘attestable key’ vs. a traditional CSR. The CA should look for a signature from the mfg cert over the CSR (certificate management message?) containing the generated public key. I’m still not seeing where there is a self-signed (issued) certificate in the equation.
This began with request to codify binding to certificate request protocols, not for a self signed certificate.