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

[Michael Richardson <[e-mail]>]

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:    [e-mail]
        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 [e-mail].  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
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf-announce

--- End Message ---

-- 
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-