From paul.hoffman@vpnc.org Mon May 13 10:08:29 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09AE21F92F4 for ; Mon, 13 May 2013 10:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ub4whoenBJBr for ; Mon, 13 May 2013 10:08:28 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E820321F92C2 for ; Mon, 13 May 2013 10:08:27 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4DH8QDu014090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 13 May 2013 10:08:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 13 May 2013 10:08:26 -0700 To: "pkix@ietf.org PKIX" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [pkix] A well-researched article on use of CRLs in browsers X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 17:08:29 -0000 h= ttp://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doe= snt-work-in-practice.html The Netcraft folks are well-known for their research and = non-flamingness. --Paul Hoffman= From piyush@ditenity.com Mon May 13 10:21:40 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEC621F93EA for ; Mon, 13 May 2013 10:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONwpRhxcFtl2 for ; Mon, 13 May 2013 10:21:35 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 750D021F93B1 for ; Mon, 13 May 2013 10:21:26 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n12so7940762oag.31 for ; Mon, 13 May 2013 10:21:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=iQw8bysRNdGcJpKX2O1pNy3p+SP76MzOv6ftyNUXRMc=; b=OwxbAcRgMRs5MRCaqIfuDNP2r86ysGJtyObSNOV/mLANwJDgiBuxZz4Rd3/n4zkoLP MhnE7ni7uCMqe/4SQlVpT++AGWigtnPlTwGuTV3detSStXpNKlQNiDspe1892xlzzaaP mqPs2+/dg0JxBb0iuwY0JxcghJ2up5ajRdz/4kbLvDV18+aMu6+jR0BosG6R961Nn3zV yPiV+ZQX83KlYQgdgtS+vvTgamHuf6VXXU0w5PXICquAybm7EhzgsHI8PlPNI6ElBLQt Zw/NlgcjhpUJidT6uMgdp/NnWyEG/hgregwjCB4GtfJH6yEp6jCH4AqiYtGtbKv4sJZA 6NqQ== X-Received: by 10.60.37.33 with SMTP id v1mr13616019oej.96.1368465685721; Mon, 13 May 2013 10:21:25 -0700 (PDT) Received: from piyushlaptop (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPSA id qj8sm17545256oeb.2.2013.05.13.10.21.24 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 13 May 2013 10:21:24 -0700 (PDT) From: "Piyush J.comain" To: "'Paul Hoffman'" , References: In-Reply-To: Date: Mon, 13 May 2013 10:21:23 -0700 Message-ID: <004e01ce4ffe$4be2df10$e3a89d30$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJFMPG6Vvy1qQLslmhtBb5xuDMO5pgVmBCw Content-Language: en-us X-Gm-Message-State: ALoCoQk+3QD0xj2foab27XlUzgQC9qfhfIw0oqQwg9VegDEV4DQ7h+rSVnxFG9tlPSmUI25zQf0r Subject: Re: [pkix] A well-researched article on use of CRLs in browsers X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 17:21:40 -0000 It got to me with the opening hook - "Certificate revocation is intended to convey a complete withdrawal of trust in an SSL certificate and thereby protect the people using a site against fraud, eavesdropping, and theft" Promoting the common misconception that PK certificates are only good for establishing trust in SSL sites. Also, I find the conclusion that revocation is shaky because browser implementations are not consistent, a little shaky itself :). -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Monday, May 13, 2013 10:08 AM To: pkix@ietf.org PKIX Subject: [pkix] A well-researched article on use of CRLs in browsers http://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-does nt-work-in-practice.html The Netcraft folks are well-known for their research and non-flamingness. --Paul Hoffman _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From jeremy.rowley@digicert.com Mon May 13 10:49:59 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39FF21F915B for ; Mon, 13 May 2013 10:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcMH789+4CQQ for ; Mon, 13 May 2013 10:49:54 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id CADF621F90EE for ; Mon, 13 May 2013 10:49:53 -0700 (PDT) Received: from JROWLEYL1 (unknown [64.78.193.228]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 53F88666029; Mon, 13 May 2013 11:49:53 -0600 (MDT) From: "Jeremy Rowley" To: "'Paul Hoffman'" , References: In-Reply-To: Date: Mon, 13 May 2013 11:50:06 -0600 Organization: DigiCert Message-ID: <0f4801ce5002$4e19bf70$ea4d3e50$@digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJFMPG6Vvy1qQLslmhtBb5xuDMO5pgVnMTQ Content-Language: en-us Subject: Re: [pkix] A well-researched article on use of CRLs in browsers X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jeremy.rowley@digicert.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 17:49:59 -0000 >From a practical standpoint, all of the browsers expect notification of revocation of an intermediate certificate. Mozilla, in the past, has blacklisted revoked intermediates directly in the browser instead of relying on revocation information. Granted, revoked intermediates in the past have been associated with industry events, but I suspect they blacklist most revoked intermediates since intermediate revocation occurs so infrequently. Although the intermediate mentioned in the article lacked an OCSP URL, the CAB Forum's baseline requirements specify that all new intermediates must have OCSP. This requirement should lead to more uniform revocation checking practices (over time), decreasing the likelihood of a browser missing the revoked certificate. In addition, implementation of Yngve's recently adopted multi-stapling RFC will decrease any performance costs caused by an intermediate revocation check and likely increase the availability of this information. Jeremy -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Monday, May 13, 2013 11:08 AM To: pkix@ietf.org PKIX Subject: [pkix] A well-researched article on use of CRLs in browsers http://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-does nt-work-in-practice.html The Netcraft folks are well-known for their research and non-flamingness. --Paul Hoffman _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Mon May 13 22:03:25 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CDE21F87CD for ; Mon, 13 May 2013 22:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTdhvUTBmMVb for ; Mon, 13 May 2013 22:03:20 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A15CC21F90AC for ; Mon, 13 May 2013 22:03:19 -0700 (PDT) Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r4E53CiV005719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 May 2013 07:03:12 +0200 (MEST) In-Reply-To: <20121218025918.18FC91A402@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Tue, 14 May 2013 07:03:12 +0200 (CEST) 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: <20130514050312.7843B1A71C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "pkix@ietf.org" Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 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: Tue, 14 May 2013 05:03:25 -0000 When I wrote my message below, I wasn't aware how exactly the PKCS#v2.1 (rfc3447) RSASSA_PSS signature was defined, instead I was vaguely remembering code fragments of what turned out to be an early, unfinished PKCS#1 v2.1 draft 1 (1999) implementation. I noticed the difference when I recently implemented rfc3447 (rfc3447 section 9.1 is the easy, rfc4055 section 3.1 is the hard part). The optional "salt" OctetString from the PKCS#1v2.1draft1 version of the RSASSA_PSS AlgId Parameters, are not present in the final v2.1 RSASSA_PSS AlgId, that only contains a saltLength integer, so there are just a few bits to play with. On the one hand, the salt being protected under the RSA encryption looks safer, but on the other, a possibility for a CA to insert strong random noise near the beginning of TBSCertificate would have been nice... I'm sorry for the confusion. -Martin Martin Rex wrote on 17-Dec-2012: > Santosh Chokhani wrote: > > > > Yes, except "active" is a red herring again. > > If you are throwing in random meaningless extensions, RP is not going to > > check them and hence active and passive is not a meaningless distinction. > > > > The basic thing to understand is that the subject DN is the first input > > from the user and it has potential for sufficient fidelity that unless > > you put randomness before the subject DN, you are inviting trouble. > > IMHO the thing to understand is that the composition, field ordering > and fairly unlimited extensibility of X.509v3 is what enables > a mere collision attack (with two distinct internal states) to > achieve what would normally require a 2nd preimage attack. > > Looking at TBSCertificate: > > TBSCertificate ::= SEQUENCE { > version [0] Version DEFAULT v1, > serialNumber CertificateSerialNumber, > signature AlgorithmIdentifier, > issuer Name, > validity Validity, > subject Name, > subjectPublicKeyInfo SubjectPublicKeyInfo, > issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, > -- If present, version MUST be v2 or v3 > subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, > -- If present, version MUST be v2 or v3 > extensions [3] Extensions OPTIONAL > -- If present, version MUST be v3 -- } > > > maybe the AlgorithmIdententifier is finally not as useless as I > thought. If there was more support for RSA-PSS (aka PKCS#1 v2.1) > signatures in the installed base, the CA would be able to sign > the EE-Cert with a RSA-PSS AlgId that has a random, hash-sized salt > in the signature AlgorithmIdentifier parameters field... > > -Martin From SChokhani@cygnacom.com Tue May 14 06:28:36 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF5521F8F11 for ; Tue, 14 May 2013 06:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aio0wFKTn5yH for ; Tue, 14 May 2013 06:28:31 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id ACEB521F8203 for ; Tue, 14 May 2013 06:28:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,670,1363147200"; d="scan'208";a="8900532" Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge1.cygnacom.com with ESMTP; 14 May 2013 09:28:27 -0400 Received: from SCYGEXCH10.cygnacom.com ([fe80::d8df:b0bd:28be:ad62]) by scygexch10.cygnacom.com ([fe80::d8df:b0bd:28be:ad62%15]) with mapi id 14.02.0247.003; Tue, 14 May 2013 09:28:27 -0400 From: Santosh Chokhani To: "mrex@sap.com" Thread-Topic: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates Thread-Index: AQHOUGBaJ8Q/eUqF3UaAFGCcdlQgn5kErPeg Date: Tue, 14 May 2013 13:28:26 +0000 Message-ID: <4262AC0DB9856847A2D00EF817E81139015167@scygexch10.cygnacom.com> References: <20121218025918.18FC91A402@ld9781.wdf.sap.corp> <20130514050312.7843B1A71C@ld9781.wdf.sap.corp> In-Reply-To: <20130514050312.7843B1A71C@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.100.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 13:28:36 -0000 You can always put randomness in serial number or in validity period. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Tuesday, May 14, 2013 1:03 AM To: mrex@sap.com Cc: Santosh Chokhani; Erwann Abalea; pkix@ietf.org Subject: Re: [pkix] Questioning the benefit of random serials over sequenti= al ones in x.509 certificates When I wrote my message below, I wasn't aware how exactly the PKCS#v2.1 (rf= c3447) RSASSA_PSS signature was defined, instead I was vaguely remembering = code fragments of what turned out to be an early, unfinished PKCS#1 v2.1 dr= aft 1 (1999) implementation. I noticed the difference when I recently implemented rfc3447 (rfc3447 section 9.1 is the easy, rfc4055 section 3.1 is the hard part). The optional "salt" OctetString from the PKCS#1v2.1draft1 version of the RS= ASSA_PSS AlgId Parameters, are not present in the final v2.1 RSASSA_PSS AlgId, that only contains a saltLength integer, so there are just a few bits to play with. On the one hand, the salt being protected under the RSA encryption looks safer, but on the o= ther, a possibility for a CA to insert strong random noise near the beginni= ng of TBSCertificate would have been nice... I'm sorry for the confusion. -Martin Martin Rex wrote on 17-Dec-2012: > Santosh Chokhani wrote: > > > > Yes, except "active" is a red herring again. > > If you are throwing in random meaningless extensions, RP is not=20 > > going to check them and hence active and passive is not a meaningless d= istinction. > >=20 > > The basic thing to understand is that the subject DN is the first=20 > > input from the user and it has potential for sufficient fidelity=20 > > that unless you put randomness before the subject DN, you are inviting = trouble. >=20 > IMHO the thing to understand is that the composition, field ordering=20 > and fairly unlimited extensibility of X.509v3 is what enables a mere=20 > collision attack (with two distinct internal states) to achieve what=20 > would normally require a 2nd preimage attack. >=20 > Looking at TBSCertificate: >=20 > TBSCertificate ::=3D SEQUENCE { > version [0] Version DEFAULT v1, > serialNumber CertificateSerialNumber, > signature AlgorithmIdentifier, > issuer Name, > validity Validity, > subject Name, > subjectPublicKeyInfo SubjectPublicKeyInfo, > issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, > -- If present, version MUST be v2 or v3 > subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, > -- If present, version MUST be v2 or v3 > extensions [3] Extensions OPTIONAL > -- If present, version MUST be v3 -- } >=20 >=20 > maybe the AlgorithmIdententifier is finally not as useless as I=20 > thought. If there was more support for RSA-PSS (aka PKCS#1 v2.1)=20 > signatures in the installed base, the CA would be able to sign the=20 > EE-Cert with a RSA-PSS AlgId that has a random, hash-sized salt in the=20 > signature AlgorithmIdentifier parameters field... >=20 > -Martin From wwwrun@rfc-editor.org Thu May 16 04:08:11 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103B521F8F43 for ; Thu, 16 May 2013 04:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.327 X-Spam-Level: X-Spam-Status: No, score=-102.327 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9OOwIbF3Kpw for ; Thu, 16 May 2013 04:08:03 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 30E4C21F8F38 for ; Thu, 16 May 2013 04:08:02 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 438AC62103; Thu, 16 May 2013 04:07:51 -0700 (PDT) To: paul.hoffman@vpnc.org, jimsch@exmsft.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20130516110751.438AC62103@rfc-editor.org> Date: Thu, 16 May 2013 04:07:51 -0700 (PDT) Cc: pkix@ietf.org, rfc-editor@rfc-editor.org Subject: [pkix] [Technical Errata Reported] RFC5912 (3623) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 11:08:12 -0000 The following errata report has been submitted for RFC5912, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5912&eid=3623 -------------------------------------- Type: Technical Reported by: Carl Wallace Section: 14 Original Text ------------- -- CRL number extension OID and syntax ext-CRLNumber EXTENSION ::= {SYNTAX INTEGER (0..MAX) IDENTIFIED BY id-ce-cRLNumber } id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } CRLNumber ::= INTEGER (0..MAX) Corrected Text -------------- -- CRL number extension OID and syntax CRLNumber ::= INTEGER ext-CRLNumber EXTENSION ::= {SYNTAX CRLNumber IDENTIFIED BY id-ce-cRLNumber } id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } Notes ----- The CRLNumber extension was not defined to use the CRLNumber type. The CRLNumber type uses MAX to limit the maximum value. This limitation is inconsistent with section 5.2.3 and Appendix B, which allow CRLNumber values up to 20 octets in length. Instructions: ------------- This errata 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. -------------------------------------- RFC5912 (draft-ietf-pkix-new-asn1-08) -------------------------------------- Title : New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) Publication Date : June 2010 Author(s) : P. Hoffman, J. Schaad Category : INFORMATIONAL Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From jimsch@augustcellars.com Thu May 16 08:23:59 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09D521F86F7 for ; Thu, 16 May 2013 08:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqg60WArYB6L for ; Thu, 16 May 2013 08:23:10 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6E221F9227 for ; Thu, 16 May 2013 08:23:10 -0700 (PDT) Received: from Philemon (unknown [88.214.187.250]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 2607C38F1A; Thu, 16 May 2013 08:22:59 -0700 (PDT) From: "Jim Schaad" To: "'RFC Errata System'" , , , , , , References: <20130516110751.438AC62103@rfc-editor.org> In-Reply-To: <20130516110751.438AC62103@rfc-editor.org> Date: Thu, 16 May 2013 16:22:00 +0100 Message-ID: <05f301ce5249$28be3f50$7a3abdf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKuR1tHlnNqYs/us1ZC1fWGtUuH3ZdIA0ug Content-Language: en-us X-Mailman-Approved-At: Thu, 16 May 2013 08:37:05 -0700 Cc: pkix@ietf.org Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3623) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 15:24:00 -0000 Reject The serial number MUST be a positive integer assigned by the CA to each certificate. > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: Thursday, May 16, 2013 12:08 PM > To: paul.hoffman@vpnc.org; jimsch@exmsft.com; stephen.farrell@cs.tcd.ie; > turners@ieca.com; kent@bbn.com; stefan@aaa-sec.com > Cc: carl@redhoundsoftware.com; pkix@ietf.org; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC5912 (3623) > > The following errata report has been submitted for RFC5912, "New ASN.1 > Modules for the Public Key Infrastructure Using X.509 (PKIX)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5912&eid=3623 > > -------------------------------------- > Type: Technical > Reported by: Carl Wallace > > Section: 14 > > Original Text > ------------- > -- CRL number extension OID and syntax > ext-CRLNumber EXTENSION ::= {SYNTAX > INTEGER (0..MAX) IDENTIFIED BY id-ce-cRLNumber } > id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } > > CRLNumber ::= INTEGER (0..MAX) > > Corrected Text > -------------- > -- CRL number extension OID and syntax > CRLNumber ::= INTEGER > > ext-CRLNumber EXTENSION ::= {SYNTAX > CRLNumber IDENTIFIED BY id-ce-cRLNumber } > id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } > > > Notes > ----- > The CRLNumber extension was not defined to use the CRLNumber type. The > CRLNumber type uses MAX to limit the maximum value. This limitation is > inconsistent with section 5.2.3 and Appendix B, which allow CRLNumber > values up to 20 octets in length. > > Instructions: > ------------- > This errata 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. > > -------------------------------------- > RFC5912 (draft-ietf-pkix-new-asn1-08) > -------------------------------------- > Title : New ASN.1 Modules for the Public Key Infrastructure Using > X.509 (PKIX) > Publication Date : June 2010 > Author(s) : P. Hoffman, J. Schaad > Category : INFORMATIONAL > Source : Public-Key Infrastructure (X.509) > Area : Security > Stream : IETF > Verifying Party : IESG From carl@redhoundsoftware.com Thu May 16 08:37:09 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E7D21F91CB for ; Thu, 16 May 2013 08:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5ItdOqz7zzg for ; Thu, 16 May 2013 08:37:09 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 41ABF21F91AB for ; Thu, 16 May 2013 08:37:09 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id c10so1127554qcz.13 for ; Thu, 16 May 2013 08:37:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=qRlMcjwYk1+gzTTDNv/njbCNgCfbIE7qXKcPfma/t6o=; b=o1bcKlVJMeSPJ0bvs9yiReIZ29lRAZWnAOYbGktIsX0wpEvUYJumfrnOUrg1YxIiIs j2Sa5m9iwsv/3k5DEu0gb9cnpvC8Usj4gX62hpufz9dtoVcLCyrQcs04/T95D+AzJwNg HxQAKixwTMfBKG7RSCjzhYzXYi3jRI1fDGI0Pt6dVObMUDXYKHVR8P3No6sooz9buqKL oREB40Sn+xmiIAvvPmkawAWdWnFfbv0saT0HQBJ4/DeuW1GSrrdqLQ8WSdoe+CrbDel5 O11Z5zj6TXFgMhGsHqe5cFm5BgOyz3XdoIcwkvdKGxmbuAHj1CqU6tNYzsKAmRDUVjWv q1nQ== X-Received: by 10.49.35.72 with SMTP id f8mr6496020qej.4.1368718628680; Thu, 16 May 2013 08:37:08 -0700 (PDT) Received: from [10.239.53.255] (46.sub-174-227-129.myvzw.com. [174.227.129.46]) by mx.google.com with ESMTPSA id s10sm7427054qam.7.2013.05.16.08.37.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 May 2013 08:37:08 -0700 (PDT) References: <20130516110751.438AC62103@rfc-editor.org> <05f301ce5249$28be3f50$7a3abdf0$@augustcellars.com> Mime-Version: 1.0 (1.0) In-Reply-To: <05f301ce5249$28be3f50$7a3abdf0$@augustcellars.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9154E240-C749-4854-8312-8BEE436CC45E@redhoundsoftware.com> X-Mailer: iPhone Mail (10B146) From: Carl Wallace Date: Thu, 16 May 2013 11:37:05 -0400 To: Jim Schaad X-Gm-Message-State: ALoCoQnan2anjEu3xViyLUJgd/jipWsEF3noKoO37YOe2VyYspBwP4451XkpDUwUu1pIT2VfYPFe Cc: "" , "" , "" , "" , RFC Errata System Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3623) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 15:37:10 -0000 The errata has multiple parts if you feel the MAX limit is unacceptable acce= pt the type issue independently. Suggested limit change aligns with similar certificate serial number defini= tion.=20 On May 16, 2013, at 11:22 AM, "Jim Schaad" wrote:= > Reject >=20 > The serial number MUST be a positive integer assigned by the CA to > each certificate. >=20 >=20 >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: Thursday, May 16, 2013 12:08 PM >> To: paul.hoffman@vpnc.org; jimsch@exmsft.com; stephen.farrell@cs.tcd.ie; >> turners@ieca.com; kent@bbn.com; stefan@aaa-sec.com >> Cc: carl@redhoundsoftware.com; pkix@ietf.org; rfc-editor@rfc-editor.org >> Subject: [Technical Errata Reported] RFC5912 (3623) >>=20 >> The following errata report has been submitted for RFC5912, "New ASN.1 >> Modules for the Public Key Infrastructure Using X.509 (PKIX)". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D5912&eid=3D3623 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Carl Wallace >>=20 >> Section: 14 >>=20 >> Original Text >> ------------- >> -- CRL number extension OID and syntax >> ext-CRLNumber EXTENSION ::=3D {SYNTAX >> INTEGER (0..MAX) IDENTIFIED BY id-ce-cRLNumber } >> id-ce-cRLNumber OBJECT IDENTIFIER ::=3D { id-ce 20 } >>=20 >> CRLNumber ::=3D INTEGER (0..MAX) >>=20 >> Corrected Text >> -------------- >> -- CRL number extension OID and syntax >> CRLNumber ::=3D INTEGER >>=20 >> ext-CRLNumber EXTENSION ::=3D {SYNTAX >> CRLNumber IDENTIFIED BY id-ce-cRLNumber } >> id-ce-cRLNumber OBJECT IDENTIFIER ::=3D { id-ce 20 } >>=20 >>=20 >> Notes >> ----- >> The CRLNumber extension was not defined to use the CRLNumber type. The >> CRLNumber type uses MAX to limit the maximum value. This limitation is >> inconsistent with section 5.2.3 and Appendix B, which allow CRLNumber >> values up to 20 octets in length. >>=20 >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please use > "Reply >> All" to discuss whether it should be verified or rejected. When a decisio= n > is >> reached, the verifying party (IESG) can log in to change the status and > edit the >> report, if necessary. >>=20 >> -------------------------------------- >> RFC5912 (draft-ietf-pkix-new-asn1-08) >> -------------------------------------- >> Title : New ASN.1 Modules for the Public Key Infrastructure= > Using >> X.509 (PKIX) >> Publication Date : June 2010 >> Author(s) : P. Hoffman, J. Schaad >> Category : INFORMATIONAL >> Source : Public-Key Infrastructure (X.509) >> Area : Security >> Stream : IETF >> Verifying Party : IESG >=20 From eabalea@gmail.com Thu May 16 09:01:57 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BBD21F88EA for ; Thu, 16 May 2013 09:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oi5Obhdacxt2 for ; Thu, 16 May 2013 09:01:56 -0700 (PDT) Received: from mail-vb0-x22b.google.com (mail-vb0-x22b.google.com [IPv6:2607:f8b0:400c:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id EFD1B21F8F07 for ; Thu, 16 May 2013 09:01:21 -0700 (PDT) Received: by mail-vb0-f43.google.com with SMTP id p14so1550133vbm.30 for ; Thu, 16 May 2013 09:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vMxxVnmvdWiJLa2oFR/tPAZjQA8AMyjHe4BLvG1lN3w=; b=H5aKRB31SmTnNqv/xsHln/Kv48XvgNUv125TAV4NWtbtQwgIgkE2Ztl+ipWoymR64l dwHHve+mGzQzi+jbS0+R6YDXD6nMjPaBU02BpjGKabBTOlBlVwxRqDcdw4kZbNm1T7d2 kK2e7xXAIgLBT8g36pcz88SjXKTNuTuj4sa1q7DiXYKJwxRPfM7sC4JHMqXtDRhyvHBN L78A0IAhR28N5V42bzs+Akyd97/dr/lV/ciMXoUa8Nt/weIaI6doc9ikerUdnAMYINPr Zu/YBBSbW40IB4NJgixvyzqfjeBFJkiRKtQD2tvjKOW9Wmv3w7clY3n1y+LThMkK5OO6 FBqQ== MIME-Version: 1.0 X-Received: by 10.220.160.2 with SMTP id l2mr4678175vcx.38.1368720079151; Thu, 16 May 2013 09:01:19 -0700 (PDT) Received: by 10.52.180.130 with HTTP; Thu, 16 May 2013 09:01:19 -0700 (PDT) In-Reply-To: <05f301ce5249$28be3f50$7a3abdf0$@augustcellars.com> References: <20130516110751.438AC62103@rfc-editor.org> <05f301ce5249$28be3f50$7a3abdf0$@augustcellars.com> Date: Thu, 16 May 2013 18:01:19 +0200 Message-ID: From: Erwann Abalea To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Cc: Stefan Santesson , Paul Hoffman , jimsch@exmsft.com, pkix@ietf.org, RFC Errata System Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3623) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 16:01:57 -0000 The certificate serialNumber is limited to [0 .. 256^20] in value. The CRLNumber is limited to [-256^20 .. 256^20], it's not said to be a positive integer. 2013/5/16 Jim Schaad : > Reject > > The serial number MUST be a positive integer assigned by the CA to > each certificate. > > >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: Thursday, May 16, 2013 12:08 PM >> To: paul.hoffman@vpnc.org; jimsch@exmsft.com; stephen.farrell@cs.tcd.ie; >> turners@ieca.com; kent@bbn.com; stefan@aaa-sec.com >> Cc: carl@redhoundsoftware.com; pkix@ietf.org; rfc-editor@rfc-editor.org >> Subject: [Technical Errata Reported] RFC5912 (3623) >> >> The following errata report has been submitted for RFC5912, "New ASN.1 >> Modules for the Public Key Infrastructure Using X.509 (PKIX)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5912&eid=3623 >> >> -------------------------------------- >> Type: Technical >> Reported by: Carl Wallace >> >> Section: 14 >> >> Original Text >> ------------- >> -- CRL number extension OID and syntax >> ext-CRLNumber EXTENSION ::= {SYNTAX >> INTEGER (0..MAX) IDENTIFIED BY id-ce-cRLNumber } >> id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } >> >> CRLNumber ::= INTEGER (0..MAX) >> >> Corrected Text >> -------------- >> -- CRL number extension OID and syntax >> CRLNumber ::= INTEGER >> >> ext-CRLNumber EXTENSION ::= {SYNTAX >> CRLNumber IDENTIFIED BY id-ce-cRLNumber } >> id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } >> >> >> Notes >> ----- >> The CRLNumber extension was not defined to use the CRLNumber type. The >> CRLNumber type uses MAX to limit the maximum value. This limitation is >> inconsistent with section 5.2.3 and Appendix B, which allow CRLNumber >> values up to 20 octets in length. >> >> Instructions: >> ------------- >> This errata 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. >> >> -------------------------------------- >> RFC5912 (draft-ietf-pkix-new-asn1-08) >> -------------------------------------- >> Title : New ASN.1 Modules for the Public Key Infrastructure > Using >> X.509 (PKIX) >> Publication Date : June 2010 >> Author(s) : P. Hoffman, J. Schaad >> Category : INFORMATIONAL >> 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 -- Erwann. From carl@redhoundsoftware.com Thu May 16 09:38:18 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8657B21F8528 for ; Thu, 16 May 2013 09:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXNLBsjNrQDA for ; Thu, 16 May 2013 09:38:17 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 445C421F898A for ; Thu, 16 May 2013 09:38:17 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id hu16so895343qab.3 for ; Thu, 16 May 2013 09:38:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=SlOdUNjpCCKjCfFiGNa4a1euN5CEUrX6zYDYLX8ny6g=; b=cGlusGHV32/T6zBTzkyXsOtUghE/H6i24kjcBLgZmBx8OagnP3D2AuwQ3V4Sd1rjDw 8hwDrq1pu3Yh8mghwZ7gc96gz3ozGF0/iwGikHfx5XhskPOpYVLxvTgIq8qfl7cfuB8q LZ2i/SmgJFuLz+tkwY93XdZDm98VmNfjylnp4wzIiUGqJWNrn4N9maQ9bqy4Dp7n8s49 Vy1k5S3eFKxR10P9j9mv5ExmSJMgA4HhA9MMhAu3XsT9TjncUaduu7q0aOITerM/O8xa Cgz3WMLAr3l8iBs4eFZEt5HshpsiOWHKHs9O4gcB2ss5OgaJY9ykD5M9BgdmnIXUAavy zsVQ== X-Received: by 10.224.166.67 with SMTP id l3mr33116116qay.48.1368722296541; Thu, 16 May 2013 09:38:16 -0700 (PDT) Received: from [192.168.2.7] (pool-173-79-106-247.washdc.fios.verizon.net. [173.79.106.247]) by mx.google.com with ESMTPSA id v1sm7730928qab.8.2013.05.16.09.38.14 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 16 May 2013 09:38:15 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Thu, 16 May 2013 12:38:11 -0400 From: Carl Wallace To: Erwann Abalea , Jim Schaad Message-ID: Thread-Topic: [pkix] [Technical Errata Reported] RFC5912 (3623) In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQnGsACrWXpVhYSTrMDPvY5OMpoDKd6bk64VPmVsDoYMELCj/fZUhc6hFSwxXVu6pO7+7WrM Cc: RFC Errata System , Stefan Santesson , jimsch@exmsft.com, Paul Hoffman , pkix@ietf.org Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3623) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 16:38:18 -0000 Independent of limit, this should change to use CRLnumber type to facilitate satisfying the requirement for a big integer. The CRLNumber type is used in the prose describing the extension, but not in its definition. It is used in the DeltaCRLIndicator definition. On 5/16/13 12:01 PM, "Erwann Abalea" wrote: >The certificate serialNumber is limited to [0 .. 256^20] in value. >The CRLNumber is limited to [-256^20 .. 256^20], it's not said to be a >positive integer. > >2013/5/16 Jim Schaad : >> Reject >> >> The serial number MUST be a positive integer assigned by the CA to >> each certificate. >> >> >>> -----Original Message----- >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>> Sent: Thursday, May 16, 2013 12:08 PM >>> To: paul.hoffman@vpnc.org; jimsch@exmsft.com; >>>stephen.farrell@cs.tcd.ie; >>> turners@ieca.com; kent@bbn.com; stefan@aaa-sec.com >>> Cc: carl@redhoundsoftware.com; pkix@ietf.org; rfc-editor@rfc-editor.org >>> Subject: [Technical Errata Reported] RFC5912 (3623) >>> >>> The following errata report has been submitted for RFC5912, "New ASN.1 >>> Modules for the Public Key Infrastructure Using X.509 (PKIX)". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=5912&eid=3623 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Carl Wallace >>> >>> Section: 14 >>> >>> Original Text >>> ------------- >>> -- CRL number extension OID and syntax >>> ext-CRLNumber EXTENSION ::= {SYNTAX >>> INTEGER (0..MAX) IDENTIFIED BY id-ce-cRLNumber } >>> id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } >>> >>> CRLNumber ::= INTEGER (0..MAX) >>> >>> Corrected Text >>> -------------- >>> -- CRL number extension OID and syntax >>> CRLNumber ::= INTEGER >>> >>> ext-CRLNumber EXTENSION ::= {SYNTAX >>> CRLNumber IDENTIFIED BY id-ce-cRLNumber } >>> id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } >>> >>> >>> Notes >>> ----- >>> The CRLNumber extension was not defined to use the CRLNumber type. The >>> CRLNumber type uses MAX to limit the maximum value. This limitation is >>> inconsistent with section 5.2.3 and Appendix B, which allow CRLNumber >>> values up to 20 octets in length. >>> >>> Instructions: >>> ------------- >>> This errata 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. >>> >>> -------------------------------------- >>> RFC5912 (draft-ietf-pkix-new-asn1-08) >>> -------------------------------------- >>> Title : New ASN.1 Modules for the Public Key >>>Infrastructure >> Using >>> X.509 (PKIX) >>> Publication Date : June 2010 >>> Author(s) : P. Hoffman, J. Schaad >>> Category : INFORMATIONAL >>> 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 > > > >-- >Erwann. >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From eabalea@gmail.com Thu May 16 11:01:47 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3CC11E8141 for ; Thu, 16 May 2013 11:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xah8ZQIc9aXr for ; Thu, 16 May 2013 11:01:46 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A1F4011E8126 for ; Thu, 16 May 2013 11:01:46 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id 15so1455081vea.1 for ; Thu, 16 May 2013 11:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DrIsVryIcb4V7iYIF1u5/YZryBX4+In5V2NiaVyqo+Q=; b=DUzSEvG0bJWHYn+wBfUF4A6BW30fBe3lFyf6x0J95IZ32B234YfB4ckUz4u1nNxSxl DBz0n17504x63pP73Wb0Sq1xRzBjpqzFQ86dCXVKsmOVs2qKwqoKeFqodjxTGrqfWSqB wCa5z5sqFk8QCvqYD391/IOVIKWEj90Zs8rwdqMqT/feuCDZ5BnOVhzXwgTtzdMWsBUZ OWG4kvYBYo1tlc9Yh+Ha4uCPmGzjKX9dgEQpaCElznWy9zXX3qJF6OpEN3ueXpdA6IQa vqi2VzwzjGwqPufQrDzeaAMtwXrU7c3oJvaHPzvo/OkE5cPevY76mgjqpzmScHs6XDHJ sIKw== MIME-Version: 1.0 X-Received: by 10.52.16.174 with SMTP id h14mr24041724vdd.59.1368727306050; Thu, 16 May 2013 11:01:46 -0700 (PDT) Received: by 10.52.180.130 with HTTP; Thu, 16 May 2013 11:01:45 -0700 (PDT) In-Reply-To: References: <20130516110751.438AC62103@rfc-editor.org> <05f301ce5249$28be3f50$7a3abdf0$@augustcellars.com> Date: Thu, 16 May 2013 20:01:45 +0200 Message-ID: From: Erwann Abalea To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Cc: Stefan Santesson , Paul Hoffman , jimsch@exmsft.com, pkix@ietf.org, RFC Errata System Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3623) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 18:01:47 -0000 My bad. X.509 already defines CRLNumber as an INTEGER(0..MAX), so a positive number. 2013/5/16 Erwann Abalea : > The certificate serialNumber is limited to [0 .. 256^20] in value. > The CRLNumber is limited to [-256^20 .. 256^20], it's not said to be a > positive integer. > > 2013/5/16 Jim Schaad : >> Reject >> >> The serial number MUST be a positive integer assigned by the CA to >> each certificate. -- Erwann. From mrex@sap.com Thu May 16 11:28:19 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D80211E814B for ; Thu, 16 May 2013 11:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezBil0GkRVPv for ; Thu, 16 May 2013 11:28:14 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8806C11E814D for ; Thu, 16 May 2013 11:28:11 -0700 (PDT) Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r4GIRajO027059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 May 2013 20:27:36 +0200 (MEST) In-Reply-To: <9154E240-C749-4854-8312-8BEE436CC45E@redhoundsoftware.com> To: Carl Wallace Date: Thu, 16 May 2013 20:27:36 +0200 (CEST) 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: <20130516182736.C32D51A73C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "" , "" , "" , Jim Schaad , "" , RFC Errata System Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3623) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 16 May 2013 18:28:19 -0000 Carl Wallace wrote: > > The errata has multiple parts if you feel the MAX limit is > unacceptable accept the type issue independently. The change about the MAX part looks inappropriate. The change within the definition ext-CRLNumber is a defect in rfc5912. It's silly to create such an orphan. The ASN.1 definition in ITU-T Rec. X.509 08/1997 (Section 12.5.2.1 page 35): 12.5.2.1 CRL number field This CRL extension field conveys a monotonically increasing sequence number for each CRL issued by a given CRL issuer through a given CA directory attribute or CRL distribution point. It allows a CRL user to detect whether CRLs issued prior to the one being processed were also seen and processed. This field is defined as follows: cRLNumber EXTENSION ::= { SYNTAX CRLNumber IDENTIFIED BY id-ce-cRLNumber } CRLNumber ::= INTEGER (0..MAX) This extension is always non-critical. and verbatim the same in ITU-T Rec. X.509 11/2008 (Section 8.5.2.1, page 35) Given how the original purpose of this field is defined in X.509, the 20 octets limit in rfc5280 5.2.3 is pretty clueless on my scorecard. What X.509 says implies that a CA must start CRLNumber at 0 and issue CRLs without creating holes in the CRLNumber space. Reality check: 1 CRL per second, 50 years of issuance: 50*366*86400 = 1,581,120,000 < 2^31 -Martin From carl@redhoundsoftware.com Thu May 16 11:32:38 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3456611E814B for ; Thu, 16 May 2013 11:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1B4W2k7tv2z for ; Thu, 16 May 2013 11:32:32 -0700 (PDT) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 5F21A11E8158 for ; Thu, 16 May 2013 11:32:25 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id w7so2140880qeb.20 for ; Thu, 16 May 2013 11:32:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=Yne1OQxp5iDa1JN2LS1Carg+Qubamcw9GectrW8A7Mc=; b=VYFpoFldTjUtXWkcxWYbIFmsNiAPhe05FKi/9m3Zsxoi5Er9Qwdk02xAKyXrcuJXat iSqd0t4d2wf+Ovay/sENV7sYZ9AJdr5JrujLxlXaN2lJCyKVpne/3k1j5Z+1XcAWvtsj 7HVlqQSR1GvVd958a92ZgyNTZCoyPBeliLq3OWR14asiFpwljcqlv1w8Y1SFrtgm16Pa uy6VB2NUllL8F1qbfR5Umau3XW/ZNd12QN+fNNkk7g+Np6dftii+Acqz5TNGv0aXtHAj /MH90a/Kw+B9DZoAdr6HAsfMQwJeY/xzvXN/U17W03KPKFMMPkYDCzjtCVkPDOSO25oG ZYqw== X-Received: by 10.224.88.74 with SMTP id z10mr2951044qal.99.1368729144732; Thu, 16 May 2013 11:32:24 -0700 (PDT) Received: from [192.168.2.7] (pool-173-79-106-247.washdc.fios.verizon.net. [173.79.106.247]) by mx.google.com with ESMTPSA id l13sm8320219qaj.9.2013.05.16.11.32.22 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 16 May 2013 11:32:24 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Thu, 16 May 2013 14:32:16 -0400 From: Carl Wallace To: Message-ID: Thread-Topic: [pkix] [Technical Errata Reported] RFC5912 (3623) In-Reply-To: <20130516182736.C32D51A73C@ld9781.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQn0Ui9TKV1mGDnJx+82mjQjhwrRcx8xVS2K+19ssdoVrguF4RnnmkeXX9JsQ9e2mtUMnTvG Cc: "" , "" , "" , Jim Schaad , "" , RFC Errata System Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3623) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 18:32:38 -0000 On 5/16/13 2:27 PM, "Martin Rex" wrote: >Carl Wallace wrote: >> >> The errata has multiple parts if you feel the MAX limit is >> unacceptable accept the type issue independently. > >The change about the MAX part looks inappropriate. > >The change within the definition ext-CRLNumber is a defect in rfc5912. >It's silly to create such an orphan. Correct. I over-read an error message from the compiler I was using re: MAX limit bit. The type issue should be fixed. From eabalea@gmail.com Thu May 16 12:14:11 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D54121F9227 for ; Thu, 16 May 2013 12:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Szz7cL7LSyMP for ; Thu, 16 May 2013 12:14:10 -0700 (PDT) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id A897121F91D8 for ; Thu, 16 May 2013 12:14:10 -0700 (PDT) Received: by mail-vb0-f49.google.com with SMTP id q12so1657431vbe.8 for ; Thu, 16 May 2013 12:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=7QNOw7qIozaQ86QEN/sdKOLtOwXHqVMlceqn/Oddlz0=; b=hvVS53K8SwM7xkqIDV77y9P4k0a6aWT5NKTY2yvthfNN1+tp5MZRJ+UG5PdsR1Xa0F 6mk0btplKx2trZIEALwg8QPk9AuR4FtB70AaTA+uEpHg+XmrmlnrRM1F00fj/C/FYgnm 3Ft7dHNN1K0Sl7Gp7gUeIqaEuPLA3Q/LfX3wcuKj9mE/3BJBHPeAXgnP6jFE/GkXlpN5 bEgJP/gbg2zSxxD3LVVFuN8HnQuoYoQ6AGpJDiHw/llTdPZqZgIkULslpPCsMnCZNbcs FZkz5lzPZ+pYMvRwL03Y70td+gYxsacQL5fJRYQMI3dV55m0UH8c3tuJ/Z4dnKYwdxrq EANQ== MIME-Version: 1.0 X-Received: by 10.220.160.2 with SMTP id l2mr4972169vcx.38.1368731650100; Thu, 16 May 2013 12:14:10 -0700 (PDT) Received: by 10.52.180.130 with HTTP; Thu, 16 May 2013 12:14:09 -0700 (PDT) In-Reply-To: <20130516182736.C32D51A73C@ld9781.wdf.sap.corp> References: <9154E240-C749-4854-8312-8BEE436CC45E@redhoundsoftware.com> <20130516182736.C32D51A73C@ld9781.wdf.sap.corp> Date: Thu, 16 May 2013 21:14:09 +0200 Message-ID: From: Erwann Abalea To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" , "" , "" , Jim Schaad , "" , RFC Errata System Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3623) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 19:14:11 -0000 2013/5/16 Martin Rex : [...] > The ASN.1 definition in ITU-T Rec. X.509 08/1997 (Section 12.5.2.1 page 3= 5): > > 12.5.2.1 CRL number field > > This CRL extension field conveys a monotonically increasing sequence > number for each CRL issued by a given CRL issuer through a given CA > directory attribute or CRL distribution point. It allows a CRL user > to detect whether CRLs issued prior to the one being processed were > also seen and processed. This field is defined as follows: > > cRLNumber EXTENSION ::=3D { > SYNTAX CRLNumber > IDENTIFIED BY id-ce-cRLNumber } > CRLNumber ::=3D INTEGER (0..MAX) > > This extension is always non-critical. > > and verbatim the same in ITU-T Rec. X.509 11/2008 (Section 8.5.2.1, page = 35) > > > Given how the original purpose of this field is defined in X.509, > the 20 octets limit in rfc5280 5.2.3 is pretty clueless on my scorecard. > > What X.509 says implies that a CA must start CRLNumber at 0 and issue > CRLs without creating holes in the CRLNumber space. {0, 2, 4, 5, 10, 35, 42} is a monotonically increasing sequence. Each term is greater than the previous one, the "no hole" property isn't wanted. If it was, then the sequence number would be issued from an arithmetic progression with common difference of 1 (I'm not sure of the translation, we call it "suite arithm=C3=A9tique de raison 1" in french). The first CRL does not need to be numbered 0 either. -- Erwann. From mrex@sap.com Thu May 16 12:26:48 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D26421F925B for ; Thu, 16 May 2013 12:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLUfK8B3OhBx for ; Thu, 16 May 2013 12:26:43 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id A178C21F8FFA for ; Thu, 16 May 2013 12:26:38 -0700 (PDT) Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r4GJQ7f7017650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 May 2013 21:26:07 +0200 (MEST) In-Reply-To: To: Erwann Abalea Date: Thu, 16 May 2013 21:26:07 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20130516192607.76FB21A73C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "" , "" , "" , Jim Schaad , "" , RFC Errata System Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3623) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 16 May 2013 19:26:48 -0000 Erwann Abalea wrote: [ Charset UTF-8 unsupported, converting... ] > 2013/5/16 Martin Rex : > [...] > > The ASN.1 definition in ITU-T Rec. X.509 08/1997 (Section 12.5.2.1 page= 35): > > > > 12.5.2.1 CRL number field > > > > This CRL extension field conveys a monotonically increasing sequence > > number for each CRL issued by a given CRL issuer through a given CA > > directory attribute or CRL distribution point. It allows a CRL user > > to detect whether CRLs issued prior to the one being processed were > > also seen and processed. This field is defined as follows: > > > > cRLNumber EXTENSION ::=3D { > > SYNTAX CRLNumber > > IDENTIFIED BY id-ce-cRLNumber } > > CRLNumber ::=3D INTEGER (0..MAX) > > > > This extension is always non-critical. > > > > and verbatim the same in ITU-T Rec. X.509 11/2008 (Section 8.5.2.1, pag= e 35) > > > > > > Given how the original purpose of this field is defined in X.509, > > the 20 octets limit in rfc5280 5.2.3 is pretty clueless on my scorecard. > > > > What X.509 says implies that a CA must start CRLNumber at 0 and issue > > CRLs without creating holes in the CRLNumber space. >=20 > {0, 2, 4, 5, 10, 35, 42} is a monotonically increasing sequence. Each > term is greater than the previous one, the "no hole" property isn't > wanted. > If it was, then the sequence number would be issued from an arithmetic > progression with common difference of 1 (I'm not sure of the > translation, we call it "suite arithm=E9tique de raison 1" in french). >=20 > The first CRL does not need to be numbered 0 either. You failed to read X.509. Look at the DEFINED purpose of the CRLNumber in X.509 again. The stated purpose of CRLNumber is: It allows a CRL user to detect whether CRLS issued prior to the one being processed were also seen and processed. This is _not_ about a human doing research! A CA starting at a number > 0 or a that creates holes in the CRLNumber space would preclude (and enforce) the "were also seen an processed" for the CRL user, so both would be formally provable incompatible with the one and only explicitly stated purpose of CRLNumber. That there is no "shall" language on both issues in X.509 is a formally provable defect of X.509 -- of which there are *many*. -Martin From mrex@sap.com Thu May 16 14:35:43 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E039511E810E for ; Thu, 16 May 2013 14:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkPYu3MOcu9m for ; Thu, 16 May 2013 14:35:38 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6AD11E80A2 for ; Thu, 16 May 2013 14:35:38 -0700 (PDT) Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r4GLYtL2020610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 May 2013 23:34:55 +0200 (MEST) In-Reply-To: <20130516192607.76FB21A73C@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Thu, 16 May 2013 23:34:55 +0200 (CEST) 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: <20130516213455.B37961A740@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "" , "" , "" , Jim Schaad , "" , RFC Errata System Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3623) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 16 May 2013 21:35:44 -0000 Some of my previous message seems garbled. The one and only explicit purpose of CRLNumber given in ITU-T Rec X.509: > It allows a CRL user to detect whether CRLS issued prior to the one being > processed were also seen and processed. means that a "CRL user" aka "Relying Party" may REQUIRE (whenever it feels like it) to have seen and processed *ALL* prior CRLs of a CA before considering a cert from that CA as valid. The CA is prohibited from doing anything that would interfere with RPs that want to make use of that guarantee from X.509, so formal logic deduction requires that a CA MUST issue their first CRL with number 0 and MUST NOT issue a CRL with CRLNumber (n+1) when it has not previously issued a CRLNumber (n) (and n is a valid number for a CRL to have). Speaking of rfc5280 section 5.2.3: What sections 5.2.3 CRLNumber and 5.2.4 Delta CRL Indicator of rfc5280 say about CRLNumbers of Delta CRLs looks incomprehensible to me and contains ambiguities and self-contraditions. It looks like a huge mess to me, containing formally provable logical fallacies. X.509 (11/2008) is also confusing, e.g. X.509 says: However, the cRLNumber referenced in the BaseRevocationInfo field of a dCRL shall be less than or equal to the cRLNumber of the most recently issued CRL that is complete for the applicable scope. which looks bogus and I assume really should have said: However, the CRLNumber referenced in the BaseRevocationInfo field cRLNumber of a dCRL shall be less than or equal to the CRLNumber of the most recently issued CRL that is complete for the applicable scope. based on the accompanying ASN.1 definitions: cRLNumber EXTENSION ::= { SYNTAX CRLNumber IDENTIFIED BY id-ce-cRLNumber } CRLNumber ::= INTEGER (0..MAX) BaseRevocationInfo ::= SEQUENCE { cRLStreamIdentifier [0] CRLStreamIdentifier OPTIONAL, cRLNumber [1] CRLNumber, baseThisUpdate [2] GeneralizedTime } Rfc5912 is slightly better by using "ext-CRLNumber" rather than "cRLNumber" for the extension type. I'm still an ASN.1 layman for most parts of ASN.1, and the correct terminology. Frankly, to me it looks like ASN.1 is at least a magnitude too difficult that it can be used in an error-free fashion in practice... I'm unaware of any non-trivial ASN.1-based protocol definition that is (a) error-free and (b) describes the actual behaviour of the installed base. -Martin From piyush@ditenity.com Thu May 16 15:26:34 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A667311E8110 for ; Thu, 16 May 2013 15:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRP10Wg7lwfP for ; Thu, 16 May 2013 15:26:32 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 020A311E8100 for ; Thu, 16 May 2013 15:26:31 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id 9so7848765iec.36 for ; Thu, 16 May 2013 15:26:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language:x-gm-message-state; bh=hrNxIWOXZkIo/Q+jXAkqNUCWHhLlqdCql5Q2rFbB0Ng=; b=lierxAW9WDAbzVZLWHVXrp0yU6/cj549fQo5C1tnTezkWqrrPZRu7uxeiYEFX0VZrH WaAs9GD5v+UiVM0HfETyDsajpixTK5BQ7tgYl3dnIziO4QjanzzslTSvDAchp8qFf5C5 XCSuy8LThsz8HLS9Cxo9OO7d7ktXy3w27ObJZ+/M4u9nM2OH4sC2RaPisRHNNY2sAs2i HUdunj/j7XlmSatT3E25IEZfbGccnbhv+3krO9LDqkd81Dz8fpb0ChDUiIizbfwLNyDD IlY/Xuk3sRG0eo6Jh+ytA8JSzseNtmB1AXTBiiwuRRFymsxtOmSvz3ekt5b9IzF8sjBD y3iA== X-Received: by 10.50.112.67 with SMTP id io3mr10978194igb.14.1368743191465; Thu, 16 May 2013 15:26:31 -0700 (PDT) Received: from piyushlaptop (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPSA id uv10sm6598963igb.3.2013.05.16.15.26.29 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 16 May 2013 15:26:30 -0700 (PDT) From: "Piyush J.comain" To: References: <20130516192607.76FB21A73C@ld9781.wdf.sap.corp> <20130516213455.B37961A740@ld9781.wdf.sap.corp> In-Reply-To: <20130516213455.B37961A740@ld9781.wdf.sap.corp> Date: Thu, 16 May 2013 15:26:28 -0700 Message-ID: <001d01ce5284$69eea010$3dcbe030$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQG27M/1YGBKsGFYpw4hWj2jzMlADJk3JBwg Content-Language: en-us X-Gm-Message-State: ALoCoQmbxE83awgduWvSNB6tCvkPFAbNsyxA2Q/+5jc9zBUiLjtQ8LnfloTAvJeqZiAUCok0icni Cc: stefan@aaa-sec.com, paul.hoffman@vpnc.org, jimsch@exmsft.com, 'Jim Schaad' , pkix@ietf.org, 'RFC Errata System' Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3623) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 22:26:34 -0000 > The one and only explicit purpose of CRLNumber given in ITU-T Rec X.509: > > > It allows a CRL user to detect whether CRLS issued prior to the one being > > processed were also seen and processed. > > means that a "CRL user" aka "Relying Party" may REQUIRE (whenever it feels > like it) to have seen and processed *ALL* prior CRLs of a CA before > considering a cert from that CA as valid. [Piyush] Why the CRL user needs to detect if all prior CRLs were processed is an open question and there may be legitimate use cases that can be addressed by doing so. But I cannot fathom why an RP will require that all prior CRLs be processed before considering a cert from that CA valid. One genuine use case that comes to mind is providing time based validation i.e. checking revocation status of a currently expired certificate at some time in the past. If the RP has missed a few prior CRLs, it cannot be sure if a now expired certificate was revoked at some point in the past and then removed from the CRL because it expired. So I agree with you that CRL Numbers should be in arithmetic progression with difference between consecutive numbers being 1. It is also easier to issue the first CRL with number 0 so it is implicit to the client that CRL with number 0 is the first CRL. However, the standard does not preclude the CA from issuing the first CRL with number 29678 and communicating this number of the first CRL to the RPs out of band. But these are theoretical discussions. I can't imagine an implementation that generates CRL numbers using geometric progression or even using arithmetic progression with difference being more than 1 unless the implementer is trying to reveal his sense of humor. > The CA is prohibited from doing anything that would interfere with RPs that > want to make use of that guarantee from X.509, so formal logic deduction > requires that a CA MUST issue their first CRL with number 0 As I said above CA may use any number for first CRL and publish that number as the one associated with the first CRL. >and MUST NOT > issue a CRL with CRLNumber (n+1) when it has not previously issued a > CRLNumber (n) (and n is a valid number for a CRL to have). True. > > > Speaking of rfc5280 section 5.2.3: > What sections 5.2.3 CRLNumber and 5.2.4 Delta CRL Indicator of rfc5280 say > about CRLNumbers of Delta CRLs looks incomprehensible to me and contains > ambiguities and self-contraditions. It looks like a huge mess to me, > containing formally provable logical fallacies. > > Specifics please. What are the self-contradictions and the logical fallacies. From mrex@sap.com Thu May 16 19:22:35 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0183D11E80F2 for ; Thu, 16 May 2013 19:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Maa83hhoBbQx for ; Thu, 16 May 2013 19:22:30 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9E96F21F8B2B for ; Thu, 16 May 2013 19:22:28 -0700 (PDT) Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r4H2LoN5027544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 May 2013 04:21:50 +0200 (MEST) In-Reply-To: <001d01ce5284$69eea010$3dcbe030$@ditenity.com> To: "Piyush J . comain" Date: Fri, 17 May 2013 04:21:50 +0200 (CEST) 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: <20130517022150.59B491A73F@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: stefan@aaa-sec.com, paul.hoffman@vpnc.org, jimsch@exmsft.com, 'Jim Schaad' , pkix@ietf.org, 'RFC Errata System' Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3623) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 02:22:35 -0000 Piyush J . comain wrote: > > The one and only explicit purpose of CRLNumber given in ITU-T Rec X.509: > > > > > It allows a CRL user to detect whether CRLS issued prior to the one > being > > > processed were also seen and processed. > > > > means that a "CRL user" aka "Relying Party" may REQUIRE (whenever it feels > > like it) to have seen and processed *ALL* prior CRLs of a CA before > > considering a cert from that CA as valid. > > [Piyush] Why the CRL user needs to detect if all prior CRLs were processed > is an open question and there may be legitimate use cases that can be > addressed by doing so. > But I cannot fathom why an RP will require that all prior CRLs be processed > before considering a cert from that CA valid. > > One genuine use case that comes to mind is providing time based validation > i.e. checking revocation status of a currently expired certificate at some > time in the past. If the RP has missed a few prior CRLs, it cannot be sure > if a now expired certificate was revoked at some point in the past and then > removed from the CRL because it expired. Correct, that is one possible consequence when allowing CAs to remove revoked certs from CRLs after they have expired when there were listed at least once on a complete CRL. > > > > Speaking of rfc5280 section 5.2.3: > > What sections 5.2.3 CRLNumber and 5.2.4 Delta CRL Indicator of rfc5280 say > > about CRLNumbers of Delta CRLs looks incomprehensible to me and contains > > ambiguities and self-contraditions. It looks like a huge mess to me, > > containing formally provable logical fallacies. > > > Specifics please. What are the self-contradictions and the logical > fallacies. Sorting that mess out will be a time-consuming job, and one that I won't do. Example provable non-sense (from the second paragraph of 5.2.3): If a delta CRL and a complete CRL that cover the same scope are issued at the same time, they MUST have the same CRL number and provide the same revocation information. That is, the combination of the delta CRL and an acceptable complete CRL MUST provide the same revocation information as the simultaneously issued complete CRL. If the deltaCRL would reference the concurrently generated complete CRL as BaseCRLNumber, then (allegedly intended meaning of) the second sentence would result in a tautology (the concurrently generated complete CRL being the only acceptable complete CRL in existence) and the deltaCRL would have to be empty. Therefore I assume the idea here was to create a deltaCRL to a prior baseCRL concurrently with a new complete CRL, so that CRL user could continue to use a "technically expired" baseCRL with that deltaCRL. The two defects in this paragraph are: (1) "the combination of the delta CRL and an acceptable complete CRL" (2) "MUST provide the same revocation information as ... complete CRL" What it may have actually meant is "the combination of the delta CRL and EVERY acceptable complete CRL MUST provide NO LESS revocation information as the simultaneouly issued complete CRL". (2) "The SAME revocation information" in the latter sentence is formally provable non-sense, because a delta-CRL may contain "removeFromCRL" entries that can not appear on the complete CRL, and that will require any temporary revocation they refer to not appear on the new complete CRL, although that temporary revocation information may have been present on an earlier complete CRL that is acceptable for combination with the deltaCRL. On top of that, unless this requirement is supposed to entirely void the permission for CAs to drop revoked certificates off the CRL after they have expired, there may be further revocation information missing on the new complete CRL that is available in the combination of the deltaCRL and an acceptable complete CRL -- in case that deltaCRL references a an earlier BaseCRLNumber than that of the concurrently generated complete CRL. (1) Since the first sentence starts with the premise "If a delta CRL and a complete CRL that cover the same scope are issued at the same time", the new complete CRL will be _an_ acceptable complete CRL for combination with the deltaCRL, so the use of "an acceptable complete CRL" is a misleading tautology. What is really important here, is that the "NO LESS revocation information" applies to combination of this delta CRL and *EVERY* acceptable complete CRL. I also believe that as a backwards compatibility requirement with X.509, the weird fashion how rfc5280 abused the CRLNumber extension in deltaCRLs (an idea that I did not see in X.509) implies that a CA will *ALWAYS* have to issue a complete CRL with every deltaCRL, otherwise it would create holes in the sequence numbers of complete CRLS, breaking a fundamental promise/assumption of X.509. -Martin From piyush@ditenity.com Thu May 16 21:08:38 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62A321F881F for ; Thu, 16 May 2013 21:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbSW7xE55XdJ for ; Thu, 16 May 2013 21:08:38 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1554C21F87CD for ; Thu, 16 May 2013 21:08:37 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id z6so876057yhz.39 for ; Thu, 16 May 2013 21:08:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language:x-gm-message-state; bh=pTQv+KyCpLxCxV98ZE4ODzcIHnQHd5B63XNCmj4OJGo=; b=UaRtNPNyjmbKQP1YjpsUmXyKJkUm5jfApxDWgQz2S3cHgvs6EgSv8NcOiu456ZzKGz c/Kl7B/c3Yv2t7XnCPtfHPClS9NOOXCheRo/8DlEXltsAgbTu5bFrt5jc2yvYraxFsB6 A+7Fi8BboW3VLKSUjEqrh1PWF0tBncx7kG+V6QaMNSSZnzao+JMOJSJJdsNGJ3fg+u/g 73KB4ow+V6s1XP8ofv/mthz9sX9yqG84OUeuhLsMic2SCRp+XlNrW3D8Ii4wqBpiUmh7 QoeO02b84xryIA7t8Tk18561UzXFBTGXJLWjLg4jTvg156MsbNZgyAhzRdYVXYGRPA3n VMOg== X-Received: by 10.236.151.197 with SMTP id b45mr24451764yhk.89.1368763717497; Thu, 16 May 2013 21:08:37 -0700 (PDT) Received: from piyushlaptop (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPSA id v27sm14423578yhj.12.2013.05.16.21.08.35 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 16 May 2013 21:08:37 -0700 (PDT) From: "Piyush J.comain" To: References: <001d01ce5284$69eea010$3dcbe030$@ditenity.com> <20130517022150.59B491A73F@ld9781.wdf.sap.corp> In-Reply-To: <20130517022150.59B491A73F@ld9781.wdf.sap.corp> Date: Thu, 16 May 2013 21:08:33 -0700 Message-ID: <004301ce52b4$33f72970$9be57c50$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHDsf1cE48+tIwPdd4Pnds7ipVo/pkd9mzQ Content-Language: en-us X-Gm-Message-State: ALoCoQlU+IOkqp4u0jFCDc+8x3uNwv/npKZBjYzlrDAAmTVcPUNUM9tW2LDrCkmZm8ZyW+FtF1cZ Cc: stefan@aaa-sec.com, paul.hoffman@vpnc.org, jimsch@exmsft.com, 'Jim Schaad' , pkix@ietf.org, 'RFC Errata System' Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3623) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 04:08:39 -0000 > Example provable non-sense (from the second paragraph of 5.2.3): > > If a delta CRL and a complete CRL that cover the > same scope are issued at the same time, they MUST have the same CRL > number and provide the same revocation information. That is, the > combination of the delta CRL and an acceptable complete CRL MUST > provide the same revocation information as the simultaneously issued > complete CRL. > > If the deltaCRL would reference the concurrently generated complete CRL as > BaseCRLNumber, [Piyush] That would be incorrect. A delta cannot be combined with concurrently generated CRL. Section 5.2.4 bullet (d). then (allegedly intended meaning of) the second sentence > would result in a tautology (the concurrently generated complete CRL being > the only acceptable complete CRL in existence) and the deltaCRL would have > to be empty. > > Therefore I assume the idea here was to create a deltaCRL to a prior baseCRL > concurrently with a new complete CRL, so that CRL user could continue to > use a "technically expired" baseCRL with that deltaCRL. > [Piyush] correct. > > The two defects in this paragraph are: > (1) "the combination of the delta CRL and an acceptable complete CRL" > (2) "MUST provide the same revocation information as ... complete CRL" > [Piyush] I don't see the defect. > What it may have actually meant is > "the combination of the delta CRL and EVERY acceptable complete CRL > MUST provide NO LESS revocation information as the simultaneouly > issued complete CRL". > [Piyush] An acceptable complete CRL to merge with a delta is one with the CRL number greater than or equal to the one that is referenced as base CRL number in the delta. Once the merging happens the merged CRL would contain the same entries as a concurrently issued complete CRL. > > (2) "The SAME revocation information" in the latter sentence is formally > provable non-sense, because a delta-CRL may contain "removeFromCRL" > entries that can not appear on the complete CRL, and that will require any > temporary revocation they refer to not appear on the new complete CRL, > although that temporary revocation information may have been present on > an earlier complete CRL that is acceptable for combination with the deltaCRL. > [Piyush] Depends on how you interpret "SAME revocation information". "removeFromCRL" is a mechanism to indicate that entry was removed from CRL i.e. the cert referenced by that entry is not considered revoked anymore. The absence of the entry in the concurrent complete CRL indicates the same thing. > On top of that, unless this requirement is supposed to entirely void the > permission for CAs to drop revoked certificates off the CRL after they have > expired, there may be further revocation information missing on the new > complete CRL that is available in the combination of the deltaCRL and an > acceptable complete CRL -- in case that deltaCRL references a an earlier > BaseCRLNumber than that of the concurrently generated complete CRL. [Piyush] removeFromCRL just indicates that the entry was removed from the complete CRL. It could be because the cert was reinstated or because it expired. > > (1) Since the first sentence starts with the premise "If a delta CRL and a > complete CRL that cover the same scope are issued at the same time", the > new complete CRL will be _an_ acceptable complete CRL for combination > with the deltaCRL, so the use of "an acceptable complete CRL" is a misleading > tautology. What is really important here, is that the "NO LESS revocation > information" > applies to combination of this delta CRL and *EVERY* acceptable complete > CRL. > [Piyush] An acceptable complete CRL's number must be less than that of the delta. So concurrently issued CRL cannot be an acceptable CRL to merge with the delta. > > I also believe that as a backwards compatibility requirement with X.509, the > weird fashion how rfc5280 abused the CRLNumber extension in deltaCRLs > (an idea that I did not see in X.509) implies that a CA will *ALWAYS* have to > issue a complete CRL with every deltaCRL, otherwise it would create holes in > the sequence numbers of complete CRLS, breaking a fundamental > promise/assumption of X.509. > [Piyush] I don't think that your conclusion is correct. CAs can issue deltas more frequently than complete CRLs. e.g. CRL number 'n' could be associated with both a delta and a full, numbers 'n+1', 'n+2', 'n+3' would be associated with just deltas and 'n+4' would be again associated with both delta and complete. > > -Martin From mrex@sap.com Fri May 17 00:11:20 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF7521F93BA for ; Fri, 17 May 2013 00:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mf+YbntUQ4vZ for ; Fri, 17 May 2013 00:11:15 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id C351421F9253 for ; Fri, 17 May 2013 00:11:11 -0700 (PDT) Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r4H7Auvi008254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 May 2013 09:10:56 +0200 (MEST) In-Reply-To: <004301ce52b4$33f72970$9be57c50$@ditenity.com> To: "Piyush J . comain" Date: Fri, 17 May 2013 09:10:56 +0200 (CEST) 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: <20130517071056.8A6A01A73B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: stefan@aaa-sec.com, paul.hoffman@vpnc.org, jimsch@exmsft.com, 'Jim Schaad' , pkix@ietf.org, 'RFC Errata System' Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3623) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 07:11:20 -0000 Piyush J . comain wrote: > > Example provable non-sense (from the second paragraph of 5.2.3): > > > > If a delta CRL and a complete CRL that cover the > > same scope are issued at the same time, they MUST have the same CRL > > number and provide the same revocation information. That is, the > > combination of the delta CRL and an acceptable complete CRL MUST > > provide the same revocation information as the simultaneously issued > > complete CRL. > > > > If the deltaCRL would reference the concurrently generated complete CRL as > > BaseCRLNumber, > [Piyush] That would be incorrect. A delta cannot be combined with > concurrently generated CRL. Section 5.2.4 bullet (d). While I had not read through that section, this is relevant exclusively to "CAs conforming to rfc5280" (if at all), but NOT for RPs, _unless_ the same exists in ITU-T Rec. X.509 08/2005 due to the guidance in rfc5280 section 6.1: Therefore, the algorithm only includes checks to verify that the certification path is valid according to X.509 and does not include checks to verify that the certificates and CRLs conform to this profile. While the algorithm could be extended to include checks for conformance to the profiles in Sections 4 and 5, this profile RECOMMENDS against including such checks. > > The two defects in this paragraph are: > > (1) "the combination of the delta CRL and an acceptable complete CRL" > > (2) "MUST provide the same revocation information as ... complete CRL" > > > > What it may have actually meant is > > "the combination of the delta CRL and EVERY acceptable complete CRL > > MUST provide NO LESS revocation information as the simultaneouly > > issued complete CRL". > > > [Piyush] An acceptable complete CRL to merge with a delta is one with the > CRL number greater than or equal to the one that is referenced as base CRL > number in the delta. Once the merging happens the merged CRL would contain > the same entries as a concurrently issued complete CRL. (1) it says "the combination of ... revocation information" which is NOT equal to first merging the CRLs and then looking at the result. (2) removing expired certs from any "merged CRL" locally created by the RP (a) is neither required, nor appropriate, nor reasonable, and the CRL does not even whether the CA would remove expired certs. (b) not even possible for the RP, because it only sees cert serials > > > > (2) "The SAME revocation information" in the latter sentence is formally > > provable non-sense, because a delta-CRL may contain "removeFromCRL" > > entries that can not appear on the complete CRL, and that will require any > > temporary revocation they refer to not appear on the new complete CRL, > > although that temporary revocation information may have been present on > > an earlier complete CRL that is acceptable for combination with the > deltaCRL. > > [Piyush] Depends on how you interpret "SAME revocation information". I think we can safely ignore such unreasonable/illogical interpretations. > "removeFromCRL" is a mechanism to indicate that entry was removed from CRL > i.e. the cert referenced by that entry is not considered revoked anymore. > The absence of the entry in the concurrent complete CRL indicates the same > thing. Knowing that a cert was temporarily revoked during some time in the past is _still_ "revocation information", no matter how you look at it. Whether such information is useful or relevant for checks performed by the RP is highly dependent on the RP's usage scenario and/or purpose. For stuff that is also digitally timestamped (e.g. rfc3161), the certificate status at the time indicated by the secure timestamp might be MUCH more relevant than the current cert status (which may even be expired by then). btw. which well-known CRL extension will be present on complete CRLs where the CA does stupid things such as removing revoked certs after they expire, or no longer accept and publish revocations for a cert that has expired? And where in rfc5280/pkix is the algorithm described for the RP software to determine and obtain the necessary CRL to determine the cert status for some point in the past for an already expired cert? Allowing CAs to drop certs off CRLs without either of these being standardized and used, would make S/Mime/CMS pretty useless for offline use and archival, including use in EMail. > > > On top of that, unless this requirement is supposed to entirely void the > > permission for CAs to drop revoked certificates off the CRL after they > have > > expired, there may be further revocation information missing on the new > > complete CRL that is available in the combination of the deltaCRL and an > > acceptable complete CRL -- in case that deltaCRL references a an earlier > > BaseCRLNumber than that of the concurrently generated complete CRL. > [Piyush] removeFromCRL just indicates that the entry was removed from the > complete CRL. It could be because the cert was reinstated or because it > expired. > > > > > (1) Since the first sentence starts with the premise "If a delta CRL and a > > complete CRL that cover the same scope are issued at the same time", the > > new complete CRL will be _an_ acceptable complete CRL for combination > > with the deltaCRL, so the use of "an acceptable complete CRL" is a > misleading > > tautology. What is really important here, is that the "NO LESS revocation > > information" > > applies to combination of this delta CRL and *EVERY* acceptable complete > > CRL. > > > [Piyush] An acceptable complete CRL's number must be less than that of the > delta. So concurrently issued CRL cannot be an acceptable CRL to merge with > the delta. > > > > I also believe that as a backwards compatibility requirement with X.509, > > the weird fashion how rfc5280 abused the CRLNumber extension in deltaCRLs > > (an idea that I did not see in X.509) implies that a CA will *ALWAYS* have > > to issue a complete CRL with every deltaCRL, otherwise it would create > > holes in the sequence numbers of complete CRLS, breaking a fundamental > > promise/assumption of X.509. > > [Piyush] I don't think that your conclusion is correct. CAs can issue deltas > more frequently than complete CRLs. They technically could, but they will fundamentally break X.509 if they do. > e.g. CRL number 'n' could be associated with both a delta and a full, > numbers 'n+1', 'n+2', 'n+3' would be associated with just deltas and 'n+4' > would be again associated with both delta and complete. Nope, that would create 3 holes "n+1", "n+2" and "n+3" in the sequence numbering of complete CRLs. The X.509 promise about CRLNumber is that it will be monotonically increasing, that the CRL user aka RP is allowed to use CRLNumber to ensure that it has seen and processed all prior CRLs, while allowing the very same RP to be entirely ignorant about delta CRLs. -Martin From eabalea@gmail.com Fri May 17 01:24:15 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADCD21F85C7 for ; Fri, 17 May 2013 01:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytMb1nbi6nXt for ; Fri, 17 May 2013 01:24:14 -0700 (PDT) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id F302221F855A for ; Fri, 17 May 2013 01:24:13 -0700 (PDT) Received: by mail-vb0-f46.google.com with SMTP id 10so2038797vbe.5 for ; Fri, 17 May 2013 01:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=cFdTyGOa/712fqhnUPEZowLjK91g1KnDv186gBA+b/A=; b=E5zJFNDPuDEIc6rTHIPcJavZmv3sCMdrdLBmfyrp6xl4m13qkOiPiapOZo4t4eO2tx 4axsFy4D2SZvSxGp76kAaamR0wX64MDAjWRkWm1OK/9rKmteO2fwAa0k9ilma98TIS7y Gmi3WuTKucDr1sxJeMbVxOjfGW7Jr9JTncuuCGO+velBuHnUXAn5mpZe4eLoUcmol1cI EybypIbxENzxzn+biwEtrxycHsvhX2YfPm15AhNKeFeEC09KJ2o7BZNULxRphFfgQBlT m7+QBeMalBxDrHRpulyFarZtNe22cnwuJ67JOixhYCxcgURb2w4aWFpmcp+j/qNazj8J SPJg== MIME-Version: 1.0 X-Received: by 10.58.22.36 with SMTP id a4mr29613077vef.28.1368779053460; Fri, 17 May 2013 01:24:13 -0700 (PDT) Received: by 10.52.180.130 with HTTP; Fri, 17 May 2013 01:24:13 -0700 (PDT) In-Reply-To: <20130517071056.8A6A01A73B@ld9781.wdf.sap.corp> References: <004301ce52b4$33f72970$9be57c50$@ditenity.com> <20130517071056.8A6A01A73B@ld9781.wdf.sap.corp> Date: Fri, 17 May 2013 10:24:13 +0200 Message-ID: From: Erwann Abalea To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: Stefan Santesson , Paul Hoffman , jimsch@exmsft.com, Jim Schaad , pkix@ietf.org, RFC Errata System Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3623) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 08:24:15 -0000 2013/5/17 Martin Rex : > Piyush J . comain wrote: [...] >> [Piyush] An acceptable complete CRL's number must be less than that of the >> delta. So concurrently issued CRL cannot be an acceptable CRL to merge with >> the delta. >> > >> > I also believe that as a backwards compatibility requirement with X.509, >> > the weird fashion how rfc5280 abused the CRLNumber extension in deltaCRLs >> > (an idea that I did not see in X.509) implies that a CA will *ALWAYS* have >> > to issue a complete CRL with every deltaCRL, otherwise it would create >> > holes in the sequence numbers of complete CRLS, breaking a fundamental >> > promise/assumption of X.509. >> >> [Piyush] I don't think that your conclusion is correct. CAs can issue deltas >> more frequently than complete CRLs. > > They technically could, but they will fundamentally break X.509 if they do. > >> e.g. CRL number 'n' could be associated with both a delta and a full, >> numbers 'n+1', 'n+2', 'n+3' would be associated with just deltas and 'n+4' >> would be again associated with both delta and complete. > > Nope, that would create 3 holes "n+1", "n+2" and "n+3" in the sequence > numbering of complete CRLs. The X.509 promise about CRLNumber is that > it will be monotonically increasing, that the CRL user aka RP is allowed > to use CRLNumber to ensure that it has seen and processed all prior CRLs, > while allowing the very same RP to be entirely ignorant about delta CRLs. See X.509 Annex C for such examples. -- Erwann. From ietf@augustcellars.com Fri May 17 01:30:22 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD7521F92CB for ; Fri, 17 May 2013 01:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrbDvZJL3Y4t for ; Fri, 17 May 2013 01:30:17 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id BAD9C21F924A for ; Fri, 17 May 2013 01:30:17 -0700 (PDT) Received: from Philemon (unknown [88.214.187.250]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 0C88F2C9F7; Fri, 17 May 2013 01:30:13 -0700 (PDT) From: "Jim Schaad" To: "'Erwann Abalea'" , "'Jim Schaad'" References: <20130516110751.438AC62103@rfc-editor.org> <05f301ce5249$28be3f50$7a3abdf0$@augustcellars.com> In-Reply-To: Date: Fri, 17 May 2013 09:29:22 +0100 Message-ID: <064401ce52d8$a5eeb060$f1cc1120$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKuR1tHlnNqYs/us1ZC1fWGtUuH3QIsBP1tAo5UC3+XI0+qAA== Content-Language: en-us Cc: 'RFC Errata System' , 'Stefan Santesson' , jimsch@exmsft.com, 'Paul Hoffman' , pkix@ietf.org Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3623) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 08:30:22 -0000 The following text is from RFC 5280 id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } CRLNumber ::= INTEGER (0..MAX) This says that the ASN.1 makes it a positive number > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Erwann Abalea > Sent: Thursday, May 16, 2013 5:01 PM > To: Jim Schaad > Cc: Stefan Santesson; Paul Hoffman; jimsch@exmsft.com; pkix@ietf.org; RFC > Errata System > Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3623) > > The certificate serialNumber is limited to [0 .. 256^20] in value. > The CRLNumber is limited to [-256^20 .. 256^20], it's not said to be a positive > integer. > > 2013/5/16 Jim Schaad : > > Reject > > > > The serial number MUST be a positive integer assigned by the CA to > > each certificate. > > > > > >> -----Original Message----- > >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > >> Sent: Thursday, May 16, 2013 12:08 PM > >> To: paul.hoffman@vpnc.org; jimsch@exmsft.com; > >> stephen.farrell@cs.tcd.ie; turners@ieca.com; kent@bbn.com; > >> stefan@aaa-sec.com > >> Cc: carl@redhoundsoftware.com; pkix@ietf.org; > >> rfc-editor@rfc-editor.org > >> Subject: [Technical Errata Reported] RFC5912 (3623) > >> > >> The following errata report has been submitted for RFC5912, "New > >> ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)". > >> > >> -------------------------------------- > >> You may review the report below and at: > >> http://www.rfc-editor.org/errata_search.php?rfc=5912&eid=3623 > >> > >> -------------------------------------- > >> Type: Technical > >> Reported by: Carl Wallace > >> > >> Section: 14 > >> > >> Original Text > >> ------------- > >> -- CRL number extension OID and syntax > >> ext-CRLNumber EXTENSION ::= {SYNTAX > >> INTEGER (0..MAX) IDENTIFIED BY id-ce-cRLNumber } > >> id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } > >> > >> CRLNumber ::= INTEGER (0..MAX) > >> > >> Corrected Text > >> -------------- > >> -- CRL number extension OID and syntax > >> CRLNumber ::= INTEGER > >> > >> ext-CRLNumber EXTENSION ::= {SYNTAX > >> CRLNumber IDENTIFIED BY id-ce-cRLNumber } > >> id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } > >> > >> > >> Notes > >> ----- > >> The CRLNumber extension was not defined to use the CRLNumber type. > >> The CRLNumber type uses MAX to limit the maximum value. This > >> limitation is inconsistent with section 5.2.3 and Appendix B, which > >> allow CRLNumber values up to 20 octets in length. > >> > >> Instructions: > >> ------------- > >> This errata 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. > >> > >> -------------------------------------- > >> RFC5912 (draft-ietf-pkix-new-asn1-08) > >> -------------------------------------- > >> Title : New ASN.1 Modules for the Public Key Infrastructure > > Using > >> X.509 (PKIX) > >> Publication Date : June 2010 > >> Author(s) : P. Hoffman, J. Schaad > >> Category : INFORMATIONAL > >> 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 > > > > -- > Erwann. > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Fri May 17 03:06:46 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7301521F93A5 for ; Fri, 17 May 2013 03:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6MOZnbdhbub for ; Fri, 17 May 2013 03:06:41 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF4421F8C23 for ; Fri, 17 May 2013 03:06:40 -0700 (PDT) Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r4HA6CfM027288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 May 2013 12:06:12 +0200 (MEST) In-Reply-To: To: Erwann Abalea Date: Fri, 17 May 2013 12:06:08 +0200 (CEST) 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: <20130517100608.C3D381A73B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Stefan Santesson , Paul Hoffman , jimsch@exmsft.com, Jim Schaad , pkix@ietf.org, RFC Errata System Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3623) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 10:06:46 -0000 Erwann Abalea wrote: [ Charset UTF-8 unsupported, converting... ] > 2013/5/17 Martin Rex : > > Piyush J . comain wrote: > [...] > >> [Piyush] An acceptable complete CRL's number must be less than that of the > >> delta. So concurrently issued CRL cannot be an acceptable CRL to merge with > >> the delta. > >> > > >> > I also believe that as a backwards compatibility requirement with X.509, > >> > the weird fashion how rfc5280 abused the CRLNumber extension in deltaCRLs > >> > (an idea that I did not see in X.509) implies that a CA will *ALWAYS* have > >> > to issue a complete CRL with every deltaCRL, otherwise it would create > >> > holes in the sequence numbers of complete CRLS, breaking a fundamental > >> > promise/assumption of X.509. > >> > >> [Piyush] I don't think that your conclusion is correct. CAs can issue deltas > >> more frequently than complete CRLs. > > > > They technically could, but they will fundamentally break X.509 if they do. > > > >> e.g. CRL number 'n' could be associated with both a delta and a full, > >> numbers 'n+1', 'n+2', 'n+3' would be associated with just deltas and 'n+4' > >> would be again associated with both delta and complete. > > > > Nope, that would create 3 holes "n+1", "n+2" and "n+3" in the sequence > > numbering of complete CRLs. The X.509 promise about CRLNumber is that > > it will be monotonically increasing, that the CRL user aka RP is allowed > > to use CRLNumber to ensure that it has seen and processed all prior CRLs, > > while allowing the very same RP to be entirely ignorant about delta CRLs. > > See X.509 Annex C for such examples. Whoa there! more flying pigs (in Appendix B of X.509 08/2005): (Thanks for the pointer, though). B.5.2 Validate delta CRL scope The dCRL shall be issued after the base CRL. One way to ensure this is to check that the CRL number in the crlNumber extension of the dCRL is greater than the CRL number in the crlNumber extension of the base CRL the relying party is using and the cRLStreamIdentifier fields in the base and the dCRL match. This approach may require additional logic to account for number wrapping. Another way is to compare the thisUpdate fields in the base and dCRLs the relying party has; Wrapping a CRLNumber that is defined as montonically increasing from the INTEGER range (0..MAX) exceed "positive infinity" and wraps is a lame argument (OK, CRLs require DER encoding, and DER doesn't allow indefinite length encoding, but anyhow). Curiously, I found the following in an X.509: BaseCRLNumber ::= CRLNumber The value of type BaseCRLNumber identifies the CRL number of the base CRL that was used as the starting point in the generation of this delta-CRL, i.e. this delta-CRL contains the changes between the base CRL and the complete CRL issued along with this delta-CRL. It is the decision of a CA as to whether to provide delta-CRLs. However, a delta-CRL shall not be issued without a corresponding complete CRL being issued at the same time. The value of the CRL number, as conveyed in the CRL number extension field (if present), shall be identical for both the delta-CRL and the corresponding complete CRL. Some of this text is carried through in rfc5280. Curiously, some of it got dropped in a clearly backwards-incompatible and formally provable breaking fashion from newer specs. Ouch! -Martin From era@x500.eu Fri May 17 03:32:14 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B92721F9128 for ; Fri, 17 May 2013 03:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.01 X-Spam-Level: ** X-Spam-Status: No, score=2.01 tagged_above=-999 required=5 tests=[BAYES_60=1, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNIKnGcxId3b for ; Fri, 17 May 2013 03:32:08 -0700 (PDT) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id 3586221F8607 for ; Fri, 17 May 2013 03:32:08 -0700 (PDT) Received: from ([62.44.135.250]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id CPX90600 for ; Fri, 17 May 2013 12:32:00 +0200 From: "Erik Andersen" To: "PKIX" Date: Fri, 17 May 2013 12:31:58 +0200 Message-ID: <002d01ce52e9$c49dda20$4dd98e60$@eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01CE52FA.8826AA20" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5S6cJrdkbWihZrTkCsKtjXGLYclQ== Content-Language: da Subject: [pkix] Whitelisting X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 10:32:14 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002E_01CE52FA.8826AA20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit There were some ideas about whitelisting of certificates. What is the status? Erik ------=_NextPart_000_002E_01CE52FA.8826AA20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There were = some ideas about whitelisting of certificates. What is the = status?

 

Erik

------=_NextPart_000_002E_01CE52FA.8826AA20-- From wwwrun@rfc-editor.org Fri May 17 03:34:47 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398E421F93E8 for ; Fri, 17 May 2013 03:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SY+lL5-T4Z7i for ; Fri, 17 May 2013 03:34:46 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D04BE21F90C1 for ; Fri, 17 May 2013 03:34:46 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 611066210E; Fri, 17 May 2013 03:34:32 -0700 (PDT) To: paul.hoffman@vpnc.org, jimsch@exmsft.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20130517103432.611066210E@rfc-editor.org> Date: Fri, 17 May 2013 03:34:32 -0700 (PDT) Cc: pkix@ietf.org, rfc-editor@rfc-editor.org Subject: [pkix] [Technical Errata Reported] RFC5912 (3626) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 10:34:47 -0000 The following errata report has been submitted for RFC5912, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5912&eid=3626 -------------------------------------- Type: Technical Reported by: Carl Wallace Section: 14 Original Text ------------- -- CRL number extension OID and syntax ext-CRLNumber EXTENSION ::= {SYNTAX INTEGER (0..MAX) IDENTIFIED BY id-ce-cRLNumber } id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } CRLNumber ::= INTEGER (0..MAX) Corrected Text -------------- -- CRL number extension OID and syntax CRLNumber ::= INTEGER (0..MAX) ext-CRLNumber EXTENSION ::= {SYNTAX CRLNumber IDENTIFIED BY id-ce-cRLNumber } id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } Notes ----- The CRLNumber extension was not defined to use the CRLNumber type. It should use the CRLNumber type. This is a corrected resubmission of an earlier errata submission that included an error. Instructions: ------------- This errata 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. -------------------------------------- RFC5912 (draft-ietf-pkix-new-asn1-08) -------------------------------------- Title : New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) Publication Date : June 2010 Author(s) : P. Hoffman, J. Schaad Category : INFORMATIONAL Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From eabalea@gmail.com Fri May 17 06:57:25 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C1221F95E0 for ; Fri, 17 May 2013 06:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPnmGxJ0cwJ7 for ; Fri, 17 May 2013 06:57:25 -0700 (PDT) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 320DC21F95C4 for ; Fri, 17 May 2013 06:57:19 -0700 (PDT) Received: by mail-vb0-f50.google.com with SMTP id w15so1149764vbb.9 for ; Fri, 17 May 2013 06:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=D+lc5qQTtAC5Qp5A1TfD0b9lie3Qm2Bj3u+Qw4fW4FU=; b=fRA+LvwA7ruETqWCVl8aWtqX7X8NbByQiQwn7k5GrvImhc8ogBMg6YCwXEu++QJHI1 0piLQhSJF1GnlIyAyc4xtlfvtzWQ2VIyfCmjmtpRQjg5GRgH5CZ3DkT0eJ3Q1MY28ZOo l/f6S+jlHeklsU9UIKGmVZb0t+i4KsBbz6gUcNng2eCsEeqkRH4p/p4rj6ZkV8LNmtlP yWlkTPNhuKdAzouHx+hGvvOviu4MtCmq3RvKBqo9ZzhadCB3GdB9LPRpgYSZ2cvJQ2ch 7ZAFvbFDM0zDz3tHAuObi43jnO90uyuDExrbk6W+9dHQUU+VnuVGMhbZ5TxQeNXEPN22 Eupw== MIME-Version: 1.0 X-Received: by 10.220.223.202 with SMTP id il10mr30314208vcb.4.1368799038613; Fri, 17 May 2013 06:57:18 -0700 (PDT) Received: by 10.52.180.130 with HTTP; Fri, 17 May 2013 06:57:18 -0700 (PDT) In-Reply-To: <002d01ce52e9$c49dda20$4dd98e60$@eu> References: <002d01ce52e9$c49dda20$4dd98e60$@eu> Date: Fri, 17 May 2013 15:57:18 +0200 Message-ID: From: Erwann Abalea To: Erik Andersen Content-Type: text/plain; charset=UTF-8 Cc: PKIX Subject: Re: [pkix] Whitelisting X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 13:57:25 -0000 Are you talking about MECAI, Google CT, EFF Sovereign Keys, and similar ideas? 2013/5/17 Erik Andersen : > There were some ideas about whitelisting of certificates. What is the > status? -- Erwann. From mrex@sap.com Fri May 17 07:10:02 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B07B21F933B for ; Fri, 17 May 2013 07:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tb5VXWwJ0ydR for ; Fri, 17 May 2013 07:09:58 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id AEC0A21F8B64 for ; Fri, 17 May 2013 07:09:57 -0700 (PDT) Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r4HE9tMY001557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 May 2013 16:09:55 +0200 (MEST) In-Reply-To: To: Erwann Abalea Date: Fri, 17 May 2013 16:09:55 +0200 (CEST) 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: <20130517140955.551F21A740@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: PKIX Subject: Re: [pkix] Whitelisting X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 14:10:02 -0000 I assume Erik was asking about an OCSP Extension "Proof of cert issuance", such as a CertHash included with an OCSP "good" status. One example for an "existing solution" was mentioned by Johannes Merkle and is quoted here: http://www.ietf.org/mail-archive/web/pkix/current/msg32667.html -Martin Erwann Abalea wrote: > Are you talking about MECAI, Google CT, EFF Sovereign Keys, and similar ideas? > > 2013/5/17 Erik Andersen : > > There were some ideas about whitelisting of certificates. What is the > > status? From era@x500.eu Fri May 17 07:31:16 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CD321F933B for ; Fri, 17 May 2013 07:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, HELO_EQ_DK=1.009] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BcFW9X41UwY for ; Fri, 17 May 2013 07:31:11 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id A642621F9452 for ; Fri, 17 May 2013 07:31:10 -0700 (PDT) Received: from ([62.44.135.170]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id CTW45007 for ; Fri, 17 May 2013 16:31:07 +0200 From: "Erik Andersen" To: "PKIX" References: <20130517140955.551F21A740@ld9781.wdf.sap.corp> In-Reply-To: <20130517140955.551F21A740@ld9781.wdf.sap.corp> Date: Fri, 17 May 2013 16:31:05 +0200 Message-ID: <004701ce530b$2bcca2a0$8365e7e0$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5TCDoa2NRmForWTNiuLvaqhXO5CAAAhXVA Content-Language: da Subject: Re: [pkix] Whitelisting X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 14:31:16 -0000 The reason I am asking is that I am sitting with a document that I am commenting. It says: "In certain deployments, additional support is necessary to further restrict the usage of certificates based on their serial numbers and issuers. This restriction is known as certificate white listing or certificate pinning, and is currently being defined in the IETF" I was trying to find out whether that is true and if yes, what the status is. Erik -----Oprindelig meddelelse----- Fra: Martin Rex [mailto:mrex@sap.com] Sendt: 17. maj 2013 16:10 Til: Erwann Abalea Cc: Erik Andersen; PKIX Emne: Re: [pkix] Whitelisting I assume Erik was asking about an OCSP Extension "Proof of cert issuance", such as a CertHash included with an OCSP "good" status. One example for an "existing solution" was mentioned by Johannes Merkle and is quoted here: http://www.ietf.org/mail-archive/web/pkix/current/msg32667.html -Martin Erwann Abalea wrote: > Are you talking about MECAI, Google CT, EFF Sovereign Keys, and similar ideas? > > 2013/5/17 Erik Andersen : > > There were some ideas about whitelisting of certificates. What is > > the status? From agl@google.com Fri May 17 07:35:32 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E379621F9530 for ; Fri, 17 May 2013 07:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2PNzYNiWUDu for ; Fri, 17 May 2013 07:35:32 -0700 (PDT) Received: from mail-ia0-x230.google.com (mail-ia0-x230.google.com [IPv6:2607:f8b0:4001:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 48F6221F9298 for ; Fri, 17 May 2013 07:35:32 -0700 (PDT) Received: by mail-ia0-f176.google.com with SMTP id j3so2594520iae.35 for ; Fri, 17 May 2013 07:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MBB8//wE0UOfs/Bgiqq9YSKoz8Zu2v8x7bBcZLeAEiE=; b=SsXG89uaBpOxy22fstAiXQcuYgREQsmVQsL2WIUtfRgKV4CISoRt60wWalfXbxruru x8oiTNmW1J76lQhRS+U9T5y2x78E/J7+rBvZTXaCavh889Zre/U2NEqCQxBrSZTTZlRG kSPswzdG0c4hZaI6XYZTjnb5Kw3Ipxexpn9VaDsJ7gvzuBy2XGa7yKd5eES3jtWRdIdN 2sQELpgi2AkH3mWbPSNjyJS13172j3DSH1BKk4WBZ0V5ShsG7bClEe64+vYyEOfS9FAt d8JA1c0rnSRZ1Uk0R6mLurhw274wd15jjSv1SsDJdIc1DqGB7MTYpmLX30eFJPZvzcl2 QVgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=MBB8//wE0UOfs/Bgiqq9YSKoz8Zu2v8x7bBcZLeAEiE=; b=OUQT1MFun9BWycOaszqkQo1D6+MmJek9wrVYss9eyXNnQS0mwvYQNl81SHQASBXJTW KL2QfGjDioU7ud81/M1ykTp9XCPk3vlGjPDQtVlgvylciw2ONYkbOzvZXrf1xgsQK+mz tgmbx9TKsIuR+IxZOsl7rD/sSbXPj2KwKnC5znfq+wSdHqmausNLO5OuLhHXXvOWvsTA wemdt9Uk0bLjwWzw2OQlPcjcvQw2R56rfhwOPSlcbuu3FT4Psj0W+cpecGj5fZu3aM+1 MD68CVGPQSEBCSFsPAsHzNryQ0Fk1flK4/5v0WnepXAcKfN8YUP1miS+UbDsUYxPglQ+ ifsg== MIME-Version: 1.0 X-Received: by 10.50.12.3 with SMTP id u3mr13487131igb.1.1368801331790; Fri, 17 May 2013 07:35:31 -0700 (PDT) Received: by 10.231.196.71 with HTTP; Fri, 17 May 2013 07:35:31 -0700 (PDT) In-Reply-To: <004701ce530b$2bcca2a0$8365e7e0$@eu> References: <20130517140955.551F21A740@ld9781.wdf.sap.corp> <004701ce530b$2bcca2a0$8365e7e0$@eu> Date: Fri, 17 May 2013 10:35:31 -0400 Message-ID: From: Adam Langley To: Erik Andersen Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmIWT24suLWFM+UohAoewqZUOsbpjDL3HzNNkILljrP/A3Y4weG9xMUWmFV261maMAeOhnnTuMcuykZgswKWcB1F0LSj1anv1/raVQoVWpnI/xDWxIg3RxiX+PiO6cz1KVO5tdmRfyCF1k3d1tNhh0L91s1c7PUPahYNQHPDxgMNG/CLcCfEffzllhIrDVqaY7qgYQV Cc: PKIX Subject: Re: [pkix] Whitelisting X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 14:35:33 -0000 On Fri, May 17, 2013 at 10:31 AM, Erik Andersen wrote: > The reason I am asking is that I am sitting with a document that I am > commenting. It says: > > "In certain deployments, additional support is necessary to further restrict > the usage of certificates based on their serial numbers and issuers. This > restriction is known as certificate white listing or certificate pinning, > and is currently being defined in the IETF" > > I was trying to find out whether that is true and if yes, what the status > is. It is possibly this document: https://tools.ietf.org/html/draft-ietf-websec-key-pinning-04 Cheers AGL From piyush@ditenity.com Fri May 17 08:06:17 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0334121F961F for ; Fri, 17 May 2013 08:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlZGyRVrRfa7 for ; Fri, 17 May 2013 08:06:16 -0700 (PDT) Received: from mail-gg0-x22b.google.com (mail-gg0-x22b.google.com [IPv6:2607:f8b0:4002:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECD221F961D for ; Fri, 17 May 2013 08:06:16 -0700 (PDT) Received: by mail-gg0-f171.google.com with SMTP id h13so885444ggd.2 for ; Fri, 17 May 2013 08:06:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language:x-gm-message-state; bh=M/mBH1dUtfkKn6bQstXLIcwt03KsU6wsY7O7irv6V/w=; b=Xi2H4KZ0LOwUgguzamlR/Pwoy1bfCII4Cmppoj86MO+oLpnrv4s0asQPaozxRg+FrT jy9KBQ1K+wKEXITIi7McHTg0BaH/Mik2zx/aTcF0dureTrv19WJjAB8cZcfOGFHUTPiK gwgmjl7A5DE3r/kBqyD/NbzgWKhNyH+gr0XXGdcEXw+tBmpE7eIPwNbkbEHOQYowTB2Y yDlDKchBOEHAl8v+B3cI+2dlZwMcJ/IySTV/kdXbufmund2dCfFLngjKxMERzoq7ExfR Y7o4ohOc0hrJ3QxR7wxbj5JThTvNncIoAmF9UFeLbYZkKZhrmLikyhlr5X+a2CQS/idF oPgQ== X-Received: by 10.236.145.136 with SMTP id p8mr18179499yhj.74.1368803175611; Fri, 17 May 2013 08:06:15 -0700 (PDT) Received: from piyushlaptop (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPSA id v27sm18000482yhj.12.2013.05.17.08.06.13 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 17 May 2013 08:06:14 -0700 (PDT) From: "Piyush Jain" To: "'Adam Langley'" , "'Erik Andersen'" References: <20130517140955.551F21A740@ld9781.wdf.sap.corp> <004701ce530b$2bcca2a0$8365e7e0$@eu> In-Reply-To: Date: Fri, 17 May 2013 08:06:11 -0700 Message-ID: <008101ce5310$12808dc0$3781a940$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHEunm5SQnDNXNrJ8dFFMT/1C4lVAJhV2ZVAYrw94sCRGbwbJjrJZ3g Content-Language: en-us X-Gm-Message-State: ALoCoQnxu6g6oNPYFHRw0GzoIYPai03XhhLuuVPaDos3sQsRaYaBqZFIaZToF09eZp6It6LY8FLe Cc: 'PKIX' Subject: Re: [pkix] Whitelisting X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 15:06:17 -0000 And this http://tools.ietf.org/html/draft-perrin-tls-tack-02 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Adam Langley > Sent: Friday, May 17, 2013 7:36 AM > To: Erik Andersen > Cc: PKIX > Subject: Re: [pkix] Whitelisting > > On Fri, May 17, 2013 at 10:31 AM, Erik Andersen wrote: > > The reason I am asking is that I am sitting with a document that I am > > commenting. It says: > > > > "In certain deployments, additional support is necessary to further > > restrict the usage of certificates based on their serial numbers and > > issuers. This restriction is known as certificate white listing or > > certificate pinning, and is currently being defined in the IETF" > > > > I was trying to find out whether that is true and if yes, what the > > status is. > > It is possibly this document: > https://tools.ietf.org/html/draft-ietf-websec-key-pinning-04 > > > Cheers > > AGL > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From ietf@augustcellars.com Fri May 17 09:03:47 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA28921F8F43 for ; Fri, 17 May 2013 09:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEd0NKumI6ij for ; Fri, 17 May 2013 09:03:43 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id DCE7121F8FA9 for ; Fri, 17 May 2013 09:03:41 -0700 (PDT) Received: from Philemon (unknown [88.214.187.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 794A638F12; Fri, 17 May 2013 09:03:37 -0700 (PDT) From: "Jim Schaad" To: "'RFC Errata System'" , , , , , , References: <20130517103432.611066210E@rfc-editor.org> In-Reply-To: <20130517103432.611066210E@rfc-editor.org> Date: Fri, 17 May 2013 17:02:46 +0100 Message-ID: <067b01ce5317$fd8afa60$f8a0ef20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMGgF+2o1X9Vkj974YuCKLkNRECj5aZLxew Content-Language: en-us Cc: pkix@ietf.org Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3626) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 16:03:48 -0000 Totally reasonable - should be accepted. > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > RFC Errata System > Sent: Friday, May 17, 2013 11:35 AM > To: paul.hoffman@vpnc.org; jimsch@exmsft.com; stephen.farrell@cs.tcd.ie; > turners@ieca.com; kent@bbn.com; stefan@aaa-sec.com > Cc: pkix@ietf.org; rfc-editor@rfc-editor.org > Subject: [pkix] [Technical Errata Reported] RFC5912 (3626) > > The following errata report has been submitted for RFC5912, "New ASN.1 > Modules for the Public Key Infrastructure Using X.509 (PKIX)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5912&eid=3626 > > -------------------------------------- > Type: Technical > Reported by: Carl Wallace > > Section: 14 > > Original Text > ------------- > -- CRL number extension OID and syntax > ext-CRLNumber EXTENSION ::= {SYNTAX > INTEGER (0..MAX) IDENTIFIED BY id-ce-cRLNumber } > id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } > > CRLNumber ::= INTEGER (0..MAX) > > Corrected Text > -------------- > -- CRL number extension OID and syntax > CRLNumber ::= INTEGER (0..MAX) > > ext-CRLNumber EXTENSION ::= {SYNTAX > CRLNumber IDENTIFIED BY id-ce-cRLNumber } > id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } > > Notes > ----- > The CRLNumber extension was not defined to use the CRLNumber type. It > should use the CRLNumber type. This is a corrected resubmission of an > earlier errata submission that included an error. > > Instructions: > ------------- > This errata 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. > > -------------------------------------- > RFC5912 (draft-ietf-pkix-new-asn1-08) > -------------------------------------- > Title : New ASN.1 Modules for the Public Key Infrastructure Using > X.509 (PKIX) > Publication Date : June 2010 > Author(s) : P. Hoffman, J. Schaad > Category : INFORMATIONAL > 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 piyush@ditenity.com Fri May 17 09:05:40 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A3521F9765 for ; Fri, 17 May 2013 09:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UjjHMX8nfhT for ; Fri, 17 May 2013 09:05:40 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 015D721F974C for ; Fri, 17 May 2013 09:05:39 -0700 (PDT) Received: by mail-yh0-f46.google.com with SMTP id v1so1036470yhn.19 for ; Fri, 17 May 2013 09:05:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language:x-gm-message-state; bh=Xn5vbTyN09vZxMuDBTqZypYdJq0n917T93nIbbcL1q8=; b=UZZoyH63qAacUP6RfNchf/qwNbMg6GuFxK6qVMq7buqWbfQjn5luiZk7w0fKkQ6jp+ H8MgQerYHFHyjWGKLQVVuCyCxmodVYRnriLuPUA0LXlLEWbjS4GFzNUlRP6Luza6nGxZ aUcTddqlDBrV0mfxkht241QTWQIPGaTsZ/TdIU0CS4fCGH1O8ba8uMWnwH4sWRb3PXIA Ur6l8H282RIM7QOzwGSCa4/XCFV67tJidzN3S+3WwY1PZwzLSUd25zt2VqKnAamomUmi 0Edu35MGkx0stL72y+wW3DA7sThiWjvf4qVvrEAFMpUk2/6FnCQMOs8g4J3xBi5kSxCA 3JZg== X-Received: by 10.236.227.234 with SMTP id d100mr17639681yhq.134.1368806739470; Fri, 17 May 2013 09:05:39 -0700 (PDT) Received: from piyushlaptop (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPSA id y24sm18268351yhn.20.2013.05.17.09.05.37 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 17 May 2013 09:05:38 -0700 (PDT) From: "Piyush Jain" To: References: <004301ce52b4$33f72970$9be57c50$@ditenity.com> <20130517071056.8A6A01A73B@ld9781.wdf.sap.corp> In-Reply-To: <20130517071056.8A6A01A73B@ld9781.wdf.sap.corp> Date: Fri, 17 May 2013 09:05:35 -0700 Message-ID: <009b01ce5318$5f016310$1d042930$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQH4pQy6BVxVinAB2KmqFL6khTLhdZi02BvQ Content-Language: en-us X-Gm-Message-State: ALoCoQkx4a+kHF9LRyEk3cKOlFY8DQ7oXCucO0tTaLv6L7prbUFt96yv27cY9SHFAT56+M8Y0laG Cc: stefan@aaa-sec.com, paul.hoffman@vpnc.org, jimsch@exmsft.com, 'Jim Schaad' , pkix@ietf.org, 'RFC Errata System' Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3623) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 16:05:41 -0000 > (1) it says "the combination of ... revocation information" which is NOT > equal to first merging the CRLs and then looking at the result. [[Piyush] The way I interpret it is following the combining rules which are defined in 5280, though not using a mathematical notation. Base CRL is a set. Delta is another set where each entry should be either added or deleted from the Base CRL based on the reason code. You are interpreting 'combination' as a simple search in both the base CRL and delta CRL which is incorrect IMO. > (2) removing expired certs from any "merged CRL" locally created by the RP > (a) is neither required, nor appropriate, nor reasonable, and > the CRL does not even whether the CA would remove expired certs. > (b) not even possible for the RP, because it only sees cert serials > > [Piyush] I think you misunderstood me. RPs don't need to remove expired cert from merged CRL. They just need to remove entries from the base CRL that are marked as "removeFromCRL" in the delta while creating a merged CRL. Or if you prefer the word "combination", the serial number must be searched in both Base and delta to figure out the revocation status (even if an entry for that serial exists in the base CRL). > > > > "removeFromCRL" is a mechanism to indicate that entry was removed > > from CRL i.e. the cert referenced by that entry is not considered revoked > anymore. > > The absence of the entry in the concurrent complete CRL indicates the > > same thing. > > Knowing that a cert was temporarily revoked during some time in the past is > _still_ "revocation information", no matter how you look at it. > [Piyush] You cannot conclusively use a current CRL to determine the status of a certificate sometime in the past. But I hear your point. What you are saying is "add 1 to 0" and delete "1 from the result" is not same information as "0" because in former case you know that add and delete operations were performed whereas in the latter case you don't. However, I don't see any practical use of this information in context of certificate revocation status check. > Whether such information is useful or relevant for checks performed by the > RP is highly dependent on the RP's usage scenario and/or purpose. > For stuff that is also digitally timestamped (e.g. rfc3161), the certificate status > at the time indicated by the secure timestamp might be MUCH more > relevant than the current cert status (which may even be expired by then). [Piyush] You cannot use current CRL to determine historical status. SO this is a moot point. > > btw. which well-known CRL extension will be present on complete CRLs > where the CA does stupid things such as removing revoked certs after they > expire, or no longer accept and publish revocations for a cert that has > expired? [Piyush] Its optional. I wish you understand the tradeoffs before passing judgments. In an environment where there is no need for historical validation, including status of expired certificates is waste of space and bandwidth. > > And where in rfc5280/pkix is the algorithm described for the RP software to > determine and obtain the necessary CRL to determine the cert status for > some point in the past for an already expired cert? [Piyush] To find the status at time t, find a CRL whose thisUpdate is less than t and nextUpdate is greater than t. How to find such a CRL is beyond the scope of the document. Consult your CRL infrastructure administrator for additional information :). > > Allowing CAs to drop certs off CRLs without either of these being > standardized and used, would make S/Mime/CMS pretty useless for offline > use and archival, including use in EMail. [Piyush] You have created an artificial requirement that historical validations should be possible using current CRL. While it is nice to have, it's not a requirement for every implementation, hence the option. In some scenarios archival solutions can chose to archive the revocation information source with the record of the transaction. In other scenarios they can choose to include the revocation information beyond expiry. From kent@bbn.com Fri May 17 12:32:09 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D15921F9705 for ; Fri, 17 May 2013 12:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qaB-DTVbuIu for ; Fri, 17 May 2013 12:32:04 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 178B721F96FC for ; Fri, 17 May 2013 12:32:03 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:39957 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UdQNX-000M1f-Pc; Fri, 17 May 2013 15:31:47 -0400 Message-ID: <519685A9.8080702@bbn.com> Date: Fri, 17 May 2013 15:31:53 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jim Schaad References: <20130517103432.611066210E@rfc-editor.org> <067b01ce5317$fd8afa60$f8a0ef20$@augustcellars.com> In-Reply-To: <067b01ce5317$fd8afa60$f8a0ef20$@augustcellars.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: stefan@aaa-sec.com, paul.hoffman@vpnc.org, jimsch@exmsft.com, pkix@ietf.org, 'RFC Errata System' Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3626) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 19:32:09 -0000 I concur with Jim. Steve ------ On 5/17/13 12:02 PM, Jim Schaad wrote: > Totally reasonable - should be accepted. > >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> RFC Errata System >> Sent: Friday, May 17, 2013 11:35 AM >> To: paul.hoffman@vpnc.org; jimsch@exmsft.com; stephen.farrell@cs.tcd.ie; >> turners@ieca.com; kent@bbn.com; stefan@aaa-sec.com >> Cc: pkix@ietf.org; rfc-editor@rfc-editor.org >> Subject: [pkix] [Technical Errata Reported] RFC5912 (3626) >> >> The following errata report has been submitted for RFC5912, "New ASN.1 >> Modules for the Public Key Infrastructure Using X.509 (PKIX)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5912&eid=3626 >> >> -------------------------------------- >> Type: Technical >> Reported by: Carl Wallace >> >> Section: 14 >> >> Original Text >> ------------- >> -- CRL number extension OID and syntax >> ext-CRLNumber EXTENSION ::= {SYNTAX >> INTEGER (0..MAX) IDENTIFIED BY id-ce-cRLNumber } >> id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } >> >> CRLNumber ::= INTEGER (0..MAX) >> >> Corrected Text >> -------------- >> -- CRL number extension OID and syntax >> CRLNumber ::= INTEGER (0..MAX) >> >> ext-CRLNumber EXTENSION ::= {SYNTAX >> CRLNumber IDENTIFIED BY id-ce-cRLNumber } >> id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } >> >> Notes >> ----- >> The CRLNumber extension was not defined to use the CRLNumber type. It >> should use the CRLNumber type. This is a corrected resubmission of an >> earlier errata submission that included an error. >> >> Instructions: >> ------------- >> This errata 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. >> >> -------------------------------------- >> RFC5912 (draft-ietf-pkix-new-asn1-08) >> -------------------------------------- >> Title : New ASN.1 Modules for the Public Key Infrastructure > Using >> X.509 (PKIX) >> Publication Date : June 2010 >> Author(s) : P. Hoffman, J. Schaad >> Category : INFORMATIONAL >> 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 pgut001@cs.auckland.ac.nz Sat May 18 18:43:45 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4955C21F84E7 for ; Sat, 18 May 2013 18:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmneH7qQqOFR for ; Sat, 18 May 2013 18:43:30 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 848F521F81FF for ; Sat, 18 May 2013 18:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1368927810; x=1400463810; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=XDBHaqPQQRU9zL9LBXotl7hMHc1F6c2ucPk8fhHrAFk=; b=UfQP9KEcOoX3GsV6gAVk/DRQx3GStRA2R9YZV/3c/HUiqlG0aAy711n5 iypf40c9+OObNHTiRivRJUlUmc+TVp8YIcoN0Cae0owbF3LRqlvubHZmZ XAmtUMUmWYCQ9W6lfesZsPCwYfJiwZoSTEgV11gJwfUlTMUYzCHFYXcWx o=; X-IronPort-AV: E=Sophos;i="4.87,702,1363086000"; d="scan'208";a="187554758" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 19 May 2013 13:43:27 +1200 Received: from UXCN10-TDC02.UoA.auckland.ac.nz ([169.254.8.4]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Sun, 19 May 2013 13:43:27 +1200 From: Peter Gutmann To: "pkix@ietf.org" Thread-Topic: [pkix] Whitelisting Thread-Index: Ac5UMkGGeZQ8GMd9TpiYkA3Dvy+bXA== Date: Sun, 19 May 2013 01:43:26 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D4F279@uxcn10-tdc02.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Whitelisting X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 01:43:45 -0000 Martin Rex writes:=0A= =0A= >I assume Erik was asking about an OCSP Extension "Proof of cert issuance",= =0A= >such as a CertHash included with an OCSP "good" status.=0A= >=0A= >One example for an "existing solution" was mentioned by Johannes Merkle an= d=0A= >is quoted here:=0A= >=0A= >http://www.ietf.org/mail-archive/web/pkix/current/msg32667.html=0A= =0A= Another solution, which has been around as long as OCSP has, is RTCS, which= =0A= was desgined to fix all (known) problems with OCSP:=0A= =0A= http://tools.ietf.org/html/draft-gutmann-cms-rtcs-01=0A= =0A= Peter.=0A= =0A= From stefan@aaa-sec.com Wed May 29 15:21:24 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E4421F8D00 for ; Wed, 29 May 2013 15:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VE+gJvfXa85Q for ; Wed, 29 May 2013 15:21:19 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 9B77A21F8CA5 for ; Wed, 29 May 2013 15:21:09 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 622BAC4B189 for ; Thu, 30 May 2013 00:21:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id V23yVmCUlZ60 for ; Thu, 30 May 2013 00:21:06 +0200 (CEST) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 1E0E0C4B186 for ; Thu, 30 May 2013 00:21:06 +0200 (CEST) Received: (qmail 1885 invoked from network); 29 May 2013 22:21:05 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.103]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 29 May 2013 22:21:05 -0000 User-Agent: Microsoft-MacOutlook/14.3.4.130416 Date: Thu, 30 May 2013 00:21:02 +0200 From: Stefan Santesson To: Erik Andersen , PKIX Message-ID: Thread-Topic: [pkix] Whitelisting In-Reply-To: <004701ce530b$2bcca2a0$8365e7e0$@eu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Whitelisting X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 22:21:24 -0000 Erik, There was also some discussions about a white-list OCSP extension with proof of existence. That never took of into a WG effort. However, to create such extension would be a perfectly valid effort now when the updated OCSP is published (to be RFC 6960) But as PKIX is closing down, it must be done some place else. /Stefan On 5/17/13 4:31 PM, "Erik Andersen" wrote: >The reason I am asking is that I am sitting with a document that I am >commenting. It says: > >"In certain deployments, additional support is necessary to further >restrict >the usage of certificates based on their serial numbers and issuers. This >restriction is known as certificate white listing or certificate pinning, >and is currently being defined in the IETF" > >I was trying to find out whether that is true and if yes, what the status >is. > >Erik > >-----Oprindelig meddelelse----- >Fra: Martin Rex [mailto:mrex@sap.com] >Sendt: 17. maj 2013 16:10 >Til: Erwann Abalea >Cc: Erik Andersen; PKIX >Emne: Re: [pkix] Whitelisting > >I assume Erik was asking about an OCSP Extension "Proof of cert issuance", >such as a CertHash included with an OCSP "good" status. > >One example for an "existing solution" was mentioned by Johannes Merkle >and >is quoted here: > >http://www.ietf.org/mail-archive/web/pkix/current/msg32667.html > >-Martin > >Erwann Abalea wrote: >> Are you talking about MECAI, Google CT, EFF Sovereign Keys, and similar >ideas? >> >> 2013/5/17 Erik Andersen : >> > There were some ideas about whitelisting of certificates. What is >> > the status? > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From stefan@aaa-sec.com Wed May 29 15:38:08 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8213521F96B7 for ; Wed, 29 May 2013 15:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYgKWYe96znH for ; Wed, 29 May 2013 15:38:02 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDBD21F96B1 for ; Wed, 29 May 2013 15:38:02 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 14629C4B7E3 for ; Thu, 30 May 2013 00:37:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8R1KcrNU95AM for ; Thu, 30 May 2013 00:37:57 +0200 (CEST) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id C0025C4B800 for ; Thu, 30 May 2013 00:37:57 +0200 (CEST) Received: (qmail 38162 invoked from network); 29 May 2013 22:37:57 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.103]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 29 May 2013 22:37:57 -0000 User-Agent: Microsoft-MacOutlook/14.3.4.130416 Date: Thu, 30 May 2013 00:37:54 +0200 From: Stefan Santesson To: PKIX Message-ID: Thread-Topic: Update need to RFC 3739 In-Reply-To: <004701ce530b$2bcca2a0$8365e7e0$@eu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [pkix] Update need to RFC 3739 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 22:38:08 -0000 Most of what got defined in RFC 3739 was good. It is a very highly deployed standard in the EU. At the time, EU defined Qualified Certificates as something that was only issued to a natural person. However, there is one requirement of RFC 3739 that was doomed to fail given enough time. And that is the required list of attributes in section 3.1.2. In particular this sentence: "Other attributes MAY also be present; however, the use of other attributes MUST NOT be necessary to distinguish one subject name from another subject name. That is, the attributes listed above are sufficient to ensure unique subject names." Yes, I wrote that. And I fully admit my mistake. In particular two things have happened that makes this requirement plain wrong and obsolete. 1) EU has now concluded that QC can be issued not only to people, but to organisations. 2) X.520 has defined a new attribute for organisationIdentifier That attribute is much more suitable to use for an organisation unique identifier rather than serialNumber. Especially if the cert includes information about both a person and an organisation. So the organisationIdentifier attribute may very well be necessary to achieve uniqueness in many cases. It is nether very future proof to assume that serialNumber will be used forever. There are other more suitable attributes that you may want at times. As an example, there is a local Swedish attribute for national Swedish ID numbers used in many Swedish PKI deployments. They will never fit the attribute requirement of RFC 3739. ETSI is currently making interop profiles for QC that are not natural persons. But the EU QC profile EN 319 412-5 relies on RFC 3739. This has created a deadlock where the interop profile will have to violate RFC 3739, unless RFC 3739 is updated. I will initiate an effort to create an update RFC that opens up this requirement of RFC 3739. This will be in the form of a DIFF (OLD: NEW:) update document. I raise the issue here to get feedback. This probably has to go as a private submission, but as this list is still open, we can always discuss the issue here. /Stefan From stefan@aaa-sec.com Wed May 29 15:38:32 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CF721F96D9 for ; Wed, 29 May 2013 15:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSAdN2UbKntr for ; Wed, 29 May 2013 15:38:28 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id A789A21F96B1 for ; Wed, 29 May 2013 15:38:26 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 603C7C4B84E for ; Thu, 30 May 2013 00:38:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lb1hN1ESS8jt for ; Thu, 30 May 2013 00:38:25 +0200 (CEST) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 04D95C4B858 for ; Thu, 30 May 2013 00:38:25 +0200 (CEST) Received: (qmail 39307 invoked from network); 29 May 2013 22:38:24 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.103]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 29 May 2013 22:38:24 -0000 User-Agent: Microsoft-MacOutlook/14.3.4.130416 Date: Thu, 30 May 2013 00:38:20 +0200 From: Stefan Santesson To: Stephen Kent , Jim Schaad Message-ID: Thread-Topic: [pkix] [Technical Errata Reported] RFC5912 (3626) In-Reply-To: <519685A9.8080702@bbn.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix@ietf.org, jimsch@exmsft.com, paul.hoffman@vpnc.org, 'RFC Errata System' Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3626) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 22:38:32 -0000 +1 On 5/17/13 9:31 PM, "Stephen Kent" wrote: >I concur with Jim. > >Steve >------ >On 5/17/13 12:02 PM, Jim Schaad wrote: >> Totally reasonable - should be accepted. >> >>> -----Original Message----- >>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >>> RFC Errata System >>> Sent: Friday, May 17, 2013 11:35 AM >>> To: paul.hoffman@vpnc.org; jimsch@exmsft.com; >>>stephen.farrell@cs.tcd.ie; >>> turners@ieca.com; kent@bbn.com; stefan@aaa-sec.com >>> Cc: pkix@ietf.org; rfc-editor@rfc-editor.org >>> Subject: [pkix] [Technical Errata Reported] RFC5912 (3626) >>> >>> The following errata report has been submitted for RFC5912, "New ASN.1 >>> Modules for the Public Key Infrastructure Using X.509 (PKIX)". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=5912&eid=3626 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Carl Wallace >>> >>> Section: 14 >>> >>> Original Text >>> ------------- >>> -- CRL number extension OID and syntax >>> ext-CRLNumber EXTENSION ::= {SYNTAX >>> INTEGER (0..MAX) IDENTIFIED BY id-ce-cRLNumber } >>> id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } >>> >>> CRLNumber ::= INTEGER (0..MAX) >>> >>> Corrected Text >>> -------------- >>> -- CRL number extension OID and syntax >>> CRLNumber ::= INTEGER (0..MAX) >>> >>> ext-CRLNumber EXTENSION ::= {SYNTAX >>> CRLNumber IDENTIFIED BY id-ce-cRLNumber } >>> id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } >>> >>> Notes >>> ----- >>> The CRLNumber extension was not defined to use the CRLNumber type. It >>> should use the CRLNumber type. This is a corrected resubmission of an >>> earlier errata submission that included an error. >>> >>> Instructions: >>> ------------- >>> This errata 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. >>> >>> -------------------------------------- >>> RFC5912 (draft-ietf-pkix-new-asn1-08) >>> -------------------------------------- >>> Title : New ASN.1 Modules for the Public Key >>>Infrastructure >> Using >>> X.509 (PKIX) >>> Publication Date : June 2010 >>> Author(s) : P. Hoffman, J. Schaad >>> Category : INFORMATIONAL >>> 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 >> > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From denis.ietf@free.fr Thu May 30 07:00:29 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6845221F9371 for ; Thu, 30 May 2013 07:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CskGwnoTUps1 for ; Thu, 30 May 2013 07:00:21 -0700 (PDT) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [IPv6:2a01:e0c:1:1599::12]) by ietfa.amsl.com (Postfix) with ESMTP id C50FA21F9347 for ; Thu, 30 May 2013 07:00:19 -0700 (PDT) Received: from [127.0.0.1] (unknown [88.182.125.39]) by smtp3-g21.free.fr (Postfix) with ESMTP id B6312A630D for ; Thu, 30 May 2013 16:00:10 +0200 (CEST) Message-ID: <51A75B6C.90900@free.fr> Date: Thu, 30 May 2013 16:00:12 +0200 From: Denis User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130530-0, 30/05/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [pkix] Update need to RFC 3739 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 14:00:30 -0000 Stefan, Thank you for raising the issue to the list. However, at the time the document was written, there was no mistake. In France, nobody may get a certificate representing a company or an organization. Thus a QC cannot be issued to an organization. However, a certificate could be issued to a department within an organisation. Thus identifying the department within the organisation (as well as the organisation of course) is necessary. In other words, using only an organisation identifier is insufficient. The point which should be discussed on the list is the content of proposed "organisationIdentifier". It would be interesting to know what you propose for it in principle, before issuing a diff document. Denis : > Most of what got defined in RFC 3739 was good. > > It is a very highly deployed standard in the EU. > At the time, EU defined Qualified Certificates as something that was only > issued to a natural person. > > However, there is one requirement of RFC 3739 that was doomed to fail > given enough time. > And that is the required list of attributes in section 3.1.2. > > In particular this sentence: > "Other attributes MAY also be present; however, the use of other > attributes MUST NOT be necessary to distinguish one subject name from > another subject name. That is, the attributes listed above are > sufficient to ensure unique subject names." > > Yes, I wrote that. And I fully admit my mistake. > > In particular two things have happened that makes this requirement plain > wrong and obsolete. > > 1) EU has now concluded that QC can be issued not only to people, but to > organisations. > 2) X.520 has defined a new attribute for organisationIdentifier > > That attribute is much more suitable to use for an organisation unique > identifier rather than serialNumber. Especially if the cert includes > information about both a person and an organisation. > So the organisationIdentifier attribute may very well be necessary to > achieve uniqueness in many cases. > > It is nether very future proof to assume that serialNumber will be used > forever. > There are other more suitable attributes that you may want at times. > > As an example, there is a local Swedish attribute for national Swedish ID > numbers used in many Swedish PKI deployments. They will never fit the > attribute requirement of RFC 3739. > > ETSI is currently making interop profiles for QC that are not natural > persons. > But the EU QC profile EN 319 412-5 relies on RFC 3739. > > This has created a deadlock where the interop profile will have to violate > RFC 3739, unless RFC 3739 is updated. > > I will initiate an effort to create an update RFC that opens up this > requirement of RFC 3739. This will be in the form of a DIFF (OLD: NEW:) > update document. > > I raise the issue here to get feedback. This probably has to go as a > private submission, but as this list is still open, we can always discuss > the issue here. > > /Stefan > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From housley@vigilsec.com Thu May 30 07:56:41 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57B921F859B for ; Thu, 30 May 2013 07:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.661 X-Spam-Level: X-Spam-Status: No, score=-102.661 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKJTclNT-7Rd for ; Thu, 30 May 2013 07:56:35 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 9868221F8E3C for ; Thu, 30 May 2013 07:56:33 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id B9178F2407E; Thu, 30 May 2013 10:57:01 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id AJMVola08-fP; Thu, 30 May 2013 10:56:20 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-156-29.washdc.fios.verizon.net [96.241.156.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 91BE8F2406E; Thu, 30 May 2013 10:57:00 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Thu, 30 May 2013 10:56:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1DCFFEB8-4EB9-4358-B9E6-C7BC654A63F0@vigilsec.com> References: To: Stefan Santesson X-Mailer: Apple Mail (2.1085) Cc: PKIX Subject: Re: [pkix] Update need to RFC 3739 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 14:56:41 -0000 Seems to me that a very short update can be written. No need to open = the whole document. Russ On May 29, 2013, at 6:37 PM, Stefan Santesson wrote: > Most of what got defined in RFC 3739 was good. >=20 > It is a very highly deployed standard in the EU. > At the time, EU defined Qualified Certificates as something that was = only > issued to a natural person. >=20 > However, there is one requirement of RFC 3739 that was doomed to fail > given enough time. > And that is the required list of attributes in section 3.1.2. >=20 > In particular this sentence: > "Other attributes MAY also be present; however, the use of other > attributes MUST NOT be necessary to distinguish one subject name = from > another subject name. That is, the attributes listed above are > sufficient to ensure unique subject names." >=20 > Yes, I wrote that. And I fully admit my mistake. >=20 > In particular two things have happened that makes this requirement = plain > wrong and obsolete. >=20 > 1) EU has now concluded that QC can be issued not only to people, but = to > organisations. > 2) X.520 has defined a new attribute for organisationIdentifier >=20 > That attribute is much more suitable to use for an organisation unique > identifier rather than serialNumber. Especially if the cert includes > information about both a person and an organisation. > So the organisationIdentifier attribute may very well be necessary to > achieve uniqueness in many cases. >=20 > It is nether very future proof to assume that serialNumber will be = used > forever. > There are other more suitable attributes that you may want at times. >=20 > As an example, there is a local Swedish attribute for national Swedish = ID > numbers used in many Swedish PKI deployments. They will never fit the > attribute requirement of RFC 3739. >=20 > ETSI is currently making interop profiles for QC that are not natural > persons. > But the EU QC profile EN 319 412-5 relies on RFC 3739. >=20 > This has created a deadlock where the interop profile will have to = violate > RFC 3739, unless RFC 3739 is updated. >=20 > I will initiate an effort to create an update RFC that opens up this > requirement of RFC 3739. This will be in the form of a DIFF (OLD: = NEW:) > update document. >=20 > I raise the issue here to get feedback. This probably has to go as a > private submission, but as this list is still open, we can always = discuss > the issue here. >=20 > /Stefan >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From stefan@aaa-sec.com Thu May 30 08:07:11 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946FC21F854E for ; Thu, 30 May 2013 08:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpYMi1nvkRM4 for ; Thu, 30 May 2013 08:07:06 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB2C21F91AB for ; Thu, 30 May 2013 08:07:02 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id F1AF2C90CFC for ; Thu, 30 May 2013 17:06:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id B-xCNLQa8-_U for ; Thu, 30 May 2013 17:06:55 +0200 (CEST) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 3A25DC90C99 for ; Thu, 30 May 2013 17:06:53 +0200 (CEST) Received: (qmail 87276 invoked from network); 30 May 2013 15:06:53 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.103]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 30 May 2013 15:06:53 -0000 User-Agent: Microsoft-MacOutlook/14.3.4.130416 Date: Thu, 30 May 2013 17:06:49 +0200 From: Stefan Santesson To: Russ Housley Message-ID: Thread-Topic: [pkix] Update need to RFC 3739 In-Reply-To: <1DCFFEB8-4EB9-4358-B9E6-C7BC654A63F0@vigilsec.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: PKIX Subject: Re: [pkix] Update need to RFC 3739 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 15:07:11 -0000 Yes, I agree. /Stefan On 5/30/13 4:56 PM, "Russ Housley" wrote: >Seems to me that a very short update can be written. No need to open the >whole document. > >Russ > > >On May 29, 2013, at 6:37 PM, Stefan Santesson wrote: > >> Most of what got defined in RFC 3739 was good. >> >> It is a very highly deployed standard in the EU. >> At the time, EU defined Qualified Certificates as something that was >>only >> issued to a natural person. >> >> However, there is one requirement of RFC 3739 that was doomed to fail >> given enough time. >> And that is the required list of attributes in section 3.1.2. >> >> In particular this sentence: >> "Other attributes MAY also be present; however, the use of other >> attributes MUST NOT be necessary to distinguish one subject name from >> another subject name. That is, the attributes listed above are >> sufficient to ensure unique subject names." >> >> Yes, I wrote that. And I fully admit my mistake. >> >> In particular two things have happened that makes this requirement plain >> wrong and obsolete. >> >> 1) EU has now concluded that QC can be issued not only to people, but to >> organisations. >> 2) X.520 has defined a new attribute for organisationIdentifier >> >> That attribute is much more suitable to use for an organisation unique >> identifier rather than serialNumber. Especially if the cert includes >> information about both a person and an organisation. >> So the organisationIdentifier attribute may very well be necessary to >> achieve uniqueness in many cases. >> >> It is nether very future proof to assume that serialNumber will be used >> forever. >> There are other more suitable attributes that you may want at times. >> >> As an example, there is a local Swedish attribute for national Swedish >>ID >> numbers used in many Swedish PKI deployments. They will never fit the >> attribute requirement of RFC 3739. >> >> ETSI is currently making interop profiles for QC that are not natural >> persons. >> But the EU QC profile EN 319 412-5 relies on RFC 3739. >> >> This has created a deadlock where the interop profile will have to >>violate >> RFC 3739, unless RFC 3739 is updated. >> >> I will initiate an effort to create an update RFC that opens up this >> requirement of RFC 3739. This will be in the form of a DIFF (OLD: NEW:) >> update document. >> >> I raise the issue here to get feedback. This probably has to go as a >> private submission, but as this list is still open, we can always >>discuss >> the issue here. >> >> /Stefan >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From stefan@aaa-sec.com Thu May 30 12:40:15 2013 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E610B21F907E for ; Thu, 30 May 2013 12:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJD3lCQA1aZ1 for ; Thu, 30 May 2013 12:40:10 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 9A69F21F8EFC for ; Thu, 30 May 2013 12:40:10 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 16EC2CC60DB for ; Thu, 30 May 2013 21:40:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NAW_ouRqLbwi for ; Thu, 30 May 2013 21:40:08 +0200 (CEST) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 7E950CC60D9 for ; Thu, 30 May 2013 21:40:08 +0200 (CEST) Received: (qmail 11506 invoked from network); 30 May 2013 19:40:08 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 30 May 2013 19:40:08 -0000 User-Agent: Microsoft-MacOutlook/14.3.4.130416 Date: Thu, 30 May 2013 21:40:04 +0200 From: Stefan Santesson To: Denis , Message-ID: Thread-Topic: [pkix] Update need to RFC 3739 In-Reply-To: <51A75B6C.90900@free.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Update need to RFC 3739 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 19:40:16 -0000 Denis, The content of the organisationIdentifier is an interesting question. But it can be done separate to the discussion of the need for an update of 3739. The organisationIdentifier is already defined in X.520, so we have no power over it. It is an unstructured string, much like serialNumber is, except it is not limited to PrintableString which is a good thing. What we need to agree on in the case of 3739 is simply to remove the requirement that any particular set of attributes must provide a unique identity, and simply accept that the unique identity is provided by the complete set of any attributes. /Stefan On 5/30/13 4:00 PM, "Denis" wrote: > Stefan, > >Thank you for raising the issue to the list. >However, at the time the document was written, there was no mistake. > >In France, nobody may get a certificate representing a company or an >organization. >Thus a QC cannot be issued to an organization. > >However, a certificate could be issued to a department within an >organisation. >Thus identifying the department within the organisation (as well as the >organisation of course) is necessary. >In other words, using only an organisation identifier is insufficient. > >The point which should be discussed on the list is the content of >proposed "organisationIdentifier". >It would be interesting to know what you propose for it in principle, >before issuing a diff document. > >Denis >: >> Most of what got defined in RFC 3739 was good. >> >> It is a very highly deployed standard in the EU. >> At the time, EU defined Qualified Certificates as something that was >>only >> issued to a natural person. >> >> However, there is one requirement of RFC 3739 that was doomed to fail >> given enough time. >> And that is the required list of attributes in section 3.1.2. >> >> In particular this sentence: >> "Other attributes MAY also be present; however, the use of other >> attributes MUST NOT be necessary to distinguish one subject name >>from >> another subject name. That is, the attributes listed above are >> sufficient to ensure unique subject names." >> >> Yes, I wrote that. And I fully admit my mistake. >> >> In particular two things have happened that makes this requirement plain >> wrong and obsolete. >> >> 1) EU has now concluded that QC can be issued not only to people, but to >> organisations. >> 2) X.520 has defined a new attribute for organisationIdentifier >> >> That attribute is much more suitable to use for an organisation unique >> identifier rather than serialNumber. Especially if the cert includes >> information about both a person and an organisation. >> So the organisationIdentifier attribute may very well be necessary to >> achieve uniqueness in many cases. >> >> It is nether very future proof to assume that serialNumber will be used >> forever. >> There are other more suitable attributes that you may want at times. >> >> As an example, there is a local Swedish attribute for national Swedish >>ID >> numbers used in many Swedish PKI deployments. They will never fit the >> attribute requirement of RFC 3739. >> >> ETSI is currently making interop profiles for QC that are not natural >> persons. >> But the EU QC profile EN 319 412-5 relies on RFC 3739. >> >> This has created a deadlock where the interop profile will have to >>violate >> RFC 3739, unless RFC 3739 is updated. >> >> I will initiate an effort to create an update RFC that opens up this >> requirement of RFC 3739. This will be in the form of a DIFF (OLD: NEW:) >> update document. >> >> I raise the issue here to get feedback. This probably has to go as a >> private submission, but as this list is still open, we can always >>discuss >> the issue here. >> >> /Stefan >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix