[Iot-onboarding] what can pinned-domain-cert actually pin?

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 27 August 2019 16:30 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: iot-onboarding@ietfa.amsl.com
Delivered-To: iot-onboarding@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 31339120909 for <iot-onboarding@ietfa.amsl.com>; Tue, 27 Aug 2019 09:30:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Vj6-U0zuL2pi for <iot-onboarding@ietfa.amsl.com>; Tue, 27 Aug 2019 09:30:20 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0803112090C for <iot-onboarding@ietf.org>; Tue, 27 Aug 2019 09:30:19 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E06353818E for <iot-onboarding@ietf.org>; Tue, 27 Aug 2019 12:29:10 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 80B4F89 for <iot-onboarding@ietf.org>; Tue, 27 Aug 2019 12:30:18 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: iot-onboarding@ietf.org
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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-sha256; protocol="application/pgp-signature"
Date: Tue, 27 Aug 2019 12:30:18 -0400
Message-ID: <2693.1566923418@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/77_QN2A9ccJreTJa5BexyecEa6w>
Subject: [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 16:30:22 -0000

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.

--- Begin Message ---
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

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
--- End Message ---
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-