Re: [lamps] draft-ounsworth-pkix-key-attestation-02
Tomas Gustavsson <Tomas.Gustavsson@keyfactor.com> Fri, 17 March 2023 08:16 UTC
Return-Path: <Tomas.Gustavsson@keyfactor.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3B8C15152C for <spasm@ietfa.amsl.com>; Fri, 17 Mar 2023 01:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.798
X-Spam-Level:
X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=keyfactorinc.onmicrosoft.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60V2YmN_L_gA for <spasm@ietfa.amsl.com>; Fri, 17 Mar 2023 01:16:51 -0700 (PDT)
Received: from EUR03-DBA-obe.outbound.protection.outlook.com (mail-dbaeur03on2071a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1a::71a]) (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 8BB0BC14E513 for <spasm@ietf.org>; Fri, 17 Mar 2023 01:16:51 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Neb1bl+LGKOQL6OfHo2IOmEt3TvrjHmY2+T3olP/AqMW70vs1HW2iWtd3BE3wF+cKl1V5B8FAS71yx/bhc4SzGJVEFL0qWaXcEVJHHo2SoXGPwN0MKCxfut1PUM17BM1cuTNS5ufBtdbRvovWk1n2HgMpE8fk04s1UBmNtw9KEl/G9nfW3QSGhwUt7SkLKQYBym5e7hAPTCCKhGWHEKj+QUD6Jkp/Xp5lRyDKV3hFOQBmx2neChtIPt5Reqfq3V3cWIljed05pmn55dhuk+kD/nAhMgVVvQjZo1Hon2Fx9sT3Y9ZhcTIR2hkZ/+YqGmMcAd7qDtC8sp79WdO6+kTUA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uskSwJ3RWwl22qHSLFGWcUs8SS9qi9tiw2ySCQWKxHM=; b=fWXGN21keQ3Z8iHwgYhhGF8PKt0gBDYHciJrBHSm8ffP8WTU3toCCJgusLOIKRtifYX/ss5LyTmPSs1EToC56VB6rwsfi5KyCFHmWWT15cOLpCbpoVIqP9jvYgD0MtzWHumEL50EoD7TSnVTEfnrrZYWKae43NRLOTtvaBLdKtstUhioUMtr3j5LHo7PX2SqggbYYRb2G/tmG3MxjEPhtAOaafAdivyaiowF+jqN+m8kNm1DM80dCsWodmHqKfNejzOyMRO/BTIlcCyIR0jtFkcfjV7XMp93Esf8ynGYihTK0Y10pxayKSYngwphZYibJLe9jRse3OuLgD8jKMWM7w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=keyfactor.com; dmarc=pass action=none header.from=keyfactor.com; dkim=pass header.d=keyfactor.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=KeyfactorInc.onmicrosoft.com; s=selector1-KeyfactorInc-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uskSwJ3RWwl22qHSLFGWcUs8SS9qi9tiw2ySCQWKxHM=; b=kc7Gx+4mROjuOgmmh+WiUyl4CTcOq1Q4rHcwpF+YSebd+Um5wOtuMDPgNfRIF9iI10UVPJizwnTLO0HGuLih3W0NiqK8BCglDQXi87YhH2ibTaqDd7b5W6pBuCdkL4WAV2zFXyVZ6BVw6+29F/+P95z2zo9wHnbXDVsI7r0qB5JHSdiLdBg9naEhnyPiYX4qTW0gTGJ+Y8S89EBq3LNOXkQykE1rVNgA96X+Hl8wV/HnXD5iMKTbUsFJnOfmJTWovTq6wBSUVNujqN/PkHdF2Lt4/ICvO3F2waKyNLKaP50OhAcy3X5JWGqCjoJ9+6f3IbUdEy+EP3iLVOQK+vSmtg==
Received: from DU0PR03MB8696.eurprd03.prod.outlook.com (2603:10a6:10:3ef::5) by AM0PR03MB6257.eurprd03.prod.outlook.com (2603:10a6:20b:144::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6178.35; Fri, 17 Mar 2023 08:16:47 +0000
Received: from DU0PR03MB8696.eurprd03.prod.outlook.com ([fe80::3647:297d:97d1:34b4]) by DU0PR03MB8696.eurprd03.prod.outlook.com ([fe80::3647:297d:97d1:34b4%6]) with mapi id 15.20.6178.035; Fri, 17 Mar 2023 08:16:47 +0000
From: Tomas Gustavsson <Tomas.Gustavsson@keyfactor.com>
To: Michael StJohns <msj@nthpermutation.com>, Mike Ounsworth <Mike.Ounsworth@entrust.com>, Carl Wallace <carl@redhoundsoftware.com>
CC: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "spasm@ietf.org" <spasm@ietf.org>, Chris Trufan <Chris.Trufan@entrust.com>, Richard Kettlewell <Richard.Kettlewell@entrust.com>
Thread-Topic: [lamps] draft-ounsworth-pkix-key-attestation-02
Thread-Index: AQHZVscyCvo3E32wjk6ScJoHWtz6PK78MIkAgAAF7QCAACp1AIAAFaoAgAACZACAAALngIAABcmAgAA7WwCAAHKWgIAA3oGAgAB5UICAABt6dw==
Date: Fri, 17 Mar 2023 08:16:46 +0000
Message-ID: <DU0PR03MB8696620C88C7D02B8E430A6386BD9@DU0PR03MB8696.eurprd03.prod.outlook.com>
References: <19f6d953-1124-7232-88fa-69259f65a995@nthpermutation.com> <7F135A77-EE7C-4843-84F9-7BFC25D34104@redhoundsoftware.com> <e8de67c6-78c9-05ed-128a-2611548e8ebc@nthpermutation.com> <6412d42f-87fd-3764-13d4-1bfe447e6bce@cs.tcd.ie> <CANeU+ZDYwUA8RDctfXZ6XrC0u8oDuUrbT3Gt1Q7iAXq8Nnygkw@mail.gmail.com> <56F93112-A469-444C-A8CF-74C3986774DE@redhoundsoftware.com> <CANeU+ZCcdCHu4c1ziYNs_oGGztEc0Y4asAxCdwrYac81D7gR+w@mail.gmail.com> <4E8596ED-E411-4BDB-A9EF-3E3A414BBBA5@redhoundsoftware.com> <561d558f-8951-c176-a26d-989670a248c3@nthpermutation.com> <E46CE5CE-B067-476A-BFBC-7344943BD346@redhoundsoftware.com> <CH0PR11MB5739D77A1EF29EDA218304989FBC9@CH0PR11MB5739.namprd11.prod.outlook.com> <04fa4fd8-456c-2f04-eaef-ca3cb5e23fda@nthpermutation.com>
In-Reply-To: <04fa4fd8-456c-2f04-eaef-ca3cb5e23fda@nthpermutation.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=keyfactor.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DU0PR03MB8696:EE_|AM0PR03MB6257:EE_
x-ms-office365-filtering-correlation-id: a8ad6af4-b623-4527-5c4b-08db26bff370
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ertk6EQEvyGxixDYGXFMFDobOzhH3iA0008NgwC1/Lc4Q6o7f3QWiIudfjOhbcZEMp1jQCvEgT6X3bUQy5fu0PRoSgrrZCrkCRgMz3tG1XFYI9Dc1TQa6195BgkBPLB2EvX8p+VgRJeArR6gqK42nzSM5xDLwieuxtA1KUE1btN7DlJBvw5pCMMq7U4dJ5w42cBgMmoXgXHllHqqmb3FUHbhSbjYiMV5k7vAclawrwxJRIYNpkdOjfLgDHLrogMF4Sbh+cjuvFlZZPBs8bN7YaCsk7BmKqpIbqanziw4Rsp7YRdwsNr37yWVU6Sm5yX8QpkQH384KKYyB7Pb4Gy+SxqO8g/NAPBgfxkhBj3cqUv4+vUZvJaPl/5uRF1bjguGOt3lC922K2herz+JFLK26s/BbkrtJ2N8KoO76Vdr9k2x/NJwdezGsN7DitvjOjCgUVG5YGq48S8iPkVno19z9Ny1xdZ1Uo6QgdooKaABn/TkB7FzlrMT/3Wotq3KAOtxvbEbwiDhaYAHsgQFEAh4HeAYI/gBZXDHQ9SFtIEuMummToeeoDV68R6kVm3FiTRPAI/vkXq4H5I6U/lGl/gEfq0a0/pM/TfhVBh3MJZhJuFARRpovx8mOY0YExFb9f2nDSTEBj+A5HiNhtSGBCRRomaeuOfuOyT9+BnAzUk+1oXZp+JnvAtet1Eur3oJhmzo5lIfT6p3EjKarIqSnzMnAqdVdrBdabwPm0kammVqoTo=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU0PR03MB8696.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(4636009)(136003)(396003)(376002)(346002)(39850400004)(366004)(451199018)(53546011)(6506007)(26005)(966005)(9686003)(66476007)(64756008)(66446008)(19627405001)(76116006)(91956017)(66556008)(66946007)(4326008)(8676002)(86362001)(66574015)(186003)(7696005)(66899018)(71200400001)(478600001)(83380400001)(45080400002)(33656002)(110136005)(54906003)(296002)(316002)(55016003)(38070700005)(8936002)(52536014)(19627235002)(38100700002)(166002)(41300700001)(5660300002)(2906002)(122000001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: /feMXqGB8oSV5zz16/WOmZf2dpEfzfnfUe+EKESRI+o7lI9mjO4MezVQjvmdcuMRwnCtzc3lxS684qerdykqepROe7uuCxQSuPMcujB2hi+SLEc2SqqJAQt6s4I6kqce7RVBWkSEysj7bWDsdR6nwX7ByfE6rRcxBibFbg3w2QEXcJp73X55PjrQnR8gVx52C896X3aDCwyuY0wKEUCAKnpWcwhImokF3TasQSlyvUXiPRVFw11VCi8tNmTd3APTDF1+Ko1uggCLdfZ3U2h7xuriKap3Vk6xqaXrpvX1jGaT4mrYKxUUjvYeVF1FNJjcNd+ucVqMPDj1mf0Z70GlAVmowKsQZjeXrYZ6USDccFjtlbKnOT5KZw2yfZGxYW8xteiOj3cKzpoTnxkpJXYXVmTaOGxg6GMzTrLtSuZUsz0T7rUL3t7bSKLQd7ldb6xkd+1kETNT9CFmvq5av4/DDNUTTt7/8AuO+4c3zzJkiB/FBoKJ5In8gkfKHrGIKSrB74zkR5M9iJauZ43iW5gviG4+rCQTgU98qYo9quZtRrvTgIaOQUiI4X8V4wzPBDSklDrdvpNwmdAWhT+vbyWAyxmvhHW4dvzE2NezisqHHKupvwFrSRhqvaZxFgBDyvNi6xrlr7ZyM2K2mEQQwAVsCnu9K5czzyJiwEwFTl+1SqqJyfjWCzLMpws8NiC15GMvijES7x+KhOfCQzpGBBjhCt1nuvm4LB84JhzGsI+2358r/vCcWx9XgXvb12Y+h5ir1P/h+bR0MqyeQNeNRGj/ufeU1Kv5AqsaqGlp+Vwn1/cQLq6A37UoZVtc/VS0Wnmo09PUzx+aYqkC/A12iFpjQ0QdSSeFAUnrdbnH60cWbXnfmEkLcXOhSEYpS2NojXWp/rQhYfJYLvwm0xKfWOxehKMM9m2125gGbhDkHMr+8nlTG7slsrKL3Dkj8CJxkmEqSEI4ogVMPdvMD4Qtv1bQvyIaFcbDX1ieGcRja8dg44zo8cBBhIsY5/469isdpBX6DHRB0xAbe5yjuIcaIMM9cLSDMmv7FWtD/KKFpma+f6HGJ7NcFUMzfE0jNMmQVhgu5+idoXMOgEM8ja8jUwHO77JiVIJLxY/ZhyB0XgtILcRtMwh1mScgFYzWoBe47jkdk6kFzSxg3AWzyIoloqOVuI+LR2pSSoW6zeYNa5Q2/A+hVyfsS8PYoWKA6+h9LNiAVEl5707g989D8r+KdNB9V0uNbhD3eG2qukup85X2G3lhmIe4RME0Sw+g1QIcHeyYtYSyzo8AjvllFQCHL3qidsOkWNYteugIMRAOGD7VzU4PirZAs4dcz5tFUoka/tAoC0eIc+238v6qUaigfXCaoVsixHVw4U3I2K+rKXf7YW7/neDiCDr2z1uHpIOHywHVTUqFjV7NQIddswaBUHsBbqrHe/X3STZWs6CDMnHU9t2Kk+cIVCfx/lKgjBd+nn16P9dRCP4frCnZZksHU1mIni3Ta4hYcSdw0O4TACSwxEGyk90HreQuGrrDHlTeJOChou8DJgd6dsQRjqnuU3nLX8VYK7ufY1KGpq1AGFbDxBzyjCKvujBeedvQGF9Ys3he
Content-Type: multipart/alternative; boundary="_000_DU0PR03MB8696620C88C7D02B8E430A6386BD9DU0PR03MB8696eurp_"
MIME-Version: 1.0
X-OriginatorOrg: keyfactor.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DU0PR03MB8696.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a8ad6af4-b623-4527-5c4b-08db26bff370
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2023 08:16:46.7268 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c9ed4b45-9f70-418a-aa58-f04c80848ca9
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: +QwnsCeRtxjZFyfI2oVFU7outpQdY2oMBrspWnT/I6kbPLK7uhKXPq0kryItZp84l6Ol/SWW2kXrG+W5Tc/1FECQUmJwlNpO5OAOht4MQJk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB6257
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/D8LpHd2GFWNBO-Otv9X9R2mLT08>
Subject: Re: [lamps] draft-ounsworth-pkix-key-attestation-02
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Mar 2023 08:16:54 -0000
Key attestation standardization has been ducked for decades unfortunately...hence the jungle we have out there. As it comes to code signing certificates I suspect it will be mayhem For TPM, thanks for the reference to TPMS_ATTEST, I will add a link to that to the github page. I assume that what Microsoft uses for key attestation for TPMs, tucket into a PKCS#10 CSR. Is that correct? https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation Cheers, Tomas ________________________________ From: Spasm <spasm-bounces@ietf.org> on behalf of Michael StJohns <msj@nthpermutation.com> Sent: Friday, March 17, 2023 7:34 AM To: Mike Ounsworth <Mike.Ounsworth@entrust.com>; Carl Wallace <carl@redhoundsoftware.com> Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>; spasm@ietf.org <spasm@ietf.org>; Chris Trufan <Chris.Trufan@entrust.com>; Richard Kettlewell <Richard.Kettlewell@entrust.com> Subject: Re: [lamps] draft-ounsworth-pkix-key-attestation-02 CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email InfoSec@keyfactor.com with any questions. On 3/16/2023 7:20 PM, Mike Ounsworth wrote: Hi, First-off, I value all the opinions expressed here. Good to get many view points and public scrutiny, and all that. I’ll try to respond to as many of the points raised as possible. I am going to thoroughly dodge the holy war about X.509 in general (sorry Stephen). Other than the openssl scripts in the github for this draft, this is not implemented in any set-in-stone way. We are legitimately interested in community feedback, subject to the constraints I’ll try to outline below. Thanks for the pointer to https://github.com/pkic/remote-key-attestation<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpkic%2Fremote-key-attestation&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7C9a5f95a2d6cf4581651a08db26b1a785%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638146316717172465%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hEfjugZCexeBseNSd9k%2FiBhGoHFUR7fMuc6TqhZ2hGo%3D&reserved=0> The fact that pretty much every row has something different in the Format column is the problem (including that almost 50% have not implemented anything yet). As a CA, needing to implement parsers for several dozen different formats underscores the need for a standard. Timeline: we have a short fuse on this one in the form of the CA/Browser Forum requirement that CAs need to verify HSM key residency for code-signing certs by June 1, 2023, which is basically tomorrow. We need an automated solution ASAP. Doubtful we’ll make the June 1 deadline with any meaningful level of adoption, but the longer this drags on without a standardized automated solution, the more annoying it’s gonna be for everyone trying to buy a code-signing cert (Michael SJ, I see your “worst form I can see for attestation" and raise you screenshots of Teams sessions of HSM consoles, which I suspect will be the status quo for a while, and one that we want to get off of ASAP). Um - if this is your timeline, then what you seem to be saying is - "This is what we need, and we're not going to take any input because we need it now." So not quite sure why you're asking for this to be a WG document? That paragraph above unfortunately has a a number of logical fallacies. The most important one is that NO big-iron HSM implements this, and worse than that, no big-iron HSM has the certifications to issue an attestation. I.e. say you figure out a format, you've probably got a complete HSM replacement cycle to go through before you start getting manufacturer attested HSM systems that can issue attestable keys that you can actually believe. (Or are you planning on some sort of bootstrap for the HSMs chain of trust?) WRT code signing certificates, I'd actually focus on issuing certificates against a TPM attestation for a key tied to a particular personal computer. It also has the characteristic of being built with a manufacturing chain of trust that can be used to bootstrap the attestation chain. What you want inside the HSM is a fairly clean and simple list of attributes that can be bound into an easily constructed signed blob associated with that . That blob has really no requirement to look anything like ASN1 - just something that can be signed by an originator and that can be verified by a CA system. The cost of the CA system to implement [1..N) parsers is tiny compared to the cost of the HSM vendors writing and implementing the code, setting up the attestation process for the manufacture of their devices and the device attestation key, and then going through all the QA pain necessary to make sure they didn't screw up the other security functions. Constraints: ASAP. Given that the generation side of these will need to be done inside HSM firmware, which has CommonCriteria and possibly FIPS validation implications. We’re going for absolutely minimal amount of new code because otherwise re-certification becomes the biggest threat to “ASAP. We’re proposing a pure X.509 cert chain with a small number of new EKUs and v3 extensions (which contain more-or-less constant contents) because that’s the most likely to be something that all crypto modules can already do. You’re right Micheal that, especially on the leaf cert, DN, SerialNumber, notAfter are unnecessary baggage, but we’re proposing an on-average 5-long cert chain, so we’re obviously not counting bytes. /shrug Crypto modules mostly DO not grok X.509 or more than a little bit of ASN.1 and that's usually templated. The rest of the stuff (e.g. the various chain certificates for the attestation key ROT), tend to be static opaque data rather than interpreted by the HSMs. I also counter with how simple this thing is for CAs to parse: run it through any cert chain parser with a trust store full of the HSM manufacturer TrustAnchors, check that the leaf cert does not have the `id-Recoverable` EKU, check that the key in the leaf cert matches the key in the CSR (or equiv. that the CSR signature validates under the key in the leaf cert, if that’s easier), and that’s it, you’ve satisfied the CA/B BRs. There’s literally no way for HSM vendors to muck it up in ways that will force CAs to implement per-vendor parsers because it’s either a valid X.509 chain, or it’s not. Sure - and I counter with the pain of having the HSM create a signed X.509 cert internally (vice having the HSM sign a cert - different things here). The cert MUST be created internally for security purposes. You could probably hard template it - build a structure that looks like a cert, but that has places to drop your attestation stuff into it - but again, why would you? And if you're going to template something, then why not use the TPM2.0 structure as the signed blob? (e.g TPMS_ATTEST - described in part 2 of the TPM Rev 2.0 documents). Already defined. Then all you need to do is define how that signed blob is carried in the CSR, and that's about 15 lines of ASN1 maybe. Note that I have no problem whatsoever of having the chain of trust be a set of X.509 certificates. I’m all for building something beautiful from scratch, but that is a different project for a different deadline since this CA/B F deadline doesn’t afford us 3+ years of debate plus 3+ years of interop testing. I never said we’re going for pretty. We are going for easy and fast. So probably not a working group document then. People have tried to use the IETF as a rubber stamp before. It doesn't usually go well. The approach you're suggesting doesn't come close to being a general solution for including an attestation in an CSR. Just saying - Mike --- Mike Ounsworth
- [lamps] draft-ounsworth-pkix-key-attestation-02 Michael StJohns
- Re: [lamps] draft-ounsworth-pkix-key-attestation-… Carl Wallace
- Re: [lamps] draft-ounsworth-pkix-key-attestation-… Michael StJohns
- Re: [lamps] draft-ounsworth-pkix-key-attestation-… Stephen Farrell
- Re: [lamps] draft-ounsworth-pkix-key-attestation-… StJohns, Michael
- Re: [lamps] draft-ounsworth-pkix-key-attestation-… Carl Wallace
- Re: [lamps] draft-ounsworth-pkix-key-attestation-… StJohns, Michael
- Re: [lamps] draft-ounsworth-pkix-key-attestation-… Carl Wallace
- Re: [lamps] draft-ounsworth-pkix-key-attestation-… Michael StJohns
- Re: [lamps] draft-ounsworth-pkix-key-attestation-… Tomas Gustavsson
- Re: [lamps] draft-ounsworth-pkix-key-attestation-… Carl Wallace
- Re: [lamps] draft-ounsworth-pkix-key-attestation-… Mike Ounsworth
- Re: [lamps] draft-ounsworth-pkix-key-attestation-… Michael StJohns
- Re: [lamps] draft-ounsworth-pkix-key-attestation-… Michael StJohns
- Re: [lamps] draft-ounsworth-pkix-key-attestation-… Tomas Gustavsson
- Re: [lamps] draft-ounsworth-pkix-key-attestation-… Michael StJohns
- Re: [lamps] draft-ounsworth-pkix-key-attestation-… Tomas Gustavsson
- Re: [lamps] draft-ounsworth-pkix-key-attestation-… Tim Hollebeek
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pkix-k… Mike Ounsworth
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pkix-k… StJohns, Michael
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pkix-k… Tomas Gustavsson
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pkix-k… Wang Haiguang
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pkix-k… Michael StJohns
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pkix-k… Michael StJohns