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

Jeremy O'Donoghue <jodonogh@qti.qualcomm.com> Wed, 24 October 2018 16:32 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 0167212D4E8; Wed, 24 Oct 2018 09:32:24 -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 oEKfh73iHc7B; Wed, 24 Oct 2018 09:32: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 47CEB126F72; Wed, 24 Oct 2018 09:32: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=1540398739; x=1571934739; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dNi8dPkOn3M8ZfUHPx5mIkl/QisaiUW5eTJzo4Gdl+Q=; b=WdyJ7yamUIOyqtFOfPYVdM1ITyBNMSXCvE5lQXJa1E5I+YOpn10tOUw6 RJppr4Lq2xkScUxEkv6EJ0c5kEsAsvRnrV3NGNg6nIzrxlRRaGFBKjokX pmEXeYwNZebHvbT2IDuGi8WfS349KKZHddXSmHbbzSo0clOZ2ZpcTvE2S U=;
X-IronPort-AV: E=Sophos;i="5.54,421,1534802400"; d="scan'208,217";a="1388275"
Received: from ironmsg02-ams.qualcomm.com ([10.251.56.3]) by alexa-out-ams-02.qualcomm.com with ESMTP; 24 Oct 2018 18:32:17 +0200
X-IronPort-AV: E=McAfee;i="5900,7806,9055"; a="6119156"
Received: from euamsexm01b.eu.qualcomm.com ([10.251.127.41]) by ironmsg02-ams.qualcomm.com with ESMTP/TLS/AES256-SHA; 24 Oct 2018 18:32:17 +0200
Received: from euamsexm01a.eu.qualcomm.com (10.251.127.40) by euamsexm01b.eu.qualcomm.com (10.251.127.41) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 24 Oct 2018 18:32:15 +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 18:32:15 +0200
From: Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
CC: "eat@ietf.org" <eat@ietf.org>, Carl Wallace <carl@redhoundsoftware.com>, Michael Richardson <mcr+ietf@sandelman.ca>, "Smith, Ned" <ned.smith@intel.com>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [EAT] [Rats] Attestation BoF charter updates?
Thread-Index: AQHUavXP5xlM3Oo/GUa0I+2fOxOmhqUs9bMAgAAVBwCAAARWgIAADiwAgAAAmYCAARnZgIAAPd8AgAABPQA=
Date: Wed, 24 Oct 2018 16:32:15 +0000
Message-ID: <91CD33FE-A023-464F-A49F-04B38A2A6274@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> <8340B1B8-775D-4932-B432-29B715A3B45D@qti.qualcomm.com> <D4F3DF93-D63F-4254-8014-9039B856B760@sit.fraunhofer.de>
In-Reply-To: <D4F3DF93-D63F-4254-8014-9039B856B760@sit.fraunhofer.de>
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_91CD33FEA023464FA49F04B38A2A6274qtiqualcommcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/LaCpoSU0WdvpPIiv4I2YQafvcbE>
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 16:32:24 -0000

I think you already have text which keeps this scenario in scope in the latest draft (the bit about ASN.1 interoperability). From my perspective this is enough for now.

Jeremy

On 24 Oct 2018, at 17:27, Henk Birkholz <henk.birkholz@sit.fraunhofer.de<mailto:henk.birkholz@sit.fraunhofer.de>> wrote:

Please all keep in mind that we are intending to cut work items into phases. While we are starting to agree more than we disagree, I think, we should continue to pay attention to scoping, please. Not now does not mean never!

Viele Grüße,

Henk

On October 24, 2018 2:46:21 PM GMT+02:00, Jeremy O'Donoghue <jodonogh@qti.qualcomm.com<mailto:jodonogh@qti.qualcomm.com>> wrote:
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.



--
Sent from my Android device with K-9 Mail. Please excuse my brevity.