Subject: [saag] Question about PKI - certificate serial number

From: Hosnieh Rafiee <[email-masked]>
Date: Sun, 18 Dec 2016 13:23:03 +0100

Hello,

In RFC 5280, I read that the issuer of the certificate, assigned a
unique number to each certificate and call it a serial number. I assume
that this serial number is sent by the CA to client whenever the client
asks for the certificate of this intermediate CA. That means the
attacker might be able to eavesdrop this serial number.  is this
assumption true? that means the attacker might be able also to spoof and
use the same serial number for its fake Certificate.

I guess I am confused in some part of processes .... what if  the client
only have the list of trusted anchors received from root or issuer CA
that includes certificate serial number, issuer and some other
information as mentioned in the above RFC, how would be the serial
numbers protected against spoofing attack? specially if the client
verification method is only based on trusting this list and not go
through asking the issuer to download the intermediate CA certificate
from the repository?

The second question is that, when root CA is not always online, that
means the CRL list is valid for a certain period of time. if during this
time a certificate is compromised, the root needs to send a new CRL to
clients. In this case, if the attacker perform  replay attack with the
old list, is there any in use method to avoid such attack?

I would appreciate if someone can clarify these cases or point me to the
right RFC.

Thanks,

Best,

Hosnieh

---

From: Yoav Nir <[email-masked]>
Date: Sun, 18 Dec 2016 15:08:51 +0200

Hi, Hosnieh

On 18 Dec 2016, at 14:23, Hosnieh Rafiee <[email-masked]> wrote:
> Hello,
> 
> 
> In RFC 5280, I read that the issuer of the certificate, assigned a unique number to each certificate and call it a serial number. I assume that this serial number is sent by the CA to client whenever the client asks for the certificate of this intermediate CA.
> 
The issuer of the certificate (= the Certificate Authority) assigns the serial number when issuing the certificate, whether this certificate is for an End Entity or an Intermediate CA.
> That means the attacker might be able to eavesdrop this serial number.  is this assumption true? that means the attacker might be able also to spoof and use the same serial number for its fake Certificate.
> 
The serial number, and indeed the entire certificate is not secret information. It is sent in the clear. There may be privacy concerns about the content of some fields, but this is a case where privacy is not security.

The attacker is welcome to use the same serial number on a fake certificate. It should not be able to generate a valid signature on that fake certificate.
> I guess I am confused in some part of processes .... what if  the client only have the list of trusted anchors received from root or issuer CA that includes certificate serial number, issuer and some other information as mentioned in the above RFC, how would be the serial numbers protected against spoofing attack? specially if the client verification method is only based on trusting this list and not go through asking the issuer to download the intermediate CA certificate from the repository?
> 
For the root CAs there is not protection. The certificates of the root CAs serve only as vessels for the public key within them. The list of trusted CA is part of the configuration of a Relying Party.  The serial numbers in other certificate are part of the tbsCertificate structure (section 4.1.1.1) and are thus protected by the signature. 
> The second question is that, when root CA is not always online, that means the CRL list is valid for a certain period of time. if during this time a certificate is compromised, the root needs to send a new CRL to clients. In this case, if the attacker perform  replay attack with the old list, is there any in use method to avoid such attack?
> 
Not with CRLs. And you don’t need an attack either. If I have just fetched a CRL for which the nextUpdate field is January 1st 2017, I am allowed to cache it until then. Any compromise that happens in that time — I won’t know about it until January 1st. And this is true even with no CA downtime. Add CA downtime, and I might use the cached CRL longer. The CA does not actively send fresh CRLs to relying parties. It waits for them.

OCSP usually has shorter validity periods, but the mechanism is the same. The relying party is allowed to cache the responses until the nextUpdate time.
> I would appreciate if someone can clarify these cases or point me to the right RFC.
> 
I don’t know that there’s anything that explains this beyond 5280.

Yoav

---

From: "Black, David" <[email-masked]>
Date: Mon, 19 Dec 2016 15:36:11 +0000

David> Small clarification inline ....

Thanks, --David

From: saag [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Sunday, December 18, 2016 8:09 AM
To: Hosnieh Rafiee
Cc: Security Area Advisory Group
Subject: Re: [saag] Question about PKI - certificate serial number

Hi, Hosnieh

On 18 Dec 2016, at 14:23, Hosnieh Rafiee <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

David> Specifically, the trust anchor includes the issuer’s public key, which is why the attacker can’t generate a valid signature even if she uses the same serial number in her fake certificate - she doesn’t have the issuer’s private key.  Also, client verification involves a lot more than just checking the serial number - see the Certificate Path Validation algorithm in Section 6 of RFC 5280 - everything there needs to be done, as skipping steps that appear to be irrelevant risks introducing subtle security flaws.
The second question is that, when root CA is not always online, that means the CRL list is valid for a certain period of time. if during this time a certificate is compromised, the root needs to send a new CRL to clients. In this case, if the attacker perform  replay attack with the old list, is there any in use method to avoid such attack?
Not with CRLs. And you don’t need an attack either. If I have just fetched a CRL for which the nextUpdate field is January 1st 2017, I am allowed to cache it until then. Any compromise that happens in that time — I won’t know about it until January 1st. And this is true even with no CA downtime. Add CA downtime, and I might use the cached CRL longer. The CA does not actively send fresh CRLs to relying parties. It waits for them.

Yoav

---

From: Denis <[email-masked]>
Date: Mon, 19 Dec 2016 16:57:03 +0100

Hi Hosnieh,

Some more details about your sentence:

    The second question is that, when root CA is not always online, that
    means the CRL list is valid for a certain period of time.
    If during this time a certificate is compromised, the root needs to
    send a new CRL to clients. In this case, if the attacker perform
    replay attack with the old list, is there any in use method to avoid
    such attack?

Replay of an old CRL may only be mitigated by using a short validity 
period of the CRL, e.g. one day or half a day.
Root CAs are most of the case managed off-line. About ten years ago, it 
was common to have one CRL generated once a year
and hence it was valid during one full year.

Some RP implementations were keeping such CRLs during one year in their 
caches and were not even trying to see if an emergency CRL had been issued
before the end of the CRL validity period. Deleting the cache every day 
at night time is a good practice, and will force the fetch of a new CRL.
However, this practice, AFAIK,  is written nowhere.

During the last ten years, some off-line root CAs are being managed a 
little better. They issue a CRL that is valid only during one day and 
these root CAs
are still working off-line. How is it possible ?

CRLs are generated in advance once a year and these (365) CRLs are kept 
in a directory. Once a day, the appropriate CRL is pushed
into a DMZ and then becomes publicly accessible. If a sub-CA gets 
revoked, all the previously issued CRLs are suppressed and a new set of CRLs
is issued.

Denis

>> unique number to each certificate and call it a serial number. I 
>> assume that this serial number is sent by the CA to client whenever 
>> the client asks for the certificate of this intermediate CA.
>>
> The issuer of the certificate (= the Certificate Authority) assigns 
> the serial number when issuing the certificate, whether this 
> certificate is for an End Entity or an Intermediate CA.
>>
>> That means the attacker might be able to eavesdrop this serial 
>> number.  is this assumption true? that means the attacker might be 
>> able also to spoof and use the same serial number for its fake 
>> Certificate.
>>
> The serial number, and indeed the entire certificate is not secret 
> information. It is sent in the clear. There may be privacy concerns 
> about the content of some fields, but this is a case where privacy is 
> not security.
>
> The attacker is welcome to use the same serial number on a fake 
> certificate. It should not be able to generate a valid signature on 
> that fake certificate.
>>
>> I guess I am confused in some part of processes .... what if the 
>> client only have the list of trusted anchors received from root or 
>> issuer CA that includes certificate serial number, issuer and some 
>> other information as mentioned in the above RFC, how would be the 
>> serial numbers protected against spoofing attack? specially if the 
>> client verification method is only based on trusting this list and 
>> not go through asking the issuer to download the intermediate CA 
>> certificate from the repository?
>>
> For the root CAs there is not protection. The certificates of the root 
> CAs serve only as vessels for the public key within them. The list of 
> trusted CA is part of the configuration of a Relying Party.  The 
> serial numbers in other certificate are part of the tbsCertificate 
> structure (section 4.1.1.1) and are thus protected by the signature.
>>
>> means the CRL list is valid for a certain period of time. if during 
>> this time a certificate is compromised, the root needs to send a new 
>> CRL to clients. In this case, if the attacker perform  replay attack 
>> with the old list, is there any in use method to avoid such attack?
>>
> Not with CRLs. And you don’t need an attack either. If I have just 
> fetched a CRL for which the nextUpdate field is January 1st 2017, I am 
> allowed to cache it until then. Any compromise that happens in that 
> time — I won’t know about it until January 1st. And this is true even 
> with no CA downtime. Add CA downtime, and I might use the cached CRL 
> longer. The CA does not actively send fresh CRLs to relying parties. 
> It waits for them.
>
> OCSP usually has shorter validity periods, but the mechanism is the 
> same. The relying party is allowed to cache the responses until the 
> nextUpdate time.
>>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag