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

Henk Birkholz <> Wed, 24 October 2018 16:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DBFC7130DED; Wed, 24 Oct 2018 09:28:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qug3qclFGgy4; Wed, 24 Oct 2018 09:28:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BDB31126F72; Wed, 24 Oct 2018 09:28:00 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w9OGRttX017346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Oct 2018 18:27:56 +0200
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 24 Oct 2018 18:27:49 +0200
Date: Wed, 24 Oct 2018 18:27:48 +0200
User-Agent: K-9 Mail for Android
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----FDJ1RH0N2KOTYDPUWQ11H6TELC52NJ"
Content-Transfer-Encoding: 7bit
To: <>, "Jeremy O'Donoghue" <>, Carl Wallace <>
CC: Michael Richardson <>, "Smith, Ned" <>, "" <>, "" <>
From: Henk Birkholz <>
Message-ID: <>
X-Originating-IP: []
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: Wed, 24 Oct 2018 16:28:05 -0000

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,


On October 24, 2018 2:46:21 PM GMT+02:00, Jeremy O'Donoghue <> wrote:
>I have the following understanding (possibly misunderstood) from this
>*   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
>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.
>On 23 Oct 2018, at 20:57, Carl Wallace
><<>> wrote:
>[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
>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.