Subject: defined format for renewal requests?

From: Joel Rees <[email-masked]>
Date: Tue, 9 Aug 2005 14:51:38 +0900

Apologies in advance for the noise.

I've done quick searches on what looked like the relevant RFCs and  
not really found much more than a suggestion that the renewal request  
be the same as the original certificate request. (Which would imply  
that the RA would check the database for existing certificates and  
treat, for instance, a CSR for a DN already in the database as a  
request for renewal, perhaps if it is some policy specified number of  
days before expiration? but that would seem to conflict with  
something else I read about requiring an error response if a CSR for  
a DN already issued is received.)

I did find RFC 2797, and I'm trying to digest it, but a quick search  
for the word "renew" turned up

    No special services are provided for doing either renewal (new
    certificates with the same key) or re-keying (new certificates on  
new
    keys) of clients.  Instead a renewal/re-key message looks the  
same as
    any enrollment message, with the identity proof being supplied by
    existing certificates from the CA.

but this looks at first blush like definitions of protocols between  
servers, say the LRA and the CA?

Is this perhaps primarily an implementation detail?

I was thinking perhaps of defining a custom, system internal  
extension to the CSR, containing simply a flag that says this is a  
renewal request, to eliminate ambiguity. But I seem to remember that  
CSRs are v1 and thus would not have extensions?

And, while I'm being the noisy newbie here, is automatic renewal  
generally preferred in implementations where there are no specific  
policy issues that would require the certificate subject to actively  
request the renewal? I've read parts of a thread or two in the  
archives that seemed to contain an assumption that renewal requests  
were not considered ordinary procedure.

--
Joel Rees   <[email-masked]>
digitcom, inc.   株式会社デジコム
Kobe, Japan   +81-78-672-8800
** <http://www.ddcom.co.jp> **

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 9 Aug 2005 09:45:44 +0200

Joel,

AFAIK a CSR does not authenticate the subscriber.  That is, the CSRs
origin is verified out OOB using a method that the CA considers suitable.

For renewals it seems logical to use the soon-to-be-expired certificate
as authentication.

There are BTW two different use-cases hidden here.
1) Certificate renewal.
2) Certificate "cloning".

I agree that a renewal CSR option would be nice because then the original
certificate (c|w)ould also be deleted.  Note, the latter would have to be
implemented as an "atomic" operation in order to not create more troubles
than it was supposed to solve...

In fact, current CSR schemes are much too primitive for serious uses and
have thus been replaced by custom solutions in many cases.  For example
there is no standard way of identifying the "key container" or define
PIN-code policies in spite of being high on most CAs whish-lists.

The biggest problem is that the entire CSR-stuff is convoluted by proprietary
methods such as Microsoft's XENROLL, making progress in this area hard.

Anders Rundgren
Security Architect

---

From: Joel Rees <[email-masked]>
Date: Tue, 9 Aug 2005 20:40:38 +0900

> origin is verified out OOB using a method that the CA considers  

Right.

> For renewals it seems logical to use the soon-to-be-expired  

That's what I expect to do.

> 2) Certificate "cloning".

Not sure what you mean by cloning.

I am aware of the difference between renewing to roll the key over,  
renewing while keeping the same key, and renewing for policy or usage  
changes.

> certificate (c|w)ould also be deleted.

So I'm safe in understanding that there are no recommended practices  
or true standards in that regard?

> Note, the latter would have to be

I've been assuming we would set a policy such that once a renewed  
certificate was in the VA's (Is Validation Authority in in-company  
invention?) database, the old certificate would be considered invalid  
for signing. I suppose that would require putting the old certificate  
in the CRL us "suspended", but I don't recall an appropriate standard  
reason.

It's an internal system, so we don't have to maintain standards  
compatibility, but I do want to keep the options open if there are  
any recognized best practices that don't involve mind-reading the big  
players' documentation.

> methods such as Microsoft's XENROLL, making progress in this area  

I sure wish Microsoft could learn that when they let their cattle  
water upstream, they're gonna end up drinking the polluted water  
downstream just like the rest of us.

Thanks, Anders.