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>ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> -- 
> Iot-onboarding mailing list
> Iot-onboarding@ietf.org
> https://www.ietf.org/mailman/listinfo/iot-onboarding