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

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Aug 2019 12:30:18 -0400

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.

Subject: RFC 8649 on Hash Of Root Key Certificate Extension
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Date: Mon, 26 Aug 2019 12:04:40 -0700 (PDT)
List-Id: "IETF announcement list. No discussions." <ietf-announce.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:    [email-masked]
        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 [email-masked].  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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Kent Watsen <[email-masked]>
Date: Tue, 27 Aug 2019 18:42:56 +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 <[email-masked]> wrote:
> 
> 
> Date: August 26, 2019 at 3:04:40 PM EDT
> Reply-To: [email-masked]
> Iot-onboarding mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iot-onboarding

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Aug 2019 15:21:45 -0400

Kent Watsen <[email-masked]> wrote:
    > 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.

i.e. adding a layer of indirection solves the problem in the classic way.

    > 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.

When certificates, or when vouchers?

    > 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.

These organization-wide commerical CA certificates seem impossible to obtain
today.  At least, I haven't found a CA willing to sell that anymore, and I
would love to be told I'm wrong.

    > 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.

A revision could change it from single item to an array of items.
That would be relatively easy to figure out in code, but I'm not entirely
sure I understand the use case.  Are these independant anchors, or are the
intended to be related.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Kent Watsen <[email-masked]>
Date: Tue, 27 Aug 2019 19:56:50 +0000

> i.e. adding a layer of indirection solves the problem in the classic way.

Yep  ;)

> When certificates, or when vouchers?

In this example, I meant certificates, but the same principle can apply to vouchers.  We only didn't discuss it because voucher-expiration was out-of-scope to SZTP, other than devices needing to ensure the voucher isn't expired, assuming a validity period is specified at all.

> would love to be told I'm wrong.

Figures.  Oh well, they'll be out of business soon enough...

> A revision could change it from single item to an array of items.

Right, the simplest backward-compatible change would be:

OLD:
   type binary;

NEW:
   type union {
      type binary;
      type ct:trust-anchor-cert-cms;
   }

> sure I understand the use case.  Are these independant anchors, or are the

It's just as I was saying before, to support cases where the pinned-domain-cert isn't a root CA, and the verifying software doesn't support partial-chain validation, hence external mechanisms have to supply the remainder of the chain.

Kent

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Aug 2019 20:21:56 -0400

> It's just as I was saying before, to support cases where the
    > pinned-domain-cert isn't a root CA, and the verifying software doesn't
    > support partial-chain validation, hence external mechanisms have to
    > supply the remainder of the chain.
    
If the other certificates are part of a chain connecting from the
pinned-domain-cert, I'd rather just put them in another field.

In the CMS case, we can perhaps also put them in the CMS certificate set.
I'm not sure if that's a good idea or not.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 28 Aug 2019 08:24:41 +0200

This is worth some discussion tomorrow.  Should I add it to the agenda?

Eliot

> On 27 Aug 2019, at 21:56, Kent Watsen <[email-masked]> wrote:
> 
> 
>

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Wed, 28 Aug 2019 09:08:21 +0000

> -----Original Message-----
> From: Iot-onboarding <[email-masked]> On Behalf Of Kent
> Watsen
> Sent: 27 August 2019 19:43
> To: Michael Richardson <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Iot-onboarding] what can pinned-domain-cert actually pin?
> 
> 
> 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.

What do you mean by long-lived? Public CAs can issue EE certs with expiration times up to 825 days as per https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf. When thinking about pinned nonceless vouchers for thing onboarding, that's still pretty long. If pinning the EE cert, then the voucher is valid until the EE cert expires (assuming of course that the non-bootstrapped thing has an accurate trusted view of time). If the public CA root is pinned, then that 825 day limit doesn't matter as the public CA root will be long lived. E.g. Lets Encrypt ISRG Root X1 root expires in 2035, but if pinning that then we have the DNS-ID issue.

With the advent of Lets Encrypt, and cheap GoDaddy certs, we can expect more operators to use public CAs for everything, including AAA and RA identity certs. Operators already deploy public CA certs on AAAs for guest access and public hotspots.

I really don't understand the statement that "it means that a private PKI needs to be used". I think that the current RFC8366 Voucher format forces a private CAs to be used for practical operational reasons, but there is no reason outside of that why an operator MUST use a private CA for their AAA, RA and/or bootstrap server identity.

> 
> 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.

That still doesn't address the admittedly infrequent root CA change. E.g. if an operator wants to change the offline HSM from an RSA to an EC signature cert.

And if an operator wants to use a public CA, having multiple pinned-domain-cert entries allows an operator to change public CA providers (e.g. from LetsEncrypt to GoDaddy or vice-versa) without killing all existing nonceless vouchers.

Extending the Voucher to allow (i) multiple pinned-domain-cert entries which are independent roots, not just a root and a chain of intermediates and (ii) optionally specify a DNS-ID(s) seems like it gives operators the flexibility of making a public vs. private CA provider choice.

> 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>].

CA/Browser Forum does not allow public CAs to issue intermediate CAs to anyone. If you do that, your root CA will be blacklisted by the industry. So I don't think that's a real world problem.

> 
> 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
> <mailto:[email-masked]> wrote:
> 
> 
> EE certificate that comes from LetsEncrypt (LE), or some commercial CA such
> as Verisign or Goddy, etc.
> 
> 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.
> 
> 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.
> 
> I doubt that CAs will let one include this extension, but if they did it might
> also help with the above problem.
> 
> 
> From: mailto:[email-masked]
> To: mailto:[email-masked], mailto:[email-masked]
> Cc: mailto:[email-masked], mailto:[email-masked], mailto:rfc-
> [email-masked]
> Reply-To: mailto:[email-masked]
> 
> 
>        Mailbox:    mailto:[email-masked]
>        Pages:      10
>        Characters: 22410
> 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.
> 
> It does not specify an Internet standard of any kind. Distribution of this
> memo is unlimited.
> 
> 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 mailto:[email-masked].  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for unlimited
> distribution.
> 
> 
> The RFC Editor Team
> mailto:[email-masked]
> Michael Richardson <mailto:[email-masked]>, Sandelman Software
> Works -= IPv6 IoT consulting =-
> 
> 
> 
> --
> mailto:[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 28 Aug 2019 11:39:21 +0200

> On 28 Aug 2019, at 11:08, Owen Friel (ofriel) <[email-masked]> wrote:
> 
> 
> 
>> From: Iot-onboarding <[email-masked] <mailto:[email-masked]>> On Behalf Of Kent
>> Watsen
>> To: Michael Richardson <[email-masked] <mailto:[email-masked]>>
>> Cc: [email-masked] <mailto:[email-masked]>
> What do you mean by long-lived? Public CAs can issue EE certs with expiration times up to 825 days as per https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf <https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf>.

I don’t think it’s long enough.  A manufacturer at least needs the option to issue a voucher that doesn’t expire for a cert that doesn’t expire.  We just don’t know how long a device might sit in a drawer, nor whether the manufacturer would continue to exist or support a particular device.

One issue we might want to take into account: time may be quite a fluid concept as far as end device clocks are concerned.  That is- how does the client know whether a cert actually is expired?  Now I don’t think we can count on them NOT knowing, but it could also be the case that cert expiry in these cases should just be ignored in favor of the voucher expiry.

Eliot

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Wed, 28 Aug 2019 10:55:10 +0000

> From: Eliot Lear <[email-masked]>
> Sent: 28 August 2019 10:39
> To: Owen Friel (ofriel) <[email-masked]>
> Cc: Kent Watsen <[email-masked]>; Michael Richardson
> <[email-masked]>; [email-masked]
> On 28 Aug 2019, at 11:08, Owen Friel (ofriel) <mailto:[email-masked]>
> wrote:
> 
> 
> 
> 
> From: Iot-onboarding <mailto:[email-masked]> On Behalf
> Of Kent
> Watsen
> To: Michael Richardson <mailto:[email-masked]>
> Cc: mailto:[email-masked]
> What do you mean by long-lived? Public CAs can issue EE certs with
> expiration times up to 825 days as per https://cabforum.org/wp-
> content/uploads/CA-Browser-Forum-BR-1.6.5.pdf.
> 
> 
> I don’t think it’s long enough.  A manufacturer at least needs the option to
> issue a voucher that doesn’t expire for a cert that doesn’t expire.  We just
> don’t know how long a device might sit in a drawer, nor whether the
> manufacturer would continue to exist or support a particular device.

That’s why pinning of the public root CA (and DNS-ID) may be desirable.

> 
> One issue we might want to take into account: time may be quite a fluid
> concept as far as end device clocks are concerned.  That is- how does the
> client know whether a cert actually is expired?  Now I don’t think we can
> count on them NOT knowing, but it could also be the case that cert expiry in
> these cases should just be ignored in favor of the voucher expiry.
> 
> Eliot

This is what BRSKI says about that time issue: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-26#section-2.6.1

---

From: Michael Richardson <[email-masked]>
Date: Wed, 28 Aug 2019 12:37:01 -0400

> expiration times up to 825 days as per
    > https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf. When
    > thinking about pinned nonceless vouchers for thing onboarding, that's
    > still pretty long. If pinning the EE cert, then the voucher is valid
    > until the EE cert expires (assuming of course that the non-bootstrapped
    > thing has an accurate trusted view of time). If the public CA root is
    > pinned, then that 825 day limit doesn't matter as the public CA root
    > will be long lived. E.g. Lets Encrypt ISRG Root X1 root expires in
    > 2035, but if pinning that then we have the DNS-ID issue.

1) LetsEncrypt does not issue 825 day certificates. (That's 2 1/4 years).

2) I'm not worried about the LE key rolling, because the RFC8649 will likely
   be used.

3) By Long Lived, I mean 10 to 30 years.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Wed, 28 Aug 2019 22:29:48 +0000

> From: Iot-onboarding <[email-masked]> On Behalf Of
> Michael Richardson
> Sent: 28 August 2019 17:37
> To: [email-masked]
>     > https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-
> 1.6.5.pdf.. When

I never said LE issued 825 day certs. CA/Brower forum allows public CAs to issue 825 day certs. LE is currently at 90.

> 2) I'm not worried about the LE key rolling, because the RFC8649 will likely

I wouldn’t necessarily say so. Have any CA providers, whether public CAs or private CA implementations (e.g. Microsoft ADCS) committed to supporting this? I'm not aware of a single one that has. Plus, RFC8649 requires that the existing root CA includes the hash of the next root CA keys, meaning that when the existing LE root expires in 2035, then the next root CA could include the RFC8649 hash, and then the next root after that can be seamlessly rotated to. In like 2045. I hope to be long retired by then.

Regardless, LE root rotation is not at issue here. The issue is what happens if an operator wants to move from GoDaddy to LetsEncrypt. Either (i) all existing vouchers are dead or (ii) we need multiple pinned-domain-cert entries. And maybe (i) is fine and if an operator wants to change root CA providers, then the operator sucks it up and reissues all nonceless vouchers.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Aug 2019 14:48:54 -0400

> I never said LE issued 825 day certs. CA/Brower forum allows public CAs
    > to issue 825 day certs. LE is currently at 90.

I know you didn't :-)
The 90 day limit by LE is a significiant operational challenge.
An 825 day limit is significantly less so, however my understanding is that
the pressure is on to lower that limit significantly; to use ACME to (re-)issue
certificates significantly more often, particilarly in light of the STAR work.

    > I wouldn’t necessarily say so. Have any CA providers, whether public
    > CAs or private CA implementations (e.g. Microsoft ADCS) committed to
    > supporting this? I'm not aware of a single one that has. Plus, RFC8649
    > requires that the existing root CA includes the hash of the next root
    > CA keys, meaning that when the existing LE root expires in 2035, then
    > the next root CA could include the RFC8649 hash, and then the next root
    > after that can be seamlessly rotated to. In like 2045. I hope to be
    > long retired by then.

They haven't announced anything, but I think that it they will, and I think
that it provides a very nice way to deal with private CA keys rolling over.

    > Regardless, LE root rotation is not at issue here. The issue is what
    > happens if an operator wants to move from GoDaddy to
    > LetsEncrypt. Either (i) all existing vouchers are dead or (ii) we need
    > multiple pinned-domain-cert entries. And maybe (i) is fine and if an
    > operator wants to change root CA providers, then the operator sucks it
    > up and reissues all nonceless vouchers.

We could also consider pinning the public key of the Registrar.
This is how constrained-BRSKI works.  There are crypto-hygiene issues here,
but maybe it's better than putting more fragile logic into a device that
might remain on a shelf for many years.

This is my only real objection to pinning an DNS-ID: the cost of the full
PKI validation that it requires the Pledge to have (in a bug-free way for a
period of decades), and that the rules for validation of chains won't change
during that period of time.

This is core of the tussle.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Fri, 30 Aug 2019 10:47:17 +0000

> Sent: 29 August 2019 19:49
> An 825 day limit is significantly less so, however my understanding is that the
> pressure is on to lower that limit significantly; to use ACME to (re-)issue

That  is correct, the CA/Browser forum is already discussing that: https://cabforum.org/2019/08/08/2019-07-25-minutes-of-the-server-certificate-working-group/#5-Validation-Subcommittee-Updatenbsp

" Another topic they discussed was the Certificate lifetime which Ryan introduced at the F2F in Thessaloniki. He is close to creating a draft ballot to reduce lifetime to roughly 1 year or roughly 13 months. "

But it is contentious:  https://cabforum.org/2019/08/26/2019-08-08-minutes-of-the-server-certificate-working-group/#5-Validation-Subcommittee-Updatenbsp

" Dean said that DigiCert is actively gathering feedback from large enterprise customers with multi-year certificates and no automation. "

> They haven't announced anything, but I think that it they will, and I think that
> it provides a very nice way to deal with private CA keys rolling over.
> 
> but maybe it's better than putting more fragile logic into a device that might
> remain on a shelf for many years.

Right. You could pin the raw public key and then the RA EE cert could rotate provided the key remained the same. Obviously any changes to the key (length, algorithm, etc.) invalidate vouchers.

> 
> This is my only real objection to pinning an DNS-ID: the cost of the full PKI
> validation that it requires the Pledge to have (in a bug-free way for a period
> of decades), and that the rules for validation of chains won't change during
> that period of time.
> 

Yep.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Aug 2019 16:37:39 -0400

> Right. You could pin the raw public key and then the RA EE cert could
    > rotate provided the key remained the same. Obviously any changes to the
    > key (length, algorithm, etc.) invalidate vouchers.

Depending upon what kind of processing we could assume on the pledge
(thus the tussle), one could imagine that if the key/algorithm/etc. became
too weak, that one could use the key to sign another stronger certificate
to be used going forward.

This doesn't make the key stronger suddenly, but unless the key is actually
compromised, it allows the old nonceless vouchers to be used in the future.

My take is that this is a lot of code effort in the Pledge.
If the Enterprise/Registrar would cause to be operated a long-lived private
CA, then the problem goes away.   It doesn't have to be operated by the
Enterprise itself; it could be operated by a service provider that they
trust.  In effect, it's just a new form of MASA.

I think that this is really the right way to go: to allow chains of
vouchers pinning keys, which can then be used to issue new vouchers
(which could pin new keys).  This solves the long-term problems you have
mentioned, and removes the external dependancy upon a MASA.... by createing a
new dependancy upon an internal MASA.