Re: Renew/Rekey/Modification

[Johannes Merkle <johannes.merkle@xxxxxxxxxxx>]

Stephen,

I do not know the FPKI documents but I think your questions generally refer to RFC 3647.

> Re-key is said (in the FPKI CP) to be a good idea because the older a
> key gets, the more susceptible it is to loss and compromise.  Fair
> enough, but why wouldn't that consideration be factored into the chosen
> certificate validity period?
> 
Typically, a certificate is re-keyed when or right before it expires. In this case, the maximum key lifetime is factored
into the certificate.


> 
> Is there ever a real world scenario when a Subject would of their own
> accord request re-key because they feel the key is getting old?  If so,
Yes, right before the old certificate expires. An alternative scenario would be after revocation due to suspected key
compromise, but in this case the application for the new cert can not be secured by the old one.

> why wouldn't they revoke as well?  The FPKI CA says that after re-key
> "The old certificate may or may not be revoked".  Why would you not
> revoke, given the possibility that the key has got too old?  I don't
> think it would ever be sensible to keep using an old original key and a
> fresh key.  And if I were a Relying Party, I might like to know about
> this possible quality difference, yet there would be nothing in a CRL or
> anywhere else to mark the fact that the Subscriber has re-keyed.
If the old certificate is going to expire very soon, revocation might not be necessary. However, it is considered good
practice to revoke the old certificate in the process of re-keying.


> The FPKI CA goes on to say that after re-key "The old certificate ...
> must not be further re-keyed, renewed, or modified".  This seems almost
> oxymoronic.  Consider that I have certificate A and then I re-key A to
> create certificate B.  And then I re-key B to create certificate C.  I
> would say that C is indistinguishable from a re-keyed A since A, B and C
> will only differ by key value.  So how is it meaningful to forbid
> re-keying A more than once?
> 
You are right, they are indistinguishable. However, the rule refers to the re-key application process. In this process
the old certificate is used as a reference, typically to authenticate the certificate request and to verify the
correctness of the certificate content data. I understand this rule to prohibit future certificate requests being
authenticated and verified with the old certificate. In particular, if after a re-key a certificate modification has
occured (e.g. because the subject attributes have changed), a re-key based on the re-keyed certificate could result in a
certificate with the outdated attributes.


> Finally, why does RFC 3647 bother to describe "Certificate Modification"
> at all?  The term is inherently confusing since one of the most obvious
> characteristics of a digital certificate is that it cannot be tampered
> with.  I question the need for a special bit of counter intuitive jargon
> (and a whole slab of the RFC) to cover what is really a mundane
> scenario; viz a certificate Subject needs a certificate with different
> details in it.  That is, it's just a new certificate.  Why is it treated
> any differently from an original certificate application?
> 
As far as I understand certificate modification covers any application for a new certificate where the data requested to
include into the certificate differs from the old certificate in more than merely the public key. You are right, it is a
new certificate for the subject, but this also holds for re-key or renewal.

The reason why it is treated different from initial (original) certificate application is that registration process can
be facilitated. For instance, subject identification and verification of unchanged data can be omitted. Furthermore, the
old certificate can be used to authenticate and protect the certificate application process.

I agree that the term "certificate modification" is a bit misleading.

Johannes