From nobody Sun Feb 1 19:05:30 2015 Return-Path: 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 8E75C1A9253 for ; Sun, 1 Feb 2015 19:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 a1PVCvuTgfHM for ; Sun, 1 Feb 2015 19:05:27 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E321A9250 for ; Sun, 1 Feb 2015 19:05:27 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id tr6so14855807ieb.2 for ; Sun, 01 Feb 2015 19:05:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=GJFJ52perLMbgv8VzTxuUUrIjfeMmjea98PTYSFQqlE=; b=KBCRIeIp2JwwQXvn7UO9TlFM/RRCfGS+FO/1X/QYRB1p9p9yFFQz07P8rsVeaGNjMA NUaa390jHb6cbGog2b5uRRzcyMPrlFXgRPvQJLA+Wk2YHx7XueaJOf5aBqiKTzIp3Yge 0y2SJKqQALQaUPMmWCr7ttlSUSs0zH8El7RKoHuGfAbOV/usTFZ4WXjtbeAXsYoOZN1P kLrRL59kbTWK7hX/XqDBav4VS3rVN9InUL2M/5t777G3QjVGUFgklnpddO87o5ypuxyt xLtZbncJ4azqw1tItdhNWyri2UgbNwx5recSGKa2Yn+7ZLs9wqjeiacqPjgCheyUHMLb qjzA== MIME-Version: 1.0 X-Received: by 10.107.132.101 with SMTP id g98mr14770560iod.66.1422846326181; Sun, 01 Feb 2015 19:05:26 -0800 (PST) Received: by 10.36.20.15 with HTTP; Sun, 1 Feb 2015 19:05:26 -0800 (PST) Date: Sun, 1 Feb 2015 22:05:26 -0500 Message-ID: From: Jeffrey Walton To: PKIX Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [pkix] RFC 6125, Server Identity Check and insecure DNS lookup X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 03:05:28 -0000 What does RFC 6125 mean when they say the following: 2.4. Server Identity Check o The client MUST use the server hostname it used to open the connection as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done. Is this saying that all DNS is considered insecure, and only the original hostname used by the client should be used for validation? Or is it saying its OK to follow the CNAME aliases when using a "secure" DNS, like DNSSEC? Or is it saying something else? From nobody Mon Feb 2 04:35:00 2015 Return-Path: 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 2C4121A028A for ; Mon, 2 Feb 2015 04:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 7rFVFkjsah95 for ; Mon, 2 Feb 2015 04:34:57 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD9141A0277 for ; Mon, 2 Feb 2015 04:34:56 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 5B1C3444EE; Mon, 2 Feb 2015 13:34:54 +0100 (CET) X-purgate-ID: 152705::1422880494-00003099-9389FDD1/0/0 X-purgate-size: 1308 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 51F8C421C0; Mon, 2 Feb 2015 13:34:54 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 4BD661B14C; Mon, 2 Feb 2015 13:34:54 +0100 (CET) In-Reply-To: To: noloader@gmail.com Date: Mon, 2 Feb 2015 13:34:54 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150202123454.4BD661B14C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: PKIX Subject: Re: [pkix] RFC 6125, Server Identity Check and insecure DNS lookup X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 12:34:59 -0000 Jeffrey Walton wrote: > What does RFC 6125 mean when they say the following: > > 2.4. Server Identity Check > > o The client MUST use the server hostname it used to open the > connection as the value to compare against the server name as > expressed in the server certificate. The client MUST NOT use any > form of the server hostname derived from an insecure remote source > (e.g., insecure DNS lookup). CNAME canonicalization is not done. > > Is this saying that all DNS is considered insecure, and only the > original hostname used by the client should be used for validation? > > Or is it saying its OK to follow the CNAME aliases when using a > "secure" DNS, like DNSSEC? The difference here is "lack of trust" in the data contained in DNS. The two characteristics that DNSSEC provides (according to its own specification) is data origin authentication and data integrity protection. But using DNSSEC does not increase the trustworthyness of the data conveyed through DNS. Similarily using HTTPS rather than HTTP for searching Google will provide only data origin authentication and data integrity protection for the search results, but will not increase the trustworthyness of the search results (there is no trust). -Martin From Antanas.Zivatkauskas@gyvreg.lt Fri Feb 13 04:36:09 2015 Return-Path: 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 E94241A1B9C for ; Fri, 13 Feb 2015 04:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.101 X-Spam-Level: * X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 BjDjz5477xsM for ; Fri, 13 Feb 2015 04:36:06 -0800 (PST) Received: from mail3.kada.lt (mail3.kada.lt [91.199.55.10]) (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 F27B31A19F6 for ; Fri, 13 Feb 2015 04:36:05 -0800 (PST) Received: from rcmail.kada.lan (rcmail [10.254.254.56]) by mail3.kada.lt (8.15.1/8.14.9) with ESMTPS id t1DCZXN9003591 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 13 Feb 2015 14:35:33 +0200 (EET) (envelope-from Antanas.Zivatkauskas@gyvreg.lt) Received: from rcmail.kada.lan (10.254.254.56) by rcmail.kada.lan (10.254.254.56) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 13 Feb 2015 14:35:32 +0200 Received: from rcmail.kada.lan ([::1]) by rcmail.kada.lan ([::1]) with mapi id 15.00.1044.021; Fri, 13 Feb 2015 14:35:32 +0200 From: =?windows-1257?Q?Antanas_=DEivatkauskas?= To: "'pkix@ietf.org'" Thread-Topic: RFC 6960 section 4.2.2.2. question Thread-Index: AdBHiL8RA0CkdGMZQ7OvyuRXQLKqlw== Date: Fri, 13 Feb 2015 12:35:32 +0000 Message-ID: <02c3425c45974d09861b79e078dd23f1@rcmail.kada.lan> Accept-Language: en-US, lt-LT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.102.14.53] Content-Type: multipart/alternative; boundary="_000_02c3425c45974d09861b79e078dd23f1rcmailkadalan_" MIME-Version: 1.0 X-RegistruCentras-MailScanner-Information: Please contact the ISP for more information X-RegistruCentras-MailScanner-ID: t1DCZXN9003591 X-RegistruCentras-MailScanner: Found to be clean X-RegistruCentras-MailScanner-From: antanas.zivatkauskas@gyvreg.lt Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 12:53:28 -0000 --_000_02c3425c45974d09861b79e078dd23f1rcmailkadalan_ Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable Need help in interpreting the following statement in RFC 6960 section 4.2.2= .2. Authorized Responders: =93Systems 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.=94 It is not really clear if it is a must for systems relying on OCSP response= s in all cases accept a delegation certificate as long as CA uses =93the sa= me issuing key to issue a delegation certificate as that used to sign the c= ertificate being checked for revocation=94, so that the alternative option = of providing =93a means of locally configuring one or more OCSP signing aut= horities and specifying the set of CAs for which each signing authority is = trusted=94 is irrelevant. Is the word RECOGNIZE in the excerpt above interchangable with the word ACC= EPT? If not, what is the meaning of RECOGNIZE, respectively the purpose of such = recognition? --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --_000_02c3425c45974d09861b79e078dd23f1rcmailkadalan_ Content-Type: text/html; charset="windows-1257" Content-Transfer-Encoding: quoted-printable

 

Need help in interpret= ing the following statement in RFC 6960 section 4.2.2.2.  Authorized R= esponders:

 

=93Systems relying on = OCSP responses MUST recognize a

delegation certificate= as being issued by the CA that issued the

certificate in questio= n only if the delegation certificate and the

certificate being chec= ked for revocation were signed by the same key.=94

 

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 =93the same issuing key to issu= e a delegation certificate as that used to sign the certificate being checked for revocation=94, so that the alter= native option of providing =93a means of locally configuring one or more OC= SP signing authorities and specifying the set of CAs for which each signing= authority is trusted=94 is irrelevant.

 

Is the word RECOGNIZE = in the excerpt above interchangable with the word ACCEPT?=

If not, what is the me= aning of RECOGNIZE, respectively the purpose of such recognition?

 

 


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --_000_02c3425c45974d09861b79e078dd23f1rcmailkadalan_-- From nobody Fri Feb 13 12:59:41 2015 Return-Path: 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 ; 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 ; 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 ; 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 To: =?iso-8859-2?Q?Antanas_=AEivatkauskas?= , "'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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 20:59:40 -0000 --_000_1628fc57677b4fa4a5ba9b59da1e3a94svaexch1cygnacomcom_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable To me it is saying that the relying party must only accept CA-delegated OCS= P Responder certificate only if both certificates were signed using the sam= e key. It is trying to disambiguate a purported ambiguity in 2560. BTW, the two certificates are: OCSP Responder certificate and the certifica= te 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 =AEivatkausk= as 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 response= s 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 cer= tificate being checked for revocation", so that the alternative option of p= roviding "a means of locally configuring one or more OCSP signing authoriti= es and specifying the set of CAs for which each signing authority is truste= d" is irrelevant. Is the word RECOGNIZE in the excerpt above interchangable with the word ACC= EPT? 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, and is believed to be clean. --_000_1628fc57677b4fa4a5ba9b59da1e3a94svaexch1cygnacomcom_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

To me it is saying tha= t the relying party must only accept CA-delegated OCSP Responder certificat= e only if both certificates were signed using the same key.  It is try= ing to disambiguate a purported ambiguity in 2560.

 

BTW, the two certifica= tes are: OCSP Responder certificate and the certificate whose status is bei= ng checked by the OCSP Responder.

 

This constraint provid= es simple crypto binding to the delegation.

 

From: pkix [mailto:pkix-bounces@ietf.org] = On Behalf Of Antanas =AEivatkauskas
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 interpret= ing the following statement in RFC 6960 section 4.2.2.2.  Authorized R= esponders:

 

“Systems relying= on OCSP responses MUST recognize a

delegation certificate= as being issued by the CA that issued the

certificate in questio= n only if the delegation certificate and the

certificate being chec= ked 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 a= lternative 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 me= aning of RECOGNIZE, respectively the purpose of such recognition?

 

 


--
This message has been scanned for viruses and
dangerous content by MailScanne= r, and is
believed to be clean.

--_000_1628fc57677b4fa4a5ba9b59da1e3a94svaexch1cygnacomcom_-- From nobody Fri Feb 13 13:26:06 2015 Return-Path: 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 4E74F1A1A58 for ; Fri, 13 Feb 2015 13:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 j4kZH1z67wbV for ; Fri, 13 Feb 2015 13:25:49 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9709B1A1A91 for ; Fri, 13 Feb 2015 13:25:47 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 13 Feb 2015 16:26:10 -0500 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.389.2; Fri, 13 Feb 2015 16:25:46 -0500 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id t1DLPbe7023862; Fri, 13 Feb 2015 16:25:37 -0500 Message-ID: <54DE6BD1.9030703@nist.gov> Date: Fri, 13 Feb 2015 16:25:37 -0500 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Santosh Chokhani , =?windows-1252?Q?Antanas_?= =?windows-1252?Q?=8Eivatkauskas?= , "'pkix@ietf.org'" References: <02c3425c45974d09861b79e078dd23f1@rcmail.kada.lan> <1628fc57677b4fa4a5ba9b59da1e3a94@svaexch1.cygnacom.com> In-Reply-To: <1628fc57677b4fa4a5ba9b59da1e3a94@svaexch1.cygnacom.com> Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit X-NIST-MailScanner-Information: Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 21:26:04 -0000
Actually, this is not what the text is trying to say. The text is not imposing a constraint on relying parties, it is only saying that relying parties are not required to be able to handle the case in which the CA uses different keys to sign the certificate in question and the delegation certificate. As noted in RFC 6960, RFC 2560 was very clear that it did not impose such a constraint.

Here is the quoted text with more context included, which makes it clear that the text is not imposing a constraint on relying parties:

   The CA SHOULD use the same issuing key to issue a delegation
   certificate as that used to sign the certificate being checked for
   revocation.  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.

   Note: For backwards compatibility with RFC 2560 [RFC2560], it is not
         prohibited to issue a certificate for an Authorized Responder
         using a different issuing key than the key used to issue the
         certificate being checked for revocation.  However, such a
         practice is strongly discouraged, since clients are not
         required to recognize a responder with such a certificate as an
         Authorized Responder.

I think the reason that the word "recognize" was used instead of "accept" is that verifying that the certificate in question and the delegation certificate were issued by the same CA is neither necessary nor sufficient to accept a response. The relying party could accept the response based on its being signed by a locally-trusted responder, and the relying party could reject the response for other reasons (e.g., response is too old or does not provide information about the certificate in question).

On 02/13/2015 03:59 PM, Santosh Chokhani wrote:

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, and is
believed to be clean. 



_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

From nobody Sat Feb 14 03:32:08 2015 Return-Path: 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 D27D21A1BE0 for ; Sat, 14 Feb 2015 03:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 0VrSrm7Jejuf for ; Sat, 14 Feb 2015 03:32:02 -0800 (PST) Received: from mail3.kada.lt (mail3.kada.lt [91.199.55.10]) (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 D6D151A1BE7 for ; Sat, 14 Feb 2015 03:32:01 -0800 (PST) Received: from rcmail.kada.lan (rcmail [10.254.254.56]) by mail3.kada.lt (8.15.1/8.14.9) with ESMTPS id t1EBVR6r022915 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 14 Feb 2015 13:31:28 +0200 (EET) (envelope-from Antanas.Zivatkauskas@gyvreg.lt) Received: from rcmail.kada.lan (10.254.254.56) by rcmail.kada.lan (10.254.254.56) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Sat, 14 Feb 2015 13:31:27 +0200 Received: from rcmail.kada.lan ([::1]) by rcmail.kada.lan ([::1]) with mapi id 15.00.1044.021; Sat, 14 Feb 2015 13:31:27 +0200 From: =?Windows-1252?Q?Antanas_=8Eivatkauskas?= To: "David A. Cooper" , Santosh Chokhani , "'pkix@ietf.org'" Thread-Topic: [pkix] RFC 6960 section 4.2.2.2. question Thread-Index: AdBHiL8RA0CkdGMZQ7OvyuRXQLKqlwARONNw///qa4CAAP5mAw== Date: Sat, 14 Feb 2015 11:31:26 +0000 Message-ID: <1423913471668.74024@gyvreg.lt> References: <02c3425c45974d09861b79e078dd23f1@rcmail.kada.lan> <1628fc57677b4fa4a5ba9b59da1e3a94@svaexch1.cygnacom.com>, <54DE6BD1.9030703@nist.gov> In-Reply-To: <54DE6BD1.9030703@nist.gov> Accept-Language: en-US, lt-LT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [213.159.35.23] Content-Type: multipart/alternative; boundary="_000_142391347166874024gyvreglt_" MIME-Version: 1.0 X-RegistruCentras-MailScanner-Information: Please contact the ISP for more information X-RegistruCentras-MailScanner-ID: t1EBVR6r022915 X-RegistruCentras-MailScanner: Found to be clean X-RegistruCentras-MailScanner-From: antanas.zivatkauskas@gyvreg.lt Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 11:32:06 -0000 --_000_142391347166874024gyvreglt_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable What I am trying to understand in other words is whether systems or applica= tions that rely on OCSP responses are still free to use local configuration= of OCSP signing authority for the certificate in question even when the OC= SP responses they get contain the delegation certificate which is signed by= the same key as the certificate being checked for revocation? You say that the text is not imposing a constraint on relying parties, mean= ing that the answer to the question above is "Yes". However for me it seems= to conflict with the note which says: such a practice is strongly discouraged, since clients are not required to recognize a responder with such a certificate as an Authorized Responder. This statement I interpret in the following way: clients are NOT REQUIRED t= o recognize responder if it is using a diffent key for delegation certifica= te as the one which signed certificate being checked for revocation which i= mplies they are REQUIRED to recognize responder if the two keys are the sam= e and consequently it does not matter what local configuration of OCSP sign= ing authority they use. I am still confused ... ________________________________ From: David A. Cooper Sent: Friday, February 13, 2015 11:25 PM To: Santosh Chokhani; Antanas =8Eivatkauskas; 'pkix@ietf.org' Subject: Re: [pkix] RFC 6960 section 4.2.2.2. question Actually, this is not what the text is trying to say. The text is not impos= ing a constraint on relying parties, it is only saying that relying parties= are not required to be able to handle the case in which the CA uses differ= ent keys to sign the certificate in question and the delegation certificate= . As noted in RFC 6960, RFC 2560 was very clear that it did not impose such= a constraint. Here is the quoted text with more context included, which makes it clear th= at the text is not imposing a constraint on relying parties: The CA SHOULD use the same issuing key to issue a delegation certificate as that used to sign the certificate being checked for revocation. 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. Note: For backwards compatibility with RFC 2560 [RFC2560], it is not prohibited to issue a certificate for an Authorized Responder using a different issuing key than the key used to issue the certificate being checked for revocation. However, such a practice is strongly discouraged, since clients are not required to recognize a responder with such a certificate as an Authorized Responder. I think the reason that the word "recognize" was used instead of "accept" i= s that verifying that the certificate in question and the delegation certif= icate were issued by the same CA is neither necessary nor sufficient to acc= ept a response. The relying party could accept the response based on its be= ing signed by a locally-trusted responder, and the relying party could reje= ct the response for other reasons (e.g., response is too old or does not pr= ovide information about the certificate in question). On 02/13/2015 03:59 PM, Santosh Chokhani wrote: To me it is saying that the relying party must only accept CA-delegated OCS= P Responder certificate only if both certificates were signed using the sam= e key. It is trying to disambiguate a purported ambiguity in 2560. BTW, the two certificates are: OCSP Responder certificate and the certifica= te 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 =8Eivatkausk= as 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: =93Systems 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.=94 It is not really clear if it is a must for systems relying on OCSP respons= es in all cases accept a delegation certificate as long as CA uses =93the s= ame issuing key to issue a delegation certificate as that used to sign the = certificate being checked for revocation=94, so that the alternative option= of providing =93a means of locally configuring one or more OCSP signing au= thorities and specifying the set of CAs for which each signing authority is= trusted=94 is irrelevant. Is the word RECOGNIZE in the excerpt above interchangable with the word ACC= EPT? If not, what is the meaning of RECOGNIZE, respectively the purpose of such = recognition? --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --_000_142391347166874024gyvreglt_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

What I am trying to understand in other words is whether systems or appl= ications that rely on OCSP responses are still free to use local configurat= ion of OCSP signing authority for the certificate in question even when the= OCSP responses they get contain the delegation certificate which is signed by the same key as the certific= ate being checked for revocation?

You say that the text is not imposing a constraint on relying parties, mean= ing that the answer to the question above is "Yes". However for m= e it seems to conflict with the note which says:


         such a practice is strongly discouraged, since clients are not=
         required to recog= nize a responder with such a certificate as an
         Authorized Respon= der.


This statement I interpret in the following way: clients are NOT REQUIRE= D to recognize responder if it is using a diffent key for delegation certif= icate as the one which signed certificate being checked for revocation whic= h implies they are REQUIRED to recognize responder if the two keys are the same and consequently it does not matter= what local configuration of OCSP signing authority they use.


I am still confused ...


From: David A. Cooper <= david.cooper@nist.gov>
Sent: Friday, February 13, 2015 11:25 PM
To: Santosh Chokhani; Antanas =8Eivatkauskas; 'pkix@ietf.org'
Subject: Re: [pkix] RFC 6960 section 4.2.2.2. question
 
Actually, this is not what the text is tryin= g to say. The text is not imposing a constraint on relying parties, it is o= nly saying that relying parties are not required to be able to handle the c= ase in which the CA uses different keys to sign the certificate in question and the delegation certificate. A= s noted in RFC 6960, RFC 2560 was very clear that it did not impose such a = constraint.

Here is the quoted text with more context included, which makes it clear th= at the text is not imposing a constraint on relying parties:

   The CA SHOULD use the same is= suing key to issue a delegation
   certificate as that used to sign the certificate bein= g checked for
   revocation.  Systems relying on OCSP responses M= UST recognize a
   delegation certificate as being issued by the CA that= issued the
   certificate in question only if the delegation certif= icate and the
   certificate being checked for revocation were signed = by the same key.

   Note: For backwards compatibility with RFC 2560 [RFC2= 560], it is not
         prohibited to iss= ue a certificate for an Authorized Responder
         using a different= issuing key than the key used to issue the
         certificate being= checked for revocation.  However, such a
         practice is stron= gly discouraged, since clients are not
         required to recog= nize a responder with such a certificate as an
         Authorized Respon= der.

I think the reason that the word "recognize" was used instead of = "accept" is that verifying that the certificate in question and t= he delegation certificate were issued by the same CA is neither necessary n= or sufficient to accept a response. The relying party could accept the response based on its being signed by a locally-trusted r= esponder, and the relying party could reject the response for other reasons= (e.g., response is too old or does not provide information about the certi= ficate in question).

On 02/13/2015 03:59 PM, Santosh Chokhani wrote:

To me it is saying tha= t the relying party must only accept CA-delegated OCSP Responder certificat= e only if both certificates were signed using the same key.  It is try= ing to disambiguate a purported ambiguity in 2560.

 

BTW, the two certifica= tes are: OCSP Responder certificate and the certificate whose status is bei= ng checked by the OCSP Responder.

 

This constraint provid= es simple crypto binding to the delegation.

 

From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Antanas =8Eivatkauskas
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 interpret= ing the following statement in RFC 6960 section 4.2.2.2.  Authorized R= esponders:

 

=93Systems relying on = OCSP responses MUST recognize a

delegation certificate= as being issued by the CA that issued the

certificate in questio= n only if the delegation certificate and the

certificate being chec= ked for revocation were signed by the same key.=94

 

It is not really clear= if it is  a= must for systems relying on OCSP responses in all cases accept a delegatio= n certificate as long as CA uses =93the same issuing key to issue a delegat= ion certificate as that used to sign the certificate being checked for revocation=94, so that the alternative optio= n of providing =93a means of locally configuring one or more OCSP signing a= uthorities and specifying the set of CAs for which each signing authority i= s trusted=94 is irrelevant.

 

Is the word RECOGNIZE = in the excerpt above interchangable with the word ACCEPT?

If not, what is the me= aning of RECOGNIZE, respectively the purpose of such recognition?

 



--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --_000_142391347166874024gyvreglt_-- From nobody Sun Feb 15 06:44:21 2015 Return-Path: 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 C71D31A1EEA for ; Sun, 15 Feb 2015 06:44:17 -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 0Nt9ulJZbU1i for ; Sun, 15 Feb 2015 06:44:13 -0800 (PST) Received: from ipesa1.cygnacom.com (ipesa1.cygnacom.com [65.242.48.200]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3AE01A1C02 for ; Sun, 15 Feb 2015 06:44:12 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssFAEaw4FQKPDLZ/2dsb2JhbABbgkNDUloEwjKFdQKBDkMBAQEBAQF8hAwBAQEELVwCAQUDDQQEAQEoBzIUCQgBAQQBEgiIJQXOYwEBAQEBAQEBAQEBAQEBAQEBAQEBAReKP02BPYM2AQaEJAWfVIwoIoICHIFQPjGBRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,581,1418101200"; d="scan'208,217";a="35951" Received: from unknown (HELO svaexch2.cygnacom.com) ([10.60.50.217]) by ipesa1.cygnacom.com with ESMTP; 15 Feb 2015 09:44:08 -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; Sun, 15 Feb 2015 09:44:09 -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; Sun, 15 Feb 2015 09:44:08 -0500 From: Santosh Chokhani To: =?iso-8859-2?Q?Antanas_=AEivatkauskas?= , "David A. Cooper" , "'pkix@ietf.org'" Thread-Topic: [pkix] RFC 6960 section 4.2.2.2. question Thread-Index: AdBHiL8RA0CkdGMZQ7OvyuRXQLKqlwARONNwAAv4jIAAHYoxAAAuaFFg Date: Sun, 15 Feb 2015 14:44:08 +0000 Message-ID: <88626183739549a1b23028251cc50882@svaexch1.cygnacom.com> References: <02c3425c45974d09861b79e078dd23f1@rcmail.kada.lan> <1628fc57677b4fa4a5ba9b59da1e3a94@svaexch1.cygnacom.com>, <54DE6BD1.9030703@nist.gov> <1423913471668.74024@gyvreg.lt> In-Reply-To: <1423913471668.74024@gyvreg.lt> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.191.89.116] Content-Type: multipart/alternative; boundary="_000_88626183739549a1b23028251cc50882svaexch1cygnacomcom_" MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2015 14:44:18 -0000 --_000_88626183739549a1b23028251cc50882svaexch1cygnacomcom_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Based on Section 2.2 which states "a Trusted Responder whose public key is = trusted by the requestor" I would say that you can still trust a locally co= nfigured OCSP Responder and be compliant with the RFC. From: Antanas =AEivatkauskas [mailto:Antanas.Zivatkauskas@gyvreg.lt] Sent: Saturday, February 14, 2015 6:31 AM To: David A. Cooper; Santosh Chokhani; 'pkix@ietf.org' Subject: Re: [pkix] RFC 6960 section 4.2.2.2. question What I am trying to understand in other words is whether systems or applica= tions that rely on OCSP responses are still free to use local configuration= of OCSP signing authority for the certificate in question even when the OC= SP responses they get contain the delegation certificate which is signed by= the same key as the certificate being checked for revocation? You say that the text is not imposing a constraint on relying parties, mean= ing that the answer to the question above is "Yes". However for me it seems= to conflict with the note which says: such a practice is strongly discouraged, since clients are not required to recognize a responder with such a certificate as an Authorized Responder. This statement I interpret in the following way: clients are NOT REQUIRED t= o recognize responder if it is using a diffent key for delegation certifica= te as the one which signed certificate being checked for revocation which i= mplies they are REQUIRED to recognize responder if the two keys are the sam= e and consequently it does not matter what local configuration of OCSP sign= ing authority they use. I am still confused ... ________________________________ From: David A. Cooper > Sent: Friday, February 13, 2015 11:25 PM To: Santosh Chokhani; Antanas =AEivatkauskas; 'pkix@ietf.org' Subject: Re: [pkix] RFC 6960 section 4.2.2.2. question Actually, this is not what the text is trying to say. The text is not impos= ing a constraint on relying parties, it is only saying that relying parties= are not required to be able to handle the case in which the CA uses differ= ent keys to sign the certificate in question and the delegation certificate= . As noted in RFC 6960, RFC 2560 was very clear that it did not impose such= a constraint. Here is the quoted text with more context included, which makes it clear th= at the text is not imposing a constraint on relying parties: The CA SHOULD use the same issuing key to issue a delegation certificate as that used to sign the certificate being checked for revocation. 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. Note: For backwards compatibility with RFC 2560 [RFC2560], it is not prohibited to issue a certificate for an Authorized Responder using a different issuing key than the key used to issue the certificate being checked for revocation. However, such a practice is strongly discouraged, since clients are not required to recognize a responder with such a certificate as an Authorized Responder. I think the reason that the word "recognize" was used instead of "accept" i= s that verifying that the certificate in question and the delegation certif= icate were issued by the same CA is neither necessary nor sufficient to acc= ept a response. The relying party could accept the response based on its be= ing signed by a locally-trusted responder, and the relying party could reje= ct the response for other reasons (e.g., response is too old or does not pr= ovide information about the certificate in question). On 02/13/2015 03:59 PM, Santosh Chokhani wrote: To me it is saying that the relying party must only accept CA-delegated OCS= P Responder certificate only if both certificates were signed using the sam= e key. It is trying to disambiguate a purported ambiguity in 2560. BTW, the two certificates are: OCSP Responder certificate and the certifica= te 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 =AEivatkausk= as 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 respons= es in all cases accept a delegation certificate as long as CA uses "the sam= e issuing key to issue a delegation certificate as that used to sign the ce= rtificate being checked for revocation", so that the alternative option of = providing "a means of locally configuring one or more OCSP signing authorit= ies and specifying the set of CAs for which each signing authority is trust= ed" is irrelevant. Is the word RECOGNIZE in the excerpt above interchangable with the word ACC= EPT? 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, and is believed to be clean. --_000_88626183739549a1b23028251cc50882svaexch1cygnacomcom_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Based on Section 2.2 w= hich states “a Trusted Responder whose public key is trusted by the r= equestor” I would say that you can still trust a locally configured O= CSP Responder and be compliant with the RFC.

 

From: Antanas =AEivatkauskas [mailto:Antanas.= Zivatkauskas@gyvreg.lt]
Sent: Saturday, February 14, 2015 6:31 AM
To: David A. Cooper; Santosh Chokhani; 'pkix@ietf.org'
Subject: Re: [pkix] RFC 6960 section 4.2.2.2. question

 

W= hat I am trying to understand in other words is whether systems or applicat= ions that rely on OCSP responses are still free to use local configuration = of OCSP signing authority for the certificate in question even when the OCSP responses they get contain the delegation c= ertificate which is signed by the same key as the certificate being checked= for revocation?

You say that the text is not imposing a constraint on relying parties, mean= ing that the answer to the question above is "Yes". However for m= e it seems to conflict with the note which says:

<= o:p> 

      &nb= sp;  such a practice is strongly discouraged, since clients are not
         required to recognize = a responder with such a certificate as an
         Authorized Responder.<= /tt>

<= o:p> 

T= his statement I interpret in the following way: clients are NOT REQUIRED to= recognize responder if it is using a diffent key for delegation certificat= e as the one which signed certificate being checked for revocation which implies they are REQUIRED to recognize respon= der if the two keys are the same and consequently it does not matter what l= ocal configuration of OCSP signing authority they use.

<= o:p> 

I= am still confused ...

<= o:p> 

From: David A. Cooper <david.cooper@nist.gov>
Sent: Friday, February 13, 2015 11:25 PM
To: Santosh Chokhani; Antanas =AEivatkauskas; 'pkix@ietf.org'
Subject: Re: [pkix] RFC 6960 section 4.2.2.2. question

 = ;

Actua= lly, this is not what the text is trying to say. The text is not imposing a= constraint on relying parties, it is only saying that relying parties are = not required to be able to handle the case in which the CA uses different keys to sign the certificate in questi= on and the delegation certificate. As noted in RFC 6960, RFC 2560 was very = clear that it did not impose such a constraint.

Here is the quoted text with more context included, which makes it clear th= at the text is not imposing a constraint on relying parties:

   The CA = SHOULD use the same issuing key to issue a delegation
   certificate as that used to sign the certificate being che= cked for
   revocation.  Systems relying on OCSP responses MUST r= ecognize a
   delegation certificate as being issued by the CA that issu= ed the
   certificate in question only if the delegation certificate= and the
   certificate being checked for revocation were signed by th= e same key.

   Note: For backwards compatibility with RFC 2560 [RFC2560],= it is not
         prohibited to issue a = certificate for an Authorized Responder
         using a different issu= ing key than the key used to issue the
         certificate being chec= ked for revocation.  However, such a
         practice is strongly d= iscouraged, since clients are not
         required to recognize = a responder with such a certificate as an
         Authorized Responder.<= /tt>

I think the reason that the word "recognize" was used instead of = "accept" is that verifying that the certificate in question and t= he delegation certificate were issued by the same CA is neither necessary n= or sufficient to accept a response. The relying party could accept the response based on its being signed by a locally-trusted r= esponder, and the relying party could reject the response for other reasons= (e.g., response is too old or does not provide information about the certi= ficate in question).

On 02/13/2015 03:59 PM, Santosh Chokhani wrote:

To me it is saying tha= t the relying party must only accept CA-delegated OCSP Responder certificat= e only if both certificates were signed using the same key.  It is try= ing to disambiguate a purported ambiguity in 2560.

 

BTW, the two certifica= tes are: OCSP Responder certificate and the certificate whose status is bei= ng checked by the OCSP Responder.=

 

This constraint provid= es simple crypto binding to the delegation.

 

From: pkix [= mailto:pkix-bounces@ietf.org] On Behalf Of Antanas =AEivatkauskas
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 interpret= ing the following statement in RFC 6960 section 4.2.2.2.  Authorized R= esponders:

 

“Systems relying= on OCSP responses MUST recognize a

delegation certificate= as being issued by the CA that issued the

certificate in questio= n only if the delegation certificate and the

certificate being chec= ked 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 a= ccept a delegation certificate as long as CA uses “the same issuing k= ey to issue a delegation certificate as that used to sign the certificate being checked for revocation”, so that the a= lternative 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 me= aning of RECOGNIZE, respectively the purpose of such recognition?

 

=  


--
This message has been scanned for viruses and
dangerous content by MailScanne= r, and is
believed to be clean.

--_000_88626183739549a1b23028251cc50882svaexch1cygnacomcom_-- From nobody Thu Feb 19 17:59:44 2015 Return-Path: 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 1B9D91A8AAE for ; Thu, 19 Feb 2015 02:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 hZ66g9PohZUE for ; Thu, 19 Feb 2015 02:43:47 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 0600B1A8AAC for ; Thu, 19 Feb 2015 02:43:47 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 831BA181D1F; Thu, 19 Feb 2015 02:43:38 -0800 (PST) To: david.cooper@nist.gov, stefans@microsoft.com, stephen.farrell@cs.tcd.ie, sharon.boeyen@entrust.com, housley@vigilsec.com, wpolk@nist.gov, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, kent@bbn.com, stefan@aaa-sec.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150219104338.831BA181D1F@rfc-editor.org> Date: Thu, 19 Feb 2015 02:43:38 -0800 (PST) Archived-At: X-Mailman-Approved-At: Thu, 19 Feb 2015 17:59:43 -0800 Cc: pkix@ietf.org, i.matveychikov@securitycode.ru, rfc-editor@rfc-editor.org Subject: [pkix] [Editorial Errata Reported] RFC5280 (4274) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 10:43:49 -0000 The following errata report has been submitted for RFC5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5280&eid=4274 -------------------------------------- Type: Editorial Reported by: Ilya V. Matveychikov Section: A.1 Original Text ------------- -- Naming attributes of type X520CommonName: -- X520CommonName ::= DirectoryName (SIZE (1..ub-common-name)) ... -- Naming attributes of type X520LocalityName: -- X520LocalityName ::= DirectoryName (SIZE (1..ub-locality-name)) ... -- Naming attributes of type X520StateOrProvinceName: -- X520StateOrProvinceName ::= DirectoryName (SIZE (1..ub-state-name)) ... -- Naming attributes of type X520OrganizationName: -- X520OrganizationName ::= -- DirectoryName (SIZE (1..ub-organization-name)) ... -- Naming attributes of type X520OrganizationalUnitName: -- X520OrganizationalUnitName ::= -- DirectoryName (SIZE (1..ub-organizational-unit-name)) ... -- Naming attributes of type X520Title: -- X520Title ::= DirectoryName (SIZE (1..ub-title)) ... -- Naming attributes of type X520Pseudonym: -- X520Pseudonym ::= DirectoryName (SIZE (1..ub-pseudonym)) Corrected Text -------------- -- Naming attributes of type X520CommonName: -- X520CommonName ::= DirectoryString (SIZE (1..ub-common-name)) ... -- Naming attributes of type X520LocalityName: -- X520LocalityName ::= DirectoryString (SIZE (1..ub-locality-name)) ... -- Naming attributes of type X520StateOrProvinceName: -- X520StateOrProvinceName ::= -- DirectoryString (SIZE (1..ub-state-name)) ... -- Naming attributes of type X520OrganizationName: -- X520OrganizationName ::= -- DirectoryString (SIZE (1..ub-organization-name)) ... -- Naming attributes of type X520OrganizationalUnitName: -- X520OrganizationalUnitName ::= -- DirectoryString (SIZE (1..ub-organizational-unit-name)) ... -- Naming attributes of type X520Title: -- X520Title ::= DirectoryString (SIZE (1..ub-title)) ... -- Naming attributes of type X520Pseudonym: -- X520Pseudonym ::= DirectoryString (SIZE (1..ub-pseudonym)) Notes ----- Appendix B. ASN.1 Notes says that: For many of the attribute types defined in [X.520], the AttributeValue uses the DirectoryString type. Of the attributes specified in Appendix A, the name, surname, givenName, initials, generationQualifier, commonName, localityName, stateOrProvinceName, organizationName, organizationalUnitName, title, and pseudonym attributes all use the DirectoryString type. X.520 uses a parameterized type definition [X.683] of DirectoryString to specify the syntax for each of these attributes. The parameter is used to indicate the maximum string length allowed for the attribute. In Appendix A, in order to avoid the use of parameterized type definitions, the DirectoryString type is written in its expanded form for the definition of each of these attribute types. So, the ASN.1 in Appendix A describes the syntax for each of these attributes as being a CHOICE of TeletexString, PrintableString, UniversalString, UTF8String, and BMPString, with the appropriate constraints on the string length applied to each of the types in the CHOICE, rather than using the ASN.1 type DirectoryString to describe the syntax. There is nothing about DirectoryName type here. So comments in ASN.1 in A.1 are wrong and DirectoryName should be fixed to DirectoryString. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5280 (draft-ietf-pkix-rfc3280bis-11) -------------------------------------- Title : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Publication Date : May 2008 Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From nobody Thu Feb 19 17:59:46 2015 Return-Path: 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 E0FEB1A1ADB for ; Thu, 19 Feb 2015 17:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_NONE=-0.0001] 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 DIr8ViFrTiV7 for ; Thu, 19 Feb 2015 17:33:17 -0800 (PST) Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [194.9.95.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E95931A1AC2 for ; Thu, 19 Feb 2015 17:33:16 -0800 (PST) Received: from s314.loopia.se (localhost [127.0.0.1]) by s314.loopia.se (Postfix) with ESMTP id 971E216181B3 for ; Fri, 20 Feb 2015 02:33:13 +0100 (CET) X-Loopia-Auth: user X-Loopia-Originating-IP: 90.228.164.127 X-Loopia-User: stefan@fiddler.nu Received: from s500.loopia.se (unknown [172.21.200.98]) by s314.loopia.se (Postfix) with ESMTP id 799DE1FFE33F; Fri, 20 Feb 2015 02:33:13 +0100 (CET) Received: from s406.loopia.se (unknown [172.21.200.105]) by s500.loopia.se (Postfix) with ESMTP id 6F5E996FAEE; Fri, 20 Feb 2015 02:33:13 +0100 (CET) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s499.loopia.se ([172.21.200.105]) by s406.loopia.se (s406.loopia.se [172.21.200.136]) (amavisd-new, port 10024) with LMTP id a0nhJfrLqgYj; Fri, 20 Feb 2015 02:33:12 +0100 (CET) Received: from [10.0.1.53] (unknown [90.228.164.127]) (Authenticated sender: stefan@fiddler.nu) by s499.loopia.se (Postfix) with ESMTPSA id 32368B1F7FE; Fri, 20 Feb 2015 02:33:10 +0100 (CET) User-Agent: Microsoft-MacOutlook/14.4.7.141117 Date: Fri, 20 Feb 2015 02:33:08 +0100 From: Stefan Santesson To: RFC Errata System , , , , , , , , Message-Id: Thread-Topic: [Editorial Errata Reported] RFC5280 (4274) References: <20150219104338.831BA181D1F@rfc-editor.org> In-Reply-To: <20150219104338.831BA181D1F@rfc-editor.org> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 19 Feb 2015 17:59:43 -0800 Cc: pkix@ietf.org, i.matveychikov@securitycode.ru Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (4274) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 01:33:20 -0000 These size limitations are gone in the current edition of X.520 In X.520 2001 edition, surname as example was defined as: surname ATTRIBUTE ::= { SUBTYPE OF name WITH SYNTAX DirectoryString{ub-surname} ID id-at-surname } Where Directory string is size limited by the upper bound ub-surname ub-surname INTEGER ::= 64 In the current edition of X.520 (102012) the definition is instead: surname ATTRIBUTE ::= { SUBTYPE OF name WITH SYNTAX UnboundedDirectoryString LDAP-SYNTAX directoryString.&id LDAP-NAME {"sn"} ID id-at-surname } Where UnboundedDirectoryString no longer is bounded to the old ub-surname size limit. The same is true for all attributes listed in this errata. /Stefan On 19/02/15 11:43, "RFC Errata System" wrote: >The following errata report has been submitted for RFC5280, >"Internet X.509 Public Key Infrastructure Certificate and Certificate >Revocation List (CRL) Profile". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=5280&eid=4274 > >-------------------------------------- >Type: Editorial >Reported by: Ilya V. Matveychikov > >Section: A.1 > >Original Text >------------- >-- Naming attributes of type X520CommonName: >-- X520CommonName ::= DirectoryName (SIZE (1..ub-common-name)) > >... > >-- Naming attributes of type X520LocalityName: >-- X520LocalityName ::= DirectoryName (SIZE (1..ub-locality-name)) > >... > >-- Naming attributes of type X520StateOrProvinceName: >-- X520StateOrProvinceName ::= DirectoryName (SIZE (1..ub-state-name)) > >... > >-- Naming attributes of type X520OrganizationName: >-- X520OrganizationName ::= >-- DirectoryName (SIZE (1..ub-organization-name)) > >... > >-- Naming attributes of type X520OrganizationalUnitName: >-- X520OrganizationalUnitName ::= >-- DirectoryName (SIZE (1..ub-organizational-unit-name)) > >... > >-- Naming attributes of type X520Title: >-- X520Title ::= DirectoryName (SIZE (1..ub-title)) > >... > >-- Naming attributes of type X520Pseudonym: >-- X520Pseudonym ::= DirectoryName (SIZE (1..ub-pseudonym)) > > >Corrected Text >-------------- >-- Naming attributes of type X520CommonName: >-- X520CommonName ::= DirectoryString (SIZE (1..ub-common-name)) > >... > >-- Naming attributes of type X520LocalityName: >-- X520LocalityName ::= DirectoryString (SIZE (1..ub-locality-name)) > >... > >-- Naming attributes of type X520StateOrProvinceName: >-- X520StateOrProvinceName ::= >-- DirectoryString (SIZE (1..ub-state-name)) > >... > >-- Naming attributes of type X520OrganizationName: >-- X520OrganizationName ::= >-- DirectoryString (SIZE (1..ub-organization-name)) > >... > >-- Naming attributes of type X520OrganizationalUnitName: >-- X520OrganizationalUnitName ::= >-- DirectoryString (SIZE (1..ub-organizational-unit-name)) > >... > >-- Naming attributes of type X520Title: >-- X520Title ::= DirectoryString (SIZE (1..ub-title)) > >... > >-- Naming attributes of type X520Pseudonym: >-- X520Pseudonym ::= DirectoryString (SIZE (1..ub-pseudonym)) > > >Notes >----- >Appendix B. ASN.1 Notes says that: > > For many of the attribute types defined in [X.520], the > AttributeValue uses the DirectoryString type. Of the attributes > specified in Appendix A, the name, surname, givenName, initials, > generationQualifier, commonName, localityName, stateOrProvinceName, > organizationName, organizationalUnitName, title, and pseudonym > attributes all use the DirectoryString type. X.520 uses a > parameterized type definition [X.683] of DirectoryString to specify > the syntax for each of these attributes. The parameter is used to > indicate the maximum string length allowed for the attribute. In > Appendix A, in order to avoid the use of parameterized type > definitions, the DirectoryString type is written in its expanded form > for the definition of each of these attribute types. So, the ASN.1 > in Appendix A describes the syntax for each of these attributes as > being a CHOICE of TeletexString, PrintableString, UniversalString, > UTF8String, and BMPString, with the appropriate constraints on the > string length applied to each of the types in the CHOICE, rather than > using the ASN.1 type DirectoryString to describe the syntax. > >There is nothing about DirectoryName type here. So comments in ASN.1 in >A.1 are wrong and DirectoryName should be fixed to DirectoryString. > >Instructions: >------------- >This erratum is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party (IESG) >can log in to change the status and edit the report, if necessary. > >-------------------------------------- >RFC5280 (draft-ietf-pkix-rfc3280bis-11) >-------------------------------------- >Title : Internet X.509 Public Key Infrastructure >Certificate and Certificate Revocation List (CRL) Profile >Publication Date : May 2008 >Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. >Housley, W. Polk >Category : PROPOSED STANDARD >Source : Public-Key Infrastructure (X.509) >Area : Security >Stream : IETF >Verifying Party : IESG > From nobody Fri Feb 20 10:43:32 2015 Return-Path: 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 83E781A0074 for ; Fri, 20 Feb 2015 10:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 2RdjV5LkqtEc for ; Fri, 20 Feb 2015 10:43:28 -0800 (PST) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CEDE1A3BA9 for ; Fri, 20 Feb 2015 10:43:23 -0800 (PST) Received: by qcvp6 with SMTP id p6so2180893qcv.9 for ; Fri, 20 Feb 2015 10:43:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-type:content-transfer-encoding; bh=IUxYJTZBmrWCtw1Hk+tMHbwNxTKFDYsblJZH7g7Gvq8=; b=YjwXgQuab9jLxNrxZO0AHaUS1VQdmCXedmuXucr1D4cClP5Eu8mUF4ZAPdFn4xFPdp R9sqdYXovDl+OhQbqbM5ckHZJe8EKjwKdksHZIRySQzwrq8Pl49hJFao/xgJAdSIpGJ4 7YYSL7HOCqf8/fqZFMbicnUfHS77ctv97W7O+HcfGpnnRhfPQ6FvBEgzKRJc0Zm86UXr 6uvEIJjMh/klGjfvPSiyPpo+CJK2NVBSdZ0lsaLoi1wiSKvV/JHG4mUq8gYnZoyyZ5SH iaaCDq8a/WYr2i9Cbc3NpIrKyo92p+o/jdDN3ujPB6jiyykbRs/zIiseV9cYC8+kSfAX aq/A== X-Gm-Message-State: ALoCoQk8pBJVSyv5IUkmWe9R+me6z1c7MhG0QTihpReKFXHVdZ/x+HDBofV8rvrh520kBhIrHaqU X-Received: by 10.140.216.201 with SMTP id m192mr27679005qhb.26.1424457802660; Fri, 20 Feb 2015 10:43:22 -0800 (PST) Received: from [192.168.2.27] (pool-96-255-230-90.washdc.fios.verizon.net. [96.255.230.90]) by mx.google.com with ESMTPSA id 7sm12325978qhv.8.2015.02.20.10.43.21 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 20 Feb 2015 10:43:22 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.4.7.141117 Date: Fri, 20 Feb 2015 13:43:19 -0500 From: Carl Wallace To: Message-ID: Thread-Topic: [pkix] [Editorial Errata Reported] RFC5280 (4274) Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (4274) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 18:43:30 -0000 Is this really an errata? Seems more like an invitation to interoperability problems. Same issues will apply to 5912 too if this route is pursued. On 2/19/15, 8:33 PM, "Stefan Santesson" wrote: >These size limitations are gone in the >current edition of X.520 > >In X.520 2001 edition, surname as example was defined as: > >surname ATTRIBUTE ::=3D { >SUBTYPE OF name >WITH SYNTAX DirectoryString{ub-surname} >ID id-at-surname >} > > >Where Directory string is size limited by the upper bound ub-surname > >ub-surname =20 >INTEGER ::=3D 64 > >In the current edition of X.520 (102012) the definition is instead: > >surname ATTRIBUTE ::=3D { >SUBTYPE OF name >WITH SYNTAX UnboundedDirectoryString >LDAP-SYNTAX directoryString.&id >LDAP-NAME {"sn"} >ID id-at-surname >} > > >Where UnboundedDirectoryString no longer is bounded to the old ub-surname >size limit. > >The same is true for all attributes listed in this errata. > >/Stefan > > > >On 19/02/15 11:43, "RFC Errata System" wrote: > >>The following errata report has been submitted for RFC5280, >>"Internet X.509 Public Key Infrastructure Certificate and Certificate >>Revocation List (CRL) Profile". >> >>-------------------------------------- >>You may review the report below and at: >>http://www.rfc-editor.org/errata_search.php?rfc=3D5280&eid=3D4274 >> >>-------------------------------------- >>Type: Editorial >>Reported by: Ilya V. Matveychikov >> >>Section: A.1 >> >>Original Text >>------------- >>-- Naming attributes of type X520CommonName: >>-- X520CommonName ::=3D DirectoryName (SIZE (1..ub-common-name)) >> >>... >> >>-- Naming attributes of type X520LocalityName: >>-- X520LocalityName ::=3D DirectoryName (SIZE (1..ub-locality-name)) >> >>... >> >>-- Naming attributes of type X520StateOrProvinceName: >>-- X520StateOrProvinceName ::=3D DirectoryName (SIZE (1..ub-state-name)) >> >>... >> >>-- Naming attributes of type X520OrganizationName: >>-- X520OrganizationName ::=3D >>-- DirectoryName (SIZE (1..ub-organization-name)) >> >>... >> >>-- Naming attributes of type X520OrganizationalUnitName: >>-- X520OrganizationalUnitName ::=3D >>-- DirectoryName (SIZE (1..ub-organizational-unit-name)) >> >>... >> >>-- Naming attributes of type X520Title: >>-- X520Title ::=3D DirectoryName (SIZE (1..ub-title)) >> >>... >> >>-- Naming attributes of type X520Pseudonym: >>-- X520Pseudonym ::=3D DirectoryName (SIZE (1..ub-pseudonym)) >> >> >>Corrected Text >>-------------- >>-- Naming attributes of type X520CommonName: >>-- X520CommonName ::=3D DirectoryString (SIZE (1..ub-common-name)) >> >>... >> >>-- Naming attributes of type X520LocalityName: >>-- X520LocalityName ::=3D DirectoryString (SIZE (1..ub-locality-name)) >> >>... >> >>-- Naming attributes of type X520StateOrProvinceName: >>-- X520StateOrProvinceName ::=3D >>-- DirectoryString (SIZE (1..ub-state-name)) >> >>... >> >>-- Naming attributes of type X520OrganizationName: >>-- X520OrganizationName ::=3D >>-- DirectoryString (SIZE (1..ub-organization-name)) >> >>... >> >>-- Naming attributes of type X520OrganizationalUnitName: >>-- X520OrganizationalUnitName ::=3D >>-- DirectoryString (SIZE (1..ub-organizational-unit-name)) >> >>... >> >>-- Naming attributes of type X520Title: >>-- X520Title ::=3D DirectoryString (SIZE (1..ub-title)) >> >>... >> >>-- Naming attributes of type X520Pseudonym: >>-- X520Pseudonym ::=3D DirectoryString (SIZE (1..ub-pseudonym)) >> >> >>Notes >>----- >>Appendix B. ASN.1 Notes says that: >> >> For many of the attribute types defined in [X.520], the >> AttributeValue uses the DirectoryString type. Of the attributes >> specified in Appendix A, the name, surname, givenName, initials, >> generationQualifier, commonName, localityName, stateOrProvinceName, >> organizationName, organizationalUnitName, title, and pseudonym >> attributes all use the DirectoryString type. X.520 uses a >> parameterized type definition [X.683] of DirectoryString to specify >> the syntax for each of these attributes. The parameter is used to >> indicate the maximum string length allowed for the attribute. In >> Appendix A, in order to avoid the use of parameterized type >> definitions, the DirectoryString type is written in its expanded form >> for the definition of each of these attribute types. So, the ASN.1 >> in Appendix A describes the syntax for each of these attributes as >> being a CHOICE of TeletexString, PrintableString, UniversalString, >> UTF8String, and BMPString, with the appropriate constraints on the >> string length applied to each of the types in the CHOICE, rather than >> using the ASN.1 type DirectoryString to describe the syntax. >> >>There is nothing about DirectoryName type here. So comments in ASN.1 in >>A.1 are wrong and DirectoryName should be fixed to DirectoryString. >> >>Instructions: >>------------- >>This erratum is currently posted as "Reported". If necessary, please >>use "Reply All" to discuss whether it should be verified or >>rejected. When a decision is reached, the verifying party (IESG) >>can log in to change the status and edit the report, if necessary. >> >>-------------------------------------- >>RFC5280 (draft-ietf-pkix-rfc3280bis-11) >>-------------------------------------- >>Title : Internet X.509 Public Key Infrastructure >>Certificate and Certificate Revocation List (CRL) Profile >>Publication Date : May 2008 >>Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. >>Housley, W. Polk >>Category : PROPOSED STANDARD >>Source : Public-Key Infrastructure (X.509) >>Area : Security >>Stream : IETF >>Verifying Party : IESG >> > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From nobody Sat Feb 21 13:50:49 2015 Return-Path: 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 006FA1A00B5 for ; Sat, 21 Feb 2015 13:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 y7On812F6Pka for ; Sat, 21 Feb 2015 13:50:46 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8651A00B0 for ; Sat, 21 Feb 2015 13:50:46 -0800 (PST) Received: by iecrl12 with SMTP id rl12so15656240iec.2 for ; Sat, 21 Feb 2015 13:50:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=Q1YUV/nQ0bFuhWocKMIOET7Mj6FV65kWqVI6z6SJF7I=; b=BKPJdReakWzzPDIZjFUnQEEbWq0B2oTiGDuxCmUe4Dvdzef1Wa5aAEr6mXHK+on6j2 XnGE955vwxYrhEN95HIONKE8vdxpJI6qM/Tkt43h2eVJYWFz1p5rqYERva+QGMROxDO+ EhtDtCq/yyr6J4mKo0Y5AQ0b40n9ZAQaTpQ4leO7ai9LHD6hzmYLYG2wQMypLozh8NgJ GrhQ6j0TIYLsqllXls78ThyYmnFDx/SJCEQD1OO+zbflZUgO0bvozAgac/++NMFwg1C9 oT6Npyar0lcF3JDjXskVSzW4OvM68gcC1DTIr3/hdn6uzzDVUzVJf/nEHVcse/4Mkw9B 7kyw== MIME-Version: 1.0 X-Received: by 10.42.249.2 with SMTP id mi2mr4496054icb.36.1424555445648; Sat, 21 Feb 2015 13:50:45 -0800 (PST) Received: by 10.36.81.15 with HTTP; Sat, 21 Feb 2015 13:50:45 -0800 (PST) Date: Sat, 21 Feb 2015 16:50:45 -0500 Message-ID: From: Jeffrey Walton To: PKIX Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [pkix] How to enforce domain constraints on intermediate CA? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 21:50:48 -0000 I have an internal PKI, and I'm trying to figure out how to apply a policy that constrains names to the one used internally. I've read through RFCs like 5280, but its not clear to me how to do it. How does one apply a domain policy constraint to an intermediate CA under PKIX? From nobody Sat Feb 21 14:18:00 2015 Return-Path: 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 009A41A00F4 for ; Sat, 21 Feb 2015 14:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 IGKgUJWAPRaX for ; Sat, 21 Feb 2015 14:17:58 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9801A00F3 for ; Sat, 21 Feb 2015 14:17:58 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id h15so10677189igd.4 for ; Sat, 21 Feb 2015 14:17:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kzezk9fMJt/2J2Qnkdys3C0dbj1uRGCHbk4wVIiHDe0=; b=CwtrnQfCeXZIXWvKEhhqRUMmu66Ly9TJo8kgEzgmD85Cp6amSGK0V63Isw1R1qTrpm 2UHOLF2+CBbLw5f5FIK8fuZAFziMwU9EAFfOf4I+KWrPrL/VdeZ2MOv2Y/t00pcl+Nlv K+cWcYNxp9VUQeGMn6qxepJFqYCRnfwZxho5hnBXlwGX1rc+Z56q9owRAolzm7Nydh9P AS2q2unhWWxA1GnxakU9peKxKXbOyrXgRJonQI2CfUuCc0ss3QndtklCd8T5v3ZdID0K euBAL79IOvjNpL7Jz8HH6ihdH1j4apxz4OQlhixmoRoDlTf3jtbnz2K2eY3Md7NkZKoW kyyA== MIME-Version: 1.0 X-Received: by 10.107.35.140 with SMTP id j134mr5514791ioj.11.1424557077623; Sat, 21 Feb 2015 14:17:57 -0800 (PST) Received: by 10.36.81.15 with HTTP; Sat, 21 Feb 2015 14:17:57 -0800 (PST) In-Reply-To: <20150202123454.4BD661B14C@ld9781.wdf.sap.corp> References: <20150202123454.4BD661B14C@ld9781.wdf.sap.corp> Date: Sat, 21 Feb 2015 17:17:57 -0500 Message-ID: From: Jeffrey Walton To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: PKIX Subject: Re: [pkix] RFC 6125, Server Identity Check and insecure DNS lookup X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 22:18:00 -0000 Thanks Martin. > The two characteristics that DNSSEC provides (according to its own > specification) is data origin authentication and data integrity protection. > But using DNSSEC does not increase the trustworthyness of the data > conveyed through DNS. Isn't this the equivalent problem issuing certificates via domain validation from the WHOIS database? That is, the data can be sent securely (for some definition of secure), but we're not sure the data itself is accurate? If they are equivalent, then why do we accept certificates based on domain validation from the WHOIS database? It seems to me both should be accepted, or both should be rejected. Jeff On Mon, Feb 2, 2015 at 7:34 AM, Martin Rex wrote: > Jeffrey Walton wrote: >> What does RFC 6125 mean when they say the following: >> >> 2.4. Server Identity Check >> >> o The client MUST use the server hostname it used to open the >> connection as the value to compare against the server name as >> expressed in the server certificate. The client MUST NOT use any >> form of the server hostname derived from an insecure remote source >> (e.g., insecure DNS lookup). CNAME canonicalization is not done. >> >> Is this saying that all DNS is considered insecure, and only the >> original hostname used by the client should be used for validation? >> >> Or is it saying its OK to follow the CNAME aliases when using a >> "secure" DNS, like DNSSEC? > > > The difference here is "lack of trust" in the data contained in DNS. > > The two characteristics that DNSSEC provides (according to its own > specification) is data origin authentication and data integrity protection. > But using DNSSEC does not increase the trustworthyness of the data > conveyed through DNS. > > Similarily using HTTPS rather than HTTP for searching Google will provide > only data origin authentication and data integrity protection for the > search results, but will not increase the trustworthyness of the > search results (there is no trust). From nobody Sat Feb 21 16:14:12 2015 Return-Path: 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 E522A1A00BD for ; Sat, 21 Feb 2015 16:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 3aMMJbN5GmO0 for ; Sat, 21 Feb 2015 16:14:09 -0800 (PST) Received: from ipesa1.cygnacom.com (ipesa1.cygnacom.com [65.242.48.200]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E701A0007 for ; Sat, 21 Feb 2015 16:14:08 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FACUe6VQKPDLY/2dsb2JhbABagwZSWgTDAAqFcQKBGEMBAQEBAQF8hA8BAQEEAQEBNzQXBAIBBQMNBAQBAR8JBycLFAkIAgQBEgiIJwUI0jkBAQEBAQEEAQEBAQEBARcEixOEdQaEJQWaMIVZC4w0IoNuPjGBRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,622,1418101200"; d="scan'208";a="41959" Received: from unknown (HELO svaexch1.cygnacom.com) ([10.60.50.216]) by ipesa1.cygnacom.com with ESMTP; 21 Feb 2015 19:14:08 -0500 Received: from svaexch1.cygnacom.com (10.60.50.216) by svaexch1.cygnacom.com (10.60.50.216) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sat, 21 Feb 2015 19:14:06 -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; Sat, 21 Feb 2015 19:14:06 -0500 From: Santosh Chokhani To: "noloader@gmail.com" , PKIX Thread-Topic: [pkix] How to enforce domain constraints on intermediate CA? Thread-Index: AQHQTiB1+9Vo4nl2ak6fBjpII7p2z5z7yfuQ Date: Sun, 22 Feb 2015 00:14:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.45.170.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [pkix] How to enforce domain constraints on intermediate CA? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 00:14:11 -0000 I would think this can be done via using name constraints extension and ass= erting appropriate DNS name spaces -----Original Message----- From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Jeffrey Walton Sent: Saturday, February 21, 2015 4:51 PM To: PKIX Subject: [pkix] How to enforce domain constraints on intermediate CA? I have an internal PKI, and I'm trying to figure out how to apply a policy = that constrains names to the one used internally. I've read through RFCs li= ke 5280, but its not clear to me how to do it. How does one apply a domain policy constraint to an intermediate CA under P= KIX? _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From nobody Sat Feb 21 17:14:30 2015 Return-Path: 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 C38E01A016A for ; Sat, 21 Feb 2015 17:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 njWhOV1HfRqL for ; Sat, 21 Feb 2015 17:14:26 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E5BD1A0018 for ; Sat, 21 Feb 2015 17:14:26 -0800 (PST) Received: by iecrp18 with SMTP id rp18so16173281iec.1 for ; Sat, 21 Feb 2015 17:14:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wxPuKBPXOpa+JiGQE8FtwQVa+HcLGljB8O5GgNsuf70=; b=Da2kJJIrYthqcVBTaNCsxnLgJ2ZmQp1gKyP8b0AJ9fEV2i9AI4klckDbLR5kmjmn27 QXhUycSvqm+FurGIoh0SgwMZweGPWR6xjBt3TrCJdbSkuEykLh1Ke9LLBqdFrTV2YL1R 3/LZ+CzEcJ4OdlwY6DlplX0Q4Z80faGBjq76HUP/T9y+C/pxxgWwNWJMtL/HxpRMcMtW CUBB4bFfReSNChEuaj/luiztXF5HJrfiuSCEvW6IfAeQxMA0+t/dbwWyygBzQhBRJuDT BMGZy4cbOOUo6f6lh+qJ63hR4DCmi64npI/MVQ8pi+oRzEcnLyDU81i41LefA5+bncr+ 7mAg== MIME-Version: 1.0 X-Received: by 10.107.131.224 with SMTP id n93mr6054425ioi.66.1424567665582; Sat, 21 Feb 2015 17:14:25 -0800 (PST) Received: by 10.36.81.15 with HTTP; Sat, 21 Feb 2015 17:14:25 -0800 (PST) In-Reply-To: References: Date: Sat, 21 Feb 2015 20:14:25 -0500 Message-ID: From: Jeffrey Walton To: Santosh Chokhani Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: PKIX Subject: Re: [pkix] How to enforce domain constraints on intermediate CA? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 01:14:28 -0000 On Sat, Feb 21, 2015 at 7:14 PM, Santosh Chokhani wrote: > I would think this can be done via using name constraints extension and asserting appropriate DNS name spaces Ah, thanks. I was looking for a policy object, and not an extension. Sorry about that. Jeff > -----Original Message----- > From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Jeffrey Walton > Sent: Saturday, February 21, 2015 4:51 PM > To: PKIX > Subject: [pkix] How to enforce domain constraints on intermediate CA? > > I have an internal PKI, and I'm trying to figure out how to apply a policy that constrains names to the one used internally. I've read through RFCs like 5280, but its not clear to me how to do it. > > How does one apply a domain policy constraint to an intermediate CA under PKIX? > From nobody Mon Feb 23 07:20:54 2015 Return-Path: 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 5C5A01A1B70 for ; Thu, 19 Feb 2015 18:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.601 X-Spam-Level: X-Spam-Status: No, score=-4.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 CEtgRESjUbpN for ; Thu, 19 Feb 2015 18:31:27 -0800 (PST) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6931A1AAA for ; Thu, 19 Feb 2015 18:31:26 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id f12so10090537qad.9 for ; Thu, 19 Feb 2015 18:31:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version:content-type:content-transfer-encoding; bh=3yq4Dp4SBtHzbtPeGZVj0zya4xKogP1/rlozxoo5KGM=; b=OXCtokk+YcYhz4w30+QeF6WK3mz7hu851Ravz9wCVoNJKmB9HdU0TcowfH3dgC+MRW CdYMRh8LXuvsdlzHoWkTy9r7oWvLrD2Ft5bGtPHOiKC1ANFZCfH1c1CLorkiLid8tUGq 31Ell+vkemNXvYJIChCj0JeYbQzzr+zv3XjdqSeFTLDPFsQX5zbn7CB1pqMgzKfLEhsK oAVHJHWs0R7dopcWqLatP8GXQlZVM4/TpNzpFa5/D8XHiMUqmHLm7vGWAZBpvzbLgPBO c5laJNRXFziKyl741ubkExxF1lyGljXQv+/axhizLp85cyAi/cOucF6l1gIgpQm9oDt7 cAsg== X-Gm-Message-State: ALoCoQkLW1FzolaDpDom4Wm43MiRevupkW8fNsgty+icTRKOruXBZ1b61z0Fx4QAy9LOIVG5IM0+ X-Received: by 10.140.96.55 with SMTP id j52mr18324972qge.92.1424399485623; Thu, 19 Feb 2015 18:31:25 -0800 (PST) Received: from [192.168.2.246] (pool-96-255-230-90.washdc.fios.verizon.net. [96.255.230.90]) by mx.google.com with ESMTPSA id k5sm20977655qgf.46.2015.02.19.18.31.14 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 19 Feb 2015 18:31:25 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.4.7.141117 Date: Thu, 19 Feb 2015 21:31:08 -0500 From: Carl Wallace To: Stefan Santesson , RFC Errata System , , , , , , , , Message-ID: Thread-Topic: [pkix] [Editorial Errata Reported] RFC5280 (4274) Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: X-Mailman-Approved-At: Mon, 23 Feb 2015 07:20:52 -0800 Cc: pkix@ietf.org, i.matveychikov@securitycode.ru Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (4274) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 02:31:29 -0000 Is this really an errata? Seems more like an invitation to interoperability problems. Same issues will apply to 5912 too is this route is pursued. On 2/19/15, 8:33 PM, "Stefan Santesson" wrote: >These size limitations are gone in the >current edition of X.520 > >In X.520 2001 edition, surname as example was defined as: > >surname ATTRIBUTE ::= { >SUBTYPE OF name >WITH SYNTAX DirectoryString{ub-surname} >ID id-at-surname >} > > >Where Directory string is size limited by the upper bound ub-surname > >ub-surname >INTEGER ::= 64 > >In the current edition of X.520 (102012) the definition is instead: > >surname ATTRIBUTE ::= { >SUBTYPE OF name >WITH SYNTAX UnboundedDirectoryString >LDAP-SYNTAX directoryString.&id >LDAP-NAME {"sn"} >ID id-at-surname >} > > >Where UnboundedDirectoryString no longer is bounded to the old ub-surname >size limit. > >The same is true for all attributes listed in this errata. > >/Stefan > > > >On 19/02/15 11:43, "RFC Errata System" wrote: > >>The following errata report has been submitted for RFC5280, >>"Internet X.509 Public Key Infrastructure Certificate and Certificate >>Revocation List (CRL) Profile". >> >>-------------------------------------- >>You may review the report below and at: >>http://www.rfc-editor.org/errata_search.php?rfc=5280&eid=4274 >> >>-------------------------------------- >>Type: Editorial >>Reported by: Ilya V. Matveychikov >> >>Section: A.1 >> >>Original Text >>------------- >>-- Naming attributes of type X520CommonName: >>-- X520CommonName ::= DirectoryName (SIZE (1..ub-common-name)) >> >>... >> >>-- Naming attributes of type X520LocalityName: >>-- X520LocalityName ::= DirectoryName (SIZE (1..ub-locality-name)) >> >>... >> >>-- Naming attributes of type X520StateOrProvinceName: >>-- X520StateOrProvinceName ::= DirectoryName (SIZE (1..ub-state-name)) >> >>... >> >>-- Naming attributes of type X520OrganizationName: >>-- X520OrganizationName ::= >>-- DirectoryName (SIZE (1..ub-organization-name)) >> >>... >> >>-- Naming attributes of type X520OrganizationalUnitName: >>-- X520OrganizationalUnitName ::= >>-- DirectoryName (SIZE (1..ub-organizational-unit-name)) >> >>... >> >>-- Naming attributes of type X520Title: >>-- X520Title ::= DirectoryName (SIZE (1..ub-title)) >> >>... >> >>-- Naming attributes of type X520Pseudonym: >>-- X520Pseudonym ::= DirectoryName (SIZE (1..ub-pseudonym)) >> >> >>Corrected Text >>-------------- >>-- Naming attributes of type X520CommonName: >>-- X520CommonName ::= DirectoryString (SIZE (1..ub-common-name)) >> >>... >> >>-- Naming attributes of type X520LocalityName: >>-- X520LocalityName ::= DirectoryString (SIZE (1..ub-locality-name)) >> >>... >> >>-- Naming attributes of type X520StateOrProvinceName: >>-- X520StateOrProvinceName ::= >>-- DirectoryString (SIZE (1..ub-state-name)) >> >>... >> >>-- Naming attributes of type X520OrganizationName: >>-- X520OrganizationName ::= >>-- DirectoryString (SIZE (1..ub-organization-name)) >> >>... >> >>-- Naming attributes of type X520OrganizationalUnitName: >>-- X520OrganizationalUnitName ::= >>-- DirectoryString (SIZE (1..ub-organizational-unit-name)) >> >>... >> >>-- Naming attributes of type X520Title: >>-- X520Title ::= DirectoryString (SIZE (1..ub-title)) >> >>... >> >>-- Naming attributes of type X520Pseudonym: >>-- X520Pseudonym ::= DirectoryString (SIZE (1..ub-pseudonym)) >> >> >>Notes >>----- >>Appendix B. ASN.1 Notes says that: >> >> For many of the attribute types defined in [X.520], the >> AttributeValue uses the DirectoryString type. Of the attributes >> specified in Appendix A, the name, surname, givenName, initials, >> generationQualifier, commonName, localityName, stateOrProvinceName, >> organizationName, organizationalUnitName, title, and pseudonym >> attributes all use the DirectoryString type. X.520 uses a >> parameterized type definition [X.683] of DirectoryString to specify >> the syntax for each of these attributes. The parameter is used to >> indicate the maximum string length allowed for the attribute. In >> Appendix A, in order to avoid the use of parameterized type >> definitions, the DirectoryString type is written in its expanded form >> for the definition of each of these attribute types. So, the ASN.1 >> in Appendix A describes the syntax for each of these attributes as >> being a CHOICE of TeletexString, PrintableString, UniversalString, >> UTF8String, and BMPString, with the appropriate constraints on the >> string length applied to each of the types in the CHOICE, rather than >> using the ASN.1 type DirectoryString to describe the syntax. >> >>There is nothing about DirectoryName type here. So comments in ASN.1 in >>A.1 are wrong and DirectoryName should be fixed to DirectoryString. >> >>Instructions: >>------------- >>This erratum is currently posted as "Reported". If necessary, please >>use "Reply All" to discuss whether it should be verified or >>rejected. When a decision is reached, the verifying party (IESG) >>can log in to change the status and edit the report, if necessary. >> >>-------------------------------------- >>RFC5280 (draft-ietf-pkix-rfc3280bis-11) >>-------------------------------------- >>Title : Internet X.509 Public Key Infrastructure >>Certificate and Certificate Revocation List (CRL) Profile >>Publication Date : May 2008 >>Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. >>Housley, W. Polk >>Category : PROPOSED STANDARD >>Source : Public-Key Infrastructure (X.509) >>Area : Security >>Stream : IETF >>Verifying Party : IESG >> > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From nobody Mon Feb 23 07:20:55 2015 Return-Path: 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 C47921A8789 for ; Fri, 20 Feb 2015 08:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.151 X-Spam-Level: X-Spam-Status: No, score=-5.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 dNcET6n3SSSi for ; Fri, 20 Feb 2015 08:03:21 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82B801A854B for ; Fri, 20 Feb 2015 08:03:21 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3716F2AF41; Fri, 20 Feb 2015 17:03:18 +0100 (CET) X-purgate-ID: 152705::1424448199-000007DF-77195847/0/0 X-purgate-size: 1023 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 11D3542F06; Fri, 20 Feb 2015 17:03:18 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 094B11B1C3; Fri, 20 Feb 2015 17:03:18 +0100 (CET) In-Reply-To: To: Stefan Santesson Date: Fri, 20 Feb 2015 17:03:18 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150220160318.094B11B1C3@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: X-Mailman-Approved-At: Mon, 23 Feb 2015 07:20:52 -0800 Cc: stefans@microsoft.com, i.matveychikov@securitycode.ru, pkix@ietf.org, RFC Errata System Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (4274) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 16:03:23 -0000 Stefan Santesson wrote: > > These size limitations are gone in the current edition of X.520 > > In X.520 2001 edition, surname as example was defined as: > > Where Directory string is size limited by the upper bound ub-surname > > ub-surname > INTEGER ::= 64 > > In the current edition of X.520 (102012) the definition is instead: > > Where UnboundedDirectoryString no longer is bounded to the old ub-surname > size limit. > > The same is true for all attributes listed in this errata. This change in X.520 (2012) seems to be entirely irrelevant to PKIX. PKIX (rfc5280, 2008) is based on X.509 (2005). I remember when I asked for a correction of an obvious flaw in PKIX that was based on the same flaw in X.509 (2005) in the same fashion that this flaw had already been fixed in X.509 (2008), but there was pretty violent opposition to "fixing" it -- potentially because this would make implementations of this flaw retroactively incompliant with PKIX. -Martin From nobody Mon Feb 23 07:30:01 2015 Return-Path: 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 AEA0D1A1ADD for ; Mon, 23 Feb 2015 07:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 2503YubcPkX3 for ; Mon, 23 Feb 2015 07:29:50 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 881EA1A1AD0 for ; Mon, 23 Feb 2015 07:29:47 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1DF2D72E063; Mon, 23 Feb 2015 10:29:47 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 1531672E05A; Mon, 23 Feb 2015 10:29:47 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.185]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0224.002; Mon, 23 Feb 2015 10:29:46 -0500 From: "Miller, Timothy J." To: "noloader@gmail.com" , Santosh Chokhani Thread-Topic: [pkix] How to enforce domain constraints on intermediate CA? Thread-Index: AQHQTiB12hiH5ICD3kuq8J71D1q1qZz8IIEAgAAQ2oCAAiw5EA== Date: Mon, 23 Feb 2015 15:29:46 +0000 Message-ID: <195DB2510AAA004391F58E28FCE212004621337A@IMCMBX01.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.140.19.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: PKIX Subject: Re: [pkix] How to enforce domain constraints on intermediate CA? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 15:29:57 -0000 FWIW, Microsoft Cert Services uses name constraints and other things in int= ermediate CA certs as part of "qualified subordination." -- T > -----Original Message----- > From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Jeffrey Walton > Sent: Saturday, February 21, 2015 7:14 PM > To: Santosh Chokhani > Cc: PKIX > Subject: Re: [pkix] How to enforce domain constraints on intermediate CA? >=20 > On Sat, Feb 21, 2015 at 7:14 PM, Santosh Chokhani > wrote: > > I would think this can be done via using name constraints extension > > and asserting appropriate DNS name spaces >=20 > Ah, thanks. I was looking for a policy object, and not an extension. > Sorry about that. >=20 > Jeff >=20 > > -----Original Message----- > > From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Jeffrey Walton > > Sent: Saturday, February 21, 2015 4:51 PM > > To: PKIX > > Subject: [pkix] How to enforce domain constraints on intermediate CA? > > > > I have an internal PKI, and I'm trying to figure out how to apply a pol= icy that > constrains names to the one used internally. I've read through RFCs like = 5280, > but its not clear to me how to do it. > > > > How does one apply a domain policy constraint to an intermediate CA > under PKIX? > > >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From nobody Mon Feb 23 14:05:59 2015 Return-Path: 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 B51A01A00B7 for ; Mon, 23 Feb 2015 14:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_NONE=-0.0001] 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 ImImA36caYrW for ; Mon, 23 Feb 2015 14:05:56 -0800 (PST) Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [194.9.95.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46AD1A003A for ; Mon, 23 Feb 2015 14:05:56 -0800 (PST) Received: from s314.loopia.se (localhost [127.0.0.1]) by s314.loopia.se (Postfix) with ESMTP id C9E451610160 for ; Mon, 23 Feb 2015 23:05:53 +0100 (CET) X-Loopia-Auth: user X-Loopia-Originating-IP: 85.235.7.89 X-Loopia-User: stefan@fiddler.nu Received: from s498.loopia.se (unknown [172.21.200.96]) by s314.loopia.se (Postfix) with ESMTP id 8302220088F3; Mon, 23 Feb 2015 23:05:53 +0100 (CET) Received: from s404.loopia.se (unknown [172.21.200.105]) by s498.loopia.se (Postfix) with ESMTP id 25781EE2C01; Mon, 23 Feb 2015 23:05:08 +0100 (CET) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s499.loopia.se ([172.21.200.105]) by s404.loopia.se (s404.loopia.se [172.21.200.134]) (amavisd-new, port 10024) with LMTP id JX7gyuENF7Xa; Mon, 23 Feb 2015 23:05:07 +0100 (CET) Received: from [192.168.1.216] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: stefan@fiddler.nu) by s499.loopia.se (Postfix) with ESMTPSA id 2B006B221C5; Mon, 23 Feb 2015 23:05:05 +0100 (CET) User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Mon, 23 Feb 2015 23:05:04 +0100 From: Stefan Santesson To: Message-Id: Thread-Topic: [pkix] [Editorial Errata Reported] RFC5280 (4274) References: <20150220160318.094B11B1C3@ld9781.wdf.sap.corp> In-Reply-To: <20150220160318.094B11B1C3@ld9781.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Archived-At: Cc: pkix@ietf.org, stefans@microsoft.com, i.matveychikov@securitycode.ru Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (4274) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 22:05:58 -0000 Hi Martin, My post was just a reflection of the apparent reality. There is no sign in a certificate that declares it to be RFC 5280 conformant. RFC 5280 compliance is an agreement between systems, using the profile for interop. The size limitations on attributes is however severely broken, and highly unmotivated. For these reasons they are usually ignored and replaced with common sense. We might not want to go through the pain to correct this, but the facts stays the same. /Stefan On 20/02/15 17:03, "Martin Rex" wrote: >Stefan Santesson wrote: >> >> These size limitations are gone in the current edition of X.520 >> >> In X.520 2001 edition, surname as example was defined as: >> >> Where Directory string is size limited by the upper bound ub-surname >> >> ub-surname >> INTEGER ::= 64 >> >> In the current edition of X.520 (102012) the definition is instead: >> >> Where UnboundedDirectoryString no longer is bounded to the old >>ub-surname >> size limit. >> >> The same is true for all attributes listed in this errata. > > >This change in X.520 (2012) seems to be entirely irrelevant to PKIX. >PKIX (rfc5280, 2008) is based on X.509 (2005). > >I remember when I asked for a correction of an obvious flaw in >PKIX that was based on the same flaw in X.509 (2005) in the same >fashion that this flaw had already been fixed in X.509 (2008), >but there was pretty violent opposition to "fixing" it -- potentially >because this would make implementations of this flaw retroactively >incompliant with PKIX. > > >-Martin > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From nobody Wed Feb 25 00:25:09 2015 Return-Path: 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 435C11A6EE0 for ; Wed, 25 Feb 2015 00:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.809 X-Spam-Level: * X-Spam-Status: No, score=1.809 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DK=1.009, RCVD_IN_DNSWL_NONE=-0.0001] 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 PNagFtZzmIw6 for ; Wed, 25 Feb 2015 00:25:06 -0800 (PST) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) (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 194091A1A80 for ; Wed, 25 Feb 2015 00:25:05 -0800 (PST) Received: from Morten ([62.44.134.150]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id 3201502250925037638 for ; Wed, 25 Feb 2015 09:25:03 +0100 From: "Erik Andersen" To: "PKIX" References: <20150220160318.094B11B1C3@ld9781.wdf.sap.corp> In-Reply-To: <20150220160318.094B11B1C3@ld9781.wdf.sap.corp> Date: Wed, 25 Feb 2015 09:25:02 +0100 Message-ID: <000c01d050d4$8e611400$ab233c00$@x500.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKjqYL94SiDrP34k6Q99s38HAsOMptXp2Vg Content-Language: da Archived-At: Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (4274) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 08:25:08 -0000 The upper bound was removed from X.520 from 2008. The upper bound were = added to X.520 already in the first edition from 1988, despite quite strong opposition. Hard coded upper band could impair future use of the = attribute types. The major reason for removing the upper bounds was compatibility with = LDAP, which does not have such upper bounds. There was no opposition to the = change within the X.500 community, as X.500 vendors typically also have LDAP implementations. If there is a need to refer to a specification without upper bounds, = then refer to X.509 instead of RFC 5280. Erik -----Oprindelig meddelelse----- Fra: pkix [mailto:pkix-bounces@ietf.org] P=E5 vegne af Martin Rex Sendt: 20. februar 2015 17:03 Til: Stefan Santesson Cc: stefans@microsoft.com; i.matveychikov@securitycode.ru; = pkix@ietf.org; RFC Errata System Emne: Re: [pkix] [Editorial Errata Reported] RFC5280 (4274) Stefan Santesson wrote: > > These size limitations are gone in the current edition of X.520 >=20 > In X.520 2001 edition, surname as example was defined as: >=20 > Where Directory string is size limited by the upper bound ub-surname >=20 > ub-surname =20 > INTEGER ::=3D 64 >=20 > In the current edition of X.520 (102012) the definition is instead: >=20 > Where UnboundedDirectoryString no longer is bounded to the old=20 > ub-surname size limit. >=20 > The same is true for all attributes listed in this errata. This change in X.520 (2012) seems to be entirely irrelevant to PKIX. PKIX (rfc5280, 2008) is based on X.509 (2005). I remember when I asked for a correction of an obvious flaw in PKIX that = was based on the same flaw in X.509 (2005) in the same fashion that this = flaw had already been fixed in X.509 (2008), but there was pretty violent opposition to "fixing" it -- potentially because this would make implementations of this flaw retroactively incompliant with PKIX. -Martin _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix