Subject: Re: [lamps] WG Last call: draft-ietf-lamps-hash-of-root-key-cert-extn

From: Jim Schaad <[email-masked]>
Date: Tue, 6 Nov 2018 10:32:37 +0700

* Abstract - I think it would be worth while to add to the last sentence 'by
the trust anchor, it does not indicate when that trust anchor will be used.'

* Section 1.2 - I hope that certificates are only generated using DER.
Using BER is not supposed to happen.

* Section 2 - I don't like the concept of saying that the new potential Root
CA chains back to the previous CA.  The term is highly overloaded in the
world of certificates.  I think links would be a better term.

* Section 2 - What operational considerations are there for when to retire
the old Root CA certificate when a new one has been discovered and is to be
used?

* Section 5? - I think that a discussion of the difference between signature
and public key algorithms might be needed here and that in order to do the
roll over the signature on the new self-signed cert needs to be
"acceptable".  It might even be necessary to have a discussion of why you
are not fixing the signature algorithm at the same time that you are fixing
the public key value.  - Think an ECDSA new key, but it comes with an
ECDSA-with-md5 signature algorithm (and yes I know that is not real).

* Section 5 - Need a discussion on what happens if the hash algorithm is
sufficiently weakened to be able to do a second pre-image attack.  Unlikely
but completist.

* Section 4 - If the document makes no requests of IANA - where is the TBD
in the OID in section 3 being resolved?

* ASN.1 module - if you don't believe that this document is going to be
extended then making CertExtensions is redundant.

Jim

---

From: Russ Housley <[email-masked]>
Date: Mon, 5 Nov 2018 22:59:03 -0500

> the trust anchor, it does not indicate when that trust anchor will be used.'

How about this?

   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.

> Using BER is not supposed to happen.

   Certificates [RFC5280] are generated using ASN.1 [X680]; certificates
   are always encoded with the Distinguished Encoding Rules (DER)
   [X690].

> world of certificates.  I think links would be a better term.

Okay.  Changed.

> the old Root CA certificate when a new one has been discovered and is to be

I'm not sure what you are requesting.  Install the new one, and remove the old one?

> ECDSA-with-md5 signature algorithm (and yes I know that is not real).

A trust anchor public key is always a digital signature key.  I assume that all CAs know that.

The CA needs to ensure that the new key is as strong or stronger than the key that it is replacing.  Is there really anything more to say?

> sufficiently weakened to be able to do a second pre-image attack.  Unlikely

Okay.  I'll work on some text for that.

> in the OID in section 3 being resolved?

TBD = 51483

I fixed it in the ASN.1 module, but I missed it in Section 3.  I'll fix it.

> extended then making CertExtensions is redundant.

You are talking about:

   CertExtensions EXTENSION ::= {
      ext-HashOfRootKey, ... }

This is just a way of saying that the certificate extensions list in [RFC5912] has one more member.

Is there a reason to remove it?

Russ

---

From: Jim Schaad <[email-masked]>
Date: Tue, 6 Nov 2018 11:51:35 +0700

> -----Original Message-----
> From: Russ Housley <[email-masked]>
> Sent: Tuesday, November 6, 2018 10:59 AM
> To: Jim Schaad <[email-masked]>
> Cc: SPASM <[email-masked]>
> Subject: Re: [lamps] WG Last call: draft-ietf-lamps-hash-of-root-key-cert-
> extn
> 
> Jim:
> >
> > * Section 2 - What operational considerations are there for when to
> > retire the old Root CA certificate when a new one has been discovered
> > and is to be used?
> 

When you install the new one, I don't believe that you are going to remove
the old one.  There are still going to be valid certificates running around
that will chain to the old root until you have done all of the issuing of
certificates to the new root.  This is going to take time.  Additionally, if
you are looking at something like the mail case you want to keep the old
root but mark it as being "expired" so that you can validate the chain of
certificates. 

This means that it might be some time before the old one is removed.  

> 
> > * Section 5? - I think that a discussion of the difference between
> > signature and public key algorithms might be needed here and that in
> > order to do the roll over the signature on the new self-signed cert
> > needs to be "acceptable".  It might even be necessary to have a
> > discussion of why you are not fixing the signature algorithm at the
> > same time that you are fixing the public key value.  - Think an ECDSA
> > new key, but it comes with an
> A trust anchor public key is always a digital signature key.  I assume
that all
> CAs know that.
> 
> The CA needs to ensure that the new key is as strong or stronger than the
key
> that it is replacing.  Is there really anything more to say?

But why are you not making the determination of the signature algorithm that
is going to be used by the new key at the same time that you are generating
it. 

The new key could be an ECDSA key of a longer length than the previous key.
This would be appropriately reflected and checked.  The issue is that the CA
does not say what the signature algorithm is.  This means that I might be
able to attack by using a signature algorithm that is weaker than what the
CA intended it to be.  For algorithm where the signature OID and the public
key OID are the same, this is not possible.  However for algorithms where
that is not the case it is a possible way for an attack to be pushed
forward.

> > * ASN.1 module - if you don't believe that this document is going to
> > be extended then making CertExtensions is redundant.
> 
> You are talking about:
> 
> This is just a way of saying that the certificate extensions list in
[RFC5912]
> has one more member.

Actually it does not say what you think it says.  What it does is define a
new item in this document which contains a list of extensions with one item
in it.  It does not modify the version of CertExtensions in RFC5912 in any
way.  If that is what is desired then this item has to be imported into RFC
5912 and added to the CertExtensions variable in that module.

No there is no reason to remove it, it is just some slight cruft.

Jim

---

From: Russ Housley <[email-masked]>
Date: Tue, 6 Nov 2018 04:43:52 -0500

> root but mark it as being "expired" so that you can validate the chain of

If one follows the old-with-new and new-with-old advice in RFC 2510, then the replacement should not cause any disruption.  If you think it is useful, an operational consideration about this can be added.

> This means that it might be some time before the old one is removed.  

It should not need to linger...

>> The CA needs to ensure that the new key is as strong or stronger than the key

The hash is computed on the SubjectPublicKeyInfo, so it includes the algorithm identifier.

> that is not the case it is a possible way for an attack to be pushed

Right, the algorithm identifier of the public key is nailed down, but other details are not.  I do not see a way to exploit this without the private key being compromised.  Such a compromise would, of course, have many more issues to sort out.

> 5912 and added to the CertExtensions variable in that module.

I realize that, which is the reason for the comment in the ASN.1.

> No there is no reason to remove it, it is just some slight cruft.

Would it help an implementer to add the IMPORT?  My experience is that sucks in a whole bunch of other ASN.1 modules that are not necessarily helpful to the guy writing code.

Russ

---

From: Jim Schaad <[email-masked]>
Date: Tue, 6 Nov 2018 17:13:15 +0700

> Sent: Tuesday, November 6, 2018 4:44 PM
> >>> retire the old Root CA certificate when a new one has been
> >>> discovered and is to be used?
> >>
> > When you install the new one, I don't believe that you are going to
> > remove the old one.  There are still going to be valid certificates
> > running around that will chain to the old root until you have done all
> > of the issuing of certificates to the new root.  This is going to take
> > time.  Additionally, if you are looking at something like the mail
> > case you want to keep the old root but mark it as being "expired" so
> > that you can validate the chain of certificates.
> 
> If one follows the old-with-new and new-with-old advice in RFC 2510, then
> the replacement should not cause any disruption.  If you think it is
useful, an
> operational consideration about this can be added.
> 

Since it was not obvious to me, then yes the hint should be included.

> >>> same time that you are fixing the public key value.  - Think an
> >>> ECDSA new key, but it comes with an
> >> The CA needs to ensure that the new key is as strong or stronger than
> >> the key that it is replacing.  Is there really anything more to say?
> >
> > But why are you not making the determination of the signature
> > algorithm that is going to be used by the new key at the same time
> > that you are generating it.
> 
> > This would be appropriately reflected and checked.  The issue is that
> > the CA does not say what the signature algorithm is.  This means that
> > I might be able to attack by using a signature algorithm that is
> > weaker than what the CA intended it to be.  For algorithm where the
> > signature OID and the public key OID are the same, this is not
> > possible.  However for algorithms where that is not the case it is a
> > possible way for an attack to be pushed forward.
> 
> Right, the algorithm identifier of the public key is nailed down, but
other
> details are not.  I do not see a way to exploit this without the private
key
> being compromised.  Such a compromise would, of course, have many more
> issues to sort out.

If I can second preimage the hash algorithm, for some signature algorithms I
would be able to do the compromise.  It was odd to me that this was not
noted but I would not insist on it.

> >> [RFC5912] has one more member.
> >>
> > Actually it does not say what you think it says.  What it does is
> > define a new item in this document which contains a list of extensions
> > with one item in it.  It does not modify the version of CertExtensions
> > in RFC5912 in any way.  If that is what is desired then this item has
> > to be imported into RFC
> Would it help an implementer to add the IMPORT?  My experience is that
> sucks in a whole bunch of other ASN.1 modules that are not necessarily
> helpful to the guy writing code.

No importing that both would not solve your problem or be useful.

Jim

---

From: Russ Housley <[email-masked]>
Date: Tue, 6 Nov 2018 05:18:45 -0500

Jim:

>> the replacement should not cause any disruption.  If you think it is useful, an

Will do.

>> Right, the algorithm identifier of the public key is nailed down, but other
>> details are not.  I do not see a way to exploit this without the private key

Okay.  This is details on the same issue that you raise earlier in the thread.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 6 Nov 2018 06:06:33 -0500

> Since it was not obvious to me, then yes the hint should be included.

Does this text address your concern:

5.  Operational Considerations

   Guidance on the transition from one trust anchor to another is
   available in [RFC2510].  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
   technique ovoids the need for all relying parties to make the
   transition at the same time.

Russ

---

From: Jim Schaad <[email-masked]>
Date: Tue, 6 Nov 2018 19:23:40 +0700

Yes that satisfies my concern.

From: Russ Housley <[email-masked]> 
Sent: Tuesday, November 6, 2018 6:07 PM
To: Jim Schaad <[email-masked]>
Cc: SPASM <[email-masked]>
Subject: Re: [lamps] WG Last call:
draft-ietf-lamps-hash-of-root-key-cert-extn

Jim:

I'm not sure what you are requesting.  Install the new one, and
remove the old one?

If one follows the old-with-new and new-with-old advice in RFC 2510, then
the replacement should not cause any disruption.  If you think it is useful,
an

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 7 Nov 2018 06:38:04 -0500

Jim:

I think I have two comments from you that have not yet been resolved.  Here is the text for the Security Considerations that I propose to address them:

   The Root CA needs to ensure that the public key in the next
   generation certificate is as strong or stronger than the key that it
   is replacing.

   The Root CA needs to employ a hash function that is resistant to
   preimage attacks [RFC4270].  A first-preimage attack against the hash
   function would allow an attacker to find another input that results
   published hash value.  For the attack to be successful, the input
   would have to be a valid SubjectPublicKeyInfo that contains the
   public key that corresponds to a private key known to the attacker.
   A second-preimage attack becomes possible once the Root CA releases
   the next generation public key, which makes the input to the hash
   function becomes available to the attacker and everyone else.  Again,
   the attacker needs to find a valid SubjectPublicKeyInfo that contains
   the public key that corresponds to a private key known to the
   attacker.

Russ

---

From: Jim Schaad <[email-masked]>
Date: Wed, 7 Nov 2018 19:31:03 +0700

That looks fine

> Sent: Wednesday, November 7, 2018 6:38 PM
> I think I have two comments from you that have not yet been resolved.
Here
> is the text for the Security Considerations that I propose to address