Problem verifying signature

[Massimiliano Max]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi all. My problem isn't related to bouncycastle itself : I'm able to successfully verify signatures.
What I need is an advice about the way I should verify signature in the case I'm facing right now.

Here is the situation.

I work for an Italian Certification Authority.
In this days, we are in the process of renewing the CA certificate. To be compliant with Italian laws, the renewval process will follow these steps:
1) Some month before the actual CA certificate will end validity, the new CA certificate will be released.
2) The new CA certificate will have the same Distinguished Name of the old CA certificate, but a totally different key pair
3) The CRL, as soon as the new CA certificate will be issued, will be signed by the new CA certificate

Point 3 is what makes me crazy...

The flow I use to verify signature validity in a P7M file is:
1) Check the document integrity
2) Check that the signer certificate is valid against the CA certificate
3) Download the CRL from the CDP found inside the certificate
4) *** Verify the CRL against the CA certificate
5) Check that the certificate was not revoked at the time of the signature (if the signature-timestamp-token is present).

When the new CA certificate will be online, if the certificate inside the P7M to verify was issued by the old CA certificate, point 4 will always fail (because now the
CRL are signed by the new CA certificate)!

Can someone please point me to the right way to handle this situation?
I don't want to skip point 4 , because that would be a BIG security hole!

Thank you,
Massimiliano

---

Keep your friends updated— even when you’re not signed in.

[Rajani123]

There is a another i.e, After you generate a new CA certificate,
maintain two copies of signed (Sign with old and new certificates)
CRLs at CRL distribution point. Generally there will be a small
difference between two serials so you can put them in the same
location.
Based the certificate you used coresponding CRL will called. Once the
old CA certificate is expired then remove the coresponding CRL from
the server.

I hope this will work.....
Regards,
Rajani

On 10/23/09, rajani chowdary <grajanichowdary@...> wrote:

> Dear Massimiliano,
> You have to generate new CA certificate in one month advance. Here my
> doubt is, generated certificate is valid from the date of creation or
> it will be valid after one month?
> If it is valid till it's expiry date (even though you created a new CA
> certificate ) CRL will not have the certificate's serial number in
> that.
> So when you do the verification by using old CA certificate it will
> not give any exception.
> Even you generate a new CA certificate it can contain the same old CRL
> distribution point based on configuration in the CA.
>
> Please correct me if my understanding is wrong .
>
> Regards,
> Rajani
>
> On 10/23/09, Massimiliano Max <dottzero@...> wrote:
>>
>> Hi all. My problem isn't related to bouncycastle itself : I'm able to
>> successfully verify signatures.
>> What I need is an advice about the way I should verify signature in the
>> case
>> I'm facing right now.
>>
>> Here is the situation.
>>
>> I work for an Italian Certification Authority.
>> In this days, we are in the process of renewing the CA certificate. To be
>> compliant with Italian laws, the renewval process will follow these
>> steps:
>> 1) Some month before the actual CA certificate will end validity, the new
>> CA
>> certificate will be released.
>> 2) The new CA certificate will have the same Distinguished Name of the
>> old
>> CA certificate, but a totally different key pair
>> 3) The CRL, as soon as the new CA certificate will be issued, will be
>> signed
>> by the new CA certificate
>>
>> Point 3 is what makes me crazy...
>>
>> The flow I use to verify signature validity in a P7M file is:
>> 1) Check the document integrity
>> 2) Check that the signer certificate is valid against the CA certificate
>> 3) Download the CRL from the CDP found inside the certificate
>> 4) *** Verify the CRL against the CA certificate
>> 5) Check that the certificate was not revoked at the time of the
>> signature
>> (if the signature-timestamp-token is present).
>>
>> When the new CA certificate will be online, if the certificate inside the
>> P7M to verify was issued by the old CA certificate, point 4 will always
>> fail
>> (because now the
>> CRL are signed by the new CA certificate)!
>>
>> Can someone please point me to the right way to handle this situation?
>> I don't want to skip point 4 , because that would be a BIG security hole!
>>
>> Thank you,
>> Massimiliano
>>
>>    
>> _________________________________________________________________
>> Keep your friends updated—even when you’re not signed in.
>> http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010
>
>
> --
> Thanks & Regards,
> Rajani Chowdary Gali,
> [phone]
>

--
Thanks & Regards,
Rajani Chowdary Gali,
[phone]

[Massimiliano Max]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi Rajani! Thank you!

>You have to generate new CA certificate in one month advance. Here my
> doubt is, generated certificate is valid from the date of creation or
> it will be valid after one month?

Yes. For one month, both certificates will be valid.

> If it is valid till it's expiry date (even though you created a new CA
> certificate ) CRL will not have the certificate's serial number in
> that.
> So when you do the verification by using old CA certificate it will
> not give any exception.

Probably I didn't explain point 4 the right way.

In point 4, I verify that the CRL is *signed* by the same CA that
realesed the signer certificate. Since the CA certificate has changed
and the CRL is signed by the new CA certificate , this check can't be
successfully.

Regards,
Massimiliano

---

Keep your friends updated— even when you’re not signed in.

[martijn.list]

A CRL can revoke certificates for other CAs than the CA that signed the
CRL. This however is afaik not supported by Windows.

Take a look at this thread for more information:

http://www.ietf.org/mail-archive/web/pkix/current/msg17582.html

PS. I think they (read the Italian lawmakers) should not have come up
with such an awkward (read stupid ;) 'law' to create a new CA. It's not
supported by Windows (correct me if I'm wrong) and probably also not
supported by a lot of other PKI implementations. A new CA certificate
should imho have a different name than the old CA.


Massimiliano Max wrote:

> Hi all. My problem isn't related to bouncycastle itself : I'm able to
> successfully verify signatures.
> What I need is an advice about the way I should verify signature in the
> case I'm facing right now.
>
> Here is the situation.
>
> I work for an Italian Certification Authority.
> In this days, we are in the process of renewing the CA certificate. To
> be compliant with Italian laws, the renewval process will follow these
> steps:
> 1) Some month before the actual CA certificate will end validity, the
> new CA certificate will be released.
> 2) The new CA certificate will have the same Distinguished Name of the
> old CA certificate, but a totally different key pair
> 3) The CRL, as soon as the new CA certificate will be issued, will be
> signed by the new CA certificate
>
> Point 3 is what makes me crazy...
>
> The flow I use to verify signature validity in a P7M file is:
> 1) Check the document integrity
> 2) Check that the signer certificate is valid against the CA certificate
> 3) Download the CRL from the CDP found inside the certificate
> 4) *** Verify the CRL against the CA certificate
> 5) Check that the certificate was not revoked at the time of the
> signature (if the signature-timestamp-token is present).
>
> When the new CA certificate will be online, if the certificate inside
> the P7M to verify was issued by the old CA certificate, point 4 will
> always fail (because now the
> CRL are signed by the new CA certificate)!
>
> Can someone please point me to the right way to handle this situation?
> I don't want to skip point 4 , because that would be a BIG security hole!
>
> Thank you,
> Massimiliano
>
>
> ------------------------------------------------------------------------
> Keep your friends updated— even when you’re not signed in.
> <http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010>

--
Djigzo open source email encryption

[Lothar Kimmeringer-4]

Massimiliano Max schrieb:

> 3) The CRL, as soon as the new CA certificate will be issued, will be
> signed by the new CA certificate

Is there only one signature allowed? What keeps you from signing
it with the old and the new certificate?


Regards, Lothar

[Massimiliano Max]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Thank you all for your help!

The software that will be used to validate signatures performed with our certificates, will
validate signatures performed with certificates issued by other CAs too.

I need a 'right' way (if it exists) to perform such validation (or I need a document
to give to our PKI to tell them : you must do it this way), so if something should ever go
wrong with other CA in our same situation, we can tell :'We comply to ....'

---

Windows Live Hotmail: Your friends can get your Facebook updates, right from Hotmail®.

[martijn.list]

There is no single 'right' way but this comes close

http://www.itu.int/rec/T-REC-X.509/en


Massimiliano Max wrote:

> Thank you all for your help!
>
> The software that will be used to validate signatures performed with our
> certificates, will
> validate signatures performed with certificates issued by other CAs too.
>
> I need a 'right' way (if it exists) to perform such validation (or I
> need a document
> to give to our PKI to tell them : you must do it this way), so if
> something should ever go
> wrong with other CA in our same situation, we can tell :'We comply to ....'
>
>
>
> ------------------------------------------------------------------------
> Windows Live Hotmail: Your friends can get your Facebook updates, right
> from Hotmail®.
> <http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009>

--
Djigzo open source email encryption

[Rajani123]

On 10/23/09, Massimiliano Max <dottzero@...> wrote:
>
> Thank you all for your help!
I understand your point and this is very basic thing you need to do.
We should support any CA's certificate.

Even if CA is different all certificates will have CRL dp.
So you need to write a code which can get the CRL file from the CA
(based on CRL DP available in the certificate).
Once you get the CRL file remaining functionality is same for
certificate verification (Even though certificates issued by different
CAs).

If you are verifying certificate before signing or verification that
means you need check the REVOCATION CHECK as well as CHINE
VERIFICATION.
CHAIN VERIFICATION means you need to import the certificate chine of
the certificate ( Import sub CA certificates if certificate is issued
by sub CA) and check whether CA certificate is valid or not.

If you want more details, don't hesitate to send me a mail....... :-)


I will try to send you a document which says how to do CHINE
VERIFICATION and REVOCATION CHECK.

All the best...
Rajani

>
> The software that will be used to validate signatures performed with our
> certificates, will
> validate signatures performed with certificates issued by other CAs too.
>
> I need a 'right' way (if it exists) to perform such validation (or I need a
> document
> to give to our PKI to tell them : you must do it this way), so if something
> should ever go
> wrong with other CA in our same situation, we can tell :'We comply to ....'
>
>
>    
> _________________________________________________________________
> Windows Live Hotmail: Your friends can get your Facebook updates, right from
> Hotmail®.
> http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009

--
Thanks & Regards,
Rajani Chowdary Gali,
[phone]