[Acme] Use cases / trust model for device certs

Richard Barnes <rlb@ipv.sx> Wed, 17 April 2019 17:09 UTC

Return-Path: <rlb@ipv.sx>
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 C8890120127 for <acme@ietfa.amsl.com>; Wed, 17 Apr 2019 10:09:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
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 dFzYUjBzCTWE for <acme@ietfa.amsl.com>; Wed, 17 Apr 2019 10:09:28 -0700 (PDT)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 402201200F4 for <acme@ietf.org>; Wed, 17 Apr 2019 10:09:28 -0700 (PDT)
Received: by mail-oi1-x232.google.com with SMTP id f196so9905540oib.7 for <acme@ietf.org>; Wed, 17 Apr 2019 10:09:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=oHiJpG/8VGShSh3eLQOZ+jaYJxNFygxfZ4uWOgsbaqY=; b=F7/oVCU+0LoXCexNDOn2SVpBy+Uazytvir93nUPoqSLuLdJmxXDL0252kdat/uJCdK 4Ba+aYoFV757uaRWJ64vYpJuCykQLVVToDBovIhAvXpOm7M5xVsFdJPFrGAHX6AbAJ43 7bd8zkn7FunviPGjc4U/gCnjB/WEn2eKmeHxQHK7BhwB9VY49HjNtnM30dsk/td8jeTz 87MoBcSndbUHzffnUUhWvi9lu3VisGZ6+mG7evlSfrN8xf4xYSOhB4s1mOFLCrmGEsjF 6ykDnMXOnPL+48u7WjY1/jqOt5AdX5Dvitm+olG+EQ+9As4Dr+mPFgUY+2keXmTytO0A xs/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=oHiJpG/8VGShSh3eLQOZ+jaYJxNFygxfZ4uWOgsbaqY=; b=FQUb8z/8wYeYzlEK+7pz7pYo1sugU67qQrYO+GsUrq7TAgGsgdy22MxkLf/gwfC3eD LfE42RecVtCYVOPrs5MqzYSk6sHjpC9XVfbmpDzbB3D+p1MDgVWuoDYowjKsST6HxYuB RuPjUixIMfPfzImLwYLhILv56sd7unwfU6zaM2TJ0FRmiZ2ezayQdwcpdTDuMJlVmRq8 ZQxdi2JlSGdmWAdrFzX7HvjLD+XFmINRpF9q23yWXd55Rnn2dtI4BkAvyen+dMldH/mx VZxeCt4xAE+zocz20VnbjQNCj64GrO7/WeACkn6eZ70W9KpK1WYe+VAuNOEL+tf1dzpG vKuw==
X-Gm-Message-State: APjAAAVxA36j+IpzLvL+uHXHCWg7l8lTiWkk42i4yaqxh6MdTd8x+exf 181lHB5kyQ8W9JJOkNXbgBnChFE7/Ds8MXzyXNt8H9XZ9slIGQ==
X-Google-Smtp-Source: APXvYqynAXVhkPNMu4Az7YCAKr9zzpfOMlhddgo1iJjcaNb+8hRlb86OhKv5xX8TodyqVvYQybhJnwJgOdZAOrneQYo=
X-Received: by 2002:aca:d54f:: with SMTP id m76mr181139oig.149.1555520967145; Wed, 17 Apr 2019 10:09:27 -0700 (PDT)
MIME-Version: 1.0
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 17 Apr 2019 13:09:08 -0400
Message-ID: <CAL02cgT1hY_wm8d0zpa3hpx926B3_of+=cnDEwikMHS90gVyjw@mail.gmail.com>
To: IETF ACME <acme@ietf.org>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: Owen Friel <ofriel@cisco.com>
Content-Type: multipart/alternative; boundary="000000000000b00e000586bcf20d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/ABK5p-xlzejnwG18bYkIqGHsTKI>
Subject: [Acme] Use cases / trust model for device certs
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, 17 Apr 2019 17:09:30 -0000

Hey Rifaat,

Owen and I were chatting about ACME and device certs this morning, and it
seemed like it might be useful to rekindle discussion on the topic here on
the ACME list.

I'd like to push a little more on the trust model here.  Just to establish
some terminology:

- Device: Uses certificates to authenticate identifiers
- Vendor: Makes the device that will get the end certificate
- Customer: Buys the device from the vendor and operates it
- CA: Validates identifiers and issues certificates
- Relying Party: Uses certificates to verify authentication for identifiers
- Device Identity: MAC address or similar

In the flows Owen and I have been discussing (more based on ANIMA/BRSKI),
the model is basically broken in two, with the customer in the middle:

1. The customer validates devices' device identity as part of the ANIMA
flow, based on the customer trusting the vendor, and assigns the device a
domain name
2. The customer uses ACME to issue domain name certificates (the CA is
unaware of the device identity)

That all pretty much just works with BRSKI and ACME as they are today.  But
it presumes that the RP is authenticating the device by domain name, as is
prevalent in most uses of TLS today.

In contrast, it seems like your draft presumes that the RP needs to know
the device identity; it's not satisfied by a domain name alone.  Can you
elaborate a bit more on what scenarios you have in mind for this?  If all
you care about is the customer tracking things, then the model above is
sufficient; the customer can simply assign domain names that encode the
device identity however it likes.

Thanks,
--Richard