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

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Wed, 24 October 2018 16:43 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
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 753D1126CB6; Wed, 24 Oct 2018 09:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 5PBjrA0Yyxvj; Wed, 24 Oct 2018 09:43:04 -0700 (PDT)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 772E612D4E7; Wed, 24 Oct 2018 09:43:04 -0700 (PDT)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w9OGh1qv017550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Oct 2018 18:43:02 +0200
Received: from eduroam-pool7-0363.wlan.uni-bremen.de (134.102.113.107) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 24 Oct 2018 18:42:55 +0200
Date: Wed, 24 Oct 2018 18:42:53 +0200
User-Agent: K-9 Mail for Android
In-Reply-To: <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> <91CD33FE-A023-464F-A49F-04B38A2A6274@qti.qualcomm.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----3446V243X3O1N6LHF1HMZFUM61TRU2"
Content-Transfer-Encoding: 7bit
To: "Jeremy O'Donoghue" <jodonogh@qti.qualcomm.com>
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>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <543135F2-9D4F-4411-A561-21B4751EBE26@sit.fraunhofer.de>
X-Originating-IP: [134.102.113.107]
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/KV4gMywOrgsf1aN-GFmoIzqFfhA>
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:43:09 -0000

It is in the current charter text, because I think your answer in the quote below is well met. 

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

None I can technically justify."

However, even boiling of the ocean is subject to phasing - and the ASN.1 related wording is not intended to be a loophole ;-)

Viele Grüße,

Henk



On October 24, 2018 6:32:15 PM GMT+02:00, Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>; wrote:
>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.

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