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

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Spasm <[e-mail]> On Behalf Of Russ Housley
> Sent: Thursday, January 3, 2019 7:28 AM
> To: SPASM <[e-mail]>
> Cc: [e-mail]; IETF
<[e-mail]>
> 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
> 
> 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.

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
> 
> 
> > On Jan 2, 2019, at 3:17 PM, Paul Hoffman <[e-mail]> wrote:
> >
> > On 2 Jan 2019, at 11:57, Russ Housley wrote:
> >
> >>> On Jan 2, 2019, at 1:26 PM, Paul Hoffman <[e-mail]>
> 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.
> >>>
> >>> 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.
> >
> > 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:
> >
> >> 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.
> >
> > 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.
> >
> >>
> >> 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.
> >
> > That is all fine, but it does not address the significant risk a CA is
undertaking
> by promising what the next key will be.
> >
> >>> 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".
> >>
> >> 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.
> >
> > 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 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.
> >
> > Yes, adding this clarifies how all the trust anchor information is
linked
> through the validation process. This is a good addition.
> >
> > --Paul Hoffman
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm