From wwwrun@rfc-editor.org Fri Aug 2 09:58: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 8EA7E11E810F for ; Fri, 2 Aug 2013 09:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.29 X-Spam-Level: X-Spam-Status: No, score=-102.29 tagged_above=-999 required=5 tests=[AWL=0.310, 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 nrSV-S-3q5Um for ; Fri, 2 Aug 2013 09:58:59 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id ACB5011E8116 for ; Fri, 2 Aug 2013 09:58:57 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3AC0262113; Fri, 2 Aug 2013 09:55:21 -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: <20130802165521.3AC0262113@rfc-editor.org> Date: Fri, 2 Aug 2013 09:55:21 -0700 (PDT) Cc: pkix@ietf.org, rfc-editor@rfc-editor.org Subject: [pkix] [Technical Errata Reported] RFC5912 (3692) 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, 02 Aug 2013 16:58:59 -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=3692 -------------------------------------- Type: Technical Reported by: Carl Wallace Section: 14 Original Text ------------- crlExtensions EXTENSION ::= { ext-AuthorityKeyIdentifier | ext-IssuerAltName | ext-CRLNumber | ext-DeltaCRLIndicator | ext-IssuingDistributionPoint | ext-FreshestCRL, ... } Corrected Text -------------- crlExtensions EXTENSION ::= { ext-AuthorityKeyIdentifier | ext-IssuerAltName | ext-CRLNumber | ext-DeltaCRLIndicator | ext-IssuingDistributionPoint | ext-FreshestCRL | ext-AuthorityInfoAccess, ... } Notes ----- Section 5.2.7 of RFC 5280 allows AIA to be a CRL extension. 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 turners@ieca.com Thu Aug 8 13:39:12 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 6D9BF11E821E for ; Thu, 8 Aug 2013 13:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.852 X-Spam-Level: X-Spam-Status: No, score=-101.852 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 PCZz2RQjqCzh for ; Thu, 8 Aug 2013 13:39:07 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [67.18.65.19]) by ietfa.amsl.com (Postfix) with ESMTP id B40BF11E821F for ; Thu, 8 Aug 2013 13:39:06 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 560FAABD94036; Thu, 8 Aug 2013 15:39:06 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 3A8B0ABD93FF5 for ; Thu, 8 Aug 2013 15:39:06 -0500 (CDT) Received: from [96.231.225.44] (port=49665 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1V7WzC-0001fj-2K for pkix@ietf.org; Thu, 08 Aug 2013 15:39:06 -0500 Message-ID: <520401E9.9070609@ieca.com> Date: Thu, 08 Aug 2013 16:39:05 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: pkix@ietf.org References: <20130730074001.16244.7339.idtracker@ietfa.amsl.com> In-Reply-To: <20130730074001.16244.7339.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130730074001.16244.7339.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.225.44]:49665 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 13 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [pkix] Fwd: I-D Action: draft-turner-cmc-serverkeygeneration-00.txt 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, 08 Aug 2013 20:39:12 -0000 Here's a revised version of a draft that was formerly a wg draft. Denis' comments from a while back actually resulted in a complete re-write. Comments are welcome. spt -------- Original Message -------- Subject: I-D Action: draft-turner-cmc-serverkeygeneration-00.txt Date: Tue, 30 Jul 2013 00:40:01 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CMC (Certificate Management over Cryptographic Message Syntax) Extensions: Server Key Generation Author(s) : Jim Schaad Sean Turner Paul Timmel Filename : draft-turner-cmc-serverkeygeneration-00.txt Pages : 42 Date : 2013-07-30 Abstract: This document defines a set of extensions to the Certificate Management over Cryptographic Message Syntax (CMC) protocol that addresses the desire to support server-side generation of keys. This service is provided by the definition of additional control statements within the CMC architecture. Additional CMC errors are also defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-turner-cmc-serverkeygeneration There's also a htmlized version available at: http://tools.ietf.org/html/draft-turner-cmc-serverkeygeneration-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From wwwrun@rfc-editor.org Mon Aug 12 06:11:05 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 5E53221F9D98 for ; Mon, 12 Aug 2013 06:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.247 X-Spam-Level: X-Spam-Status: No, score=-102.247 tagged_above=-999 required=5 tests=[AWL=0.353, 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 3YzyvL5yqZSR for ; Mon, 12 Aug 2013 06:11:03 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id EAA0921F8C20 for ; Mon, 12 Aug 2013 06:00:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9598CB1E005; Mon, 12 Aug 2013 05:56:39 -0700 (PDT) To: david.cooper@nist.gov, stefans@microsoft.com, stephen.farrell@cs.tcd.ie, sharon.boeyen@entrust.com, housley@vigilsec.com, wpolk@nist.gov, stephen.farrell@cs.tcd.ie, turners@ieca.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20130812125639.9598CB1E005@rfc-editor.org> Date: Mon, 12 Aug 2013 05:56:39 -0700 (PDT) X-Mailman-Approved-At: Tue, 13 Aug 2013 09:10:11 -0700 Cc: fweimer@redhat.com, pkix@ietf.org, rfc-editor@rfc-editor.org Subject: [pkix] [Technical Errata Reported] RFC5280 (3693) 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, 12 Aug 2013 13:11:05 -0000 The following errata report has been submitted for RFC5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5280&eid=3693 -------------------------------------- Type: Technical Reported by: Florian Weimer Section: 4.2.1.10 Original Text ------------- DNS name restrictions are expressed as host.example.com. Any DNS name that can be constructed by simply adding zero or more labels to the left-hand side of the name satisfies the name constraint. For example, www.host.example.com would satisfy the constraint but host1.example.com would not. Corrected Text -------------- [Add this to the paragraph] If an implementation extracts DNS names from the subject distinguished name, DNS name restrictions MUST be applied to these names as well. Notes ----- When used with TLS and HTTP (according to RFC 2818), section 4.2.1.10, Name Constraints, is technically a NOP that doesn't constraint the CA that has this attribute because RFC 2818 mandates processing of the common name attribute in the subject distinguished name. Consequentially, the constraint can be bypassed by issuing a certificate without a subject alternative name. The fix is to apply the DNS name restrictions to the relevant parts of the subject distinguished name, too, as implemented here: https://bugzilla.mozilla.org/show_bug.cgi?id=394919 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. -------------------------------------- RFC5280 (draft-ietf-pkix-rfc3280bis-11) -------------------------------------- Title : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Publication Date : May 2008 Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From internet-drafts@ietf.org Tue Aug 13 15:45: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 1E9BB21E8188; Tue, 13 Aug 2013 15:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.006, 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 8plhQNXWmJ0d; Tue, 13 Aug 2013 15:45:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFCE921E816E; Tue, 13 Aug 2013 15:45:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130813224528.3991.23342.idtracker@ietfa.amsl.com> Date: Tue, 13 Aug 2013 15:45:28 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-est-09.txt 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, 13 Aug 2013 22:45:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Working= Group of the IETF. Title : Enrollment over Secure Transport Author(s) : Max Pritikin Peter E. Yee Dan Harkins Filename : draft-ietf-pkix-est-09.txt Pages : 49 Date : 2013-08-13 Abstract: This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple yet functional certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificate(s). It also supports client-generated public/ private key pairs as well as key pairs generated by the CA. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-est There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pkix-est-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-est-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ynir@checkpoint.com Tue Aug 13 22:30:55 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 40ECB21F9CAE for ; Tue, 13 Aug 2013 22:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 0XP5V4X6v8Uo for ; Tue, 13 Aug 2013 22:30:50 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8326321F9BEB for ; Tue, 13 Aug 2013 22:30:49 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7E5UnVl012673 for ; Wed, 14 Aug 2013 08:30:49 +0300 X-CheckPoint: {520B1608-27-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Wed, 14 Aug 2013 08:30:48 +0300 From: Yoav Nir To: " PKIX" Thread-Topic: [pkix] [Technical Errata Reported] RFC5280 (3693) Thread-Index: AQHOmD+mfDlftBOwWEC7TjEznGREwJmT98AAgAAEEAA= Date: Wed, 14 Aug 2013 05:30:48 +0000 Message-ID: <731EEEE0-83A4-4EA6-8146-860281C72916@checkpoint.com> References: <20130812125639.9598CB1E005@rfc-editor.org> <3B771C52-CAFA-4D2D-8F5E-35B7A1B0AADF@checkpoint.com> In-Reply-To: <3B771C52-CAFA-4D2D-8F5E-35B7A1B0AADF@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.117] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 1143de8adfe8f0b2f52cf1294bb4898fb7cddbaf4b Content-Type: text/plain; charset="us-ascii" Content-ID: <433B5E66BF94834B9FEFF73BDBE5FB1F@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) 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, 14 Aug 2013 05:30:55 -0000 Forwarding to PKIX because of too many addressees. On Aug 14, 2013, at 8:15 AM, Yoav Nir wrote: IMO this is not an erratum. RFC 2818 acknowledges the practice of placing t= he FQDN in the Common Name field, but recommends not to do it.=20 Sure, the authors of RFC 5280 could have said "It is common practice, as do= cumented in [RFC5280] to place the FQDN in the Common Name field for certif= icates in use for HTTPS. Because of this, DNS name constraints MUST be appl= ied to that field as well.". Choosing not to do so may have been the right = or the wrong decision, but it's not a textual or technical error. I also don't think it's a good idea, because certificates are used in other= domains than HTTPS.=20 But most important, there is a bunch of certificates out there that are per= fectly valid according to RFC 5280, which would become invalid based on the= suggested fix in the report. If we want to do this, I think this requires = an updated RFC (or at least, an updating RFC). You shouldn't prohibit valid= certificates with an Errata Report. Yoav On Aug 12, 2013, at 3:56 PM, RFC Errata System = wrote: > The following errata report has been submitted for RFC5280, > "Internet X.509 Public Key Infrastructure Certificate and Certificate Rev= ocation List (CRL) Profile". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5280&eid=3D3693 >=20 > -------------------------------------- > Type: Technical > Reported by: Florian Weimer >=20 > Section: 4.2.1.10 >=20 > Original Text > ------------- > DNS name restrictions are expressed as host.example.com. Any DNS > name that can be constructed by simply adding zero or more labels to > the left-hand side of the name satisfies the name constraint. For > example, www.host.example.com would satisfy the constraint but > host1.example.com would not. >=20 >=20 > Corrected Text > -------------- > [Add this to the paragraph] >=20 > If an implementation extracts DNS names from the subject > distinguished name, DNS name restrictions MUST be applied > to these names as well. >=20 >=20 > Notes > ----- > When used with TLS and HTTP (according to RFC 2818), section 4.2.1.10, Na= me Constraints, is technically a NOP that doesn't constraint the CA that ha= s this attribute because RFC 2818 mandates processing of the common name at= tribute in the subject distinguished name. Consequentially, the constraint= can be bypassed by issuing a certificate without a subject alternative nam= e. The fix is to apply the DNS name restrictions to the relevant parts of = the subject distinguished name, too, as implemented here: >=20 > https://bugzilla.mozilla.org/show_bug.cgi?id=3D394919 >=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 decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5280 (draft-ietf-pkix-rfc3280bis-11) > -------------------------------------- > Title : Internet X.509 Public Key Infrastructure Certificat= e and Certificate Revocation List (CRL) Profile > Publication Date : May 2008 > Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. = Housley, W. Polk > Category : PROPOSED STANDARD > Source : Public-Key Infrastructure (X.509) > Area : Security > Stream : IETF > Verifying Party : IESG > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From kent@bbn.com Wed Aug 14 08:26: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 7827E21F99CE for ; Wed, 14 Aug 2013 08:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.438 X-Spam-Level: X-Spam-Status: No, score=-106.438 tagged_above=-999 required=5 tests=[AWL=0.162, 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 CDfU3fat4ZsQ for ; Wed, 14 Aug 2013 08:26:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C399311E81ED for ; Wed, 14 Aug 2013 08:26:00 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:51794) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V9cww-0004n5-Ex; Wed, 14 Aug 2013 11:25:26 -0400 Message-ID: <520BA165.3050404@bbn.com> Date: Wed, 14 Aug 2013 11:25:25 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: RFC Errata System References: <20130812125639.9598CB1E005@rfc-editor.org> In-Reply-To: <20130812125639.9598CB1E005@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 14 Aug 2013 10:07:43 -0700 Cc: fweimer@redhat.com, stefans@microsoft.com, stefan@aaa-sec.com, pkix@ietf.org Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) 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, 14 Aug 2013 15:26:22 -0000 I agree with Yoav. The suggested change is not editorial; it represents a significant technical change. It also does not accurately reflect the intent of the WG. This erratum should be rejected. Steve ------ On 8/12/13 8:56 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC5280, > "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5280&eid=3693 > > -------------------------------------- > Type: Technical > Reported by: Florian Weimer > > Section: 4.2.1.10 > > Original Text > ------------- > DNS name restrictions are expressed as host.example.com. Any DNS > > name that can be constructed by simply adding zero or more labels to > > the left-hand side of the name satisfies the name constraint. For > > example, www.host.example.com would satisfy the constraint but > > host1.example.com would not. > > > > Corrected Text > -------------- > [Add this to the paragraph] > > > > If an implementation extracts DNS names from the subject > > distinguished name, DNS name restrictions MUST be applied > > to these names as well. > > > > Notes > ----- > When used with TLS and HTTP (according to RFC 2818), section 4.2.1.10, Name Constraints, is technically a NOP that doesn't constraint the CA that has this attribute because RFC 2818 mandates processing of the common name attribute in the subject distinguished name. Consequentially, the constraint can be bypassed by issuing a certificate without a subject alternative name. The fix is to apply the DNS name restrictions to the relevant parts of the subject distinguished name, too, as implemented here: > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=394919 > > 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. > > -------------------------------------- > RFC5280 (draft-ietf-pkix-rfc3280bis-11) > -------------------------------------- > Title : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile > Publication Date : May 2008 > Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk > Category : PROPOSED STANDARD > Source : Public-Key Infrastructure (X.509) > Area : Security > Stream : IETF > Verifying Party : IESG > From mrex@sap.com Wed Aug 14 11:10: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 D2FFB21F9BD1 for ; Wed, 14 Aug 2013 11:10:13 -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 gmDYSfo5FzeL for ; Wed, 14 Aug 2013 11:10:09 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5E64711E80F7 for ; Wed, 14 Aug 2013 11:10:08 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r7EI9x8v010913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Aug 2013 20:10:00 +0200 (MEST) In-Reply-To: <731EEEE0-83A4-4EA6-8146-860281C72916@checkpoint.com> To: Yoav Nir Date: Wed, 14 Aug 2013 20:09:59 +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: <20130814180959.A59DC1A907@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) 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: Wed, 14 Aug 2013 18:10:14 -0000 Yoav Nir wrote: > > Forwarding to PKIX because of too many addressees. > > > On Aug 14, 2013, at 8:15 AM, Yoav Nir wrote: > > IMO this is not an erratum. RFC 2818 acknowledges the practice of > placing the FQDN in the Common Name field, but recommends not to do it. rfc2818 goes even further: http://tools.ietf.org/html/rfc2818#page-5 If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead. There are two significant problems with the idea in this errata: 1) Name constraints processing is something that is performed entirely within the so called "path validation function (rfc5280 Section 6.1) and rfc5280 explicitly says that using an X.509 08/2005 path validation function as a substitute is OK. This change will not fly with the latter. 2) Name constraints are only processed for an EE cert if a name of that type is present in the certficate. Combined with what rfc2818 _truely_ says, this amounts to a NO-OP. a) if any CA Cert on the path contains NameConstraints on SubjectAltNames type DNSName, but the EE-Cert contains no SubjectAltName of type DNSName, then these NameConstraints must be ignored. b) if any CA Cert on the path contains NameConstraints on SubjectAltNames of type DNSName, and the EE-Cert contains SubjectAltNames of type DNSName, the constraints will be processed, but per rfc2818 Section 3.1, the CN= part of the certificate must be ignored for the purpose of Server Endpoint identification. So currently, this idea looks somewhat half-baked to me. Anyone can implement any behaviour and still argue compliance. There is nothing that the proposed change (which is _not_ an errata) would change about the situation. -Martin From piyush@ditenity.com Wed Aug 14 11:47: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 8ECAA11E818C for ; Wed, 14 Aug 2013 11:47:08 -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 S-dWx-q23XvI for ; Wed, 14 Aug 2013 11:47:04 -0700 (PDT) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1F21F11E8187 for ; Wed, 14 Aug 2013 11:47:04 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j6so945733oag.28 for ; Wed, 14 Aug 2013 11:47:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :thread-index:content-language; bh=t+tV+TbWi0vxsuPqtf/cO1Y6jVD652sPdUDRHdfWo8g=; b=ScTmNXWypoHfm/z3CGdmhC50s17CEWVkbZ30Nhn3KLX4tIZQDy7EIXCMTocHhqk2dB YgNIcllsyQauicaTtRJX8jp1kIb4spjc9YLNgo2DvxntE0MvDhr+Utgl0zTSa/ZuPvVJ d7fK/MOzItpwrteHoBRrDzBdmKYyKZlsWZCyTgvuZ96CJC6aabTXspRqNK7QMWUqwb4V rbO7c7Zb/1GVDueEMA07/wXlSWytWrC4dpNzW1lRSkd95J2pT1uzdL+LgqIf4vCjeKfP mqVcf/wQUhSIx8ZyetpeXpgOcHrt+VEAvjcVTvwMKnX2KfXG6XWacSkzI+AA7fPiBhmq 22bA== X-Gm-Message-State: ALoCoQk2xAqbi+Ozb2buqbYLsIXLDk5C2vZnijG5AbjNa6WN+q/7dpJqdfbhfUl/K+IPHAhA4knd X-Received: by 10.60.70.134 with SMTP id m6mr9341250oeu.14.1376506023636; Wed, 14 Aug 2013 11:47:03 -0700 (PDT) Received: from piyushlaptop (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPSA id rr6sm48098856oeb.0.2013.08.14.11.47.02 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 14 Aug 2013 11:47:03 -0700 (PDT) From: "Piyush Jain" To: "'Stephen Kent'" , "'RFC Errata System'" References: <20130812125639.9598CB1E005@rfc-editor.org> <520BA165.3050404@bbn.com> In-Reply-To: <520BA165.3050404@bbn.com> Date: Wed, 14 Aug 2013 11:47:01 -0700 Message-ID: <0f0b01ce991e$aac85f50$00591df0$@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: AQFgJ5tAE2DhtElIelX+JvqTRkl3PgFDzzI+mmfII+A= Content-Language: en-us Cc: fweimer@redhat.com, stefan@aaa-sec.com, stefans@microsoft.com, pkix@ietf.org Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) 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, 14 Aug 2013 18:47:08 -0000 I think it is filled as a technical not an editorial erratum. And I also think that this should be editorial :). The intent is clearly stated in 4.2.1.10 paragraph 4. "If a name constraints extension that is marked as critical imposes constraints on a particular name form, and an instance of that name form appears in the subject field or subjectAltName extension of a subsequent certificate, then the application MUST either process the constraint or reject the certificate." So the fact that the DNS name was extracted from subjectName as opposed to subjectAltName is irrelevant. The constraint must be applied in either case. The proposed text clarifies this. Whether it is redundant is a different question altogether. Explicit clarification is provided for RFC822Name. So I do not see a reason for not providing the same for DNS names. -Piyush > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Stephen Kent > Sent: Wednesday, August 14, 2013 8:25 AM > To: RFC Errata System > Cc: fweimer@redhat.com; stefans@microsoft.com; stefan@aaa-sec.com; > pkix@ietf.org > Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) > > I agree with Yoav. The suggested change is not editorial; it represents a > significant technical change. It also does not accurately reflect the intent of > the WG. > > This erratum should be rejected. > > Steve > ------ > On 8/12/13 8:56 AM, RFC Errata System wrote: > > The following errata report has been submitted for RFC5280, "Internet > > X.509 Public Key Infrastructure Certificate and Certificate Revocation List > (CRL) Profile". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=5280&eid=3693 > > > > -------------------------------------- > > Type: Technical > > Reported by: Florian Weimer > > > > Section: 4.2.1.10 > > > > Original Text > > ------------- > > DNS name restrictions are expressed as host.example.com. Any DNS > > > > name that can be constructed by simply adding zero or more labels > > to > > > > the left-hand side of the name satisfies the name constraint. For > > > > example, www.host.example.com would satisfy the constraint but > > > > host1.example.com would not. > > > > > > > > Corrected Text > > -------------- > > [Add this to the paragraph] > > > > > > > > If an implementation extracts DNS names from the subject > > > > distinguished name, DNS name restrictions MUST be applied > > > > to these names as well. > > > > > > > > Notes > > ----- > > When used with TLS and HTTP (according to RFC 2818), section 4.2.1.10, > Name Constraints, is technically a NOP that doesn't constraint the CA that has > this attribute because RFC 2818 mandates processing of the common name > attribute in the subject distinguished name. Consequentially, the constraint > can be bypassed by issuing a certificate without a subject alternative name. > The fix is to apply the DNS name restrictions to the relevant parts of the > subject distinguished name, too, as implemented here: > > > > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=394919 > > > > 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. > > > > -------------------------------------- > > RFC5280 (draft-ietf-pkix-rfc3280bis-11) > > -------------------------------------- > > Title : Internet X.509 Public Key Infrastructure Certificate and > Certificate Revocation List (CRL) Profile > > Publication Date : May 2008 > > Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, > W. Polk > > Category : PROPOSED STANDARD > > Source : Public-Key Infrastructure (X.509) > > Area : Security > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From piyush@ditenity.com Wed Aug 14 12:07: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 BCF0321F9EA7 for ; Wed, 14 Aug 2013 12:07:43 -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 INIwE42WPY0h for ; Wed, 14 Aug 2013 12:07:38 -0700 (PDT) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id DE5B621F9E6E for ; Wed, 14 Aug 2013 12:07:37 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i18so13807121oag.29 for ; Wed, 14 Aug 2013 12:07:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :thread-index:content-language; bh=Bby/KsJp/z1DPNCu6v8a1quA+lUSiOVI4plId0DkLhU=; b=ou1try4hKD6GTqpNnChBUIHfh51zO+DR8xZRlYM64waRu2dXQPECwsOIIhMqZfUatu igLpr2OM+0qyT0ANXazoIs9rIBCLB1NlZY6O0kh8G5mA0H9vcj7dF3SZU/fiSh/A/F3p L4a/1is4dnYK3EdMv4WCHeeVjPbeXQqiEpp78JGNp50N7Dq1mKStDZjORJmG6vnHf4yL rFhLkvgd/mWVPWYHzS813ZKFXMUQHBHd2i3CTnY7UC4bWjWPol6F5ns3mrO310As0KAy 4hRcLXRKD88IB23g7N7DewxnUJ2K3P+x/tE5XmnYJeTeNMJ1pW00g3DlWaBUL3WZHinZ 6ZIg== X-Gm-Message-State: ALoCoQkU8VC+l9c+Rscd1wl7IgI5jsQXzVsZ8dopfx0lCOyP6eAahuE+NSMsbD0SShHM5qE25lvs X-Received: by 10.60.94.39 with SMTP id cz7mr10716850oeb.17.1376507257223; Wed, 14 Aug 2013 12:07: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 it7sm8879008obb.11.2013.08.14.12.07.35 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 14 Aug 2013 12:07:36 -0700 (PDT) From: "Piyush Jain" To: "'Yoav Nir'" , References: <20130812125639.9598CB1E005@rfc-editor.org> <3B771C52-CAFA-4D2D-8F5E-35B7A1B0AADF@checkpoint.com> <731EEEE0-83A4-4EA6-8146-860281C72916@checkpoint.com> In-Reply-To: <731EEEE0-83A4-4EA6-8146-860281C72916@checkpoint.com> Date: Wed, 14 Aug 2013 12:07:35 -0700 Message-ID: <0f1001ce9921$89f3cd70$9ddb6850$@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: AQFgJ5tAE2DhtElIelX+JvqTRkl3PgIFbJUoAtxyppCaSuFmwA== Content-Language: en-us Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) 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, 14 Aug 2013 19:07:43 -0000 > Sure, the authors of RFC 5280 could have said "It is common practice, as > documented in [RFC5280] to place the FQDN in the Common Name field for > certificates in use for HTTPS. Because of this, DNS name constraints MUST be > applied to that field as well.". Choosing not to do so may have been the right > or the wrong decision, but it's not a textual or technical error. >From 5280: "Restrictions apply to the subject distinguished name and apply to subject alternative names." I would interpret that this applies to all name types. > I also don't think it's a good idea, because certificates are used in other > domains than HTTPS. > > But most important, there is a bunch of certificates out there that are > perfectly valid according to RFC 5280, which would become invalid based on > the suggested fix in the report. If we want to do this, I think this requires an > updated RFC (or at least, an updating RFC). You shouldn't prohibit valid > certificates with an Errata Report. Not sure of the existence of the certificates that you refer to. Why would a genuine sub CA issue a certificate with a DNS name that it is not authorized to issue? From kent@bbn.com Wed Aug 14 13:43: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 7BA8111E81A6 for ; Wed, 14 Aug 2013 13:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.469 X-Spam-Level: X-Spam-Status: No, score=-106.469 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Bm4Qg3Ds-ywT for ; Wed, 14 Aug 2013 13:43:16 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 76A8311E81A0 for ; Wed, 14 Aug 2013 13:43:16 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:52217) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V9huO-000GRr-It; Wed, 14 Aug 2013 16:43:08 -0400 Message-ID: <520BEBDB.90009@bbn.com> Date: Wed, 14 Aug 2013 16:43:07 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Piyush Jain References: <20130812125639.9598CB1E005@rfc-editor.org> <520BA165.3050404@bbn.com> <0f0b01ce991e$aac85f50$00591df0$@ditenity.com> In-Reply-To: <0f0b01ce991e$aac85f50$00591df0$@ditenity.com> Content-Type: multipart/alternative; boundary="------------000604040201020005060108" Cc: fweimer@redhat.com, stefan@aaa-sec.com, pkix@ietf.org, stefans@microsoft.com, 'RFC Errata System' Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) 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, 14 Aug 2013 20:43:22 -0000 This is a multi-part message in MIME format. --------------000604040201020005060108 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Piyush, > I think it is filled as a technical not an editorial erratum. And I also > think that this should be editorial :). > > The intent is clearly stated in 4.2.1.10 paragraph 4. > > "If a name constraints extension that is marked as critical imposes > constraints on a particular name form, and an instance of that name form > appears in the subject field or subjectAltName extension of a subsequent > certificate, then the application MUST either process the constraint or > reject the certificate." > > So the fact that the DNS name was extracted from subjectName as opposed to > subjectAltName is irrelevant. The constraint must be applied in either case. I disagree. The source of the identifier is relevant. The first paragraph of 4.2.1.10 ends with these 2 sentences: Restrictions apply only when thespecified name form is present. If no name of the type is in thecertificate, the certificate is acceptable. When a DNS name appears in the Subject name, not the subject alt name extension, it it not typed as a DNS name. It is an attribute of a Subject DN, often a CN attribute. If it were expressed as a series of domainComponent attributes, then I might agree that it was typed as a DNS name, but that does not tend to happen in practice. Also, pages 21-22 note that use of the domainComponent attribute is not a substitute for using a dNSName in the Subject alt name extension, and that there is NO requirement for an implementation to convert a sequence of DCs into a DNS name. But such a conversion is what would be needed to perform the name constraints comparison, so ... Note further that, on pages 41-42, an explicit exception is made for rfcC822 names that are encoded in a DN as an attribute type of emailAddress. If the intent was to create the same exception for DNS names appearing in the Subject field, it would appear in this section. It does not. So there seems to be no basis for assuming that the treatment of a DNS name that appears in the Subject name field using some attribute(s) is an oversight. Steve --------------000604040201020005060108 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Piyush,
I think it is filled as a technical not an editorial erratum. And I also
think that this should be editorial :).

The intent is clearly stated in 4.2.1.10 paragraph 4.

"If a name constraints extension that is marked as critical imposes
constraints on a particular name form, and an instance of  that name form
appears in the subject field or subjectAltName extension of a subsequent
certificate, then the application MUST  either process the constraint or
reject the certificate."

So the fact that the DNS name was extracted from subjectName as opposed to
subjectAltName is irrelevant. The constraint must be applied in either case.
I disagree. The source of the identifier is relevant. The first paragraph of
4.2.1.10 ends with these 2 sentences:

   Restrictions apply only when the specified name form is present.
   If no name of the type is in the certificate, the certificate is
   acceptable.


When a DNS name appears in the Subject name, not the subject alt name extension, it
it not typed as a DNS name. It is an attribute of a Subject DN, often a
CN attribute. If it were expressed as a series of domainComponent attributes,
then I might agree that it was typed as a DNS name, but that does not tend to happen
in practice. Also, pages 21-22 note that use of the domainComponent attribute is
not a substitute for using a dNSName in the Subject alt name extension, and that
there is NO requirement for an implementation to convert a sequence of DCs into
a DNS name. But such a conversion is what would be needed to perform the name
constraints comparison, so ...

Note further that, on pages 41-42, an explicit exception is made for rfcC822 names that
are encoded in a DN as an attribute type of emailAddress. If the intent was to create the same exception for DNS names appearing in the Subject field, it would appear in this section. It does not. So there seems to be no basis for assuming that the treatment
of a DNS name that appears in the Subject name field using some attribute(s) is an
oversight.

Steve

--------------000604040201020005060108-- From piyush@ditenity.com Wed Aug 14 15:21: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 4EA0A11E8176 for ; Wed, 14 Aug 2013 15:21:12 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6ddQ9NWVt3ss for ; Wed, 14 Aug 2013 15:20:59 -0700 (PDT) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8B80911E813B for ; Wed, 14 Aug 2013 15:20:55 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id o17so42025oag.7 for ; Wed, 14 Aug 2013 15:20:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:thread-index:content-language; bh=m+nTl+97r8u2rDai/95/AJsybdUqXPXTKscAXyakzzE=; b=Bx02/AqBL30K1zVddLbLf/vlPMDKQXsYBve9v4ryu4eiX27aAsYzkmv9hJkvzDI7JM gH/kwcP19JzJuaXjO1qH0sQD5kYvBby17i5kHOPFNg8oahj95hoRHSG2ByX0MSoqYV2e rJrB9gC4Ei05CfqJWOGIOt/zme7UCEDlcScneLXpAnw5w/Pd20NNyMt5O727OC1SpWDk zEZ3Mw6RVDJQKeZp6hi2f6Ft75io9dfCeXO9Qg/o94kLqqoRMpKmYx6eUgdRhluSKOKb 1h5r2734TtmlsIcJD1Kz3olzgmsMrAfitbk0tpviEhaMJwqU8KfaAyXVOfVER09P1H/G x0vA== X-Gm-Message-State: ALoCoQkeJEmjQUZv6MZ+DPxoK/3BaPXBXVNuYXawU91RkFitiq7PWB4hVGEl2n8Tv0F4uF18Mw7K X-Received: by 10.182.242.11 with SMTP id wm11mr23201002obc.26.1376518853658; Wed, 14 Aug 2013 15:20:53 -0700 (PDT) Received: from piyushlaptop (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPSA id z5sm48838919obg.13.2013.08.14.15.20.51 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 14 Aug 2013 15:20:52 -0700 (PDT) From: "Piyush Jain" To: "'Stephen Kent'" References: <20130812125639.9598CB1E005@rfc-editor.org> <520BA165.3050404@bbn.com> <0f0b01ce991e$aac85f50$00591df0$@ditenity.com> <520BEBDB.90009@bbn.com> In-Reply-To: <520BEBDB.90009@bbn.com> Date: Wed, 14 Aug 2013 15:20:50 -0700 Message-ID: <0f3301ce993c$89b7ba90$9d272fb0$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0F34_01CE9901.DD5C8C10" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFgJ5tAE2DhtElIelX+JvqTRkl3PgFDzzI+AgkYwPgBm9kDv5pK1QBQ Content-Language: en-us Cc: fweimer@redhat.com, stefan@aaa-sec.com, pkix@ietf.org, stefans@microsoft.com, 'RFC Errata System' Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) 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, 14 Aug 2013 22:21:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0F34_01CE9901.DD5C8C10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stephan, Your explanation below convinces me that 5280 does not require relying parties to apply name constraint on DNS names extracted from the CN. However, I still think that it was an oversight and not a conscious decision. At that time this WG did not take into account the common practice of using CN for DNS name in server certificates. I did not find any discussions in the pkix archive which indicate that WG discussed the applicability of NC on DNS name embedded in CN and consciously decided to leave any excpetions for DNS name out of the text. The purpose of NC extension is to allow a CA to constraint the sub CA. Current RFC 5280 text allows sub CAs to bypass any constraint on the DNS name by issuing a certificate without the altName. Won't you agree that it defeats the purpose of having a NC extension. This issue was raised last year as well by Santosh without any conclusion. http://www.ietf.org/mail-archive/web/pkix/current/msg30897.html. BTW, it seems that both Mozilla and chrome apply DNS name constraints to DNS name extracted from CN. -Piyush From: Stephen Kent [mailto:kent@bbn.com] Sent: Wednesday, August 14, 2013 1:43 PM To: Piyush Jain Cc: 'RFC Errata System'; fweimer@redhat.com; stefans@microsoft.com; stefan@aaa-sec.com; pkix@ietf.org Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) Piyush, I think it is filled as a technical not an editorial erratum. And I also think that this should be editorial :). The intent is clearly stated in 4.2.1.10 paragraph 4. "If a name constraints extension that is marked as critical imposes constraints on a particular name form, and an instance of that name form appears in the subject field or subjectAltName extension of a subsequent certificate, then the application MUST either process the constraint or reject the certificate." So the fact that the DNS name was extracted from subjectName as opposed to subjectAltName is irrelevant. The constraint must be applied in either case. I disagree. The source of the identifier is relevant. The first paragraph of 4.2.1.10 ends with these 2 sentences: Restrictions apply only when the specified name form is present. If no name of the type is in the certificate, the certificate is acceptable. When a DNS name appears in the Subject name, not the subject alt name extension, it it not typed as a DNS name. It is an attribute of a Subject DN, often a CN attribute. If it were expressed as a series of domainComponent attributes, then I might agree that it was typed as a DNS name, but that does not tend to happen in practice. Also, pages 21-22 note that use of the domainComponent attribute is not a substitute for using a dNSName in the Subject alt name extension, and that there is NO requirement for an implementation to convert a sequence of DCs into a DNS name. But such a conversion is what would be needed to perform the name constraints comparison, so ... Note further that, on pages 41-42, an explicit exception is made for rfcC822 names that are encoded in a DN as an attribute type of emailAddress. If the intent was to create the same exception for DNS names appearing in the Subject field, it would appear in this section. It does not. So there seems to be no basis for assuming that the treatment of a DNS name that appears in the Subject name field using some attribute(s) is an oversight. Steve ------=_NextPart_000_0F34_01CE9901.DD5C8C10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stephan,

 

Your explanation below convinces me that 5280 does not require = relying parties to apply name constraint on DNS names extracted from the = CN.

However, I still think that it was an oversight and not a conscious = decision. At that time this WG did not take into account the common = practice of using CN for DNS name in server certificates. I did not find = any discussions in the pkix archive which indicate that WG discussed the = applicability of NC on DNS name embedded in CN and consciously decided = to leave any excpetions for DNS name out of the = text.

 

The purpose of NC extension is to allow a CA to constraint the sub = CA. Current RFC 5280 text allows sub CAs to bypass any constraint on the = DNS name by issuing a certificate without the altName. Won’t you = agree that it defeats the purpose of having a NC = extension.

 

This issue was raised last year as well by Santosh without any = conclusion. = http://www.ietf.org/mail-archive/web/pkix/current/msg30897.html.=

 

BTW,  it seems that both Mozilla and chrome apply DNS name = constraints to DNS name extracted from CN.

 

-Piyush

 

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Wednesday, = August 14, 2013 1:43 PM
To: Piyush Jain
Cc: 'RFC = Errata System'; fweimer@redhat.com; stefans@microsoft.com; = stefan@aaa-sec.com; pkix@ietf.org
Subject: Re: [pkix] = [Technical Errata Reported] RFC5280 = (3693)

 

Piyush,

I think it is filled =
as a technical not an editorial erratum. And I =
also
think that this should be editorial =
:).
 
The intent is =
clearly stated in 4.2.1.10 paragraph =
4.
 
"If a name =
constraints extension that is marked as critical =
imposes
constraints on a particular name form, and =
an instance of  that name form
appears in the =
subject field or subjectAltName extension of a =
subsequent
certificate, then the application =
MUST  either process the constraint or
reject =
the =
certificate."
 
So =
the fact that the DNS name was extracted from subjectName as opposed =
to
subjectAltName is irrelevant. The constraint =
must be applied in either case.

I disagree. The source of the identifier is relevant. = The first paragraph of
4.2.1.10 ends with these 2 = sentences:


   Restrictions apply only when the = specified name form is present.
   If no name of the type = is in the certificate, the certificate is
   = acceptable.


When a DNS name appears in the = Subject name, not the subject alt name extension, it
it not typed as = a DNS name. It is an attribute of a Subject DN, often a
CN attribute. = If it were expressed as a series of domainComponent attributes,
then = I might agree that it was typed as a DNS name, but that does not tend to = happen
in practice. Also, pages 21-22 note that use of the = domainComponent attribute is
not a substitute for using a dNSName in = the Subject alt name extension, and that
there is NO requirement for = an implementation to convert a sequence of DCs into
a DNS name. But = such a conversion is what would be needed to perform the name =
constraints comparison, so ...

Note further that, on pages = 41-42, an explicit exception is made for rfcC822 names that
are = encoded in a DN as an attribute type of emailAddress. If the intent was = to create the same exception for DNS names appearing in the Subject = field, it would appear in this section. It does not. So there seems to = be no basis for assuming that the treatment
of a DNS name that = appears in the Subject name field using some attribute(s) is = an
oversight.

Steve

------=_NextPart_000_0F34_01CE9901.DD5C8C10-- From turners@ieca.com Thu Aug 15 09:12: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 8834711E81CA for ; Thu, 15 Aug 2013 09:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.52 X-Spam-Level: X-Spam-Status: No, score=-101.52 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 m6mtqUFicvOa for ; Thu, 15 Aug 2013 09:12:24 -0700 (PDT) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [67.18.125.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7246A11E8165 for ; Thu, 15 Aug 2013 09:12:24 -0700 (PDT) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id B3D7710C47A9; Thu, 15 Aug 2013 11:11:32 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway09.websitewelcome.com (Postfix) with ESMTP id A5F6610C4786 for ; Thu, 15 Aug 2013 11:11:32 -0500 (CDT) Received: from [198.180.150.142] (port=57802 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VA09v-00050K-Vk for pkix@ietf.org; Thu, 15 Aug 2013 11:12:24 -0500 Message-ID: <520CFDE7.9090305@ieca.com> Date: Thu, 15 Aug 2013 12:12:23 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: pkix@ietf.org References: <20130813224528.3991.23342.idtracker@ietfa.amsl.com> In-Reply-To: <20130813224528.3991.23342.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [198.180.150.142]:57802 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [pkix] I-D Action: draft-ietf-pkix-est-09.txt 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, 15 Aug 2013 16:12:29 -0000 This version addresses the final discuss point. Stay tuned for the approval announcement. spt On 8/13/13 6:45 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. > > Title : Enrollment over Secure Transport > Author(s) : Max Pritikin > Peter E. Yee > Dan Harkins > Filename : draft-ietf-pkix-est-09.txt > Pages : 49 > Date : 2013-08-13 > > Abstract: > This document profiles certificate enrollment for clients using > Certificate Management over CMS (CMC) messages over a secure > transport. This profile, called Enrollment over Secure Transport > (EST), describes a simple yet functional certificate management > protocol targeting Public Key Infrastructure (PKI) clients that need > to acquire client certificates and associated Certification Authority > (CA) certificate(s). It also supports client-generated public/ > private key pairs as well as key pairs generated by the CA. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pkix-est > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-pkix-est-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-est-09 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From kent@bbn.com Thu Aug 15 10:46:31 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 CBB2011E817D for ; Thu, 15 Aug 2013 10:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.491 X-Spam-Level: X-Spam-Status: No, score=-106.491 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 RsbkPQxtoxl5 for ; Thu, 15 Aug 2013 10:46:27 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id F038911E80AD for ; Thu, 15 Aug 2013 10:46:26 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:52677) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VA1cq-0004q1-GP; Thu, 15 Aug 2013 13:46:20 -0400 Message-ID: <520D13EC.4040304@bbn.com> Date: Thu, 15 Aug 2013 13:46:20 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Piyush Jain References: <20130812125639.9598CB1E005@rfc-editor.org> <520BA165.3050404@bbn.com> <0f0b01ce991e$aac85f50$00591df0$@ditenity.com> <520BEBDB.90009@bbn.com> <0f3301ce993c$89b7ba90$9d272fb0$@ditenity.com> In-Reply-To: <0f3301ce993c$89b7ba90$9d272fb0$@ditenity.com> Content-Type: multipart/alternative; boundary="------------030703090507020700030904" Cc: fweimer@redhat.com, stefan@aaa-sec.com, pkix@ietf.org, stefans@microsoft.com, 'RFC Errata System' Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) 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, 15 Aug 2013 17:46:31 -0000 This is a multi-part message in MIME format. --------------030703090507020700030904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Piyush, > Stephan, > > Your explanation below convinces me that 5280 does not require relying > parties to apply name constraint on DNS names extracted from the CN. > > However, I still think that it was an oversight and not a conscious > decision. > I have chaired the WG since it's inception, 16 years ago. My recollection is that you began participating on this list relatively recently. So, I think my perception of what was the intent of the WG, vs. what was an oversight, has a better foundation. > > At that time this WG did not take into account the common practice of > using CN for DNS name in server certificates. I did not find any > discussions in the pkix archive which indicate that WG discussed the > applicability of NC on DNS name embedded in CN and consciously decided > to leave any excpetions for DNS name out of the text. > We knew it was common practice, and we wanted to discourage it, not endorse it. > > The purpose of NC extension is to allow a CA to constraint the sub CA. > Current RFC 5280 text allows sub CAs to bypass any constraint on the > DNS name by issuing a certificate without the altName. Won't you agree > that it defeats the purpose of having a NC extension. > The normal operation of public TAs for 20 years has avoided use of NC, probably because use of this extension might diminish revenue opportunities. Only recently have some of these CAs decided that NC might be a good idea, and only if it were NOT marked critical (because f a vendor support issue). Frankly, if we're binding DNS names to public keys, DANE is the best approach. > > This issue was raised last year as well by Santosh without any > conclusion. > http://www.ietf.org/mail-archive/web/pkix/current/msg30897.html. > > BTW, it seems that both Mozilla and chrome apply DNS name constraints > to DNS name extracted from CN. > > I am not aware of what additional tests these browsers might impose. Steve --------------030703090507020700030904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Piyush,

Stephan,

 

Your explanation below convinces me that 5280 does not require relying parties to apply name constraint on DNS names extracted from the CN.

However, I still think that it was an oversight and not a conscious decision.

I have chaired the WG since it's inception, 16 years ago. My recollection is that you began participating on this list relatively recently. So, I think my perception of what
was the intent of the WG, vs. what was an oversight, has a better foundation.

At that time this WG did not take into account the common practice of using CN for DNS name in server certificates. I did not find any discussions in the pkix archive which indicate that WG discussed the applicability of NC on DNS name embedded in CN and consciously decided to leave any excpetions for DNS name out of the text.

We knew it was common practice, and we wanted to discourage it, not endorse it.

 The purpose of NC extension is to allow a CA to constraint the sub CA. Current RFC 5280 text allows sub CAs to bypass any constraint on the DNS name by issuing a certificate without the altName. Won’t you agree that it defeats the purpose of having a NC extension.

The normal operation of public TAs for 20 years has avoided use of NC, probably because use of this extension might diminish revenue opportunities. Only recently have  some of these CAs decided that NC might be a good idea, and only if it were NOT marked
critical (because f a vendor support issue). Frankly, if we're binding DNS names to public keys, DANE is the best approach.

 This issue was raised last year as well by Santosh without any conclusion. http://www.ietf.org/mail-archive/web/pkix/current/msg30897.html.

 

BTW,  it seems that both Mozilla and chrome apply DNS name constraints to DNS name extracted from CN.


I am not aware of what additional tests these browsers might impose.


Steve
--------------030703090507020700030904-- From iesg-secretary@ietf.org Thu Aug 15 11:18: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 1BB3D11E81DA; Thu, 15 Aug 2013 11:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.103, 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 1jf7FdClJuz4; Thu, 15 Aug 2013 11:18:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B2911E8213; Thu, 15 Aug 2013 11:18:45 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130815181845.7842.45322.idtracker@ietfa.amsl.com> Date: Thu, 15 Aug 2013 11:18:45 -0700 Cc: pkix mailing list , pkix chair , RFC Editor Subject: [pkix] Protocol Action: 'Enrollment over Secure Transport' to Proposed Standard (draft-ietf-pkix-est-09.txt) 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, 15 Aug 2013 18:18:47 -0000 The IESG has approved the following document: - 'Enrollment over Secure Transport' (draft-ietf-pkix-est-09.txt) as Proposed Standard This document is the product of the Public-Key Infrastructure (X.509) Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pkix-est/ Technical Summary This document profiles certificate enrollment for clients using CMC (RFC 5272) defined ³simple² PKI messages over a secure transport. In addition to supporting certificate enrollment and renewal functions, EST also provides a means to obtain copies of a Certificate Authority¹s certificates, have a public key pair generated on behalf of the client, and query the EST server on the attributes required in a certificate request. Where this reduced set of management functionality is inadequate, EST also allows the conveyance of full CMC (RFC 5272) messages. EST is designed to be a standards-track profile of CMC appropriate for solutions currently leveraging the widely implemented but never fully standardized Simple Certificate Enrollment Protocol (SCEP). It improves on that protocol by supporting a wider range of algorithms as well as using TLS for added authentication, encryption, and data integrity and aligning with existing CMC. Working Group Summary This draft is a product of the PKIX WG. It has gone through several revisions within the WG, incorporating input from several major reviews by Steve Kent and Russ Housley as well as reviews from outside sources. The draft has not elicited much in the way of controversy, reflecting only specialized interest in certificate enrollment protocols. Document Quality The document does require a fair bit of background in X.509, ASN.1, and the re-used technologies in order to understand and implement the protocol. However, implementations have been created by two of the authors and one non-author implementor using disparate code bases. Members of the Wi-Fi Alliance (WFA) have also implemented EST as part of the WFA¹s Hotspot 2.0 efforts. Thus it is believed that EST implementations can be created from its specification. Personnel Stefan Santesson (stefan at aaa-sec.com) is the document shepherd. Sean Turner (turners at ieca.com) is the responsible Area Director. From stpeter@stpeter.im Thu Aug 15 12:41: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 2FF5211E80EE for ; Thu, 15 Aug 2013 12:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.271 X-Spam-Level: X-Spam-Status: No, score=-102.271 tagged_above=-999 required=5 tests=[AWL=0.328, 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 vn6XRcmIEipd for ; Thu, 15 Aug 2013 12:41:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CCF9F11E80AD for ; Thu, 15 Aug 2013 12:41:19 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.39]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4E6BFE834E; Thu, 15 Aug 2013 13:44:22 -0600 (MDT) Message-ID: <520D2EDD.3000004@stpeter.im> Date: Thu, 15 Aug 2013 13:41:17 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: pkix@ietf.org References: <520D2E9C.9010001@stpeter.im> In-Reply-To: <520D2E9C.9010001@stpeter.im> X-Enigmail-Version: 1.5.2 X-Forwarded-Message-Id: <520D2E9C.9010001@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] Fwd: [POSH] POSH and EST 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, 15 Aug 2013 19:41:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI. Please reply on the posh@ietf.org list. - -------- Original Message -------- Subject: [POSH] POSH and EST Date: Thu, 15 Aug 2013 13:40:12 -0600 From: Peter Saint-Andre To: At the POSH BoF in Berlin, Dan Harkins asked why we couldn't just use EST: https://datatracker.ietf.org/doc/draft-ietf-pkix-est/ This puzzled me, since Matt Miller and I both reviewed EST and concluded that it wouldn't solve the secure delegation problem. But Dan was pretty adamant about it so I've taken another look. :-) The fundamental stumbling block for me is that (as far as I can see) EST provides a way for a PKIX client to obtain a certificate for itself (i.e., "certificate enrollment"), whereas in POSH we need a way for a TLS client to receive a hint about the PKIX certificate that will be presented by the TLS server during TLS negotiation within an application protocol such as IMAP or XMPP. Here is what I see as the goal and "happy path" process in each approach. (Note: Examples might be simplified.) First, let's consider EST... Goal: As the owner of example.com, obtain an end-entity certificate for, say, the domain im.example.com. Process (followed by EST client) 1. Discover the EST server for the relevant CA (say, "ca.example") 2. Send GET to https://ca.example/.well-known/est/cacerts to learn the trust anchor for the EST server 3. Receive a response from the EST server containing the root cert and any additional certs 4. Send request to https://ca.example/simpleenroll (including a PKCS#10 Certification Request) to obtain an end-entity certificate for im.example.com 5. Receive a response from the EST server containing an "application/pkcs7-mime" object 6. Happily install the end-entity certificate at my XMPP server Now let's consider POSH... Goal: As an end user of the im.example.com service, determine what end-entity certicate will be presented by the TLS server at that domain Process (followed by XMPP/TLS client) 1. Send GET to https://im.example.com/.well-known/posh._xmpp-client._tcp.json 2(a). Receive JSON Web Key set specifying the certificate to be presented by the im.example.com domain - -or- 2(b). Get redirected to a hosting provider for im.example.com, say https://hosting.example.net/.well-known/posh._xmpp-client._tcp.json (and repeat step 1 for this domain, eventually receiving a JWK set) 3. Connect to im.example.com over XMPP, initiate TLS negotiation via STARTTLS, check the PKIX certificate presented by the TLS server against the information in the JWK set, and if all is OK then proceed to do various IM things through the XMPP server at im.example.com As far as I can see, these scenarios are very different in terms of goals and process. I freely admit that I might be missing something that is specified in or implied by the EST spec, but right now I don't see what that might be. Enlightenment would be welcome. :-) Peter _______________________________________________ posh mailing list posh@ietf.org https://www.ietf.org/mailman/listinfo/posh -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSDS7dAAoJEOoGpJErxa2pvkYQAIKJsC0c+q6AUP9JAPN/z2aU mIjglJSjiUr4oJLjY0PpR6Ia6khb20TRfpYb/tncZEAYeZ/xM0GlkosoxYi99d37 MMxtGHMfeJYaqe4JveEeDRiyeEEeqDCqgCjqU2aEKTfbJGkLCq3E6nVb9no+pMNu 932Yuq1pPOSmqOct8oKlwavpVYz+3nScqHnCMrsRhcfQTSgOB4BB4E2b8GR5ZO07 GxmuiWajztCh6BvvpfXC4XlZvk3ywm9Lff22TF2XmU0kP2833CWsEWbSBuII0j9f g+rlFSwhusMeuedKXTovzYnj5nh3XUEi/FN/EBmwl24FycyyS1lF/uhKf2eDNY2/ tw4a53ZXYx25TdBxMfLOt25c0MNYNNayRlFMvQhMa6uRm72zDsUJ7WCsDliBt9WK vzmQ7VRCMzkJ/FmCTXW+xzD/JSOWTyQc6zjyr0I+qoZZ2OzkuHVg6Lw6maJWCkso S9Lu4lmbCvd+Vd861o3sVnJQqriHJz6wRciz3V5jQbUki5+R3diqE2K2oV4XFOVT 1NgyBFbghQvye6keLxAkYBwzQepYHw4e2CvuZjFHaLk+mUkxAiYoUvAtmzT5fzJb W1f0gOi47YB6sn5T+0BFYzgNojsfxuCO0VmUCaUzmCV6KhLAl2erJPSmukgL5w7D oHOmoH3jJLw3dCu2GcKD =dP/G -----END PGP SIGNATURE----- From tgindin@us.ibm.com Fri Aug 16 18:51:03 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 09A2311E81DD for ; Fri, 16 Aug 2013 18:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.498 X-Spam-Level: X-Spam-Status: No, score=-9.498 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, MIME_BAD_LINEBREAK=0.5, 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 rvuf7DR+lrya for ; Fri, 16 Aug 2013 18:50:56 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 475FF11E81C5 for ; Fri, 16 Aug 2013 18:50:53 -0700 (PDT) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sat, 17 Aug 2013 02:50:52 +0100 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Sat, 17 Aug 2013 02:50:50 +0100 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 81AAF6E8040 for ; Fri, 16 Aug 2013 21:50:44 -0400 (EDT) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r7H1ona1174764 for ; Fri, 16 Aug 2013 21:50:49 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r7H1onKS026428 for ; Fri, 16 Aug 2013 22:50:49 -0300 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r7H1om3k026414; Fri, 16 Aug 2013 22:50:48 -0300 In-Reply-To: <0f3301ce993c$89b7ba90$9d272fb0$@ditenity.com> References: <20130812125639.9598CB1E005@rfc-editor.org> <520BA165.3050404@bbn.com> <0f0b01ce991e$aac85f50$00591df0$@ditenity.com> <520BEBDB.90009@bbn.com> <0f3301ce993c$89b7ba90$9d272fb0$@ditenity.com> To: "Piyush Jain" MIME-Version: 1.0 X-KeepSent: F856E5D4:91020987-85257BC8:005F6C7B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Tom Gindin Message-ID: Date: Fri, 16 Aug 2013 21:50:46 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 08/16/2013 21:50:48, Serialize complete at 08/16/2013 21:50:48 Content-Type: multipart/alternative; boundary="=_alternative 000A23E285257BCA_=" X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13081701-0320-0000-0000-000000B54CF6 Cc: fweimer@redhat.com, stefans@microsoft.com, stefan@aaa-sec.com, pkix@ietf.org, 'RFC Errata System' Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) 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: Sat, 17 Aug 2013 01:51:03 -0000 This is a multipart message in MIME format. --=_alternative 000A23E285257BCA_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable The statement "is technically a NOP" in this erratum is wrong,=20 since the name constraint does restrict most uses of DNS name in a=20 certificate. An accurate description of this complaint would be "does not = effectively constrain all DNS Names used by RFC 2818". The complaint=20 appears to assume that all CN attribute values should be constrained in=20 this way. However, many (and perhaps most) CN attribute values don't have = DNS names in them. RFC 5280 section 4.2.1.6 already requires that the=20 subjectAltName field be populated when a DNS name is used ("Whenever such=20 identities are to be bound into a certificate, the subject alternative name (or issuer alternative name) extension MUST be used"), and RFC 2818 section 3.1 gives SAN=20 preference over CN when both are present. For that matter, RFC 2459=20 4.2.1.7 had the same requirement as 5280 14 years ago. Changes along these lines are particularly inappropriate for RFC=20 5280 because it isn't clear how one can reliably determine whether a CN=20 contains a DNS name or not. The heuristic about having periods but no=20 spaces really isn't robust enough for inclusion in a standard. Since 2818 = does NOT restrict its scope to certificates using the appropriate key=20 purposes, 5280's algorithm could not be effectively modified even if this=20 group were willing to include something like "if Extended Key Usage=20 contains server-auth and the SubjectAlternativeName extension is missing". Something that would produce the effect that the author appears to = want might be that a TLS client implementation SHOULD perform name=20 constraint verification before carrying out the check on the CN in RFC=20 2818 section 3.1 (2nd sentence of 3rd paragraph). However, that's a=20 change rather than an erratum, and it's specific to RFC 2818 and would be=20 a new subsection of a successor to that RFC. In any case, it would NOT=20 apply to RFC 2459/3280/5280-compliant certificates, because that check on=20 the CN never occurs for them. The current algorithm in section 6 couldn't be simply modified for = this purpose anyway, since the subtree checks occur for each element in=20 the tree and the CN check doesn't apply to intermediate certificates.=20 Tom Gindin From: "Piyush Jain" To: "'Stephen Kent'" ,=20 Cc: fweimer@redhat.com, stefan@aaa-sec.com, pkix@ietf.org,=20 stefans@microsoft.com, "'RFC Errata System'" Date: 08/14/2013 06:21 PM Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) Sent by: pkix-bounces@ietf.org Stephan, =20 Your explanation below convinces me that 5280 does not require relying=20 parties to apply name constraint on DNS names extracted from the CN. However, I still think that it was an oversight and not a conscious=20 decision. At that time this WG did not take into account the common=20 practice of using CN for DNS name in server certificates. I did not find=20 any discussions in the pkix archive which indicate that WG discussed the=20 applicability of NC on DNS name embedded in CN and consciously decided to=20 leave any excpetions for DNS name out of the text. =20 The purpose of NC extension is to allow a CA to constraint the sub CA.=20 Current RFC 5280 text allows sub CAs to bypass any constraint on the DNS=20 name by issuing a certificate without the altName. Won?t you agree that it = defeats the purpose of having a NC extension. =20 This issue was raised last year as well by Santosh without any conclusion. = http://www.ietf.org/mail-archive/web/pkix/current/msg30897.html. =20 BTW, it seems that both Mozilla and chrome apply DNS name constraints to=20 DNS name extracted from CN. =20 -Piyush =20 From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Wednesday, August 14, 2013 1:43 PM To: Piyush Jain Cc: 'RFC Errata System'; fweimer@redhat.com; stefans@microsoft.com;=20 stefan@aaa-sec.com; pkix@ietf.org Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) =20 Piyush, I think it is filled as a technical not an editorial erratum. And I also think that this should be editorial :). =20 The intent is clearly stated in 4.2.1.10 paragraph 4. =20 "If a name constraints extension that is marked as critical imposes constraints on a particular name form, and an instance of that name form appears in the subject field or subjectAltName extension of a subsequent certificate, then the application MUST either process the constraint or reject the certificate." =20 So the fact that the DNS name was extracted from subjectName as opposed to subjectAltName is irrelevant. The constraint must be applied in either=20 case. I disagree. The source of the identifier is relevant. The first paragraph=20 of 4.2.1.10 ends with these 2 sentences: Restrictions apply only when the specified name form is present. If no name of the type is in the certificate, the certificate is acceptable. When a DNS name appears in the Subject name, not the subject alt name=20 extension, it it not typed as a DNS name. It is an attribute of a Subject DN, often a CN attribute. If it were expressed as a series of domainComponent=20 attributes, then I might agree that it was typed as a DNS name, but that does not tend = to happen=20 in practice. Also, pages 21-22 note that use of the domainComponent=20 attribute is=20 not a substitute for using a dNSName in the Subject alt name extension,=20 and that there is NO requirement for an implementation to convert a sequence of DCs = into a DNS name. But such a conversion is what would be needed to perform the=20 name=20 constraints comparison, so ... Note further that, on pages 41-42, an explicit exception is made for=20 rfcC822 names that are encoded in a DN as an attribute type of emailAddress. If the intent=20 was to create the same exception for DNS names appearing in the Subject=20 field, it would appear in this section. It does not. So there seems to be=20 no basis for assuming that the treatment=20 of a DNS name that appears in the Subject name field using some=20 attribute(s) is an oversight. Steve=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 000A23E285257BCA_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable         The statement "is technically a NOP" in this erratum is wrong, since the name constraint does restrict most uses of DNS name in a certificate.  An accurate description of this complaint would be "does not effectively constrain all DNS Names used by RFC 2818".  The complaint appears to assume that all CN attribute values should be constrained in this way.  Howev= er, many (and perhaps most) CN attribute values don't have DNS names in them.  RFC 5280 section 4.2.1.6 already requires that the subjectAltName field be populated when a DNS name is used ("Whenever such identities are to be bound into a=0D certificate, the subject alternative name (or iss= uer alternative=0D name) extension MUST be used"), and RFC 2818 sectio= n 3.1 gives SAN preference over CN when both are present.  For that matter, RFC 2459 4.2.1.7 had the same requirement as 5280 14 years ago.
        Changes along these lines are particularly inappropriate for RFC 5280 because it isn't clear how one can reliably determine whether a CN contains a DNS name or not.  The heuristic about having periods but no spaces really isn't robust enough for inclusion in a standard.  Since 2818 does NOT restri= ct its scope to certificates using the appropriate key purposes, 5280's algori= thm could not be effectively modified even if this group were willing to include something like "if Extended Key Usage contains server-auth and the SubjectAlternativeName extension is missing".
        Something that would produce the effect that the author appears to want might be that a TLS client implementation SHOULD perform name constraint verification before carrying out the check on the CN in RFC 2818 section 3.1 (2nd senten= ce of 3rd paragraph).  However, that's a change rather than an erratum, and it's specific to RFC 2818 and would be a new subsection of a successor to that RFC.  In any case, it would NOT apply to RFC 2459/3280/5280-co= mpliant certificates, because that check on the CN never occurs for them.
        The current algorithm in section 6 couldn't be simply modified for this purpose anyway, since the subtree checks occur for each element in the tree and the CN check doesn't apply to intermediate certificates.  

Tom Gindin



From:     =    "Piyush Jain" <piyush@ditenity.com>
To:     &n= bsp;  "'Stephen Kent'" <kent@bbn.com>,
Cc:     &n= bsp;  fweimer@redhat.com, stefan@aaa-sec.com, pkix@ietf.org, stefans@microsoft.com, "'RFC Errata System'" <rfc-editor@rfc-editor.org>
Date:     =    08/14/2013 06:21 PM
Subject:   &nbs= p;    Re: [pkix] [Technical Errata Reported] RFC5280 (3693)
Sent by:   &nbs= p;    pkix-bounces@ietf.or= g



Stephan,
 
Your explanation below = convinces me that 5280 does not require relying parties to apply name constraint on DNS names extracted from the CN.
However, I still think = that it was an oversight and not a conscious decision. At that time this WG did not take into account the common practice of using CN for DNS name in server certificates. I did not find any discussions in the pkix archive which indicate that WG discussed the applicability of NC on DNS name embedd= ed in CN and consciously decided to leave any excpetions for DNS name out of the text.
 
The purpose of NC exten= sion is to allow a CA to constraint the sub CA. Current RFC 5280 text allows sub CAs to bypass any constraint on the DNS name by issuing a certificate without the altName. Won’t you agree that it defeats the purpose of h= aving a NC extension.
 
This issue was raised l= ast year as well by Santosh without any conclusion. http://www.ietf.org/mail-archive/web/pkix/c= urrent/msg30897.html.
 
BTW,  it seems that both Mozilla and chrome apply DNS name constraints to DNS name extracted from CN.
 
-Piyush
 
From: Stephen Kent [mailto:kent@bbn.co= m]
Sent: Wednesday, August 14, 2013 1:43 PM
To: Piyush Jain
Cc: 'RFC Errata System'; fweimer@redhat.com; stefans@microsoft.com; stefan@aaa-sec.com; pkix@ietf.org
Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693)
 
Piyush,
I think it is filled as a technical not an editorial erratum. And I also
think that this should be editorial :).
 
The intent is clearly stated in 4.2= .1.10 paragraph 4.
 
"If a name constraints extensi= on that is marked as critical imposes
constraints on a particular name fo= rm, and an instance of  that name form
appears in the subject field or sub= jectAltName extension of a subsequent
certificate, then the application M= UST  either process the constraint or
reject the certificate."
 
So the fact that the DNS name was e= xtracted from subjectName as opposed to
subjectAltName is irrelevant. The c= onstraint must be applied in either case.
I disagree. The source of the i= dentifier is relevant. The first paragraph of
4.2.1.10 ends with these 2 sentences:
   Restrictions apply only when the specified name form is present.
  If no name of the type is in the certificate, the certificate is
  acceptable.

When a DNS name appears in the Subject name, not the subject alt name exten= sion, it
it not typed as a DNS name. It is an attribute of a Subject DN, often a
CN attribute. If it were expressed as a series of domainComponent attribute= s,
then I might agree that it was typed as a DNS name, but that does not tend to happen
in practice. Also, pages 21-22 note that use of the domainComponent attribu= te is
not a substitute for using a dNSName in the Subject alt name extension, and that
there is NO requirement for an implementation to convert a sequence of DCs into
a DNS name. But such a conversion is what would be needed to perform the name
constraints comparison, so ...

Note further that, on pages 41-42, an explicit exception is made for rfcC822 names that
are encoded in a DN as an attribute type of emailAddress. If the intent was to create the same exception for DNS names appearing in the Subject field, it would appear in this section. It does not. So there seems to be no basis for assuming that the treatment
of a DNS name that appears in the Subject name field using some attribute(s) is an
oversight.

Steve=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 000A23E285257BCA_=-- From piyush@ditenity.com Fri Aug 16 21:46:37 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 5E93511E81C9 for ; Fri, 16 Aug 2013 21:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 YTDYxsNHjJPj for ; Fri, 16 Aug 2013 21:46:32 -0700 (PDT) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA1111E80D2 for ; Fri, 16 Aug 2013 21:46:32 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i10so3184073oag.2 for ; Fri, 16 Aug 2013 21:46:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:thread-index:content-language; bh=ED7Lk2MXFKzWb/nrzZqXcf2eigqkrfbIeCzwDkn3iM8=; b=eELHzWH2/fQWEo22d1satl911yUfJGuIBAExsz7OrQTX25w+CIkRDvY+ZX51YliFWJ zhGX1SMgXtuNEGGXEy+/sA+rMId9BnKCoi6IiXV/y5hJyp1tc4NuUmtC5SCF0IITGLzH YZ0P+Jx/0GM1KoCCBzPaER+V+t1HrJLuM74KzG3F9T/EtmX5yp+fI6iOHMmO5GS9eJHG Uma7EGVdqPAdbLRVuFyDle10Z8jsnmlL0/k/EaIIIwlOfS4nBw4kQZnmCNNkHdp5sJ6h hOIqo4pbXTwTs3C00b4CzOHmmixL9agnGjr04Llhxe+KgYUz02VSxbsKgYeBSCkFNHZH Gkyg== X-Gm-Message-State: ALoCoQm7CNlV7j050G1CabtBWT+K1k+92K8KVuG7Odcrr9UJSnhN8lkKPCBJFsQQNnL3x6eqOMwG X-Received: by 10.60.51.7 with SMTP id g7mr89904oeo.6.1376714791615; Fri, 16 Aug 2013 21:46:31 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPSA id y1sm1177755oek.4.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 16 Aug 2013 21:46:31 -0700 (PDT) From: "Piyush Jain" To: "'Tom Gindin'" References: <20130812125639.9598CB1E005@rfc-editor.org> <520BA165.3050404@bbn.com> <0f0b01ce991e$aac85f50$00591df0$@ditenity.com> <520BEBDB.90009@bbn.com> <0f3301ce993c$89b7ba90$9d272fb0$@ditenity.com> In-Reply-To: Date: Fri, 16 Aug 2013 21:46:27 -0700 Message-ID: <048801ce9b04$bd1ecd50$375c67f0$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0489_01CE9ACA.10C2B470" X-Mailer: Microsoft Outlook 14.0 thread-index: AQFgJ5tAE2DhtElIelX+JvqTRkl3PgFDzzI+AgkYwPgBm9kDvwHHlFGJAZvILGCaM1VCIA== Content-Language: en-us Cc: fweimer@redhat.com, stefans@microsoft.com, stefan@aaa-sec.com, pkix@ietf.org, 'RFC Errata System' Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) 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: Sat, 17 Aug 2013 04:46:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0489_01CE9ACA.10C2B470 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Agreed. Such checks cannot be performed by the basic path validator as defined by the RFC 5280. This check, however should be performed by a TLS client if it extracts DNS name from CN. So it belongs in the TLS specification. -Piyush From: Tom Gindin [mailto:tgindin@us.ibm.com] Sent: Friday, August 16, 2013 6:51 PM To: Piyush Jain Cc: fweimer@redhat.com; 'Stephen Kent'; pkix@ietf.org; 'RFC Errata System'; stefan@aaa-sec.com; stefans@microsoft.com Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) The statement "is technically a NOP" in this erratum is wrong, since the name constraint does restrict most uses of DNS name in a certificate. An accurate description of this complaint would be "does not effectively constrain all DNS Names used by RFC 2818". The complaint appears to assume that all CN attribute values should be constrained in this way. However, many (and perhaps most) CN attribute values don't have DNS names in them. RFC 5280 section 4.2.1.6 already requires that the subjectAltName field be populated when a DNS name is used ("Whenever such identities are to be bound into a certificate, the subject alternative name (or issuer alternative name) extension MUST be used"), and RFC 2818 section 3.1 gives SAN preference over CN when both are present. For that matter, RFC 2459 4.2.1.7 had the same requirement as 5280 14 years ago. Changes along these lines are particularly inappropriate for RFC 5280 because it isn't clear how one can reliably determine whether a CN contains a DNS name or not. The heuristic about having periods but no spaces really isn't robust enough for inclusion in a standard. Since 2818 does NOT restrict its scope to certificates using the appropriate key purposes, 5280's algorithm could not be effectively modified even if this group were willing to include something like "if Extended Key Usage contains server-auth and the SubjectAlternativeName extension is missing". Something that would produce the effect that the author appears to want might be that a TLS client implementation SHOULD perform name constraint verification before carrying out the check on the CN in RFC 2818 section 3.1 (2nd sentence of 3rd paragraph). However, that's a change rather than an erratum, and it's specific to RFC 2818 and would be a new subsection of a successor to that RFC. In any case, it would NOT apply to RFC 2459/3280/5280-compliant certificates, because that check on the CN never occurs for them. The current algorithm in section 6 couldn't be simply modified for this purpose anyway, since the subtree checks occur for each element in the tree and the CN check doesn't apply to intermediate certificates. Tom Gindin From: "Piyush Jain" To: "'Stephen Kent'" , Cc: fweimer@redhat.com, stefan@aaa-sec.com, pkix@ietf.org, stefans@microsoft.com, "'RFC Errata System'" Date: 08/14/2013 06:21 PM Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) Sent by: pkix-bounces@ietf.org _____ Stephan, Your explanation below convinces me that 5280 does not require relying parties to apply name constraint on DNS names extracted from the CN. However, I still think that it was an oversight and not a conscious decision. At that time this WG did not take into account the common practice of using CN for DNS name in server certificates. I did not find any discussions in the pkix archive which indicate that WG discussed the applicability of NC on DNS name embedded in CN and consciously decided to leave any excpetions for DNS name out of the text. The purpose of NC extension is to allow a CA to constraint the sub CA. Current RFC 5280 text allows sub CAs to bypass any constraint on the DNS name by issuing a certificate without the altName. Won't you agree that it defeats the purpose of having a NC extension. This issue was raised last year as well by Santosh without any conclusion. http://www.ietf.org/mail-archive/web/pkix/current/msg30897.html. BTW, it seems that both Mozilla and chrome apply DNS name constraints to DNS name extracted from CN. -Piyush From: Stephen Kent [ mailto:kent@bbn.com] Sent: Wednesday, August 14, 2013 1:43 PM To: Piyush Jain Cc: 'RFC Errata System'; fweimer@redhat.com; stefans@microsoft.com; stefan@aaa-sec.com; pkix@ietf.org Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) Piyush, I think it is filled as a technical not an editorial erratum. And I also think that this should be editorial :). The intent is clearly stated in 4.2.1.10 paragraph 4. "If a name constraints extension that is marked as critical imposes constraints on a particular name form, and an instance of that name form appears in the subject field or subjectAltName extension of a subsequent certificate, then the application MUST either process the constraint or reject the certificate." So the fact that the DNS name was extracted from subjectName as opposed to subjectAltName is irrelevant. The constraint must be applied in either case. I disagree. The source of the identifier is relevant. The first paragraph of 4.2.1.10 ends with these 2 sentences: Restrictions apply only when the specified name form is present. If no name of the type is in the certificate, the certificate is acceptable. When a DNS name appears in the Subject name, not the subject alt name extension, it it not typed as a DNS name. It is an attribute of a Subject DN, often a CN attribute. If it were expressed as a series of domainComponent attributes, then I might agree that it was typed as a DNS name, but that does not tend to happen in practice. Also, pages 21-22 note that use of the domainComponent attribute is not a substitute for using a dNSName in the Subject alt name extension, and that there is NO requirement for an implementation to convert a sequence of DCs into a DNS name. But such a conversion is what would be needed to perform the name constraints comparison, so ... Note further that, on pages 41-42, an explicit exception is made for rfcC822 names that are encoded in a DN as an attribute type of emailAddress. If the intent was to create the same exception for DNS names appearing in the Subject field, it would appear in this section. It does not. So there seems to be no basis for assuming that the treatment of a DNS name that appears in the Subject name field using some attribute(s) is an oversight. Steve_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_000_0489_01CE9ACA.10C2B470 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agreed.

 

Such checks cannot be performed by the basic path validator as = defined by the RFC 5280.

This check, however should be performed by a TLS client if it = extracts DNS name from CN. So it belongs in the TLS specification. =

 

-Piyush

 

 

 

From:= = Tom Gindin [mailto:tgindin@us.ibm.com]
Sent: Friday, August = 16, 2013 6:51 PM
To: Piyush Jain
Cc: = fweimer@redhat.com; 'Stephen Kent'; pkix@ietf.org; 'RFC Errata System'; = stefan@aaa-sec.com; stefans@microsoft.com
Subject: Re: [pkix] = [Technical Errata Reported] RFC5280 = (3693)

 

        The statement = "is technically a NOP" in this erratum is wrong, since the = name constraint does restrict most uses of DNS name in a certificate. =  An accurate description of this complaint would be "does not = effectively constrain all DNS Names used by RFC 2818".  The = complaint appears to assume that all CN attribute values should be = constrained in this way.  However, many (and perhaps most) CN = attribute values don't have DNS names in them.  RFC 5280 section = 4.2.1.6 already requires that the subjectAltName field be populated when = a DNS name is used ("Whenever such identities are to be bound into = a certificate, the subject alternative name (or issuer alternative name) = extension MUST be used"), and RFC 2818 section 3.1 gives SAN = preference over CN when both are present.  For that matter, RFC = 2459 4.2.1.7 had the same requirement as 5280 14 years ago. =
        = Changes along these lines are particularly inappropriate for RFC 5280 = because it isn't clear how one can reliably determine whether a CN = contains a DNS name or not.  The heuristic about having periods but = no spaces really isn't robust enough for inclusion in a standard. =  Since 2818 does NOT restrict its scope to certificates using the = appropriate key purposes, 5280's algorithm could not be effectively = modified even if this group were willing to include something like = "if Extended Key Usage contains server-auth and the = SubjectAlternativeName extension is missing". =
        = Something that would produce the effect that the author appears to want = might be that a TLS client implementation SHOULD perform name constraint = verification before carrying out the check on the CN in RFC 2818 section = 3.1 (2nd sentence of 3rd paragraph).  However, that's a change = rather than an erratum, and it's specific to RFC 2818 and would be a new = subsection of a successor to that RFC.  In any case, it would NOT = apply to RFC 2459/3280/5280-compliant certificates, because that check = on the CN never occurs for them.
        The current = algorithm in section 6 couldn't be simply modified for this purpose = anyway, since the subtree checks occur for each element in the tree and = the CN check doesn't apply to intermediate certificates. =  

Tom = Gindin




= From:        "Piyush = Jain" <piyush@ditenity.com> =
= To:        "'Stephen= Kent'" <kent@bbn.com>, =
= Cc:        fweimer@redhat.com, stefan@aaa-sec.com, pkix@ietf.org, stefans@microsoft.com, = "'RFC Errata System'" <rfc-editor@rfc-editor.org&g= t;
= Date:        08/14/2013 = 06:21 PM
= Subject:        Re: [pkix] = [Technical Errata Reported] RFC5280 (3693)
= Sent by:        pkix-bounces@ietf.org =




Stephan,
 
Your explanation below convinces me that 5280 does not require = relying parties to apply name constraint on DNS names extracted from the = CN.
However, I still think that it was an oversight and not a conscious = decision. At that time this WG did not take into account the common = practice of using CN for DNS name in server certificates. I did not find = any discussions in the pkix archive which indicate that WG discussed the = applicability of NC on DNS name embedded in CN and consciously decided = to leave any excpetions for DNS name out of the text.
 
The purpose of NC extension is to allow a CA to constraint the sub = CA. Current RFC 5280 text allows sub CAs to bypass any constraint on the = DNS name by issuing a certificate without the altName. Won’t you = agree that it defeats the purpose of having a NC extension. =
 
This issue was raised last year as well by Santosh without any = conclusion. = http://www.ietf.org/mail-archive/web/pkix/current/msg30897.html= .
 
BTW,  it seems that both Mozilla and chrome apply DNS name = constraints to DNS name extracted from CN.
 
-Piyush
 
From: Stephen = Kent [mailto:kent= @bbn.com] =
Sent: Wednesday, August 14, 2013 1:43 PM
To: Piyush = Jain
Cc: 'RFC Errata System'; fweimer@redhat.com; stefans@microsoft.com; stefan@aaa-sec.com; pkix@ietf.org
Subject: Re: = [pkix] [Technical Errata Reported] RFC5280 (3693)
  =
Piyush,

I think it is filled as a technical not an editorial erratum. And = I also
think that this should be editorial :).
  =
The = intent is clearly stated in 4.2.1.10 paragraph 4.
  =
"If = a name constraints extension that is marked as critical imposes =
constraints on a particular name form, and an instance of =  that name form
appears in the = subject field or subjectAltName extension of a subsequent =
certificate, then the application MUST  either process the = constraint or
reject the = certificate."
  =
So the = fact that the DNS name was extracted from subjectName as opposed = to
subjectAltName is irrelevant. The constraint must be applied in = either case.
I disagree. The source of the identifier is = relevant. The first paragraph of
4.2.1.10 ends with these 2 = sentences:


   Restrictions apply only when the = specified name form is present.
  If no name of the type is in = the certificate, the certificate is
  acceptable.

When a = DNS name appears in the Subject name, not the subject alt name = extension, it
it not typed as a DNS name. It is an attribute of a = Subject DN, often a
CN attribute. If it were expressed as a series of = domainComponent attributes,
then I might agree that it was typed as a = DNS name, but that does not tend to happen
in practice. Also, pages = 21-22 note that use of the domainComponent attribute is
not a = substitute for using a dNSName in the Subject alt name extension, and = that
there is NO requirement for an implementation to convert a = sequence of DCs into
a DNS name. But such a conversion is what would = be needed to perform the name
constraints comparison, so = ...

Note further that, on pages 41-42, an explicit exception is = made for rfcC822 names that
are encoded in a DN as an attribute type = of emailAddress. If the intent was to create the same exception for DNS = names appearing in the Subject field, it would appear in this section. = It does not. So there seems to be no basis for assuming that the = treatment
of a DNS name that appears in the Subject name field using = some attribute(s) is an
oversight.

Steve______________________________________________= _
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

------=_NextPart_000_0489_01CE9ACA.10C2B470-- From tgindin@us.ibm.com Tue Aug 20 18:54: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 433F31F0D37 for ; Tue, 20 Aug 2013 18:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.748 X-Spam-Level: X-Spam-Status: No, score=-9.748 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, 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 LwCQ66b+D4+2 for ; Tue, 20 Aug 2013 18:54:09 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 5499F11E8366 for ; Tue, 20 Aug 2013 18:54:07 -0700 (PDT) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 20 Aug 2013 21:54:06 -0400 Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 20 Aug 2013 21:54:03 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 86983C9003E for ; Tue, 20 Aug 2013 21:54:00 -0400 (EDT) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r7L1s2u3183412 for ; Tue, 20 Aug 2013 21:54:02 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r7L1s1bS012465 for ; Tue, 20 Aug 2013 21:54:02 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r7L1s1rf012459; Tue, 20 Aug 2013 21:54:01 -0400 In-Reply-To: <048801ce9b04$bd1ecd50$375c67f0$@ditenity.com> References: <20130812125639.9598CB1E005@rfc-editor.org> <520BA165.3050404@bbn.com> <0f0b01ce991e$aac85f50$00591df0$@ditenity.com> <520BEBDB.90009@bbn.com> <0f3301ce993c$89b7ba90$9d272fb0$@ditenity.com> <048801ce9b04$bd1ecd50$375c67f0$@ditenity.com> To: "Piyush Jain" MIME-Version: 1.0 X-KeepSent: 9CFB667E:C9649563-85257BCC:0060D348; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Tom Gindin Message-ID: Date: Tue, 20 Aug 2013 21:53:58 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3FP2 ZX853FP2HF5|February, 2013) at 08/20/2013 21:54:00, Serialize complete at 08/20/2013 21:54:00 Content-Type: multipart/alternative; boundary="=_alternative 000A6EE085257BCE_=" X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13082101-7182-0000-0000-000008285885 Cc: fweimer@redhat.com, pkix@ietf.org, stefan@aaa-sec.com, 'RFC Errata System' Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) 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, 21 Aug 2013 01:54:19 -0000 This is a multipart message in MIME format. --=_alternative 000A6EE085257BCE_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Piyush, TLS doesn't specify the matching rules between requested=20 server names and certificates, HTTPS (RFC 2818) does. That has the=20 somewhat odd result that LDAPS' only matching rules for this purpose are=20 those it inherits from HTTPS. Perhaps those rules should be split out of=20 2818 and be added to TLS, but they haven't yet been. Since this can't ever apply to a 5280-compliant cert, shouldn't it = go to a different place if not rejected - either 2818 or a successor which = is part of the TLS set? Tom Gindin From: "Piyush Jain" To: Tom Gindin/Watson/IBM@IBMUS,=20 Cc: , "'Stephen Kent'" ,=20 , "'RFC Errata System'" ,=20 , Date: 08/17/2013 12:46 AM Subject: RE: [pkix] [Technical Errata Reported] RFC5280 (3693) Agreed. =20 Such checks cannot be performed by the basic path validator as defined by=20 the RFC 5280.=20 This check, however should be performed by a TLS client if it extracts DNS = name from CN. So it belongs in the TLS specification.=20 =20 -Piyush =20 =20 =20 From: Tom Gindin [mailto:tgindin@us.ibm.com]=20 Sent: Friday, August 16, 2013 6:51 PM To: Piyush Jain Cc: fweimer@redhat.com; 'Stephen Kent'; pkix@ietf.org; 'RFC Errata=20 System'; stefan@aaa-sec.com; stefans@microsoft.com Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) =20 The statement "is technically a NOP" in this erratum is wrong,=20 since the name constraint does restrict most uses of DNS name in a=20 certificate. An accurate description of this complaint would be "does not = effectively constrain all DNS Names used by RFC 2818". The complaint=20 appears to assume that all CN attribute values should be constrained in=20 this way. However, many (and perhaps most) CN attribute values don't have = DNS names in them. RFC 5280 section 4.2.1.6 already requires that the=20 subjectAltName field be populated when a DNS name is used ("Whenever such=20 identities are to be bound into a certificate, the subject alternative=20 name (or issuer alternative name) extension MUST be used"), and RFC 2818=20 section 3.1 gives SAN preference over CN when both are present. For that=20 matter, RFC 2459 4.2.1.7 had the same requirement as 5280 14 years ago.=20 Changes along these lines are particularly inappropriate for RFC=20 5280 because it isn't clear how one can reliably determine whether a CN=20 contains a DNS name or not. The heuristic about having periods but no=20 spaces really isn't robust enough for inclusion in a standard. Since 2818 = does NOT restrict its scope to certificates using the appropriate key=20 purposes, 5280's algorithm could not be effectively modified even if this=20 group were willing to include something like "if Extended Key Usage=20 contains server-auth and the SubjectAlternativeName extension is missing". = Something that would produce the effect that the author appears to = want might be that a TLS client implementation SHOULD perform name=20 constraint verification before carrying out the check on the CN in RFC=20 2818 section 3.1 (2nd sentence of 3rd paragraph). However, that's a=20 change rather than an erratum, and it's specific to RFC 2818 and would be=20 a new subsection of a successor to that RFC. In any case, it would NOT=20 apply to RFC 2459/3280/5280-compliant certificates, because that check on=20 the CN never occurs for them.=20 The current algorithm in section 6 couldn't be simply modified for = this purpose anyway, since the subtree checks occur for each element in=20 the tree and the CN check doesn't apply to intermediate certificates. =20 Tom Gindin From: "Piyush Jain" =20 To: "'Stephen Kent'" ,=20 Cc: fweimer@redhat.com, stefan@aaa-sec.com, pkix@ietf.org,=20 stefans@microsoft.com, "'RFC Errata System'" =20 Date: 08/14/2013 06:21 PM=20 Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693)=20 Sent by: pkix-bounces@ietf.org=20 Stephan,=20 =20 Your explanation below convinces me that 5280 does not require relying=20 parties to apply name constraint on DNS names extracted from the CN.=20 However, I still think that it was an oversight and not a conscious=20 decision. At that time this WG did not take into account the common=20 practice of using CN for DNS name in server certificates. I did not find=20 any discussions in the pkix archive which indicate that WG discussed the=20 applicability of NC on DNS name embedded in CN and consciously decided to=20 leave any excpetions for DNS name out of the text.=20 =20 The purpose of NC extension is to allow a CA to constraint the sub CA.=20 Current RFC 5280 text allows sub CAs to bypass any constraint on the DNS=20 name by issuing a certificate without the altName. Won?t you agree that it = defeats the purpose of having a NC extension.=20 =20 This issue was raised last year as well by Santosh without any conclusion. = http://www.ietf.org/mail-archive/web/pkix/current/msg30897.html.=20 =20 BTW, it seems that both Mozilla and chrome apply DNS name constraints to=20 DNS name extracted from CN.=20 =20 -Piyush=20 =20 From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Wednesday, August 14, 2013 1:43 PM To: Piyush Jain Cc: 'RFC Errata System'; fweimer@redhat.com; stefans@microsoft.com;=20 stefan@aaa-sec.com; pkix@ietf.org Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693)=20 =20 Piyush, I think it is filled as a technical not an editorial erratum. And I also=20 think that this should be editorial :).=20 =20 The intent is clearly stated in 4.2.1.10 paragraph 4.=20 =20 "If a name constraints extension that is marked as critical imposes=20 constraints on a particular name form, and an instance of that name form=20 appears in the subject field or subjectAltName extension of a subsequent=20 certificate, then the application MUST either process the constraint or=20 reject the certificate."=20 =20 So the fact that the DNS name was extracted from subjectName as opposed to = subjectAltName is irrelevant. The constraint must be applied in either=20 case.=20 I disagree. The source of the identifier is relevant. The first paragraph=20 of 4.2.1.10 ends with these 2 sentences: Restrictions apply only when the specified name form is present. If no name of the type is in the certificate, the certificate is acceptable.=20 When a DNS name appears in the Subject name, not the subject alt name=20 extension, it it not typed as a DNS name. It is an attribute of a Subject DN, often a CN attribute. If it were expressed as a series of domainComponent=20 attributes, then I might agree that it was typed as a DNS name, but that does not tend = to happen=20 in practice. Also, pages 21-22 note that use of the domainComponent=20 attribute is=20 not a substitute for using a dNSName in the Subject alt name extension,=20 and that there is NO requirement for an implementation to convert a sequence of DCs = into a DNS name. But such a conversion is what would be needed to perform the=20 name=20 constraints comparison, so ... Note further that, on pages 41-42, an explicit exception is made for=20 rfcC822 names that are encoded in a DN as an attribute type of emailAddress. If the intent=20 was to create the same exception for DNS names appearing in the Subject=20 field, it would appear in this section. It does not. So there seems to be=20 no basis for assuming that the treatment=20 of a DNS name that appears in the Subject name field using some=20 attribute(s) is an oversight. Steve=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 000A6EE085257BCE_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable         Piyush, TLS doesn't specify the matching rules between requested server names and certificates, HTTPS (RFC 2818) does.  That has the somewhat odd result that LDAPS' only matching rules for this purpose are those it inherits from HTTPS.  Perhaps those rules should be split out of 2818 and be added to TLS, but they haven't yet been.
        Since this can't ever apply to a 5280-compliant cert, shouldn't it go to a different place if not rejected - either 2818 or a successor which is part of the TLS set?<= /font>

                 Tom Gindin



From:     =    "Piyush Jain" <piyush@ditenity.com>
To:     &n= bsp;  Tom Gindin/Watson/IBM@IBMUS,
Cc:     &n= bsp;  <fweimer@redhat.com>, "'Stephen Kent'" <kent@bbn.com>, <pkix@ietf.org>, "'RFC Errata System'" <rfc-editor@rfc-editor.org>, <stef= an@aaa-sec.com>, <stefans@microsoft.com>
Date:     =    08/17/2013 12:46 AM
Subject:   &nbs= p;    RE: [pkix] [Technical Errata Reported] RFC5280 (3693)



Agreed.
 
Such checks cannot be p= erformed by the basic path validator as defined by the RFC 5280.
This check, however sho= uld be performed by a TLS client if it extracts DNS name from CN. So it belongs in the TLS specification.
 
-Piyush
 
 
 
From: Tom Gindin [mailto:tgindin@= us.ibm.com]
Sent: Friday, August 16, 2013 6:51 PM
To: Piyush Jain
Cc: fweimer@redhat.com; 'Stephen Kent'; pkix@ietf.org; 'RFC Errata System'; stefan@aaa-sec.com; stefans@microsoft.com
Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693)
 
        The sta= tement "is technically a NOP" in this erratum is wrong, since the name constraint does restrict most uses of DNS name in a certificate.  An accurate description of this complaint would be "does not effectively constrain all DNS Names used by RFC 2818".  The complaint appears to assume that all CN attribute values should be constrained in this way.  However, many (and perhaps most) CN attribute values don't have DNS names in them.  RFC 5280 section 4.2.1.6 already requires that the subjectAltName field be populated when a DNS name is used ("Whenever such identities are to be bound into a certificate, the subject alternative name (or issuer alternative name) extension MUST be used"), and RFC 2818 section 3.1 gives SAN preference over CN when both are present.  = For that matter, RFC 2459 4.2.1.7 had the same requirement as 5280 14 years ago.
       Changes along these lines are particularly inappropriate for RFC 5280 because it isn't clear how one can reliably determine whether a CN contains a DNS name or not.  The heuristic about having periods but no spaces really isn't robust enough for inclusion in a standard.  Since 2818 does NOT restrict its scope to certificates using the appropriate key purposes, 5280's algorithm could not be effective= ly modified even if this group were willing to include something like "if Extended Key Usage contains server-auth and the SubjectAlternativeName extension is missing".
       Something that would produce the effect that the author appears to want might be that a TLS client implementation SHOULD perform name constraint verification before carrying out the check on the CN in RFC 2818 section 3.1 (2nd sentence of 3rd paragraph).  However, that's a change rather than an erratum, and it's specific to RFC 2818 and would be a new subsection of a successor to that RFC.  In any case, it would NOT apply to RFC 2459/3280/5280-compliant certificates, because that check on the CN never occurs for them.
       The current algorithm in section 6 couldn't be simply modified for this purpose anyway, since the subtree checks occur for each element in the tree and the CN check doesn't apply to intermediate certificates.   =

Tom Gindin




From:        "= ;Piyush Jain" <piyush@ditenity.com>
To:        "'= Stephen Kent'" <kent@bbn.com>,
Cc:        <= font size=3D1 color=3Dblue face=3D"Arial">fweimer@redhat.com<= /a>, stefan@aaa-sec.com, pkix@ietf.org, stefans@microsoft.com, "'RFC Errata System'" <rfc-editor@rfc-e= ditor.org>
Date:        08/14= /2013 06:21 PM
Subject:        Re: [pkix] [Technical Errata Reported] RFC5280 (3693)
Sent by:        pkix-bounces@ietf.or= g




Stephan,
 
Your explanation below convinces me that 5280 does not require relying parties to apply name constraint on DNS names extracted from the CN.=
However, I still think that it was an oversight and not a conscious decisio= n. At that time this WG did not take into account the common practice of using CN for DNS name in server certificates. I did not find any discussions in the pkix archive which indicate that WG discussed the applicability of NC on DNS name embedded in CN and consciously decided to leave any excpe= tions for DNS name out of the text.
 
The purpose of NC extension is to allow a CA to constraint the sub CA. Current RFC 5280 text allows sub CAs to bypass any constraint on the DNS name by issuing a certificate without the altName. Won’t you agree th= at it defeats the purpose of having a NC extension.
 
This issue was raised last year as well by Santosh without any conclusion. http://www.ietf.= org/mail-archive/web/pkix/current/msg30897.html.
 
BTW,  it seems that both Mozilla and chrome apply DNS name constraints to DNS name extracted from CN.
 
-Piyush
 
From: Stephen Kent [mailto:kent@bbn.com]
Sent: Wednesday, August 14, 2013 1:43 PM
To: Piyush Jain
Cc: 'RFC Errata System'; fweimer@redhat.com<= /a>; stefans@microsoft.com; stefan@aaa-sec.com; pkix@ietf.org<= br> Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693)
 
Piyush,

I think it is filled as a technical not an editorial erratum. And I also
think that this should be editorial :).
 
The intent is clearly stated in 4.2.1.10 paragraph 4.
 
"If a name constraints extension that is marked as critical imposes
constraints on a particular name form, and an instance of  that name form
appears in the subject field or subjectAltName extension of a subsequent
certificate, then the application MUST  either process the constraint or
reject the certificate."
 
So the fact that the DNS name was extracted from subjectName as opposed to
subjectAltName is irrelevant. The constraint must be applied in either case.
I disagree. The source of the identifier is relevant. The first paragraph of
4.2.1.10 ends with these 2 sentences:


  Restrictions apply only when the specified name form is present.
 If no name of the type is in the certificate, the certificate is
 acceptable.

When a DNS name appears in the Subject name, not the subject alt name exten= sion, it
it not typed as a DNS name. It is an attribute of a Subject DN, often a
CN attribute. If it were expressed as a series of domainComponent attribute= s,
then I might agree that it was typed as a DNS name, but that does not tend to happen
in practice. Also, pages 21-22 note that use of the domainComponent attribu= te is
not a substitute for using a dNSName in the Subject alt name extension, and that
there is NO requirement for an implementation to convert a sequence of DCs into
a DNS name. But such a conversion is what would be needed to perform the name
constraints comparison, so ...

Note further that, on pages 41-42, an explicit exception is made for rfcC822 names that
are encoded in a DN as an attribute type of emailAddress. If the intent was to create the same exception for DNS names appearing in the Subject field, it would appear in this section. It does not. So there seems to be no basis for assuming that the treatment
of a DNS name that appears in the Subject name field using some attribute(s) is an
oversight.

Steve=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/list= info/pkix
--=_alternative 000A6EE085257BCE_=-- From stpeter@stpeter.im Tue Aug 20 19:02:21 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 C038111E810C for ; Tue, 20 Aug 2013 19:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 sFCJ8R9CZJT6 for ; Tue, 20 Aug 2013 19:02:15 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B34A921F9C5A for ; Tue, 20 Aug 2013 19:02:15 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 91021414E7; Tue, 20 Aug 2013 20:05:34 -0600 (MDT) Message-ID: <52141FA5.6040804@stpeter.im> Date: Tue, 20 Aug 2013 20:02:13 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tom Gindin References: <20130812125639.9598CB1E005@rfc-editor.org> <520BA165.3050404@bbn.com> <0f0b01ce991e$aac85f50$00591df0$@ditenity.com> <520BEBDB.90009@bbn.com> <0f3301ce993c$89b7ba90$9d272fb0$@ditenity.com> <048801ce9b04$bd1ecd50$375c67f0$@ditenity.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: fweimer@redhat.com, pkix@ietf.org, 'RFC Errata System' , stefan@aaa-sec.com Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) 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, 21 Aug 2013 02:02:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/20/13 7:53 PM, Tom Gindin wrote: > Piyush, TLS doesn't specify the matching rules between requested > server names and certificates, HTTPS (RFC 2818) does. Please see RFC 6125, too. > That has the somewhat odd result that LDAPS' only matching rules > for this purpose are those it inherits from HTTPS. Actually, the rules for LDAP are specified in RFC 4513 (which superseded the rules from RFC 2830). > Perhaps those rules should be split out of 2818 and be added to > TLS, but they haven't yet been. The rules for each application protocol are still defined in the relevant specifications for those protocols. In RFC 6125 we attempted to generalize the rules, but RFC 6125 does not supersede the rules that are already defined for each application protocol (until and unless each protocol decides to use a profile of RFC 6125). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSFB+lAAoJEOoGpJErxa2pBaoP/RwpMJnAjKL2eyi7huvLLKjo SeQEYwXONyg3Fa6w5mUeptPDxd+G9eShy2c/M83GdAzQ8uoxC1Wjm7BFPxu+p5e5 2x7t7Paa0J9s3uXh7Tn7IdILw3BI0akwH6CfeHMx0u1b2Pbfh1doe9tmeMBrc54Q ay5UygDrfMuG5Ti35zColmrhHA/1f+l1Y/cfymiDWylbuaY+DZMms+FE06cE4ynW YXTZluPmCN3aJAtWxXcjAYGDd0R0sgE8S99H8idUtSGVV5OVN/W76BOlcJ+f3Z/1 ltxhQ7qS/wIfnjUxsKGH8BTZISQ0cpPjf07F/R9nJI/ZgZ1aJPOA5nI8L7MTRgiC lpBSlK5YMca+qk4fDOh/QvOtjKkDild4aTtRkoJYR0SgyGpXpm4Vlptbpcz/rmH7 Cnlbvq+V5Fj5RsoiybBpmyXVhSDo57XO8fNiORl7ffG26FtFYHJOCET3RdDSjyRK Q7dyBxQM68zPe6GWJLOjc949UMXUvpujIIRnOG4wUHxNji/736YxnxoG/atrGOJ+ peiG2J00rcCJHhMB2s0PcocA2F+g/wLRoilK8eoWmMtHgT+7DMrg9VIMJqr6hfM5 dEpzdV944vfZr96VI5KnRT6tG15+/ZYhab+DYVOnmYrmISXDMB40s0jnukNhrJ5i NfQ10n0XfgpXalVDOVkK =rgRN -----END PGP SIGNATURE----- From piyush@ditenity.com Tue Aug 20 19:32:05 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 7750B21F9AD8 for ; Tue, 20 Aug 2013 19:32:05 -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=[AWL=0.000, 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 M3MUl-zKIKLi for ; Tue, 20 Aug 2013 19:32:01 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 03BE221F9A43 for ; Tue, 20 Aug 2013 19:32:00 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id m1so2446992oag.4 for ; Tue, 20 Aug 2013 19:32:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :thread-index:content-language; bh=i7NFhT+iP24XTPZAr9PqSsPgdLHMH9urWPB0ITHo/zs=; b=FioiV1eyIuQINIir+O7AP/mEj+HBGfxDwebjyxjQjf2J/9cojfPNWTYV16r713vXYI z4o202NlrRAoyJ3FVSTNnavBuRVR/4k+iUpWe61CUV7gwp83b2Hr+IG9/LTByhZ6xsGn mQcVFiQmd9nq0GWjtTYPZG7hKWP+cCh2WSKnBy+TtCAaF5OKUCirdoxtafRb7CowwHWU pnZjYBKJCXk1k/TXwhOICT2X11qtVmES8BBqGAL7jc85RaQs0C1NP7IA0AtpsWPj+h9x HDP5ngoMccsMIkkn1L624KMRvEHYH3lL8QRnTFQBcgijPeQ0vIujU78DiAk97mPDouoJ 1jgg== X-Gm-Message-State: ALoCoQlaPChC5P7BUvdAfpFYnpJXCagbsY5ywSiV5idDxjBUjfAlXsB43Px09Rlo5KiBkK3mRFZJ X-Received: by 10.60.52.244 with SMTP id w20mr5270661oeo.30.1377052319421; Tue, 20 Aug 2013 19:31:59 -0700 (PDT) Received: from piyushlaptop (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPSA id hl3sm6735148obb.0.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 20 Aug 2013 19:31:58 -0700 (PDT) From: "Piyush Jain" To: "'Peter Saint-Andre'" , "'Tom Gindin'" References: <20130812125639.9598CB1E005@rfc-editor.org> <520BA165.3050404@bbn.com> <0f0b01ce991e$aac85f50$00591df0$@ditenity.com> <520BEBDB.90009@bbn.com> <0f3301ce993c$89b7ba90$9d272fb0$@ditenity.com> <048801ce9b04$bd1ecd50$375c67f0$@ditenity.com> <52141FA5.6040804@stpeter.im> In-Reply-To: <52141FA5.6040804@stpeter.im> Date: Tue, 20 Aug 2013 19:31:54 -0700 Message-ID: <01e901ce9e16$9b029570$d107c050$@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: AQFgJ5tAE2DhtElIelX+JvqTRkl3PgFDzzI+AgkYwPgBm9kDvwHHlFGJAZvILGABe7SHXQJrXy3xAbnStQOaDHLLYA== Content-Language: en-us Cc: fweimer@redhat.com, pkix@ietf.org, 'RFC Errata System' , stefan@aaa-sec.com Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) 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, 21 Aug 2013 02:32:05 -0000 Thanks for providing the references Peter. So a quick look at 4513 and 6125 indicates that the issue raised by this erratum is not addressed anywhere and any application protocol designed over TLS is vulnerable if client implementations extract DNS name from certificate CN. I guess the place to have this discussion is TLS WG. -Piyush > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > Sent: Tuesday, August 20, 2013 7:02 PM > To: Tom Gindin > Cc: Piyush Jain; fweimer@redhat.com; pkix@ietf.org; stefan@aaa-sec.com; > 'RFC Errata System' > Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 8/20/13 7:53 PM, Tom Gindin wrote: > > Piyush, TLS doesn't specify the matching rules between requested > > server names and certificates, HTTPS (RFC 2818) does. > > Please see RFC 6125, too. > > > That has the somewhat odd result that LDAPS' only matching rules for > > this purpose are those it inherits from HTTPS. > > Actually, the rules for LDAP are specified in RFC 4513 (which superseded the > rules from RFC 2830). > > > Perhaps those rules should be split out of 2818 and be added to TLS, > > but they haven't yet been. > > The rules for each application protocol are still defined in the relevant > specifications for those protocols. In RFC 6125 we attempted to generalize > the rules, but RFC 6125 does not supersede the rules that are already > defined for each application protocol (until and unless each protocol decides > to use a profile of RFC 6125). > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJSFB+lAAoJEOoGpJErxa2pBaoP/RwpMJnAjKL2eyi7huvLLKjo > SeQEYwXONyg3Fa6w5mUeptPDxd+G9eShy2c/M83GdAzQ8uoxC1Wjm7BFPx > u+p5e5 > 2x7t7Paa0J9s3uXh7Tn7IdILw3BI0akwH6CfeHMx0u1b2Pbfh1doe9tmeMBrc54 > Q > ay5UygDrfMuG5Ti35zColmrhHA/1f+l1Y/cfymiDWylbuaY+DZMms+FE06cE4yn > W > YXTZluPmCN3aJAtWxXcjAYGDd0R0sgE8S99H8idUtSGVV5OVN/W76BOlcJ+f3Z > /1 > ltxhQ7qS/wIfnjUxsKGH8BTZISQ0cpPjf07F/R9nJI/ZgZ1aJPOA5nI8L7MTRgiC > lpBSlK5YMca+qk4fDOh/QvOtjKkDild4aTtRkoJYR0SgyGpXpm4Vlptbpcz/rmH7 > Cnlbvq+V5Fj5RsoiybBpmyXVhSDo57XO8fNiORl7ffG26FtFYHJOCET3RdDSjyRK > Q7dyBxQM68zPe6GWJLOjc949UMXUvpujIIRnOG4wUHxNji/736YxnxoG/atrG > OJ+ > peiG2J00rcCJHhMB2s0PcocA2F+g/wLRoilK8eoWmMtHgT+7DMrg9VIMJqr6hf > M5 > dEpzdV944vfZr96VI5KnRT6tG15+/ZYhab+DYVOnmYrmISXDMB40s0jnukNhrJ5 > i > NfQ10n0XfgpXalVDOVkK > =rgRN > -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Aug 20 20:05:50 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 517F011E836A for ; Tue, 20 Aug 2013 20:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 qr3dhyNDPaiV for ; Tue, 20 Aug 2013 20:05:46 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 871D711E836B for ; Tue, 20 Aug 2013 20:05:43 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6012B414E7; Tue, 20 Aug 2013 21:09:01 -0600 (MDT) Message-ID: <52142E83.3090503@stpeter.im> Date: Tue, 20 Aug 2013 21:05:39 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Piyush Jain References: <20130812125639.9598CB1E005@rfc-editor.org> <520BA165.3050404@bbn.com> <0f0b01ce991e$aac85f50$00591df0$@ditenity.com> <520BEBDB.90009@bbn.com> <0f3301ce993c$89b7ba90$9d272fb0$@ditenity.com> <048801ce9b04$bd1ecd50$375c67f0$@ditenity.com> <52141FA5.6040804@stpeter.im> <01e901ce9e16$9b029570$d107c050$@ditenity.com> In-Reply-To: <01e901ce9e16$9b029570$d107c050$@ditenity.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: fweimer@redhat.com, pkix@ietf.org, 'RFC Errata System' , stefan@aaa-sec.com Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (3693) 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, 21 Aug 2013 03:05:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/20/13 8:31 PM, Piyush Jain wrote: > Thanks for providing the references Peter. You're welcome. (BTW, would you be so kind as to please refrain from top-posting? It makes the discussion hard to follow.) > So a quick look at 4513 and 6125 indicates that the issue raised by > this erratum is not addressed anywhere and any application protocol > designed over TLS is vulnerable if client implementations extract > DNS name from certificate CN. As Steve Kent noted, we're actively trying to discourage that behavior. In RFC 6125 we tried hard to lobby for an end to checking the CN, but we weren't able to reach consensus on that within the CA, browser, security, and application communities. I sure hope we can get there in 6125bis. (However, name constraints are explicitly out of scope for RFC 6125.) > I guess the place to have this discussion is TLS WG. I tend to agree. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSFC6DAAoJEOoGpJErxa2pUXIQAKCSpitYtqtFNf78naFRIfrP hUm9ge7pBPnKrP4xuDv37ne+mLELzUZcNhGMeHER7jeCae10Zgbu6eO+cm0GsWou ZTarCveILBgaUkd+u2oSIEKceDTbNbHg5Z5pp26n4a8JRs4tlew0Z5+bJjbqqgVU RC/9QqVmmu6PpcdFHKdJd4OgOT0zi3r7qQEq4IyYNmE7bxoPV+NanO01YFD8Gtba cKz5uRfUA0FYlWewSh8epACkRAJDLlGGJR+cSp5EnKmrKTG9cDOI/vXU1gVMTuq7 4mH/3V83nQfh03dVhUvv4+ihtYaEqZYNAtbeFTBgwmE86zchX/2XmoraD1lzA5G3 yWMYQ07v6VO3UYnInECuD7EpH+yy88zzll8bjsz+tjeZLm6cxcJUHjcfB681l862 cVN3E19QTSf63NisMd3VZQV7fECSjngDmvm+9OgXM5Gg1xwWxXAk0Gbx2x0Ke2QE R90dCPMy4WUggduJHd+K0dnpFXOwfXYyU4eNEg1xRri1XVNJ1cWrh7Q4wNkArjZu LCV+gqeEsnpzWy4fHJ9268g44rpvFPUNa4Z2ztuecl83dr74IBXrRiphIgunCEJk JSsKE47Nb6hPBMiaZgLzAUgrVC09Z3x7yyBKBSvzShJ8+k2KDpdho1yQaUrNwDRM IszPwAEyZvSfI0D6G36Q =gBJm -----END PGP SIGNATURE-----