[saag] Question about PKI - certificate serial number

Hosnieh Rafiee <ietf@rozanak.com> Sun, 18 December 2016 12:23 UTC

Return-Path: <ietf@rozanak.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86030129534 for <saag@ietfa.amsl.com>; Sun, 18 Dec 2016 04:23:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.999
X-Spam-Level:
X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzbiqoB9uYz6 for <saag@ietfa.amsl.com>; Sun, 18 Dec 2016 04:23:14 -0800 (PST)
Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48C17129521 for <saag@ietf.org>; Sun, 18 Dec 2016 04:23:14 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 5FCED25CA2DB for <saag@ietf.org>; Sun, 18 Dec 2016 12:23:12 +0000 (UTC)
X-Virus-Scanned: amavisd-new at rozanak.com
Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.rozanak.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uROgfI_7wVl6 for <saag@ietf.org>; Sun, 18 Dec 2016 13:23:11 +0100 (CET)
Received: from localhost.localdomain (p200300864F7BDE19F2DEF1FFFE58C5D4.dip0.t-ipconnect.de [IPv6:2003:86:4f7b:de19:f2de:f1ff:fe58:c5d4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 66DA525CA08F for <saag@ietf.org>; Sun, 18 Dec 2016 13:23:11 +0100 (CET)
To: saag@ietf.org
From: Hosnieh Rafiee <ietf@rozanak.com>
Message-ID: <39ed344a-2f66-5898-6c99-368779c8bb73@rozanak.com>
Date: Sun, 18 Dec 2016 13:23:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="2VAwCAEPDif1mu2t7NrRuapN1NNV2fIGc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/EhK2GJ-D5KHsf42p4LbE_LyXxg4>
Subject: [saag] Question about PKI - certificate serial number
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Dec 2016 12:23:19 -0000

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