Subject: Re-certification

From: "Rodrigo Botafogo" <[email-masked]>
Date: Fri, 2 Apr 2004 18:44:00 -0300

I'm new to this group, so sorry if I do not follow the groups culture
somehow.  I have a question regarding re-certification:
 
In Brazil, a Certificate Authority had one of its CA expiring.
According to the Brazilian legislation, a CA cannot re-certify its key,
that is, it cannot extend the certificates expiration date for the same
key.
 
What the Certificate Authority did was:
 
-          Generated a new key pair;
-          Created a new certificate with: i) the same DN as the
expiring CA, ii) the new key and iii) an extended expiration date
 
First of all, is this legal according to X.509? If not, where do we find
that on the norm?
 
If this is legal, how are the CRLs supposed to work in this case.  Note
what happens:
 
1)       There are two CA with certificates with the same DN.  Lets call
them OLD and NEW.
2)       Lets call the CRLs generated CRLOld and CRLNew
3)       When CRLNew is issued, since the DN of OLD and NEW are the
same, all revoked certificates from OLD and NEW are stored in CRLNew.
This is the software's behavior.  Question: is this ok according to
X.509?
4)       Lets suppose that CRLOld had the following certificates {1, 3,
5}
5)       Lets suppose that a new cert 8 is revoked.  CRLNew will have
{1, 3, 5, 8}
6)       When a third party receives an email signed with Cert 1 what
should it do?  It will look at CRLNew, but CRLNew is not signed with the
same private key than Cert 1?  Question: Should the third party still
say that the cert is invalid or should it say that it could not verify
the status of the certificate? We made some tests and IE reported that
it could not verify the status of the certificate and did not show any
warnings, even though the certificate was expired.
 
I'd appreciate any help on this.  It seems to me that all that was
described should not be legal according to X.509, but this is an actual
case that is happening with the CA in Brazil and I couldn't find in the
norms where it is said that this is illegal.
 
Thanks,

Rodrigo Botafogo

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 2 Apr 2004 19:29:22 -0400

The best thing to do is for the new CA to pick up with the serial number wher 
the old CA left off and for both CAs ti produce the CRL for all certificates 
issued by both.

I do not know if your product will support the capabilities required to do 
that.

On Fri, 2 Apr 2004 18:44:00 -0300, Rodrigo Botafogo wrote
> According to the Brazilian legislation, a CA cannot re-certify its 
> key, that is, it cannot extend the certificates expiration date for 
> the same key.
>  
> 4)       Lets suppose that CRLOld had the following certificates {1, 
> 3, 5} 5)       Lets suppose that a new cert 8 is revoked.  CRLNew 
> will have {1, 3, 5, 8} 6)       When a third party receives an email 
> signed with Cert 1 what should it do?  It will look at CRLNew, but 
> CRLNew is not signed with the same private key than Cert 1?  
> Question: Should the third party still say that the cert is invalid 
> or should it say that it could not verify the status of the 
> certificate? We made some tests and IE reported that it could not 
> verify the status of the certificate and did not show any warnings,
>  even though the certificate was expired.
>

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 03 Apr 2004 16:22:19 +1200

>expiring CA, ii) the new key and iii) an extended expiration date

That's exactly what Verisign did when their root certs expired, AFAIK there
were no problems with apps using the certs (provided they got the new certs in
time).  Most CAs that started operating more recently (the Verisign roots are
from 1996) have got around this problem with 10-20 year validity periods, so
that whoever authorised this behaviour will have safely retired or moved on to
another job by the time it becomes a problem.

Peter.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Sun, 04 Apr 2004 21:56:03 +0200

Peter Gutmann wrote:

>That's exactly what Verisign did when their root certs expired,
>
AFAIK I have never seen Verisign *change* the key pair of an authority.
They always extend validity, while keeping the same key pair.

About  Rorigo's question :
It's perfectly legal  to do that, if you don't reuse the same serial 
number for the old CA and the new CA cert.

The RFC proper way to do it is described in paragraph  2.4 of rfc2510.

You might find interesting to read the following document :
http://www.wide.ad.jp/wg/moca/CAkeychangeover.txt
that describes that the rfc recommended way of doing it doesn't work 
very well in real life.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 08 Apr 2004 01:50:43 +1200

Jean-Marc Desperrier <[email-masked]> writes:

>AFAIK I have never seen Verisign *change* the key pair of an authority. They
>always extend validity, while keeping the same key pair.

Ah, sorry, I was a bit too quick in my reply, what I meant was that they kept
the DN, key, and start date, and only changed the end date and serial number.
I was never quite sure why they kept the validFrom date, I can understand
wanting to leave a bit of overlap, but the new certs were backdated many years
through the direct copying of the validFrom.

Peter.

---

From: "Rodrigo Botafogo" <[email-masked]>
Date: Wed, 7 Apr 2004 12:47:57 -0300

Thanks for the answers, but I haven't seen any comments about the CRL
issue that I've also asked about.  Anybody cares to comment.  I see that
there is a thread about CRL validation and it might somehow indicate how
the validation in this case should happen.  

As I have stated previously, We've made some tests and when a new key is
generated for the same DN, some RP, Outlook for instance, sees the CRL
signed with the new key as another CA and not the same CA with a new
key.  Certificates revoked before the new key generation are not seen as
revoked, the RP seems to tread the CRL as an "invalid" CRL for this
certificate.

I couldn't find anyway to configure Outlook so that it would recognize
that the cert was revoked.  Is there any application out there that does
the right thing?  Sorry if discussing real apps is not in the scope of
the group.  If so, let me know.

Thanks again,

Rodrigo

>AFAIK I have never seen Verisign *change* the key pair of an authority.
They
>always extend validity, while keeping the same key pair.

Ah, sorry, I was a bit too quick in my reply, what I meant was that they
kept
the DN, key, and start date, and only changed the end date and serial
number.
I was never quite sure why they kept the validFrom date, I can
understand
wanting to leave a bit of overlap, but the new certs were backdated many
years
through the direct copying of the validFrom.

Peter.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 07 Apr 2004 19:57:01 +0200

Rodrigo Botafogo wrote:

>[...] I haven't seen any comments about the CRL
>issue that I've also asked about. [...]
>
AFAIC what you did about the CRL seemed really special, and I wasn't 
sure I understood it fully.

>[...] We've made some tests and when a new key is
Does it have both the old and the new CA certificate in it's store ?

You can't say "Outlook" and expect answers.
Depending on the exact version, the behavior (especially CRL) has major 
differences.

>[...]  Certificates revoked before the new key generation are not seen as
Quite interesting. 
Whatever the RFC say about the subject, accepting as valid a CRL emitted 
by a CA that has the same DN as the CA that emitted the subject (but a 
different key) is very delicate thing to handle without dangerous 
security implications, and I think most implementors just safely refuse 
it all together, which is a better solution than to do it without being 
able to define adequate safegards.
 
But the thing you can rely on to get this working is AKI identifiers.
The Microsoft implementation places a lot of confidence in AKI, even 
accepting to follow a path based on the AKI when the DN don't match 
(which is invalid).

So you can hope to get some succesful results if you generate two CRL in 
parallel, one by the old CA one by the new CA, and use an AKI inside the 
CRL to link them strongly to the adequate CA. And always revoke certs in 
the CRL signed by the keypair that issued them.
If you're still concerned about being able to revoke certs emitted by 
the old CA, that mean that old CA is not yet expired and still can emit 
CRL, doesn't it ?

>the right thing? 
I'm surprised Outlook goes as far as you apparently describe.
Since years, people have reached the conclusion with the applications on 
the market, CA changeover with key renewal and the same DN doesn't work, 
and always either keeped the same key, or (even if only slightly) 
changed the DN.
AKI is theorically the key to getting it working correctly, but it's 
adventurous to really test it.

>Sorry if discussing real apps is not in the scope of
I too sometime wonder too why this lists spends astounding amount of 
time discussing very advanced points, and so little discussing the 
actual shortcomings of existing implementations on basic things.
But this said yes to some degree detailled discussion of how to get such 
specific implementation to do some thing might be out of the scope.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 7 Apr 2004 15:29:54 -0400

As my answer said, there would not be a problem with CRL since each serial
number will be unique and both keys will be used to sign the CRL.

Please go back and read my response.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Rodrigo Botafogo
Sent: Wednesday, April 07, 2004 11:48 AM
To: [email-masked]
Subject: RES: Re-certification

As I have stated previously, We've made some tests and when a new key is
generated for the same DN, some RP, Outlook for instance, sees the CRL
signed with the new key as another CA and not the same CA with a new key.
Certificates revoked before the new key generation are not seen as
revoked, the RP seems to tread the CRL as an "invalid" CRL for this
certificate.

I couldn't find anyway to configure Outlook so that it would recognize
that the cert was revoked.  Is there any application out there that does
the right thing?  Sorry if discussing real apps is not in the scope of the
group.  If so, let me know.

Thanks again,

Rodrigo

They

Ah, sorry, I was a bit too quick in my reply, what I meant was that they
kept the DN, key, and start date, and only changed the end date and serial
number. I was never quite sure why they kept the validFrom date, I can
understand wanting to leave a bit of overlap, but the new certs were
backdated many years through the direct copying of the validFrom.

Peter.

---

From: "Rodrigo Botafogo" <[email-masked]>
Date: Wed, 7 Apr 2004 17:05:03 -0300

Santosh,

Sorry, I missed your reply.  But unfortunately, my product does not
allow me to have two CAs with the same DN active at the same time.  So,
once I create the new CA, I'll have to deactivate somehow the old CA.

But I agree, that probably would be a good solution.

Thanks

Rodrigo Botafogo

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 7 Apr 2004 17:30:16 -0400

In that case, the following may work:

1.  The new CA reissues all the old CA issued certificates that are not
yet expired.  It can keep the same serial number if possible.

2.  Everyone has the new root using secure means.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Rodrigo Botafogo
Sent: Wednesday, April 07, 2004 4:05 PM
To: [email-masked]
Subject: RES: Re-certification

Santosh,

Sorry, I missed your reply.  But unfortunately, my product does not allow
me to have two CAs with the same DN active at the same time.  So, once I
create the new CA, I'll have to deactivate somehow the old CA.

Thanks

Rodrigo Botafogo