[Acme] Draft notes from 27/3/19

Robin Wilton <wilton@isoc.org> Wed, 27 March 2019 11:26 UTC

Return-Path: <wilton@isoc.org>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B59012029B for <acme@ietfa.amsl.com>; Wed, 27 Mar 2019 04:26:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org
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 Or1tZwaTbU47 for <acme@ietfa.amsl.com>; Wed, 27 Mar 2019 04:26:45 -0700 (PDT)
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700069.outbound.protection.outlook.com [40.107.70.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E853F120254 for <acme@ietf.org>; Wed, 27 Mar 2019 04:26:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A5KtPPsoCMAzcpxMba8gnUGYoc7XUDEpeW15OA9eul0=; b=IvofIFBGwa+n5WMrqEY/xzWlHRg2YuGkfG2wbOmnx0XIlMXa4yNUlOBvHvxCtenvyMJOX6afEz7EVl5mDkUkIUdvgYupGiLJGqw9zsLfe9EoC7B9L1YCd/xFhBXxPFkVVbjNbRbzecGBQo5K5bd3M//Udbn/07UR9TgoHr8lkRQ=
Received: from BL0PR06MB4772.namprd06.prod.outlook.com (52.132.15.214) by BL0PR06MB4483.namprd06.prod.outlook.com (20.177.145.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.18; Wed, 27 Mar 2019 11:26:41 +0000
Received: from BL0PR06MB4772.namprd06.prod.outlook.com ([fe80::d809:7067:33f0:925]) by BL0PR06MB4772.namprd06.prod.outlook.com ([fe80::d809:7067:33f0:925%2]) with mapi id 15.20.1730.019; Wed, 27 Mar 2019 11:26:41 +0000
From: Robin Wilton <wilton@isoc.org>
To: "acme@ietf.org" <acme@ietf.org>
Thread-Topic: Draft notes from 27/3/19
Thread-Index: AQHU5I/zvLGf76HEaEygWpypBcDO9g==
Date: Wed, 27 Mar 2019 11:26:41 +0000
Message-ID: <BL0PR06MB477212E994DADBA195213DACBF580@BL0PR06MB4772.namprd06.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=wilton@isoc.org;
x-originating-ip: [46.4.242.9]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 396ba1e1-0f1f-4265-81e1-08d6b2a71602
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4483;
x-ms-traffictypediagnostic: BL0PR06MB4483:
x-microsoft-antispam-prvs: <BL0PR06MB44838091573E016082727369BF580@BL0PR06MB4483.namprd06.prod.outlook.com>
x-forefront-prvs: 0989A7979C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(199004)(189003)(71190400001)(14454004)(2351001)(105586002)(8936002)(2906002)(106356001)(5660300002)(33656002)(66574012)(476003)(486006)(66066001)(99286004)(55016002)(97736004)(54896002)(71200400001)(7696005)(8676002)(81156014)(2501003)(5640700003)(6436002)(81166006)(1730700003)(25786009)(68736007)(102836004)(3846002)(14444005)(26005)(498600001)(6506007)(53936002)(55236004)(9686003)(52536014)(186003)(256004)(7736002)(86362001)(6116002)(6916009)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR06MB4483; H:BL0PR06MB4772.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: iiKxvD+j+PrDXdS/bljlP/JDfudvYGVNEiN5WwA7hrQsrsZVWmTiRbVf4jYjz4KgOka5IvTce6EIJVxQHsmTQ8D2qdoQoKMIjSskjqLi33/+BdFkov1QyeCibmMdJisxK0dwWb6w4DeyorkUpj21M6H1Owf642D7Zt/M+HLQVq6rChqyA8SXcq58jSQ0jNW/x6gMfgjKJRMDBe4VXodVdHAKkuk6zqqPZiFMwobumiH1lkF8pfQVZXLGKnzNz91L1TAh/Hgffyi1CLQ8ZGEYEzhei45WIze4FUM+C2f78bQwoenUf2J+GJA6Y/hCNTDacGvhoEULJ3JR5YMhfnZAEQSJaHPaeFdZOxi7+ALmTb58jomf8CZA1WKjrEeEQfxMEbEu+C9+ieTVaDiMVxXufEDJ9Ffb92ULpsLL9kYDBVU=
Content-Type: multipart/alternative; boundary="_000_BL0PR06MB477212E994DADBA195213DACBF580BL0PR06MB4772namp_"
MIME-Version: 1.0
X-OriginatorOrg: isoc.org
X-MS-Exchange-CrossTenant-Network-Message-Id: 396ba1e1-0f1f-4265-81e1-08d6b2a71602
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2019 11:26:41.7759 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4483
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/rjaelnEjq7OeVs5lbptnpnRjk1I>
Subject: [Acme] Draft notes from 27/3/19
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Mar 2019 11:26:48 -0000

ACME WG notes, 27/3/19

Milestone: RFC8555 is out!

Rescorla: acme-ip-05 : security considerations section need to be updated following my most recent comments on it.

STAR (Short-term Automatically Renewed Certs) - Yaron Sheffer
Proposed moving to publish; authors don’t feel a new WGLC is needed.
=> Chairs asked WG to read the current version, as an informal alternative to a new WGLC.

Rescorla: My view is that the changes made are sufficient. Ask the incoming AD for his view.
Rowan (incoming AD): ack

Telefonica: there is one implementation, available on Github and in use by Telefonica.

Rescorla: Is STAR being used in certificate issuance protocols?
Carl Jennings: isn’t this the point for the chairs to ask if anyone plans to implement?
Michael Richardson: ?Anima won’t exactly implement, but does recommend it and express a need.


3rd-party device attestation for ACME - Rifaat

Richard Barnes: URL in the ACME JWT specifies the intended destination of the request, on the CA’s ACME server. Is that the intended modification here?
=> Response inconclusive; RB will re-read the specs.

Carsten Bormann: Does authorization become attestation by being packaged as a certificate? What makes this an “attestation”?

Rifaat: the JWT specifies that this device is correctly associated with this certificate.

Michael Richardson: ACME challenges essentially “attest to the existence of the device”.

Watson Ladd: what kinds of certificate are these?
Rifaat: typically, an identifier for the device (MAC address), and a service URI.

Chair: too early to hum for adoption. Draft needs updating to remove any ambiguity around terms of art such as “attestation”.


ACME Client Certificates - Kathleen Moriarty

1 - Device certificates:
Yoran Sheffer - this is interesting but not a good fit for cloud deployments, where entities might not need their own “name”, but might still need a certificate.

Thomas Peterson - IP/DNS not appropriate in all cases.

Paul - would be nice if this could work with IPSEC Cert Protocol

Richard Barnes - if client certs are already identifying themselves by one of the methods identified in the draft, no added work is needed. No core difference between client certs and server certs except in the EKU (which could be ignored under certain certs).

KM - Draft was posted to the mailing list.

2 - End user certs
Should ACME handle these? KM not aware of a use case. Can they be left to other organisations?

Alexei Melnikov: S-MIME certs are a subset of these.

Rescorla: don’t think we need a new “meta-framework” to handle end user certs.

Thomas  Peterson - I think we should, to simplify enterprise handling of browser certs.

Code-signing Certificates

Max - we do a lot of this, e.g. for cable modem certs. The processes are really strict; the certs are more than EV certs, and we wouldn’t feel comfortable automating this.

Watson Ladd: don’t use SMS/email as pre-authorization methods for this. They are too open to compromise, even with 2FA.

Jon: STIR has specified an authorisation token that could be applied in this case - at least as *part* of an automation process.

Karthikeyan: we published analysis of ACME last year; Read vs Write authentication channels are markedly different in security.

Richard Barnes: consider removing superfluous material from the draft as part of the focussing exercise.

Authority Tokens - Jon