Subject: Re: Last Call: <draft-ietf-lamps-hash-of-root-key-cert-extn-02.txt> (Hash Of Root Key Certificate Extension) to Informational RFC

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 02 Jan 2019 10:26:05 -0800

On 27 Dec 2018, at 14:13, The IESG wrote:

> The IESG has received a request from the Limited Additional Mechanisms 
> for
> PKIX and SMIME WG (lamps) to consider the following document: - 'Hash 
> Of Root
> Key Certificate Extension'
>   <draft-ietf-lamps-hash-of-root-key-cert-extn-02.txt> as 
> Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits 
> final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2019-01-10.

This extension seems useful to CAs that understand the increased risks 
that using it incurs, but those risks are not mentioned in the document.

The document implicitly assumes that the CA will in fact use the key 
named in the extension next. Using this extension increases the risk of 
a bad trust anchor rollover at the same time that it makes good rollover 
more secure. If the key listed in this extension cannot be used when the 
CA eventually changes the trust anchor, relying parties will mistrust 
the new trust anchor. There are many reasons why a CA might think they 
know the next key but cannot use that key when they change trust 
anchors, such as if the HSM that holds the next key fails or is 
destroyed. Given the last sentence in Section 2, this could mean that a 
CA might never be able to issue a new trust anchor, even if the key for 
its current trust anchor is compromised.

Given the severity of the new risks of using this extension, they need 
to be introduced at the beginning of the document and then discussed in 
more detail in the Security Considerations. Note that this risk affects 
the last paragraph of the Security Considerations section as well.

Editorial:

The abstract says:
    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 by the trust anchor
    at some point in the future.
The term "trust anchor" is used as the concept, not the bits in the 
certificate. As such, the last sentence is confusing because the trust 
anchor will change when the key changes. A possible fix is to replace 
"will be used by the trust anchor at some point in the future" with 
"will be used in a trust anchor at some point in the future".

The first list in Section 2 would be clearer if the order was R1, R2, 
H2, C1; this would also then match the order in the second list.

Later in Section 2, a sentence appears to be missing its subject. "That 
is, verify the signature on the self-signed certificate..." should 
probably be "That is, the recipient verifies the signature on the 
self-signed certificate...".

--Paul Hoffman

---

From: Russ Housley <[email-masked]>
Date: Wed, 2 Jan 2019 14:57:08 -0500

> On Jan 2, 2019, at 1:26 PM, Paul Hoffman <[email-masked]> wrote:
> 
>> The IESG has received a request from the Limited Additional Mechanisms for
>> PKIX and SMIME WG (lamps) to consider the following document: - 'Hash Of Root
>>  <draft-ietf-lamps-hash-of-root-key-cert-extn-02.txt> as Informational RFC
>> 
>> The IESG plans to make a decision in the next few weeks, and solicits final
> This extension seems useful to CAs that understand the increased risks that using it incurs, but those risks are not mentioned in the document.
> 
> The document implicitly assumes that the CA will in fact use the key named in the extension next. Using this extension increases the risk of a bad trust anchor rollover at the same time that it makes good rollover more secure. If the key listed in this extension cannot be used when the CA eventually changes the trust anchor, relying parties will mistrust the new trust anchor. There are many reasons why a CA might think they know the next key but cannot use that key when they change trust anchors, such as if the HSM that holds the next key fails or is destroyed. Given the last sentence in Section 2, this could mean that a CA might never be able to issue a new trust anchor, even if the key for its current trust anchor is compromised.
> 
> Given the severity of the new risks of using this extension, they need to be introduced at the beginning of the document and then discussed in more detail in the Security Considerations. Note that this risk affects the last paragraph of the Security Considerations section as well.

The point is to facilitate the transition from one Root CA certificate to the next.

The last sentence in Section 2 says:

   If either check fails, then potential Root CA
   certificate is not a valid replacement, and the recipient continues
   to use the current Root CA certificate.

Indeed, these check are necessary to make sure that the relying party makes the transition to the proper replacement.  Any failure of the checks leave the trust anchor unchanged, which seems like the right result to me.

Recall the definition of trust anchor from RFC 5280, Section 6.1.1:

      (d)  trust anchor information, describing a CA that serves as a
           trust anchor for the certification path.  The trust anchor
           information includes:

         (1)  the trusted issuer name,

         (2)  the trusted public key algorithm,

         (3)  the trusted public key, and

         (4)  optionally, the trusted public key parameters associated
              with the public key.

The checks make sure that the replacement self-signed certificate contains the intended information.

>   Authority (CA) certificate.  This certificate extension unambiguously
> The term "trust anchor" is used as the concept, not the bits in the certificate. As such, the last sentence is confusing because the trust anchor will change when the key changes. A possible fix is to replace "will be used by the trust anchor at some point in the future" with "will be used in a trust anchor at some point in the future".

I think I understand your point.  Does this text resolve the concern?

   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, replacing the current one.

> The first list in Section 2 would be clearer if the order was R1, R2, H2, C1; this would also then match the order in the second list.

Okay.  I changed that in my edit buffer.

> Later in Section 2, a sentence appears to be missing its subject. "That is, verify the signature on the self-signed certificate..." should probably be "That is, the recipient verifies the signature on the self-signed certificate...".

Okay.  I changed that in my edit buffer.

In addition, I added a bit more detail about the relationship to certification path validation, which I hope adds clarity around your first comment.  It now reads:

   The successor to the Root CA self-signed certificate can be
   delivered by any means.  Whenever a new Root CA certificate is
   received, the recipient is able to verify that the potential Root CA
   certificate links back to a previously authenticated Root CA
   certificate with the hashOfRootKey certificate extension.  That is,
   the recipient verifies the signature on the self-signed certificate
   and verifies that the hash of the DER-encoded SubjectPublicKeyInfo
   from the potential Root CA certificate matches the value from the
   HashOfRootKey certificate extension of the current Root CA
   certificate.  Checking the self-signed certificate signature ensures
   that the certificate contains the subject name, public key algorithm
   identifier, and public key algorithm parameters intended by the key
   owner intends; these are important inputs to certification path
   validation as defined in Section 6 of [RFC5280].  Checking the hash
   of the SubjectPublicKeyInfo ensures that the certificate contains the
   intended public key.  If either check fails, then potential Root CA
   certificate is not a valid replacement, and the recipient continues
   to use the current Root CA certificate.

Russ

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 02 Jan 2019 12:17:10 -0800

On 2 Jan 2019, at 11:57, Russ Housley wrote:

>> This extension seems useful to CAs that understand the increased 
>> risks that using it incurs, but those risks are not mentioned in the 
>> document.
>>
>> named in the extension next. Using this extension increases the risk 
>> of a bad trust anchor rollover at the same time that it makes good 
>> rollover more secure. If the key listed in this extension cannot be 
>> used when the CA eventually changes the trust anchor, relying parties 
>> will mistrust the new trust anchor. There are many reasons why a CA 
>> might think they know the next key but cannot use that key when they 
>> change trust anchors, such as if the HSM that holds the next key 
>> fails or is destroyed. Given the last sentence in Section 2, this 
>> could mean that a CA might never be able to issue a new trust anchor, 
>> even if the key for its current trust anchor is compromised.
>>
>> Given the severity of the new risks of using this extension, they 
>> need to be introduced at the beginning of the document and then 
>> discussed in more detail in the Security Considerations. Note that 
>> this risk affects the last paragraph of the Security Considerations 
>> section as well.
>

To be clear, the transition is from one public key to the next, not from 
one certificate to the next. But, more importantly, the point of this 
extension is to facilitate the transition from one Root CA certificate 
to what is supposed to be the next key. However, if that next key is not 
seen by every relying party during the transition, the extension 
prevents the CA from ever making the transition for the relying parties 
that do not see the new key in a revised trust anchor. This seems like a 
huge restriction that is only mentioned in the document in exactly one 
sentence:

> Indeed, these check are necessary to make sure that the relying party 
> makes the transition to the proper replacement.  Any failure of the 
> checks leave the trust anchor unchanged, which seems like the right 
> result to me.

It seems right to me as well, but it still seems to be wholly 
insufficient to not talk about the risks of using the extension early in 
the document.

> contains the intended information.

That is all fine, but it does not address the significant risk a CA is 
undertaking by promising what the next key will be.

>> certificate. As such, the last sentence is confusing because the 
>> trust anchor will change when the key changes. A possible fix is to 
>> replace "will be used by the trust anchor at some point in the 
>> future" with "will be used in a trust anchor at some point in the 
>> future".
>

Not really. A key will not be used as a certificate: it is just a key. A 
key might be used as the signing key for a certificate, but not as the 
certificate itself. Maybe instead: "will be used to sign a trust anchor 
at some point in the future"?

>> Later in Section 2, a sentence appears to be missing its subject. 
>> "That is, verify the signature on the self-signed certificate..." 
>> should probably be "That is, the recipient verifies the signature on 
>> the self-signed certificate...".
>
> In addition, I added a bit more detail about the relationship to 
> certification path validation, which I hope adds clarity around your 
> first comment.  It now reads:
>

Yes, adding this clarifies how all the trust anchor information is 
linked through the validation process. This is a good addition.

--Paul Hoffman

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 2 Jan 2019 20:32:22 +0000

I don't understand what the risk is.
 
If a client sees and understands the extension, it can update its trust store to have the new key.  If a client does not see, or does not understand, the extension, then the trust store will have to be updated out of band, just like it is now.

CA's that use this extension must take proper care to ensure that the private key is not exposed.

---

From: Tim Hollebeek <[email-masked]>
Date: Wed, 2 Jan 2019 20:57:17 +0000

I'm sympathetic to perhaps adding a sentence or two, but 
otherwise I'm struggling to understand the risk as well.

If an entity is incapable of managing and protecting a replacement root key,
perhaps they shouldn't be in the CA business.  And since, at worst, they
lose the ability to replace the root key, they aren't in a worse situation
than they were if this capability didn't exist.

-Tim

> -----Original Message-----
> From: Spasm <[email-masked]> On Behalf Of Salz, Rich
> Sent: Wednesday, January 2, 2019 3:32 PM
> To: Paul Hoffman <[email-masked]>; Russ Housley
> <[email-masked]>
> Cc: [email-masked]; [email-masked];
IETF
> <[email-masked]>
> Subject: Re: [lamps] Last Call:
<draft-ietf-lamps-hash-of-root-key-cert-extn-
> 02.txt> (Hash Of Root Key Certificate Extension) to Informational RFC
> 
> If a client sees and understands the extension, it can update its trust
store to
> have the new key.  If a client does not see, or does not understand, the
> extension, then the trust store will have to be updated out of band, just
like it
> is now.
> 
> CA's that use this extension must take proper care to ensure that the
private
> key is not exposed.
> 
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Jan 2019 21:19:43 +0000

Hiya,

> otherwise I'm struggling to understand the risk as well.

I assume Paul's pointing out that this is another form of
key pinning, and other instances of pinning haven't worked
out so well.

> than they were if this capability didn't exist.

IIUC Paul's concern is for the relying party, not the CA.

Compared to RPs who do not support this extension, RPs who
do support this extension may have a harder time with a
CA that mucks up pinning, e.g. because the CA's HSM vendor
has gone out of business or something.

I'm not sure how big a deal that is really but it seems
like a fine LC comment worthy of resolution to me.

Having just read the draft (for the 1st time), I think it
ought say (by inclusion or reference) how RPs could handle
bad pins, given that there are a small set of trust store
distributors (browsers, debian etc.) who aren't quite sync'd
up.

Cheers,
S.

---

From: Tim Hollebeek <[email-masked]>
Date: Wed, 2 Jan 2019 21:27:23 +0000

I'm not sure the comparison with pins is that useful, because existing pins
generally work out badly because they prevent changing keys, while this
mechanism provides the opportunity to change a key, where no such
opportunity otherwise exists.  If anything, this makes roots of trust _less_
like pinned keys, and in a good way.

But I agree that even if this is a minor issue, perhaps a few sentences
noting it is appropriate.  Just to help out anyone who might not have
thought about it.

-Tim

> From: Stephen Farrell <[email-masked]>
> Sent: Wednesday, January 2, 2019 4:20 PM
> To: Tim Hollebeek <[email-masked]>; Salz, Rich
> <[email-masked]>; Paul Hoffman <[email-masked]>; Russ
> Housley <[email-masked]>
> IETF <[email-masked]>
> > I'm sympathetic to perhaps adding a sentence or two, but otherwise I'm
> > struggling to understand the risk as well.
>
> I assume Paul's pointing out that this is another form of key pinning, and
> other instances of pinning haven't worked out so well.
>
> > If an entity is incapable of managing and protecting a replacement
> > root key, perhaps they shouldn't be in the CA business.  And since, at
> > worst, they lose the ability to replace the root key, they aren't in a
> > worse situation than they were if this capability didn't exist.
>
> Compared to RPs who do not support this extension, RPs who do support this
> extension may have a harder time with a CA that mucks up pinning, e.g.
> because the CA's HSM vendor has gone out of business or something.
>
> I'm not sure how big a deal that is really but it seems like a fine LC 
> comment
> worthy of resolution to me.
>
> Having just read the draft (for the 1st time), I think it ought say (by 
> inclusion
> or reference) how RPs could handle bad pins, given that there are a small 
> set
> of trust store distributors (browsers, debian etc.) who aren't quite sync'd 
> up.
>
> Cheers,
> S.
>
>
> >
> > -Tim
> >
> >> Cc: [email-masked];
> >> [email-masked];
> > IETF
> >> <[email-masked]>
> >> have the new key.  If a client does not see, or does not understand,
> >> the extension, then the trust store will have to be updated out of
> >> band, just
> > like it
> >> is now.
> >>

---

From: Russ Housley <[email-masked]>
Date: Wed, 2 Jan 2019 17:04:48 -0500

Paul:

> To be clear, the transition is from one public key to the next, not from one certificate to the next. But, more importantly, the point of this extension is to facilitate the transition from one Root CA certificate to what is supposed to be the next key. However, if that next key is not seen by every relying party during the transition, the extension prevents the CA from ever making the transition for the relying parties that do not see the new key in a revised trust anchor.

This is not correct.  The public key in the next self-signed certificate is identified by the hash of the public key that will appear in the subsequent certificate.  At the time of the actual transition, the recipient has the original self-signed certificate and the subsequent one.  Thus, the recipient has both in hand.

All replying parties will not see the subsequent self-signed certificate at the same time, but that is not a concern,  The old-in-new and new-in-old technique described in RFC 2510 (and referenced in Section 5) keeps all subordinate certificates valid until they expire.

> This seems like a huge restriction that is only mentioned in the document in exactly one sentence:

I think that the Abstract as reworded is pretty clear.

I will make a similar adjustment to the Introduction.

> It seems right to me as well, but it still seems to be wholly insufficient to not talk about the risks of using the extension early in the document.
> 
> That is all fine, but it does not address the significant risk a CA is undertaking by promising what the next key will be.

That is not a significant risk. In fact, the LAMPS WG had a fairly lengthy discussion on that point at IETF 101.  The conclusion from that discussion is summarized in the Security Considerations.  That is, if the Root CA decides that the committed public key is no longer the desire destination, then two transition done fairly quickly can sort it out.

I observe that standing up a new Root CA from scratch would likely be harder than two quick transitions.

> Not really. A key will not be used as a certificate: it is just a key. A key might be used as the signing key for a certificate, but not as the certificate itself. Maybe instead: "will be used to sign a trust anchor at some point in the future"?

The public key is identified by the hash value.  The public key that matches the hash value will appear in a self-signed certificate in the future.  All four of the components of the trust anchor (listed above) that are replaced, not just the public key.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 3 Jan 2019 10:28:11 -0500

I had a voice conversation with Paul Hoffman, and I think that I now understand the things that he would like to see added to the document.  Essentially, the Hash Of Root Key certificate extension is a commitment to the next generation public key and algorithm.  Recall that the hash covers the SubjectPublicKeyInfo, which is:

	SubjectPublicKeyInfo  ::=  SEQUENCE  {
	     algorithm            AlgorithmIdentifier,
	     subjectPublicKey     BIT STRING  }

So, a few things can go wrong after making this commitment.  (Stephen called it pinning.)  The Root CA needs to choose a next generation public key and algorithm that will be secure for the full lifetime.  Of course, a cryptoanalytic break through is very difficult to predict, and if one happens before the new key is used, the Root CA remains committed to the now broken key.  The remedy is to deploy a new public key and algorithm in the same manner as the initial Root CA self-signed certificate.  The benefits of automatic detection of the new public key are lost, but that is a minor concern is the scope of a  cryptoanalytic break through.

In addition, from an operational perspective, the Root CA must securely back up the yet-to-be-deployed key pair.  If the Root CA stores it in a hardware security module, and that module fails, the Root CA remains committed to the now unavailable key.   The remedy is the same as above: deploy a new public key in the same manner as the initial Root CA self-signed certificate.

Russ

> On Jan 2, 2019, at 3:17 PM, Paul Hoffman <[email-masked]> wrote:
> 
> To be clear, the transition is from one public key to the next, not from one certificate to the next. But, more importantly, the point of this extension is to facilitate the transition from one Root CA certificate to what is supposed to be the next key. However, if that next key is not seen by every relying party during the transition, the extension prevents the CA from ever making the transition for the relying parties that do not see the new key in a revised trust anchor. This seems like a huge restriction that is only mentioned in the document in exactly one sentence:
> 
> Yes, adding this clarifies how all the trust anchor information is linked through the validation process. This is a good addition.
> 
> --Paul Hoffman

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 03 Jan 2019 09:33:06 -0800

On 3 Jan 2019, at 7:28, Russ Housley wrote:

> I had a voice conversation with Paul Hoffman, and I think that I now 
> understand the things that he would like to see added to the document. 
>  Essentially, the Hash Of Root Key certificate extension is a 
> commitment to the next generation public key and algorithm.  Recall 
> that the hash covers the SubjectPublicKeyInfo, which is:
>
> So, a few things can go wrong after making this commitment.  (Stephen 
> called it pinning.)  The Root CA needs to choose a next generation 
> public key and algorithm that will be secure for the full lifetime.  
> Of course, a cryptoanalytic break through is very difficult to 
> predict, and if one happens before the new key is used, the Root CA 
> remains committed to the now broken key.  The remedy is to deploy a 
> new public key and algorithm in the same manner as the initial Root CA 
> self-signed certificate.  The benefits of automatic detection of the 
> new public key are lost, but that is a minor concern is the scope of a 
>  cryptoanalytic break through.
>
> In addition, from an operational perspective, the Root CA must 
> securely back up the yet-to-be-deployed key pair.  If the Root CA 
> stores it in a hardware security module, and that module fails, the 
> Root CA remains committed to the now unavailable key.   The remedy is 
> the same as above: deploy a new public key in the same manner as the 
> initial Root CA self-signed certificate.

Russ has issued an -03 that adds text about the commitment that comes 
with using this extension. That alleviates my concern about a CA not 
realizing that there is a risk in adding the extension to trust anchor 
certificates.

--Paul Hoffman

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 03 Jan 2019 14:35:25 -0500

On Wed 2019-01-02 10:26:05 -0800, Paul Hoffman wrote:
> Using this extension increases the risk of a bad trust anchor rollover
> at the same time that it makes good rollover more secure.

I think this may be the root (ha ha) of confusion about the purpose of
this draft, and it raises some additional concerns for me about whether
it is clear and useful as it stands (i've been reading -03).

This draft serves one main purpose as far as i can tell:

 * It provides a technical mechanism that facilitates a root authority
   releasing a new root certificate.

This is a good purpose i can get behind, but the introduction implies
that it also offers another purpose:

    remove the previous one from the trust anchor store.

but the only detail in this draft that suggests how that is supposed to
happen is in the end of the Overview:

    If either check fails, then [the] potential Root CA
    certificate is not a valid replacement, and the recipient continues
    to use the current Root CA certificate.

The implication here is of course that if both checks succeed, then the
current Root CA certificate is discarded.  But that is explicitly stated
nowhere in the document.  Should it be?  If it should, we need more
text.  If it does not, the draft should remove the text about "remove
the previous one" and "continues to use the current Root CA
certificate".

Section 5 ("Operational Considerations") talks about RFC 2510 (should
maybe be 4210 today, no?), and refers to oldWithNew and newWithOld.
However, the final sentence of that paragraph is ambiguous:

   Further, this technique avoids the need for all relying parties to
   make the transition at the same time.

Which technique?  The technique in the current draft?  oldWithNew?
newWithOld?  Both oldWithNew and newWithOld?  If the sentence is talking
about the two mechanisms from RFC 4210, then Operational Considerations
should clarify that the current draft explicitly *does* require all
relying parties (and all subscribers!) to make the transition at the
same time, since the escape of C2 into the wild means that all
subscribers MUST start shipping certs signed by C2, because they can't
know whether their relying parties have switched from C1 to C2 yet.

The safest thing is for the subscriber to force the relying party to
switch to C2 by shipping C2, but of course that will screw over any
other subscribe that hasn't switched yet.  So i'm not convinced that we
can safely say that reciept of C2 MUST (or even SHOULD) effectively
revoke C1.

Additionally, the two paragraphs added in -03 make it clear that the
traditional new-root-cert import mechanism will remain enabled for all
relying parties, subject to all the pre-existing vagaries and risks.
(perhaps some other draft can tighten those up, but this draft does not
do so on its own.)

So, without this draft offering a strong and immediate revocation
mechanism, and without it cleaning up the pre-existing new-root-cert
import mechanism, it does *not* make "rollover more secure" (since all
existing insecure channels will continue to exist).  It just makes good
rollover more convenient/automatic.

      --dkg

---

From: Russ Housley <[email-masked]>
Date: Thu, 3 Jan 2019 15:07:42 -0500

> the previous one" and "continues to use the current Root CA

The Abstract of -03 includes:

	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, replacing the current one.

And, the Introduction of -03 includes:

	This hash value is a commitment to a particular public key in
	the next generation self-signed certificate. This commitment
	allows a relying party to unambiguously recognize the next
	generation self-signed certificate when it becomes available,
	install the new self-signed certificate in the trust anchor store,
	and remove the previous one from the trust anchor store.

And, Section 2 of -03 includes:

	Checking the hash of the SubjectPublicKeyInfo ensures that
	the certificate contains the intended public key.  If either check
	fails, then potential Root CA certificate is not a valid replacement,
	and the recipient continues to use the current Root CA certificate.

I could add a sentence here:

	If both checks succeed, then the potential Root CA certificate is
	added to the trust anchor store and the current  Root CA
	certificate is removed.

Does that resolve your concern?

> maybe be 4210 today, no?),

Yes, it should be referencing RFC 4210.

> and refers to oldWithNew and newWithOld.

Please take a look at RFC 4210, Section 4.4 ("Root CA Key Update").  The way that I read the section, it is describing a technique for protecting the new public key using the previous private key and vice versa.  The technique involves both old-with-new and new-with-old.

To be more clear, I will refer to "this advice" in all of the places that reference RFC 4210.  The current text uses "this advice" in one place and "this technique" in another place.  I hope that will be more clear.

> can safely say that reciept of C2 MUST (or even SHOULD) effectively

The whole point of the old-with-new and new-with-old advice is that all of the certificates can be validated to either the old trust anchor or the new one.

> rollover more convenient/automatic.

Yes, that is the point of the extension.

Russ

---

From: Jim Schaad <[email-masked]>
Date: Thu, 3 Jan 2019 13:00:27 -0800

> From: Spasm <[email-masked]> On Behalf Of Russ Housley
> Sent: Thursday, January 3, 2019 7:28 AM
> To: SPASM <[email-masked]>
> Cc: [email-masked]; IETF
<[email-masked]>
> I had a voice conversation with Paul Hoffman, and I think that I now
understand
> the things that he would like to see added to the document.  Essentially,
the
> Hash Of Root Key certificate extension is a commitment to the next
generation
> public key and algorithm.  Recall that the hash covers the
SubjectPublicKeyInfo,
> which is:
called
> it pinning.)  The Root CA needs to choose a next generation public key and
> algorithm that will be secure for the full lifetime.  Of course, a
cryptoanalytic
> break through is very difficult to predict, and if one happens before the
new key
> is used, the Root CA remains committed to the now broken key.  The remedy
is
> to deploy a new public key and algorithm in the same manner as the initial
> Root CA self-signed certificate.  The benefits of automatic detection of
the new
> public key are lost, but that is a minor concern is the scope of a
cryptoanalytic
> break through.

I don't think this needs to be put into the document, but in the extremely
unlikely event that both the hash algorithm and the public key algorithm are
broken, then an adversary could issue new root certificates.  I believe that
they could probably issue the old/new key pair as well in most cases as
generally both the old and new roots are going to be using the same
algorithm.

If just the algorithm is broken, then it would be possible for an adversary
to intercept the new root and then issue a new set of roots and cross
certificates using the new key pair as they would then not need to invert
the hash.

Jim

> 
> In addition, from an operational perspective, the Root CA must securely
back
> up the yet-to-be-deployed key pair.  If the Root CA stores it in a
hardware
> security module, and that module fails, the Root CA remains committed to
the
> now unavailable key.   The remedy is the same as above: deploy a new
public
> key in the same manner as the initial Root CA self-signed certificate.
> 
> Russ
> 
> 
that
> using it incurs, but those risks are not mentioned in the document.
> >>>
named
> in the extension next. Using this extension increases the risk of a bad
trust
> anchor rollover at the same time that it makes good rollover more secure.
If
> the key listed in this extension cannot be used when the CA eventually
changes
> the trust anchor, relying parties will mistrust the new trust anchor.
There are
> many reasons why a CA might think they know the next key but cannot use
that
> key when they change trust anchors, such as if the HSM that holds the next
key
> fails or is destroyed. Given the last sentence in Section 2, this could
mean that a
> CA might never be able to issue a new trust anchor, even if the key for
its
> current trust anchor is compromised.
> >>>
to be
> introduced at the beginning of the document and then discussed in more
detail
> in the Security Considerations. Note that this risk affects the last
paragraph of
> the Security Considerations section as well.
> >>
> >> The point is to facilitate the transition from one Root CA certificate
to the
> next.
one
> certificate to the next. But, more importantly, the point of this
extension is to
> facilitate the transition from one Root CA certificate to what is supposed
to be
> the next key. However, if that next key is not seen by every relying party
during
> the transition, the extension prevents the CA from ever making the
transition
> for the relying parties that do not see the new key in a revised trust
anchor.
> This seems like a huge restriction that is only mentioned in the document
in
> exactly one sentence:
makes
> the transition to the proper replacement.  Any failure of the checks leave
the
> trust anchor unchanged, which seems like the right result to me.
> >
insufficient to not
> talk about the risks of using the extension early in the document.
> >
> >>
> >> The checks make sure that the replacement self-signed certificate
contains
> the intended information.
> >
undertaking
> by promising what the next key will be.
> >
> >>> Editorial:
> >>>
> >>> The abstract says:
> >>>  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 by the trust anchor  at some point in the future.
anchor will
> change when the key changes. A possible fix is to replace "will be used by
the
> trust anchor at some point in the future" with "will be used in a trust
anchor at
> some point in the future".
> >>
key might
> be used as the signing key for a certificate, but not as the certificate
itself.
> Maybe instead: "will be used to sign a trust anchor at some point in the
> future"?
> >
H2, C1;
> this would also then match the order in the second list.
> >>
"That is,
> verify the signature on the self-signed certificate..." should probably be
"That is,
> the recipient verifies the signature on the self-signed certificate...".
> >>
certification
> path validation, which I hope adds clarity around your first comment.  It
now
> reads:
linked
> through the validation process. This is a good addition.
> >
> > --Paul Hoffman
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 03 Jan 2019 18:12:21 -0500

Hi Russ--

thanks for the followup.

> Does that resolve your concern?

Yes, this final addition clarifies the intent of the document, thank
you.  I might prefer if it was active voice instead of passive, just to
be clearer about who is doing the addition and removal to the trust
store.  Is there a reason to avoid RFC 2119 language in these
descriptions?

> Please take a look at RFC 4210, Section 4.4 ("Root CA Key Update").

Please cite the relevant section number directly in the draft!

> The way that I read the section, it is describing a technique for
> protecting the new public key using the previous private key and vice
> versa.  The technique involves both old-with-new and new-with-old.
>
> To be more clear, I will refer to "this advice" in all of the places
> that reference RFC 4210.  The current text uses "this advice" in one
> place and "this technique" in another place.  I hope that will be more
> clear.

So i think you're now saying that people updating a key should use RFC
4210§4.4 guidance *in addition* to including the HashOfRootKey extension
in C1.  If that's what you mean, the draft should say it explicitly.

But (using the RFC 4210 terms), let's think about what happens to the
PSE (Personal Security Environment), the trust store (meaning the list
of trusted roots, which is a subset of the PSE, i guess, feel free to
correct if i'm misunderstanding 4210) and various certificates assuming
there are multiple heterogeneous subscribers seen by a single relying
party.

I'm working here on a TLS assumption -- if you're using these certs for
some other purpose (like LAMPS) maybe it won't apply, i'm not sure.  The
"Repository" referred to in RFC 4210 isn't something that many X.509
verification stacks have access to (and even if it was, checking it
during failed verification might raise privacy or latency concerns).

In my notation below, the CA starts with self-signed C1, and then moves
(via HashOfRootKey) to self-signed C2.  Meanwhile, the CA has also
generated COwN (the oldWithNew cert) and CNwO (the newWithOld cert).
(C1 is oldWithOld, and C2 is newWithNew, in 4210 lingo).

In my example, an end-entity cert might be written as EA or EB, and will
be signed by the root authority directly (i'm omitting traditional
intermediate certs for the sake of simplicity, though i note that COwN
and CNwO are effectively intermediate certs).

A valid simple certificate chain where end entity A is certified by the
first version of the CA looks like this: EA←C1.  Let's assume that all
servers ship their root CA certs as well (though TLS doesn't explicitly
require that, and people who care about latency are likely to try to
omit them -- should this draft explicitly recommend that TLS servers
ship root certs all the time just in case?).

in this example scenario, the relying party visits site end entity A
(which whose cert has been issued by the new C2), and then end entity B
(which is still using a cert issued by C1).

        | Trust |       | cert  |
 event  | Store | PSE   | chain | valid?   
--------+-------+-------+-------+----------
start   | C1    | C1    |       |
visit A | C2    | C1,C2 | EA←C2 | EA = ✓
visit B | C2    | C1,C2 | EB←C1 | EB = ?

It looks to me like EB will not validate, since:

 1) C1 is no longer a trusted root, despite being in the PSE
 
 2) COwN is not available to the relying party (and might not be known
    to server B either), so no chain can be formed to the only trusted
    root, C2

What am i missing?  This looks like a recipe for one party (A) to
accidentally damage another party (B) due to lack of coordination.

Furthermore, what happens if the relying party comes across CNwO before
C2?  It validates (signed by C1) but it is not self-signed.  But its
SPKI also matches C1's HashOfRootKey extension.  If it gets processed as
a new root, then C2 will *not* get processed (because C1 is already out
of the trust store, and C2 doesn't have the same HashOfRootKey as C1).
So now you'll have some RPs that have CNwO in their root store, and
others that have C2, depending on when they encountered it.  Hopefully
that won't cause any problems, but it makes me nervous.

Alternately, maybe this process *only* triggers when the cert we're
examining is self-signed.  Maybe the text "Whenever a new Root CA
certificate is received" is meant to only apply to self-signed
certificates?  perhaps it should be clearer on that, if that's the case
(subsequent text in that paragraph refers to "the self-signed
certificate", but the only "self-signed" antecedent in that paragraph is
the original "Root CA self-signed certificate" -- C1, not a potential
C2).

> The whole point of the old-with-new and new-with-old advice is that
> all of the certificates can be validated to either the old trust
> anchor or the new one.

only if the relying party has access both COwN cert as well as C2,
right?  If the TLS server ships only C1, then the RP is out of luck.

should COwN have the same subjectPublicKeyIdentifier extension as C1?
should CNwO have the same subjectPublicKeyIdentifier as C2?  if so,
should we say so explicitly?

> Yes, that is the point of the extension.

thanks, that matches my mental model.

One other open question occurs to me: Should the relying party also
verify that Subject information (or other identity info) in the new cert
matches the old certificate?  I'm imagining a case where the old root CA
("O=L'Emporium de Foobar,OU=Authorité Racine,C=FR") ends up replacing
itself with ("O=Вооружённые Силы Союза Советских Социалистических
Республик,C=SU").  That would be pretty weird and upsetting, especially
if i didn't know how my "new" Soviet military cert got into my trust
store.  Would it be legitimate to cabin the scope of this rollover to
identical Subjects?

Finally, should a relying party place any bounds on the lifetime of the
new cert?  What if C2 appears, but has an *earlier* notBefore date than
C1?  that seems weird but maybe it isn't a problem.  But what if i've
added a cert to my root store with an known expiration date, and i don't
*want* a subsequent cert to suddenly have a later expiration date? (for
example, perhaps i'm in school and the school issues its own annual
certificate authority which i'm fine with accepting for now, but i don't
want to trust it after graduation)

How can an implementation determine the intent of the local system's
inclusion of certificate in the root store?  Should we encourage trust
store implementations to be able mark certificates as DO NOT UPDATE?  or
should we instead encourage users to understand inclusion of a
certificate in a root store as effectively unbounded in duration,
despite the existence of a validUntil field?

        --dkg

---

From: Russ Housley <[email-masked]>
Date: Wed, 9 Jan 2019 11:51:33 -0500

> store.  Is there a reason to avoid RFC 2119 language in these

Yes, active voice would be better:

   If both checks succeed, then the recipient adds the potential
   Root CA certificate to the trust anchor store and removes the
   current Root CA certificate.

I do not see the need for RFC 2119 language in the Overview section.

> Please cite the relevant section number directly in the draft!

I have added it in my edit buffer.

> in C1.  If that's what you mean, the draft should say it explicitly.

Yes, this advice has been in place since 1999 for root key transition.

This is what I have in my edit buffer:

   Guidance on the transition from one trust anchor to another is
   available in Section 4.4 of [RFC4210].  In particular, the oldWithNew
   and newWithOld advice ensures that relying parties are able to
   validate certificates issued under the current Root CA certificate
   and the next generation Root CA certificate throughout the
   transition.  Further, this advice SHOULD be followed by Root CAs to
   avoid the need for all relying parties to make the transition at the
   same time.

> event  | Store | PSE   | chain | valid?   

I think about this quite differently.  Let me see if a few high-level comments can resolve this question in the TLS context.

First, TLS explicitly says that intermediate certificates can be included in the "certificate_list" during a transition.  RFC 8446 says:

   Note: Prior to TLS 1.3, "certificate_list" ordering required each
   certificate to certify the one immediately preceding it; however,
   some implementations allowed some flexibility.  Servers sometimes
   send both a current and deprecated intermediate for transitional
   purposes, and others are simply configured incorrectly, but these
   cases can nonetheless be validated properly.  For maximum
   compatibility, all implementations SHOULD be prepared to handle
   potentially extraneous certificates and arbitrary orderings from any
   TLS version, with the exception of the end-entity certificate which
   MUST be first.

So, a server can provide the intermediate certificates needed for a client that is using the old self-signed certificate and the new self-signed certificate so that both validate the servers end-entity certificate.

I observe that other protocols, including CMS, allow a bag of certificates that might be useful to be sent.  During a transition, this could help populate caches.

Second, it is quite clear that a global directory has not emerged in the way envisioned by X.500 and LDAP.  However, there are many repositories within enterprises, and these repositories can be used to locate the old-in-new and new-in-old certificates during a transition.  This is the situation for the PKI that I know about that will be using this extension.

> should we say so explicitly?

I think my comments above address this point as well.

> thanks, that matches my mental model.

Okay.  Good.

> store.  Would it be legitimate to cabin the scope of this rollover to

I do not think so.  We have seen cases in the Web PKI were the Root CA changed names as part of a key rollover.  Of course, this happens without this extension today, so they establish a new self-signed certificate and once it is well established, they issue new certificate under the new root and stop issuing certificates under the old one.

> want to trust it after graduation)

I cannot think of a reason for the new self-signed certificate to have a notBefore date that is earlier than the old one.  That said, the certification path validation rules in RFC 5280 do not use the validity period in the trust anchor.  As a result, I cannot see any attack that would be enabled by this admittedly weird use of notBefore.

> despite the existence of a validUntil field?

I am missing something in this paragraph.  If the relying party has already decided to trust a particular Root CA, and then that Root CA transitions to a different key pair, what does this have to do with that decision?  If trust in the Root CA is lost by the relying party, then they ought to remove the self-signed certificate from the trust anchor store.

Further, I do want this extension to say anything about the structure of the trust anchor store.  Rather, it depends on the definition of a trust anchor in RFC 5280 (on page 76), which says:

Finally, I want to thank you for all the careful thought that you have put into this discussion.

Russ

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 09 Jan 2019 15:39:29 -0500

Hi Russ--

thanks for the responses!

>    avoid the need for all relying parties to make the transition at the

thanks, this looks good so far, and i agree that the draft helps to
avoid needing coordination between all relying parties (RPs).  But it
doesn't cover coordination by the subscribers (e.g. TLS servers) yet,
which is what the next point was about:

> [ dkg wrote: ]

Russ responded:
> First, TLS explicitly says that intermediate certificates can be
> included in the "certificate_list" during a transition.

i agree that this "bag of certs" model is where we're at for
certificates shipped in TLS (and with CMS, and probably should be for
any other relevant protocols where certificate path discovery is
needed).  But can you be concrete about which certificates you think
which parties will include in their certificate_list?  I see two
possible proposals:

 0) A should ship EA, COwN, and C2 in order to avoid breaking the RP's
    access to site B

 1) B should make sure that B ships COwN *before* A ever ships C2

Or are you suggesting something else?

The problem with 0 is that there is no clear incentive for A to take
that action (because C2 will Just Work™ for all clients that implement
the rollover), and B can be damaged by A failing to take it.

The problem with 1 is that it requires coordination among the
subscribers.

Or did you have some other suggestion about how to use the "bag of
certs" to get COwN to the RP?  The revocation functionality of the
current draft seems to require distribution of it, but i don't see who
is going to reliably distribute it.

Perhaps the we need to add some additional guidance in the direction of
0, to give A some incentive to do the right thing, and hopefully to
prevent accidental failures when accessing B:

 * a subscriber (TLS server) cannot guarantee that the RP (TLS client)
   that currently trusts C1 will implement this draft's cert rollover
   mechanism; so any subscriber that ships C2 SHOULD also ship COwN in
   its TLS bag of certs, unless it knows that all of the CA's
   subscribers have completed the transition to using C2.

 * any RP that implements this cert rollover mechanism MUST also retain
   in its PSE all CA intermediate certs issued by the new self-signed
   certificate, and sent as part of a subscriber's "bag of certs".

 * all RPs implementing this mechanism MUST perform path discovery based
   on the union of its PSE and the bag of certs offered by peers.

Note that this requires a bit more state management by the RP than
simply adjusting the root store -- it requires retaining a list of
trusted roots, *and* a distinct pool of certificates (the PSE) that can
be used for path discovery.

I'm still kind of sad about this, because it looks to me like A might
not have super strong incentives to do the right thing.  For example,
they might have sufficient knowledge about all their RPs to know that
COwN isn't strictly necessary, but not have knowledge about all their
co-subscribers, for example.  And if B is harmed, the cause of the harm
is very attenuated and difficult to track down or remedy.

> However, there are many repositories within enterprises, and these
> repositories can be used to locate the old-in-new and new-in-old
> certificates during a transition.  This is the situation for the PKI
> that I know about that will be using this extension.

If it is a requirement of this draft that the RPs have access to some
external repository of other certificates, the draft needs to explicitly
say so -- it needs to say that those repositories should be made
available, how they should be populated, and when.  If coordinated
access to these repositories is a requirement, though, then the
statement that we don't require coordination among RPs isn't
well-supported.

Without this guidance, someone will implement this who you didn't expect
in the initial drafting, and they will experience a very
difficult-to-track-down reliability problem. :(

> I do not think so.  We have seen cases in the Web PKI were the Root CA
> changed names as part of a key rollover.  Of course, this happens
> without this extension today, so they establish a new self-signed
> certificate and once it is well established, they issue new
> certificate under the new root and stop issuing certificates under the
> old one.

I understand that these subject names do often change, sometimes as
trivially as from "CN=FooCA G1 Root" to "CN=FooCA G2 Root".

But if we allow arbitrary changes to the name, and if i install
"CN=Jane's CA", i can now end up with no trace of "Jane" in my root
store, and an entirely unrelated "CN=Bob's CA".  right?

> If trust in the Root CA is lost by the relying party, then they ought
> to remove the self-signed certificate from the trust anchor store.

So in the case above, the self-signed certificate that the user had
added is nowhere to be found, and there is no mention of "Jane".  How
does the user know which certificate to remove?

> Further, I do want this extension to say anything about the structure

  (i assume you mean "do not want" here)
  
> of the trust anchor store.  Rather, it depends on the definition of a
> trust anchor in RFC 5280 (on page 76), which says:
>

immediately thereafter, RFC 5280 says:

>>> The trust anchor information may be provided to the path processing
>>> procedure in the form of a self-signed certificate.

This draft replaces one self-signed certificate with another, and the
new one might have a different "trusted issuer name" than the old.
Unless the trust anchor store retains the name from the
originally-injected certificate, this makes maintenance and auditing of
the trust anchor store by the end user (or local system administrator)
rather unstable/uncertain.  I don't think that's a great outcome.

We could reduce that uncertainty with a few recommendations:

 a) RPs should retain the original "trusted issuer name" distinctly from
    the self-signed certificate, and should *not* change the "trusted
    issuer name" for a root CA even when the certificate rolls over.

 b) RPs should retain a history of such transitions and be able to
    display them to local operators or audit systems that inspect the
    root store.

 c) require that the Subject of the replacing certificate matches the
    Subject of the earlier root CA.  (maybe we can allow some sort of
    variance in a field in the DN, so that we permit the semi-standard
    "G1" → "G2" naming shifts? i don't have a concrete suggestion here)

Failing any of these, the draft should acknowledge that it introduces
this difficulty for auditors of the most common/likely implementations
of a root store.

> put into this discussion.

Thanks for your work on this draft, Russ!

       --dkg

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 9 Jan 2019 22:34:47 +0000

I think this is beyond the scope of the document.

I do not see how it introduces new problems.  It enables some automation of trust store updates, that is all.

---

From: Russ Housley <[email-masked]>
Date: Wed, 9 Jan 2019 18:16:38 -0500

> 1) B should make sure that B ships COwN *before* A ever ships C2

The self-signed certificates that represent the thrust anchors are not included in the "certificate_list".  I recall a discussion about whether this behavior should change in TLS 1.3, and after a fairly lengthy discussion at one of the meetings, it was decided that it should not.  More below ...

> be used for path discovery.

There are whole informational RFCs on path discovery.  The IETF does not have a standards-track RFC on this subject.  Any way that it is done that results in  valid path is acceptable.  MUST statements on this document on it seem very wrong to me.

> is very attenuated and difficult to track down or remedy.

To the replying party, the old-in-new and new-in-old certificates are intermediate certificates.  They should not really be treated differently than any other newly issued intermediate certificate.

> difficult-to-track-down reliability problem. :(

The repositories, where they are available, need to be populated with the old-in-new and new-in-old certificates before the new self-signed certificate is released.  I will add that to the operational considerations.

> trivially as from "CN=FooCA G1 Root" to "CN=FooCA G2 Root".

Sure.  That is the most common case.

> store, and an entirely unrelated "CN=Bob's CA".  right?

They sometime change much more significantly, especially after an acquisition.

>>>> procedure in the form of a self-signed certificate.

Indeed, but the path validation algorithm does not depend on any of the other fields in the self-signed certificate, including the validity period.  I am aware of some implementations that remove a self-signed certificate from the trust store when the notAfter date is reached, but that is a trust store management decision, not a path validation decision.

> rather unstable/uncertain.  I don't think that's a great outcome.

I do not think this extension is the place to impose rule about Root CA naming.

>    issuer name" for a root CA even when the certificate rolls over.

It is not a self-signed certificate unless the issuer and subject names match.

>    display them to local operators or audit systems that inspect the

I can see where this is desirable for audit purposes, but I do not think the document should be too detailed about it.  I think a MAY is sufficient, especially in cases where the old-in-new and new-in-old certificates in a repository provide a bit of history in themselves.

>    "G1" → "G2" naming shifts? i don't have a concrete suggestion here)

Again, it is not a self-signed certificate unless the issuer and subject names match.

> this difficulty for auditors of the most common/likely implementations

I will work on some words to acknowledge the concern if the old and new self-signed certificates have very different names.

Russ

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 09 Jan 2019 23:52:49 -0500

> I do not see how it introduces new problems.  It enables some automation of trust store updates, that is all.

What it introduces is the tight coupling of two previously-distinct
actions for the relying party:

 a) rollout of a new root trust anchor

 b) revocation of the old trust anchor

Previously, these two steps were not tightly coupled in time, which gave
a window for loosely-coordiated deployment (RFC 5280 §4.4, with servers
shipping OldWithNew and NewWithOld certs, as Russ points out).

In the previous model, two things can happen in parallel, in an
uncoordinated fashion:

 x) RPs can learn about the New CA cert

 y) subscribers can update their cert chains, either by:

    1) shipping new end-entity certificates (signed with New, and with
       their chain extended by NewWithOld), or

    2) augmented cert chains (ee cert still signed with Old, but its
       chain extended by OldWithNew)

Once step Y was complete, it was safe to tell the RPs to drop the Old
trust anchor as long as they had completed their part of step X.

This draft says that as soon as an RP learns about New using this
mechanism, it will drop the Old.  This is unsafe unless step Y is
universally complete.  (meanwhile, it also makes Y.2 less plausible,
because it's odd to expect a subscriber to bother shipping OldWithNew if
New isn't available to the public; yet making New available to the
public effectively acts as a revocation of Old for those implementations
which see it).

This is a new problem, and it doesn't exist without this draft's
tight coupling of steps A and B.

The only safe way i see to deploy this is in a carefully staged
sequence:

 * all subscribers complete step Y in manner 1 (new EE cert, shipped
   alongside NewWithOld).  During this time, New MUST be hidden from the
   public, or else subscribers who haven't completed the transition will
   break!

Once that is universally complete:
 
 * deploy New to all RPs (which has a side effect of revoking Old)

Once that is known to be complete, it is safe to:

 * tell all subscribers they can stop shipping NewWithOld intermediate certs

Is there some other safe way to deploy this that i'm missing?

Does no one else see this as a problem?  if not, i'll just shut up about
it and let things break, i guess.  it's not like the ecosystem has never
run into transvalidity problems and unreliable root stores before, this
is just new and interesting automated ways to arrive there…

            --dkg

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 10 Jan 2019 12:56:27 +0000

I don't see it that way.  Nobody is forcing relying parties to couple things.

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 10 Jan 2019 07:09:18 -0800

> I don't see it that way.  Nobody is forcing relying parties to couple 

DKG didn't say that the new extension is forcing relying parties to do 
this, but it is giving them a way to do so. There are obvious benefits 
to coupling rollout and revocation, so this document should be clear on 
all the decisions that would go along with doing so.

--Paul Hoffman

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 10 Jan 2019 10:54:55 -0500

Earlier in the thread, Russ wrote:

> added to the trust anchor store and the current Root CA certificate is
> removed.

Maybe this isn't *forcing* (in the sense that none of our RFCs can force
anyone to do anything), but it indicates that relying parties that
follow this specification will tightly couple these two actions, with
potentially bad consequences.

       --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 10 Jan 2019 12:01:12 -0500

[ i sent this e-mail earlier by accident to Russ offlist, re-sending it
on-list now ]

On Wed 2019-01-09 18:16:38 -0500, Russ Housley wrote:
> The self-signed certificates that represent the thrust anchors are not
> included in the "certificate_list".  I recall a discussion about
> whether this behavior should change in TLS 1.3, and after a fairly
> lengthy discussion at one of the meetings, it was decided that it
> should not.  More below ...

I agree -- the root cert is not mandatory to include in the
certificate_list.

But as you wrote earlier, the certs in certificate_list are a "bag of
certs" -- they might contain any certs.  I don't think we can *stop*
people from shipping C2, and if they do, they'll effectively be revoking
C1.

> They sometime change much more significantly, especially after an acquisition.

This draft doesn't need to support the acquisition case if we decide
it's not in the best interest of the relying parties.

> It is not a self-signed certificate unless the issuer and subject names match.

i know -- but proposal (a) here suggests that the root trust store
doesn't need to associate "trusted issuer name" with any field in the
current self-signed certificate.  rather, it can keep that information
independent.  anyway, it's one of three suggestions.

> I can see where this is desirable for audit purposes, but I do not
> think the document should be too detailed about it.  I think a MAY is
> sufficient, especially in cases where the old-in-new and new-in-old
> certificates in a repository provide a bit of history in themselves.

i agree that the document doesn't need to be overly detailed about it.
I'm not even sure that RFC 2119 language is necessary.  but it needs
some guidance to point out the problems it creates for auditors if
something like this is not done.

> Again, it is not a self-signed certificate unless the issuer and

both Old and New are self-signed certificates (Old.Issuer ==
Old.Subject, and New.Issuer == New.Subject).  Proposal (c) here suggests
that we could require Old.Subject to match New.Subject (fsvo "match"),
in order for the replacement/revocation to proceed.

> I will work on some words to acknowledge the concern if the old and
> new self-signed certificates have very different names.

Thanks!

        --dkg

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 10 Jan 2019 19:15:37 +0000

> added to the trust anchor store and the current Root CA certificate is

I suggest adding "after an appropriate amount of time (such as no old certificate chains being in use)."

Does that solve the issue?

---

From: Russ Housley <[email-masked]>
Date: Thu, 10 Jan 2019 14:15:18 -0500

DKG:

> On Jan 10, 2019, at 10:54 AM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

Again, by following the new-in-old and old-in-new advice referenced in Section 5, the replacement will not change the validity of any end-entity certificates.  So, I think the "bad consequences" is an overstatement.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 10 Jan 2019 14:37:22 -0500

DKG:

> On Jan 10, 2019, at 12:01 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

If the new-in-old and old-in-new advice is followed and the old-in-new is included in the certificate_list, then the replacement of C1 by C2 will not change the validity of any end-entity certificates.

I think your point is that the distribution of C2 by another server will cause the recipient to replace C1 by C2 in their trust anchor store.  If all of the servers have not put the old-in-new certificate in their certificate_list, then the path construction may not have all of the certificates that are needed.  However a small amount of caching will resolve this, and use of enterprise directory services will resole this.

I will work on some text to cover both of these points in the operational considerations, but I do not think this specification should mandate any particular behavior one either one.

> it's not in the best interest of the relying parties.

As I said previously, I do not think this extension specification should impose any rules on Root CA naming.

> independent.  anyway, it's one of three suggestions.

I see, I misunderstood your paragraph at the end of your list began, "Failing any of these", which I read to mean that you wanted all three of them checked by the recipient.

Now that I understand your intention, I already agreed to work on some words to acknowledge the concern if the old and new self-signed certificates have very different names.

> something like this is not done.

Okay.

> in order for the replacement/revocation to proceed.

That would require no name change at all, including the GA1 --> GA2, which you already acknowledged is commonplace.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 10 Jan 2019 14:42:19 -0500

> On Jan 10, 2019, at 2:15 PM, Salz, Rich <[email-masked]> wrote:
> 

There are two cases.  In one case, there is an enterprise directory system, and there is no concern with the discovery of the old-in-new and the new-in-old certificates. The old certificate can be removed without any concerns in this situation.  In the second case, there is no appropriate directory, and keeping the old certificate for some amount of time would prevent the issue raised by DKG.

Russ

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 10 Jan 2019 20:26:00 -0600

> is just new and interesting automated ways to arrive there…

I am late to the party, but I am happy that you are continuing to drive the
discussion, and it seems to be making good progress.

Thanks to both of you for keeping talking it through!

-Ben