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

[Russ Housley <[e-mail]>]

Jim:
> 
> * 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.'

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.

> * Section 1.2 - I hope that certificates are only generated using DER.
> 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].

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

Okay.  Changed.

> * 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?

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

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

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?

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

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

> * Section 4 - If the document makes no requests of IANA - where is the TBD
> 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.

> * 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:

   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