Re: [Anima] representing ACP info in X.509 certs

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 21 June 2020 16:09 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6470B3A0D87 for <anima@ietfa.amsl.com>; Sun, 21 Jun 2020 09:09:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 8YXbyKzblkkI for <anima@ietfa.amsl.com>; Sun, 21 Jun 2020 09:09:13 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DFAD3A0D86 for <anima@ietf.org>; Sun, 21 Jun 2020 09:09:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7D0D3389B6; Sun, 21 Jun 2020 12:06:32 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9fjafKHMr5LV; Sun, 21 Jun 2020 12:06:31 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C1D29389B4; Sun, 21 Jun 2020 12:06:31 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7412160; Sun, 21 Jun 2020 12:09:10 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Eric Rescorla <ekr@rtfm.com>, Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>, Anima WG <anima@ietf.org>
In-Reply-To: <CABcZeBMncZSQOfYsoVS-ZZoSbqZGOg+vQ41OdzAejrRfVozhyQ@mail.gmail.com>
References: <ece7aed3-ede3-5546-4586-1d98d3f71183.ref@verizon.net> <ece7aed3-ede3-5546-4586-1d98d3f71183@verizon.net> <CABcZeBMncZSQOfYsoVS-ZZoSbqZGOg+vQ41OdzAejrRfVozhyQ@mail.gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sun, 21 Jun 2020 12:09:10 -0400
Message-ID: <4280.1592755750@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/V0qBXOenJcM_zysmj9CREl6wRK8>
Subject: Re: [Anima] representing ACP info in X.509 certs
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jun 2020 16:09:15 -0000

Eric Rescorla <ekr@rtfm.com> wrote:
    > One thing that's not clear to me: is the expectation that you will be
    > using a public CA or that you will be using an enterprise-level one?

There are different many use cases, and it is precisely because we can't be
prescriptive about the operation of the CA involved that the WG compromised
on a solution that we know can be deployed today.
I wasn't happy with the result, but I realized that I could live with the
compromise result.  The WG did consider all the points that you have raised.

1) a private-CA internal to the ACP Registar.

2) an enterprise private-CA external to the ACP Registrar, which is embedded
   in another system, such as ActiveDirectory

3) when we started this work, it was possible to have (a) and (b) with
   anchors toward public CAs

4) an enterprise private-CA external to the ACP Registrar, which is
   operated by a third party, which might use ACME or something else to enroll

5) a small (or growing) enterprise entity that uses ACME to a public CA.
   The is no "group" policy to deploy a private CA, and there is a strong
   desire that the devices that are enrolled do not train users to think
   security exceptions are "normal".
   Obviously, the DN presented to a browser is not a rfc822Name,
   but would have to be an dnsName.  The ACP rfc822Name
   may not be the only SAN in the certificate, but it is one that
   draft-ietf-acme-email-smime-08 allow the Registrar to validate.

6) virtual corporation, where most of the systems are "hosted" systems
   in "the" cloud.  Some of these scenarios are described by
   https://datatracker.ietf.org/doc/draft-friel-anima-brski-cloud/

7) construction-site scenarios, where EE LDevID will "be left behind"
   for the eventual home owner, who could rekey into 1-6.
   see https://datatracker.ietf.org/doc/draft-fries-anima-brski-async-enroll/

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-