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.
- [pkix] RFC 6960 section 4.2.2.2. question Antanas Živatkauskas
- Re: [pkix] RFC 6960 section 4.2.2.2. question Santosh Chokhani
- Re: [pkix] RFC 6960 section 4.2.2.2. question David A. Cooper
- Re: [pkix] RFC 6960 section 4.2.2.2. question Antanas Živatkauskas
- Re: [pkix] RFC 6960 section 4.2.2.2. question Santosh Chokhani