IETF Logo Mail Archive

Re: [pkix] RFC 6960 section 4.2.2.2. question

Santosh Chokhani <schokhani@cygnacom.com> Fri, 13 February 2015 20:59 UTC

Return-Path: <schokhani@cygnacom.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749901A1A3C for <pkix@ietfa.amsl.com>; Fri, 13 Feb 2015 12:59:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level:
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 dL5Zt-cuEjYl for <pkix@ietfa.amsl.com>; Fri, 13 Feb 2015 12:59:37 -0800 (PST)
Received: from ipesa2.cygnacom.com (ipesa2.cygnacom.com [65.242.48.201]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ACE31A1A2D for <pkix@ietf.org>; Fri, 13 Feb 2015 12:59:37 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArYEALFk3lQKPDLZ/2dsb2JhbABbgkOBFVoEwimFdQKBVwEBAQEBAXyEDAEBAQQtXAIBCA0EBAEBKAcyFAkIAQEEARIIiCrVDQEBAQEBAQEBAgEBAQEBAQEBAQEBF4o/TYE9gzYBBoQkBZ9GjCiEEG+BRH8BAQE
X-IronPort-AV: E=Sophos;i="5.09,573,1418101200"; d="scan'208,217";a="30667"
Received: from unknown (HELO svaexch2.cygnacom.com) ([10.60.50.217]) by ipesa2.cygnacom.com with ESMTP; 13 Feb 2015 15:59:36 -0500
Received: from svaexch1.cygnacom.com (10.60.50.216) by svaexch2.cygnacom.com (10.60.50.217) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 13 Feb 2015 15:59:36 -0500
Received: from svaexch1.cygnacom.com ([fe80::b53e:f4f1:9071:563e]) by svaexch1.cygnacom.com ([fe80::b53e:f4f1:9071:563e%12]) with mapi id 15.00.0913.011; Fri, 13 Feb 2015 15:59:35 -0500
From: Santosh Chokhani <schokhani@cygnacom.com>
To: Antanas Živatkauskas <Antanas.Zivatkauskas@gyvreg.lt>, "'pkix@ietf.org'" <pkix@ietf.org>
Thread-Topic: RFC 6960 section 4.2.2.2. question
Thread-Index: AdBHiL8RA0CkdGMZQ7OvyuRXQLKqlwARONNw
Date: Fri, 13 Feb 2015 20:59:35 +0000
Message-ID: <1628fc57677b4fa4a5ba9b59da1e3a94@svaexch1.cygnacom.com>
References: <02c3425c45974d09861b79e078dd23f1@rcmail.kada.lan>
In-Reply-To: <02c3425c45974d09861b79e078dd23f1@rcmail.kada.lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.60.117.7]
Content-Type: multipart/alternative; boundary="_000_1628fc57677b4fa4a5ba9b59da1e3a94svaexch1cygnacomcom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/JQ1Kh_mrooPFwDvwG7FTrM93nCQ>
Subject: Re: [pkix] RFC 6960 section 4.2.2.2. question
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Feb 2015 20:59:40 -0000

To me it is saying that the relying party must only accept CA-delegated OCSP Responder certificate only if both certificates were signed using the same key.  It is trying to disambiguate a purported ambiguity in 2560.

BTW, the two certificates are: OCSP Responder certificate and the certificate whose status is being checked by the OCSP Responder.

This constraint provides simple crypto binding to the delegation.

From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Antanas Živatkauskas
Sent: Friday, February 13, 2015 7:36 AM
To: 'pkix@ietf.org'
Subject: [pkix] RFC 6960 section 4.2.2.2. question


Need help in interpreting the following statement in RFC 6960 section 4.2.2.2.  Authorized Responders:

"Systems relying on OCSP responses MUST recognize a
delegation certificate as being issued by the CA that issued the
certificate in question only if the delegation certificate and the
certificate being checked for revocation were signed by the same key."

It is not really clear if it is a must for systems relying on OCSP responses in all cases accept a delegation certificate as long as CA uses "the same issuing key to issue a delegation certificate as that used to sign the certificate being checked for revocation", so that the alternative option of providing "a means of locally configuring one or more OCSP signing authorities and specifying the set of CAs for which each signing authority is trusted" is irrelevant.

Is the word RECOGNIZE in the excerpt above interchangable with the word ACCEPT?
If not, what is the meaning of RECOGNIZE, respectively the purpose of such recognition?



--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

v2.23.0 | Report a Bug | By Email