[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