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

Carl Wallace <> Wed, 24 October 2018 16:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D232130E01 for <>; Wed, 24 Oct 2018 09:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CMhZPs_oBQfF for <>; Wed, 24 Oct 2018 09:45:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 986B8126F72 for <>; Wed, 24 Oct 2018 09:45:34 -0700 (PDT)
Received: by with SMTP id 131so1019984qkd.4 for <>; Wed, 24 Oct 2018 09:45:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=Vcoztq+of6qOwz38a5RqxCsJl7RkwjnQvKge6zvjILo=; b=PffOOEcI0lmoyscE4OgwHCenefb8b23kfWvgW4J1tBwK2CEJoQbW/IE5zTQWS+32RU kejyaqWaNrlDvNa6canCSfi6mII8Ls1oHhVbTWVliiGcbsQRY56jT0WisXySi3dPDHko x1dUTRJgfrYqSXrTODq98ZUogdUnex7FeQ7E4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=Vcoztq+of6qOwz38a5RqxCsJl7RkwjnQvKge6zvjILo=; b=hi2Ri/i6cWMGuBwI7eYdIoSYjA5CGtehiXPzO5A8bAyQJVqhpMH61nMDlKWSDnLOLb 6aRj8c+zAUg/4Y2nTCALUp1FyKYDF3OSV+pKNRhtiKfLVTusII1ARB4lHpzpgG+7gJS3 CgJyl3sVdLoH0P00KfgBSGAL3SJJ4uI4D16eAmzfftGWVfsdxGF7W3PvCAOJYp+mOcml Mf4yMmUqlEC/BLcor4p5DOuW/1tpabGq3Iy+H5HxylQ3nLW36wh+9GhjbWv9UwAxkM2G TyyOPm8cXQWR+9hNk6PGSk2TPgV6qTsBKk4cGWuzgQg6+04M05QDZXTGzvG01qxLy9/v TzZg==
X-Gm-Message-State: AGRZ1gJGTleSi2i0mznRt1GiQBpnPs3VUUED2ItVGEfBIBCFcEHuDHQD 7eULs477MB5mrG/0lxYYQMDyzw==
X-Google-Smtp-Source: AJdET5eKhRoGefgichNwUS/qkpkGhHpSKnhZ6EtROxzfKNbIW+svIzhW+7Ln49tXzIStXZqlVr/5fw==
X-Received: by 2002:a37:8282:: with SMTP id e124-v6mr3149721qkd.76.1540399533522; Wed, 24 Oct 2018 09:45:33 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id x1-v6sm4783291qkx.93.2018. (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 24 Oct 2018 09:45:32 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/
Date: Wed, 24 Oct 2018 12:45:22 -0400
From: Carl Wallace <>
To: Henk Birkholz <>, Jeremy O'Donoghue <>
CC: Michael Richardson <>, "Smith, Ned" <>, "" <>, "" <>
Message-ID: <>
Thread-Topic: [Rats] [EAT] Attestation BoF charter updates?
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3623229932_19512313"
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:45:37 -0000

Not sure I follow.

From:  RATS <> on behalf of Henk Birkholz
Date:  Wednesday, October 24, 2018 at 12:42 PM
To:  Jeremy O'Donoghue <>
Cc:  Michael Richardson <>ca>, "Smith, Ned"
<>om>, Carl Wallace <>om>,
"" <>rg>, "" <>
Subject:  Re: [Rats] [EAT]     Attestation BoF charter updates?

> 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
> <> 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 <>
>>> 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
>>> <> 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
>>>> <> , 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 <> 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.
> _______________________________________________ RATS mailing list