Re: [Iot-onboarding] what can pinned-domain-cert actually pin?
Kent Watsen <kent+ietf@watsen.net> Tue, 27 August 2019 18:43 UTC
Return-Path: <0100016cd46359e7-8c844438-dc7a-45df-9868-ba0957bcc89f-000000@amazonses.watsen.net>
X-Original-To: iot-onboarding@ietfa.amsl.com
Delivered-To: iot-onboarding@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F43912088E for <iot-onboarding@ietfa.amsl.com>; Tue, 27 Aug 2019 11:43:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 1AXHD_3MLo6d for <iot-onboarding@ietfa.amsl.com>; Tue, 27 Aug 2019 11:42:58 -0700 (PDT)
Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31222120876 for <iot-onboarding@ietf.org>; Tue, 27 Aug 2019 11:42:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1566931376; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=6P1S5m24kdeudGazxKyXQe9gH5dQRSgP8vUG7ip67Gg=; b=a4CboWpD9ijm9Nd4hMn+NgnrUWNN2uN6TW7HcI37JLB006RHoZ9f7u05wnqoEmYW In88X+aBpHUXmsTCNTYR/M1TXCilCk2Qk5zwtWTqAezkIpHhFGfkPzkKQXljqwGxNgl 7yNR/S8EaGcFJ6LafbmNnoMzzAyXMdF/aNDtWezg=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016cd46359e7-8c844438-dc7a-45df-9868-ba0957bcc89f-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_90AD47FF-37F6-4CB2-9D0E-D0B316CA2750"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 27 Aug 2019 18:42:56 +0000
In-Reply-To: <2693.1566923418@localhost>
Cc: iot-onboarding@ietf.org
To: Michael Richardson <mcr+ietf@sandelman.ca>
References: <2693.1566923418@localhost>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.08.27-54.240.8.33
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/pFSBAEw8Jhv6m9jdYSw_M73pY_4>
Subject: Re: [Iot-onboarding] what can pinned-domain-cert actually pin?
X-BeenThere: iot-onboarding@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IoT onboarding mechanisms <iot-onboarding.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-onboarding/>
List-Post: <mailto:iot-onboarding@ietf.org>
List-Help: <mailto:iot-onboarding-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Aug 2019 18:43:03 -0000
In SZTP, pinned-domain-cert is the long-lived TA to a potentially short-lived "Owner Certificate". In theory, the root of the pinned-domain-cert PKI could be a public CA but, in practice (because public CAs don't issue long-lived certs), it means that a private PKI needs to be used. Due to the nature of these PKIs NOT being used to secure TLS-based services, the need for a public root TA isn't there, so no big deal. The "private CA roll-over" scenario you mention is side-stepped by enabling the Owner Certificate to itself be a partial chain (i.e., total-chain = partial-root-chain + partial-owner-cert-chain), hence the partial-root-chain part can be protected by some offline HSM while signing (e.g., annually) some middle-level CAs that are used to sign the actual Owner Cert EE cert. Separately in SZTP, there is the notion the device dynamically (during bootstrap) receiving the TA for a bootstrap server it it being redirected to. In this case, the bootstrap servers are presenting a TLS-based service (specifically, HTTPS), and so EE certs MAY have a public root TA. It was discussed at one point that the TA cert may expire and thus wouldn't it be better to enable the TA to be expressed as a 2-tuple [ <long-lived TA cert (MAY be a public CA)>, <name of some 'subject' matter in the TA-issued CA cert>]. But this became complicated and, instead, we opted for introducing alerts/alarms for when certificates are nearing expiration. Part of what made it complicated is that one can imagine an organization obtaining a single top-level organization-wide commercial CA certificate that it uses for a variety of reasons, only one of which is to sign vouchers. Thus, in such cases, the 2-tuple becomes a 3-tuple (and perhaps even an N-tuple), e.g.: [ <long-lived TA cert (MAY be a public CA)>, <name of some 'subject' matter in the TA-issued CA cert>, <name of some 'subject' matter in the voucher-issuer's cert>]. Related, though not exactly, I regret that RFC 8366 states that the pinned-domain-cert value is a single X.509 cert, as opposed to a potential chain of certs. One reason is so as to simplify support for path-validations, as not all libraries support partial-chain validation. Kent > On Aug 27, 2019, at 12:30 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote: > > > There has been some private conversation about what kinds of things an > RFC8366 voucher can pin. The discussion was about the utility of pinning an > EE certificate that comes from LetsEncrypt (LE), or some commercial CA such as > Verisign or Goddy, etc. > > This was also in the context of a long-lived nonceless voucher. > Pinning the CA of a 90-day LE EE voucher is meaningless without also > including a DNS-ID. My take on this is that this is a new kind of voucher, > as it requires significantly more logic in the pledge to evaluate things. > > It has come up that even with a private CA, that there is a problem if the > private CA is pinned, and the CA rolls over. In particular, even for > vouchers with validities of more than a few days, if the private CA should > roll over during that period, there is a problem. > > RFC8649 seems to offer an additional way out for this. > I doubt that CAs will let one include this extension, but if they did it > might also help with the above problem. > > > > From: rfc-editor@rfc-editor.org > Subject: RFC 8649 on Hash Of Root Key Certificate Extension > Date: August 26, 2019 at 3:04:40 PM EDT > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Cc: spasm@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.org > Reply-To: ietf@ietf.org > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 8649 > > Title: Hash Of Root Key Certificate Extension > Author: R. Housley > Status: Informational > Stream: IETF > Date: August 2019 > Mailbox: housley@vigilsec.com > Pages: 10 > Characters: 22410 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-lamps-hash-of-root-key-cert-extn-07.txt > > URL: https://www.rfc-editor.org/info/rfc8649 > > DOI: 10.17487/RFC8649 > > This document specifies the Hash Of Root Key certificate extension. > This certificate extension is carried in the self-signed certificate > for a trust anchor, which is often called a Root Certification > Authority (CA) certificate. This certificate extension unambiguously > identifies the next public key that will be used at some point in the > future as the next Root CA certificate, eventually replacing the > current one. > > This document is a product of the Limited Additional Mechanisms for PKIX and SMIME Working Group of the IETF. > > > INFORMATIONAL: This memo provides information for the Internet community. > It does not specify an Internet standard of any kind. Distribution of > this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > > > > -- > Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > -- > Iot-onboarding mailing list > Iot-onboarding@ietf.org > https://www.ietf.org/mailman/listinfo/iot-onboarding
- [Iot-onboarding] what can pinned-domain-cert actu… Michael Richardson
- Re: [Iot-onboarding] what can pinned-domain-cert … Kent Watsen
- Re: [Iot-onboarding] what can pinned-domain-cert … Michael Richardson
- Re: [Iot-onboarding] what can pinned-domain-cert … Kent Watsen
- Re: [Iot-onboarding] what can pinned-domain-cert … Michael Richardson
- Re: [Iot-onboarding] what can pinned-domain-cert … Eliot Lear
- Re: [Iot-onboarding] what can pinned-domain-cert … Owen Friel (ofriel)
- Re: [Iot-onboarding] what can pinned-domain-cert … Eliot Lear
- Re: [Iot-onboarding] what can pinned-domain-cert … Owen Friel (ofriel)
- Re: [Iot-onboarding] what can pinned-domain-cert … Michael Richardson
- Re: [Iot-onboarding] what can pinned-domain-cert … Owen Friel (ofriel)
- Re: [Iot-onboarding] what can pinned-domain-cert … Michael Richardson
- Re: [Iot-onboarding] what can pinned-domain-cert … Owen Friel (ofriel)
- Re: [Iot-onboarding] what can pinned-domain-cert … Michael Richardson
- Re: [Iot-onboarding] what can pinned-domain-cert … Owen Friel (ofriel)
- Re: [Iot-onboarding] what can pinned-domain-cert … Michael Richardson