From nobody Mon Apr 3 13:50:35 2017 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 555C51294C9 for ; Mon, 3 Apr 2017 13:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V49vExiM5SNW for ; Mon, 3 Apr 2017 13:50:24 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEB541293E0 for ; Mon, 3 Apr 2017 13:50:24 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2A72BB801B0; Mon, 3 Apr 2017 13:50:09 -0700 (PDT) To: philliph@comodo.com, rob.stradling@comodo.com, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, kent@bbn.com, stefan@aaa-sec.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: phill@hallambaker.com, pkix@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170403205009.2A72BB801B0@rfc-editor.org> Date: Mon, 3 Apr 2017 13:50:09 -0700 (PDT) Archived-At: Subject: [pkix] [Technical Errata Reported] RFC6844 (4988) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 20:50:29 -0000 The following errata report has been submitted for RFC6844, "DNS Certification Authority Authorization (CAA) Resource Record". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6844&eid=4988 -------------------------------------- Type: Technical Reported by: Phillip Hallam-Baker Section: 4 Original Text ------------- Let CAA(X) be the record set returned in response to performing a CAA record query on the label X, P(X) be the DNS label immediately above X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME alias record specified at the label X. o If CAA(X) is not empty, R(X) = CAA (X), otherwise o If A(X) is not null, and R(A(X)) is not empty, then R(X) = R(A(X)), otherwise o If X is not a top-level domain, then R(X) = R(P(X)), otherwise o R(X) is empty. Corrected Text -------------- Let CAA(X) be the record set returned in response to performing a CAA record query on the label X, P(X) be the DNS label immediately above X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME alias record chain specified at the label X. o If CAA(X) is not empty, R(X) = CAA (X), otherwise o If A(X) is not null, and CAA(A(X)), then R(X) = CAA(X), otherwise o If X is not a top-level domain, then R(X) = R(P(X)), otherwise o R(X) is empty. Thus, when a search at node X returns a CNAME record, the CA will follow the CNAME record to its target. If the target label contains a CAA record, it is returned. otherwise, the CA continues the search at the parent of node X. Note that the search does not include the parent of a target of a CNAME record (except when the CNAME points back to its own path). If the target of a CNAME record is itself a CNAME record, the CA MAY follow it or MAY ignore it. In either case, the search continues at the parent of the label containing the initial CNAME. Processing for DNAME is exactly the same as for CNAME. Note that since DNAME records are implemented by creating the corresponding CNAME records on the fly, it is only necessary for DNAME records to appear on the wire for purposes of DNSSEC. Notes ----- This is a fuller response to the issue raised in 4515. Note that the algorithm stated in RFC6844 was the algorithm intended at the time it was written. Subsequent implementation has shown that the approach described here is preferable. This is a breaking change and thus the intended disposition is Hold for Document Update. The principle purpose of this errata is to provide a stable reference for the benefit of CABForum which publishes certificate validation guidelines that mandate CAA. This in turn will avoid the need for work being proposed to provide a full solution to the problem to have to address backwards compatibility with an approach now seen as undesirable. The issue arises because CNAME records are commonly used for the purpose of host delegation and name delegation and no distinction is made between the two. Nor does the use of DNAME records allow such distinction be made in practice. Further, the limitation that CNAME be the only record in a zone is a liability. The original algorithm was designed to provide an administrative convenience for the name delegation case. Subsequent discussion with CDNs has shown that the host delegation use is sufficiently widespread for this approach to be unsatisfactory. After discussion in the LAMPS working group, a new approach is being considered which allows both sets of requirements to be met using an extended search algorithm. Until this is done, it is best that implementations do not perform the recursive portion. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6844 (draft-ietf-pkix-caa-15) -------------------------------------- Title : DNS Certification Authority Authorization (CAA) Resource Record Publication Date : January 2013 Author(s) : P. Hallam-Baker, R. Stradling Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From nobody Mon Apr 3 15:04:03 2017 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 7B2591293FF for ; Mon, 3 Apr 2017 15:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mJVG8js8XOQ for ; Mon, 3 Apr 2017 15:03:56 -0700 (PDT) Received: from rmdccgokm1.reyn.mcr.dc.comodo.net (sgomail.comodogroup.com [IPv6:2a02:1788:402:430::9708:41f4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD651243F6 for ; Mon, 3 Apr 2017 15:03:55 -0700 (PDT) Received: (korumail 7512 invoked from network); 3 Apr 2017 22:03:54 -0000 Received: from unknown (HELO clofcgmail2.cl.office.comodo.net) () by 0 with SMTP; 3 Apr 2017 22:03:53 -0000 Received: (qmail 9791 invoked by uid 1012); 3 Apr 2017 22:03:53 -0000 Received: from pool-100-0-244-109.bstnma.fios.verizon.net (HELO VooDoo) (100.0.244.109) (smtp-auth username philliph, mechanism login) by clofcgmail2.cl.office.comodo.net (qpsmtpd/0.84/v0.84-169-ga857589) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA; Mon, 03 Apr 2017 18:03:53 -0400 From: Phillip Hallam-Baker To: 'RFC Errata System' , rob.stradling@comodo.com, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, kent@bbn.com, stefan@aaa-sec.com Cc: phill@hallambaker.com, pkix@ietf.org References: <20170403205009.2A72BB801B0@rfc-editor.org> In-Reply-To: <20170403205009.2A72BB801B0@rfc-editor.org> Date: Mon, 3 Apr 2017 18:03:51 -0400 Message-ID: <004501d2acc6$2e9e8b10$8bdba130$@comodo.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJBjNZhvWZBAzWalcLPpt1G9biGp6DWckrg X-SMTP-Filter: Korumail SMTP Filter Engine Korumail 6.6 X-KORUMAIL-Result: Clean (Content eval: 0.000000 points) X-KORUMAIL-Reason: X-KORUMAIL-QueueId: 7490-1491257033-757485 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-us Archived-At: Subject: Re: [pkix] [Technical Errata Reported] RFC6844 (4988) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 22:04:01 -0000 Damn! And as Rob pointed out, a typo o If A(X) is not null, and CAA(A(X)), then R(X) =3D CAA(A(X)), otherwise So do I submit a second errata? -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20 Sent: Monday, April 3, 2017 4:50 PM To: philliph@comodo.com; rob.stradling@comodo.com; = Kathleen.Moriarty.ietf@gmail.com; ekr@rtfm.com; kent@bbn.com; = stefan@aaa-sec.com Cc: phill@hallambaker.com; pkix@ietf.org; rfc-editor@rfc-editor.org Subject: [Technical Errata Reported] RFC6844 (4988) The following errata report has been submitted for RFC6844, "DNS = Certification Authority Authorization (CAA) Resource Record". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D6844&eid=3D4988 -------------------------------------- Type: Technical Reported by: Phillip Hallam-Baker Section: 4 Original Text ------------- Let CAA(X) be the record set returned in response to performing a CAA record query on the label X, P(X) be the DNS label immediately above X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME alias record specified at the label X. o If CAA(X) is not empty, R(X) =3D CAA (X), otherwise o If A(X) is not null, and R(A(X)) is not empty, then R(X) =3D R(A(X)), otherwise o If X is not a top-level domain, then R(X) =3D R(P(X)), otherwise o R(X) is empty. Corrected Text -------------- Let CAA(X) be the record set returned in response to performing a CAA record query on the label X, P(X) be the DNS label immediately above X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME=20 alias record chain specified at the label X. o If CAA(X) is not empty, R(X) =3D CAA (X), otherwise o If A(X) is not null, and CAA(A(X)), then R(X) =3D CAA(X), otherwise o If X is not a top-level domain, then R(X) =3D R(P(X)), otherwise o R(X) is empty. Thus, when a search at node X returns a CNAME record, the CA will follow the CNAME record to its target. If the target label contains a CAA record, it is returned. otherwise, the CA continues the search at the parent of node X.=20 Note that the search does not include the parent of a target of a CNAME record (except when the CNAME points back to its own path). If the target of a CNAME record is itself a CNAME record, the CA MAY follow it or MAY ignore it. In either case, the search continues at the parent of the label containing the initial CNAME. Processing for DNAME is exactly the same as for CNAME. Note that since DNAME records are implemented by creating the corresponding CNAME records on the fly, it is only necessary for DNAME records to appear on the wire for purposes of DNSSEC. =20 Notes ----- This is a fuller response to the issue raised in 4515. Note that the = algorithm stated in RFC6844 was the algorithm intended at the time it = was written. Subsequent implementation has shown that the approach = described here is preferable. This is a breaking change and thus the intended disposition is Hold for = Document Update. The principle purpose of this errata is to provide a = stable reference for the benefit of CABForum which publishes certificate = validation guidelines that mandate CAA. This in turn will avoid the need = for work being proposed to provide a full solution to the problem to = have to address backwards compatibility with an approach now seen as = undesirable. The issue arises because CNAME records are commonly used for the purpose = of host delegation and name delegation and no distinction is made = between the two. Nor does the use of DNAME records allow such = distinction be made in practice. Further, the limitation that CNAME be = the only record in a zone is a liability. The original algorithm was = designed to provide an administrative convenience for the name = delegation case. Subsequent discussion with CDNs has shown that the host = delegation use is sufficiently widespread for this approach to be = unsatisfactory. After discussion in the LAMPS working group, a new approach is being = considered which allows both sets of requirements to be met using an = extended search algorithm. Until this is done, it is best that = implementations do not perform the recursive portion. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use = "Reply All" to discuss whether it should be verified or rejected. When a = decision is reached, the verifying party can log in to change the status = and edit the report, if necessary.=20 -------------------------------------- RFC6844 (draft-ietf-pkix-caa-15) -------------------------------------- Title : DNS Certification Authority Authorization (CAA) = Resource Record Publication Date : January 2013 Author(s) : P. Hallam-Baker, R. Stradling Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From nobody Thu Apr 6 09:24:24 2017 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 86DEF1270B4 for ; Thu, 6 Apr 2017 09:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogLIuHRorubA for ; Thu, 6 Apr 2017 09:24:15 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25FC71293E1 for ; Thu, 6 Apr 2017 09:24:14 -0700 (PDT) Received: from email.digicert.com (ex1-sgu [10.12.1.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPS id 7F9598FA0EB for ; Thu, 6 Apr 2017 16:24:13 +0000 (GMT) From: Ben Wilson To: "pkix@ietf.org" Thread-Topic: Amendment to CABF Baseline Requirements Thread-Index: AdKu7+4NHc0VCiezSMq6lazH8C48qg== Date: Thu, 6 Apr 2017 16:24:11 +0000 Message-ID: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.137.52.8] Content-Type: multipart/alternative; boundary="_000_906f1c1dde4f44789646197d887da312EX2corpdigicertcom_" MIME-Version: 1.0 Archived-At: Subject: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:24:17 -0000 --_000_906f1c1dde4f44789646197d887da312EX2corpdigicertcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does anyone want to comment on my draft amendment to the CA/Browser Forum's= Baseline Requirements for SSL/TLS Certificates which would remove the 64-c= haracter limit on the commonName and organizationName, as an exception to = RFC 5280? The text of the relevant Baseline Requirement provision is found= below with the proposed additional language in ALL CAPS. The reason for t= he first change (commonName) is there are FQDNs (in Subject Alternative Nam= es) that are longer than 64 characters. The reason for the second change (= organizationName) is that there are organizations with names longer than 64= characters. 7.1.4.2.2. Subject Distinguished Name Fields a. Certificate Field: subject:commonName (OID 2.5.4.3) Required/Optional: Deprecated (Discouraged, but not prohibited) Contents: If present, this field MUST contain a single IP address or Fully-= Qualified Domain Name that is one of the values contained in the Certificat= e's subjectAltName extension (see Section 7.1.4.2.1). MAXIMUM LENGTH: NO STIPULATION. (THIS IS AN EXCEPTION TO RFC 5280 WHICH S= PECIFIES AN UPPER BOUND OF 64 CHARACTERS.) b. Certificate Field: subject:organizationName (OID 2.5.4.10) Optional. Contents: If present, the subject:organizationName field MUST contain eithe= r the Subject's name or DBA as verified under Section 3.2.2.2. The CA may i= nclude information in this field that differs slightly from the verified na= me, such as common variations or abbreviations, provided that the CA docume= nts the difference and any abbreviations used are locally accepted abbrevia= tions; e.g., if the official record shows "Company Name Incorporated", the = CA MAY use "Company Name Inc." or "Company Name". Because Subject name att= ributes for individuals (e.g. givenName (2.5.4.42) and surname (2.5.4.4)) a= re not broadly supported by application software, the CA MAY use the subjec= t:organizationName field to convey a natural person Subject's name or DBA. MAXIMUM LENGTH: 256 CHARACTERS (THIS IS AN EXCEPTION TO RFC 5280 WHICH SPE= CIFIES AN UPPER BOUND OF 64 CHARACTERS.) Thanks, Ben Wilson --_000_906f1c1dde4f44789646197d887da312EX2corpdigicertcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Doe= s anyone want to comment on my draft amendment to the CA/Browser Forum̵= 7;s Baseline Requirements for SSL/TLS Certificates which would remove the 6= 4-character limit on the commonName and organizationName,  as an exception to RFC 5280?  The text of the relevant Baseline Requi= rement provision is found below with the proposed additional language in AL= L CAPS.  The reason for the first change (commonName) is there are FQD= Ns (in Subject Alternative Names) that are longer than 64 characters.  The reason for the second change (organiz= ationName) is that there are organizations with names longer than 64 charac= ters.

 

7.1.4.2.2.           = ;  Subject Distinguished Name Fields

a.            Certif= icate Field: subject:commonName (OID 2.5.4.3) 

Required/Optional: Deprecated (Discouraged, but not prohibited)<= /p>

Con= tents: If present, this field MUST contain a single IP address or Fully-Qua= lified Domain Name that is one of the values contained in the Certificate&#= 8217;s subjectAltName extension (see Section 7.1.4.2.1).

MAX= IMUM LENGTH:  NO STIPULATION.  (THIS IS AN EXCEPTION TO RFC 5280 = WHICH SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.)

b.            Certif= icate Field: subject:organizationName (OID 2.5.4.10)

Optional. 

Con= tents: If present, the subject:organizationName field MUST contain either t= he Subject’s name or DBA as verified under Section 3.2.2.2. The CA ma= y include information in this field that differs slightly from the verified name, such as common variations or abbreviation= s, provided that the CA documents the difference and any abbreviations used= are locally accepted abbreviations; e.g., if the official record shows = 220;Company Name Incorporated”, the CA MAY use “Company Name Inc.” or “Company Name”.&nbs= p; Because Subject name attributes for individuals (e.g. givenName (2.5.4.4= 2) and surname (2.5.4.4)) are not broadly supported by application software= , the CA MAY use the subject:organizationName field to convey a natural person Subject’s name or DBA.

MAX= IMUM LENGTH:  256 CHARACTERS (THIS IS AN EXCEPTION TO RFC 5280 WHICH S= PECIFIES AN UPPER BOUND OF 64 CHARACTERS.)

 

Thanks,

Ben Wilson

--_000_906f1c1dde4f44789646197d887da312EX2corpdigicertcom_-- From nobody Thu Apr 6 09:28:57 2017 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 2B04112954A for ; Thu, 6 Apr 2017 09:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4F5zaEINfgbD for ; Thu, 6 Apr 2017 09:28:48 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38AA912955D for ; Thu, 6 Apr 2017 09:28:26 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id i34so40700347qtc.0 for ; Thu, 06 Apr 2017 09:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version; bh=pVD3AqhborvDVZYOTQBiAaOwVPvI/hee19oHmVeyij8=; b=HdzvKWzqQjOzlfId2QKXMFp6zI8frChh/kUyuhOpO7gT76NHv89uwp4OLo1Fbba2DW X605mlqLv+Q6gSbiyCjCsjewqsj4Wlmggje1c16ggUq8ABYSCD4NivP7UuqqsQOMgaTY a8ai/BFIAQF3sRdCRO2C4JGXzcnU/OSAY1SNw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version; bh=pVD3AqhborvDVZYOTQBiAaOwVPvI/hee19oHmVeyij8=; b=MC8PpgRVptu4hkt45tjn6Kpd+A8+jgKCT7BYWH0vgzR3TTz+CzWdUSeRhDG1ZLLyGG iaLj64IZEqd9ZF113bp0Bqlm+O1Lrh1FozObhVOIZBDen+Q2UYarKafvdKq+KL+mxIDM SQlvqJCAhl3Q/VZ8Rtsba+lZ+zRO3TSG2y9phpNPSGrhk9RFLuYqn5fKedMZCNf/QOR2 jmFjNpn9jaPgGM4RCWmXIcFp9Y8knXS6kw97NrDMX0hW7yJJ5oPtY5Jsf/xm74AlxHoq SIGdaZ6KzG0TYpX14nmVhQLP6KLp74trSZLa3alD7BE/O6EIlk6TXUgFV1jmHGrTZD1M LfFg== X-Gm-Message-State: AFeK/H2lRtPRCRhC2pwlz2BhFUwYV9/fBMXYPyD8tQuhZw7Bc1bzPcDVzjuzBHXHwvaK0w== X-Received: by 10.237.59.8 with SMTP id p8mr35789863qte.270.1491496105106; Thu, 06 Apr 2017 09:28:25 -0700 (PDT) Received: from [192.168.2.27] (pool-173-73-188-160.washdc.fios.verizon.net. [173.73.188.160]) by smtp.googlemail.com with ESMTPSA id m12sm1259755qtf.25.2017.04.06.09.28.22 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 06 Apr 2017 09:28:24 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.7.1.161129 Date: Thu, 06 Apr 2017 12:28:20 -0400 From: Carl Wallace To: Ben Wilson , "pkix@ietf.org" Message-ID: Thread-Topic: [pkix] Amendment to CABF Baseline Requirements Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3574326504_1504937" Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:28:51 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3574326504_1504937 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Given these ASN.1 upper bounds are automatically enforced by ASN.1 compiler generated code, how do we hand wave this away? These changes are a recipe for interoperability pain. From: pkix on behalf of Ben Wilson Date: Thursday, April 6, 2017 at 12:24 PM To: "pkix@ietf.org" Subject: [pkix] Amendment to CABF Baseline Requirements > Does anyone want to comment on my draft amendment to the CA/Browser Forum= =E2=80=99s > Baseline Requirements for SSL/TLS Certificates which would remove the > 64-character limit on the commonName and organizationName, as an excepti= on to > RFC 5280? The text of the relevant Baseline Requirement provision is fou= nd > below with the proposed additional language in ALL CAPS. The reason for = the > first change (commonName) is there are FQDNs (in Subject Alternative Name= s) > that are longer than 64 characters. The reason for the second change > (organizationName) is that there are organizations with names longer than= 64 > characters. > =20 > 7.1.4.2.2. Subject Distinguished Name Fields > a. Certificate Field: subject:commonName (OID 2.5.4.3) > Required/Optional: Deprecated (Discouraged, but not prohibited) > Contents: If present, this field MUST contain a single IP address or > Fully-Qualified Domain Name that is one of the values contained in the > Certificate=E2=80=99s subjectAltName extension (see Section 7.1.4.2.1). > MAXIMUM LENGTH: NO STIPULATION. (THIS IS AN EXCEPTION TO RFC 5280 WHICH > SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) > b. Certificate Field: subject:organizationName (OID 2.5.4.10) > Optional. =20 > Contents: If present, the subject:organizationName field MUST contain eit= her > the Subject=E2=80=99s name or DBA as verified under Section 3.2.2.2. The CA may > include information in this field that differs slightly from the verified > name, such as common variations or abbreviations, provided that the CA > documents the difference and any abbreviations used are locally accepted > abbreviations; e.g., if the official record shows =E2=80=9CCompany Name Incorpo= rated=E2=80=9D, > the CA MAY use =E2=80=9CCompany Name Inc.=E2=80=9D or =E2=80=9CCompany Name=E2=80=9D. Because Su= bject name > attributes for individuals (e.g. givenName (2.5.4.42) and surname (2.5.4.= 4)) > are not broadly supported by application software, the CA MAY use the > subject:organizationName field to convey a natural person Subject=E2=80=99s nam= e or > DBA. > MAXIMUM LENGTH: 256 CHARACTERS (THIS IS AN EXCEPTION TO RFC 5280 WHICH > SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) > =20 > Thanks, > Ben Wilson > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3574326504_1504937 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Given these ASN.1 upper bound= s are automatically enforced by ASN.1 compiler generated code, how do we han= d wave this away? These changes are a recipe for interoperability pain. = ;

From: pkix <pkix-bounces@ietf.org> on behalf = of Ben Wilson <ben.wilson@digice= rt.com>
Date: Thursday, Apr= il 6, 2017 at 12:24 PM
To: "pkix@ietf.org" <pkix@ietf.org>
Subject: = [pkix] Amendment to CABF Baseline Requirements

Does anyone want to comment on my draft amendment = to the CA/Browser Forum’s Baseline Requirements for SSL/TLS Certificat= es which would remove the 64-character limit on the commonName and organizat= ionName,  as an exception to RFC 5280?  The text of the relevant Baseline Requi= rement provision is found below with the proposed additional language in ALL= CAPS.  The reason for the first change (commonName) is there are FQDNs= (in Subject Alternative Names) that are longer than 64 characters.  The reason for the second change (organiz= ationName) is that there are organizations with names longer than 64 charact= ers.

 

7.1.4.2.2.           = ;  Subject Distinguished Name Fields

a.            Certif= icate Field: subject:commonName (OID 2.5.4.3) 

Required/Optional: Deprecated (Discouraged, but not prohibited)<= /p>

Conte= nts: If present, this field MUST contain a single IP address or Fully-Qualif= ied Domain Name that is one of the values contained in the Certificate’= ;s subjectAltName extension (see Section 7.1.4.2.1).

MAXIMUM LENGTH:  NO STIPULATION.  (THIS IS AN = EXCEPTION TO RFC 5280 WHICH SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.)=

b.            Certif= icate Field: subject:organizationName (OID 2.5.4.10)

Optional. 

Contents: If present, the subject:organizationName f= ield MUST contain either the Subject’s name or DBA as verified under S= ection 3.2.2.2. The CA may include information in this field that differs slightly from the verified name, such as common variations or abbreviation= s, provided that the CA documents the difference and any abbreviations used = are locally accepted abbreviations; e.g., if the official record shows ̶= 0;Company Name Incorporated”, the CA MAY use “Company Name Inc.” or “Company Name”.&nbs= p; Because Subject name attributes for individuals (e.g. givenName (2.5.4.42= ) and surname (2.5.4.4)) are not broadly supported by application software, = the CA MAY use the subject:organizationName field to convey a natural person Subject’s name or DBA.

MAXIMUM LENGTH:  = 256 CHARACTERS (THIS IS AN EXCEPTION TO RFC 5280 WHICH SPECIFIES AN UPPER BO= UND OF 64 CHARACTERS.)

 <= /p>

Thanks,

Ben Wilso= n

_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix --B_3574326504_1504937-- From nobody Thu Apr 6 09:40:10 2017 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 C6857129542 for ; Thu, 6 Apr 2017 09:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1plOOwCWV82B for ; Thu, 6 Apr 2017 09:40:06 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF08129541 for ; Thu, 6 Apr 2017 09:40:04 -0700 (PDT) Received: from email.digicert.com (ex1-sgu [10.12.1.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPS id A1E4E8FA71E; Thu, 6 Apr 2017 16:40:04 +0000 (GMT) From: Jeremy Rowley To: Carl Wallace , Ben Wilson , "pkix@ietf.org" Thread-Topic: [pkix] Amendment to CABF Baseline Requirements Thread-Index: AQHSrvLwlOcKuMKIFkKDVdh9teKwhKG4itDA Date: Thu, 6 Apr 2017 16:40:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.137.52.7] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0137_01D2AEC2.25900690" MIME-Version: 1.0 Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:40:09 -0000 ------=_NextPart_000_0137_01D2AEC2.25900690 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0138_01D2AEC2.25900690" ------=_NextPart_001_0138_01D2AEC2.25900690 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Can you point to any browser software that cares about these limits? I = can=E2=80=99t find any. =20 From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Carl Wallace Sent: Thursday, April 6, 2017 10:28 AM To: Ben Wilson ; pkix@ietf.org Subject: Re: [pkix] Amendment to CABF Baseline Requirements =20 Given these ASN.1 upper bounds are automatically enforced by ASN.1 = compiler generated code, how do we hand wave this away? These changes = are a recipe for interoperability pain.=20 =20 From: pkix > on = behalf of Ben Wilson > Date: Thursday, April 6, 2017 at 12:24 PM To: "pkix@ietf.org " > Subject: [pkix] Amendment to CABF Baseline Requirements =20 Does anyone want to comment on my draft amendment to the CA/Browser = Forum=E2=80=99s Baseline Requirements for SSL/TLS Certificates which = would remove the 64-character limit on the commonName and = organizationName, as an exception to RFC 5280? The text of the = relevant Baseline Requirement provision is found below with the proposed = additional language in ALL CAPS. The reason for the first change = (commonName) is there are FQDNs (in Subject Alternative Names) that are = longer than 64 characters. The reason for the second change = (organizationName) is that there are organizations with names longer = than 64 characters. =20 7.1.4.2.2. Subject Distinguished Name Fields a. Certificate Field: subject:commonName (OID 2.5.4.3) =20 Required/Optional: Deprecated (Discouraged, but not prohibited) Contents: If present, this field MUST contain a single IP address or = Fully-Qualified Domain Name that is one of the values contained in the = Certificate=E2=80=99s subjectAltName extension (see Section 7.1.4.2.1). MAXIMUM LENGTH: NO STIPULATION. (THIS IS AN EXCEPTION TO RFC 5280 = WHICH SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) b. Certificate Field: subject:organizationName (OID 2.5.4.10) Optional. =20 Contents: If present, the subject:organizationName field MUST contain = either the Subject=E2=80=99s name or DBA as verified under Section = 3.2.2.2. The CA may include information in this field that differs = slightly from the verified name, such as common variations or = abbreviations, provided that the CA documents the difference and any = abbreviations used are locally accepted abbreviations; e.g., if the = official record shows =E2=80=9CCompany Name Incorporated=E2=80=9D, the = CA MAY use =E2=80=9CCompany Name Inc.=E2=80=9D or =E2=80=9CCompany = Name=E2=80=9D. Because Subject name attributes for individuals (e.g. = givenName (2.5.4.42) and surname (2.5.4.4)) are not broadly supported by = application software, the CA MAY use the subject:organizationName field = to convey a natural person Subject=E2=80=99s name or DBA. MAXIMUM LENGTH: 256 CHARACTERS (THIS IS AN EXCEPTION TO RFC 5280 WHICH = SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) =20 Thanks, Ben Wilson _______________________________________________ pkix mailing list = pkix@ietf.org = https://www.ietf.org/mailman/listinfo/pkix=20 ------=_NextPart_001_0138_01D2AEC2.25900690 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Can you point to any browser software that cares about = these limits?=C2=A0 I can=E2=80=99t find any.

 

F= rom: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Carl = Wallace
Sent: Thursday, April 6, 2017 10:28 AM
To: = Ben Wilson <ben.wilson@digicert.com>; = pkix@ietf.org
Subject: Re: [pkix] Amendment to CABF Baseline = Requirements

 

Given these = ASN.1 upper bounds are automatically enforced by ASN.1 compiler = generated code, how do we hand wave this away? These changes are a = recipe for interoperability = pain. 

 =

From: pkix = <pkix-bounces@ietf.org> on = behalf of Ben Wilson <ben.wilson@digicert.com>Date: Thursday, April 6, 2017 at 12:24 PM
To: = "pkix@ietf.org" = <pkix@ietf.org>
Subject: = [pkix] Amendment to CABF Baseline = Requirements

 =

Does anyone want to comment on my draft amendment = to the CA/Browser Forum=E2=80=99s Baseline Requirements for SSL/TLS = Certificates which would remove the 64-character limit on the commonName = and organizationName,  as an exception to RFC 5280?  The text = of the relevant Baseline Requirement provision is found below with the = proposed additional language in ALL CAPS.  The reason for the first = change (commonName) is there are FQDNs (in Subject Alternative Names) = that are longer than 64 characters.  The reason for the second = change (organizationName) is that there are organizations with names = longer than 64 characters.

 

7.1.4.2.2.       = ;      Subject Distinguished Name = Fields

a.        &= nbsp;   Certificate Field: subject:commonName (OID = 2.5.4.3) 

Required/Optional: Deprecated (Discouraged, but = not prohibited)

Contents: If present, this field MUST contain a = single IP address or Fully-Qualified Domain Name that is one of the = values contained in the Certificate=E2=80=99s subjectAltName extension = (see Section 7.1.4.2.1).

MAXIMUM LENGTH:  NO STIPULATION.  (THIS = IS AN EXCEPTION TO RFC 5280 WHICH SPECIFIES AN UPPER BOUND OF 64 = CHARACTERS.)

b.        &= nbsp;   Certificate Field: subject:organizationName (OID = 2.5.4.10)

Optional. 

Contents: If present, the subject:organizationName = field MUST contain either the Subject=E2=80=99s name or DBA as verified = under Section 3.2.2.2. The CA may include information in this field that = differs slightly from the verified name, such as common variations or = abbreviations, provided that the CA documents the difference and any = abbreviations used are locally accepted abbreviations; e.g., if the = official record shows =E2=80=9CCompany Name Incorporated=E2=80=9D, the = CA MAY use =E2=80=9CCompany Name Inc.=E2=80=9D or =E2=80=9CCompany = Name=E2=80=9D.  Because Subject name attributes for individuals = (e.g. givenName (2.5.4.42) and surname (2.5.4.4)) are not broadly = supported by application software, the CA MAY use the = subject:organizationName field to convey a natural person = Subject=E2=80=99s name or DBA.

MAXIMUM LENGTH:  256 CHARACTERS (THIS IS AN = EXCEPTION TO RFC 5280 WHICH SPECIFIES AN UPPER BOUND OF 64 = CHARACTERS.)

 

Thanks,

Ben = Wilson

__________________________________= _____________ pkix mailing list pkix@ietf.org https://www.ietf.org/= mailman/listinfo/pkix =

------=_NextPart_001_0138_01D2AEC2.25900690-- ------=_NextPart_000_0137_01D2AEC2.25900690 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8 inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf /K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF 5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093 pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1 vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDA2MTY0MDAyWjAj BgkqhkiG9w0BCQQxFgQUDaxDf/PgEnRmbhfFTlZ50DIJM+cwgYgGCSsGAQQBgjcQBDF7MHkwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK 2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAGBWoqAfZHUgOehnmr8j8TwBlnpoO8XLKUG8vEHf V+0Hncg90hV4lpZP6nhEK8fpzPG4tn8FiVQPxb67vp/Gac6OEOuvTqcjYJwdYWK03U1UyCm4DOd5 psXmtS5Gky74AHaEXr5vCGxOrg68wxVeAwgUeVrUtr+BzYLYJfZ+EzeObqA7IUJXRYjRyFLX0bP0 Zm3g9uhHqoTELHzXUjwvvb3TCck1cNgmS0lAbZzToUna4Z9EB8Gjp+xGaXiAdWqV4vAR7niQPp5s VpSfTAKFlqeED7IgfQZMzcWaev1vMU5it9yMG5PcqzGqMkVSUAzF3I2VV/hUmBd87fNK1S4NIIwA AAAAAAA= ------=_NextPart_000_0137_01D2AEC2.25900690-- From nobody Thu Apr 6 09:54:48 2017 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 DBED5128854 for ; Thu, 6 Apr 2017 09:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KImuQaPkTfaQ for ; Thu, 6 Apr 2017 09:54:43 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4539F12420B for ; Thu, 6 Apr 2017 09:54:43 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id n21so41266217qta.1 for ; Thu, 06 Apr 2017 09:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=MkxNdC237Br/IaHHdLzKgLQiu8iWXxXI/UgfliqU614=; b=DJibl3IrKU3sMpEXEJh+0cXBfu5RutVT5P0GBYaiX6xMuyf9xvF+BL2QNxKooZsKYW 2wCmjdiiYjpldRnaaEuy9EsSbiYwNIqR6BzZIMl8m6qHlQj3XtdPlLHwNgvl0aGPSL2X 1k2uwjWWxT9rZ+pi2UNKvMQ3SUrg/6IK3fZkPgPkIGbfgy1cKtyIegSmJtGcctwCVjoA Jppn22VSg9mQCnUfW/MNjxVRdME1i7Wmpdfe2vMNiTCNJOepx3D7vSdFB/1jfcPjvwtW QjWSTA+faokO1lnXJuf7D2CNtWAhxGoq8j8NC5EFdS1L4OF02YuSkzau5wCv58WR0XK4 pI3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=MkxNdC237Br/IaHHdLzKgLQiu8iWXxXI/UgfliqU614=; b=AmFkOB3nJp8za9YkKWjcZz8DnN5EtgRXhyBxNKn8kT9GpFy2CPremFmDPie2tSjQkY zs/IEkhSPPrEBT4oFdKl3zS+85cASL3Db3awNmjMi/uTIlETm3j8EqJ39ln3VXhdLcz8 Fc5Ed2ecArY6scCF/fj8FqX43NCE8CCciUqafvKvSXJYYvLFPFcLDEuREDkBCZR8o129 eqHclMZO63+VA7Hm86MWHkzYGAk/MgwuobxsCgokulpvGlG6zgJSKYgHFcYxfATUsLX7 jiJO2FyygLjSQpRnfIpnyhTz+QJsqa5tzPcIt6XpUntHHhdxLu/Cb/k+AWcw7Ym7GNVY EQYQ== X-Gm-Message-State: AFeK/H3gzBMh/wYTeG5uVpL8hhGyW6QQoVMQUbCweQsKDDf9f0JibkQEvlIHZi2j6Hc61g== X-Received: by 10.200.53.150 with SMTP id k22mr34088410qtb.154.1491497681845; Thu, 06 Apr 2017 09:54:41 -0700 (PDT) Received: from ?IPv6:2601:152:4400:a2e0::159b? ([2601:152:4400:a2e0::159b]) by smtp.gmail.com with ESMTPSA id q66sm1284206qkd.69.2017.04.06.09.54.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 09:54:41 -0700 (PDT) To: pkix@ietf.org References: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> From: Michael StJohns Message-ID: Date: Thu, 6 Apr 2017 12:54:59 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> Content-Type: multipart/alternative; boundary="------------8271104F42630979D3E9198E" Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:54:46 -0000 This is a multi-part message in MIME format. --------------8271104F42630979D3E9198E Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Ben - IETF 5280 et al are profiles of the X.509 documents. The upper length bounds for orgnaizationName and commonName fields in 5280 is no different than the upper bounds specified in X.509 (at least as of the 2014 document). I would suggest that you will pretty much break any and all implementations of X.509 clients that rely or enforce this limit as well as any code that generates certificate requests. I will note that overloading text fields with structured data is generally not a good idea - as you've found. Mike On 4/6/2017 12:24 PM, Ben Wilson wrote: > > Does anyone want to comment on my draft amendment to the CA/Browser > Forum’s Baseline Requirements for SSL/TLS Certificates which would > remove the 64-character limit on the commonName and organizationName, > as an exception to RFC 5280? The text of the relevant Baseline > Requirement provision is found below with the proposed additional > language in ALL CAPS. The reason for the first change (commonName) is > there are FQDNs (in Subject Alternative Names) that are longer than 64 > characters. The reason for the second change (organizationName) is > that there are organizations with names longer than 64 characters. > > 7.1.4.2.2. Subject Distinguished Name Fields > > a. Certificate Field: subject:commonName (OID 2.5.4.3) > > Required/Optional: Deprecated (Discouraged, but not prohibited) > > Contents: If present, this field MUST contain a single IP address or > Fully-Qualified Domain Name that is one of the values contained in the > Certificate’s subjectAltName extension (see Section 7.1.4.2.1). > > MAXIMUM LENGTH: NO STIPULATION. (THIS IS AN EXCEPTION TO RFC 5280 > WHICH SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) > > b. Certificate Field: subject:organizationName (OID 2.5.4.10) > > Optional. > > Contents: If present, the subject:organizationName field MUST contain > either the Subject’s name or DBA as verified under Section 3.2.2.2. > The CA may include information in this field that differs slightly > from the verified name, such as common variations or abbreviations, > provided that the CA documents the difference and any abbreviations > used are locally accepted abbreviations; e.g., if the official record > shows “Company Name Incorporated”, the CA MAY use “Company Name Inc.” > or “Company Name”. Because Subject name attributes for individuals > (e.g. givenName (2.5.4.42) and surname (2.5.4.4)) are not broadly > supported by application software, the CA MAY use the > subject:organizationName field to convey a natural person Subject’s > name or DBA. > > MAXIMUM LENGTH: 256 CHARACTERS (THIS IS AN EXCEPTION TO RFC 5280 > WHICH SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) > > Thanks, > > Ben Wilson > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------8271104F42630979D3E9198E Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Ben -

IETF 5280 et al are profiles of the X.509 documents.  The upper length bounds for orgnaizationName and commonName fields in 5280 is no different than the upper bounds specified in X.509 (at least as of the 2014 document).  I would suggest that you will pretty much break any and all implementations of X.509 clients that rely or enforce this limit as well as any code that generates certificate requests.

I will note that overloading text fields with structured data is generally not a good idea - as you've found. 

Mike



On 4/6/2017 12:24 PM, Ben Wilson wrote:

Does anyone want to comment on my draft amendment to the CA/Browser Forum’s Baseline Requirements for SSL/TLS Certificates which would remove the 64-character limit on the commonName and organizationName,  as an exception to RFC 5280?  The text of the relevant Baseline Requirement provision is found below with the proposed additional language in ALL CAPS.  The reason for the first change (commonName) is there are FQDNs (in Subject Alternative Names) that are longer than 64 characters.  The reason for the second change (organizationName) is that there are organizations with names longer than 64 characters.

 

7.1.4.2.2.             Subject Distinguished Name Fields

a.            Certificate Field: subject:commonName (OID 2.5.4.3) 

Required/Optional: Deprecated (Discouraged, but not prohibited)

Contents: If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension (see Section 7.1.4.2.1).

MAXIMUM LENGTH:  NO STIPULATION.  (THIS IS AN EXCEPTION TO RFC 5280 WHICH SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.)

b.            Certificate Field: subject:organizationName (OID 2.5.4.10)

Optional. 

Contents: If present, the subject:organizationName field MUST contain either the Subject’s name or DBA as verified under Section 3.2.2.2. The CA may include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g., if the official record shows “Company Name Incorporated”, the CA MAY use “Company Name Inc.” or “Company Name”.  Because Subject name attributes for individuals (e.g. givenName (2.5.4.42) and surname (2.5.4.4)) are not broadly supported by application software, the CA MAY use the subject:organizationName field to convey a natural person Subject’s name or DBA.

MAXIMUM LENGTH:  256 CHARACTERS (THIS IS AN EXCEPTION TO RFC 5280 WHICH SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.)

 

Thanks,

Ben Wilson



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


--------------8271104F42630979D3E9198E-- From nobody Thu Apr 6 10:08:05 2017 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 D1BD012954C for ; Thu, 6 Apr 2017 10:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqEVFA_yeFQ8 for ; Thu, 6 Apr 2017 10:08:01 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5589124234 for ; Thu, 6 Apr 2017 10:08:00 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id r45so41565196qte.3 for ; Thu, 06 Apr 2017 10:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=ddZbqR9xK/76fAbuiTMayXJM5GcKuFKiSQNdD8dHiCI=; b=zj86oVcTs0qhlx06lX73LZlFL2OKW7v2L1Y04NmZx6c6r+YorQnLCfZ3Tq2XdtQtek PY9oKmAxUuZxF5d+jSP/eb+WdcMpL+Ij1f7RxHTRkKvJ/XQRTnfDOoYX7/gZzcekA1zs va80ofxl/Lz7I3Ru376rSwSLX/DZjTtJcb5ss= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=ddZbqR9xK/76fAbuiTMayXJM5GcKuFKiSQNdD8dHiCI=; b=KQ4xKBNHlr+ytxdQnu/NMKMAhoAyF2URdARNwnHIDis6DrbksNqhbtLglsdefB580y pGpP1yRk77fsn/Dxa0YzkSfM4WlheREETABJHN7GbQM2xd21deAMqgFKSR8+lZ7kmpsg 0j+JAAXOpdtTv9OC/5JpYkvznADLkXf5OTbMsi2OEBUqFVRCSd1M3sn8jLPREfbdwwPv K4SZnNc6E4ZExpSQTe7oKtSvPpXuOIsPYgrzrHDVRlf0hGwelf0u6cKbxZoTiVSlVoPm jTzuxwmppQ7u00bPyrovkITvJlLM1QIvUSAG5Sp91kJWlvaTo6B+5h/RvKkRyqi+wfzz sDWQ== X-Gm-Message-State: AFeK/H35IY0ozDx8Xyqd2vVCKlA83l/PubfjNL5QjMgziJ6ZwBt15RxkFEzuvUuviaLOkQ== X-Received: by 10.200.45.137 with SMTP id p9mr36077958qta.201.1491498479768; Thu, 06 Apr 2017 10:07:59 -0700 (PDT) Received: from [192.168.2.27] (pool-173-73-188-160.washdc.fios.verizon.net. [173.73.188.160]) by smtp.googlemail.com with ESMTPSA id k4sm1336991qta.5.2017.04.06.10.07.56 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 06 Apr 2017 10:07:59 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.7.1.161129 Date: Thu, 06 Apr 2017 13:07:51 -0400 From: Carl Wallace To: Jeremy Rowley , Ben Wilson , "pkix@ietf.org" Message-ID: Thread-Topic: [pkix] Amendment to CABF Baseline Requirements References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3574328871_1635205" Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 17:08:04 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3574328871_1635205 Content-type: multipart/alternative; boundary="B_3574328871_1660522" --B_3574328871_1660522 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Ah, I assumed you had all the browser folks covered and sought broader comments (hence posting here). If breaking non-browser instances is of no concern, feel free to ignore my comment. From: Jeremy Rowley Date: Thursday, April 6, 2017 at 12:40 PM To: Carl Wallace , Ben Wilson , "pkix@ietf.org" Subject: RE: [pkix] Amendment to CABF Baseline Requirements > Can you point to any browser software that cares about these limits? I c= an=E2=80=99t > find any. > =20 >=20 > From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Carl Wallace > Sent: Thursday, April 6, 2017 10:28 AM > To: Ben Wilson ; pkix@ietf.org > Subject: Re: [pkix] Amendment to CABF Baseline Requirements > =20 >=20 > Given these ASN.1 upper bounds are automatically enforced by ASN.1 compil= er > generated code, how do we hand wave this away? These changes are a recipe= for > interoperability pain. >=20 > =20 >=20 > From: pkix on behalf of Ben Wilson > > Date: Thursday, April 6, 2017 at 12:24 PM > To: "pkix@ietf.org" > Subject: [pkix] Amendment to CABF Baseline Requirements >=20 > =20 >>=20 >> Does anyone want to comment on my draft amendment to the CA/Browser Foru= m=E2=80=99s >> Baseline Requirements for SSL/TLS Certificates which would remove the >> 64-character limit on the commonName and organizationName, as an except= ion >> to RFC 5280? The text of the relevant Baseline Requirement provision is >> found below with the proposed additional language in ALL CAPS. The reas= on >> for the first change (commonName) is there are FQDNs (in Subject Alterna= tive >> Names) that are longer than 64 characters. The reason for the second ch= ange >> (organizationName) is that there are organizations with names longer tha= n 64 >> characters. >> =20 >> 7.1.4.2.2. Subject Distinguished Name Fields >> a. Certificate Field: subject:commonName (OID 2.5.4.3) >> Required/Optional: Deprecated (Discouraged, but not prohibited) >> Contents: If present, this field MUST contain a single IP address or >> Fully-Qualified Domain Name that is one of the values contained in the >> Certificate=E2=80=99s subjectAltName extension (see Section 7.1.4.2.1). >> MAXIMUM LENGTH: NO STIPULATION. (THIS IS AN EXCEPTION TO RFC 5280 WHIC= H >> SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) >> b. Certificate Field: subject:organizationName (OID 2.5.4.10) >> Optional. =20 >> Contents: If present, the subject:organizationName field MUST contain ei= ther >> the Subject=E2=80=99s name or DBA as verified under Section 3.2.2.2. The CA ma= y >> include information in this field that differs slightly from the verifie= d >> name, such as common variations or abbreviations, provided that the CA >> documents the difference and any abbreviations used are locally accepted >> abbreviations; e.g., if the official record shows =E2=80=9CCompany Name >> Incorporated=E2=80=9D, the CA MAY use =E2=80=9CCompany Name Inc.=E2=80=9D or =E2=80=9CCompany Na= me=E2=80=9D. Because >> Subject name attributes for individuals (e.g. givenName (2.5.4.42) and >> surname (2.5.4.4)) are not broadly supported by application software, th= e CA >> MAY use the subject:organizationName field to convey a natural person >> Subject=E2=80=99s name or DBA. >> MAXIMUM LENGTH: 256 CHARACTERS (THIS IS AN EXCEPTION TO RFC 5280 WHICH >> SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) >> =20 >> Thanks, >> Ben Wilson >> _______________________________________________ pkix mailing list >> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3574328871_1660522 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Ah, I assumed you had all the= browser folks covered and sought broader comments (hence posting here). If = breaking non-browser instances is of no concern, feel free to ignore my comm= ent.

From: Jeremy Ro= wley <jeremy.rowley@digicert.= com>
Date: Thursday, April = 6, 2017 at 12:40 PM
To: Carl Walla= ce <carl@redhoundsoftware.com<= /a>>, Ben Wilson <ben.wilson@= digicert.com>, "pkix@ietf.org" <= ;pkix@ietf.org>
Subject: RE: [pkix] Amendment to CABF Baseline Requireme= nts

<= div xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-microsoft-c= om:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" xmlns:m=3D"h= ttp://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http://www.w3.org/TR= /REC-html40">

Can you point to any = browser software that cares about these limits?  I can’t find any= .

 

From: pkix [mailto:pk= ix-bounces@ietf.org] On Behalf Of Carl Wallace
Sent: Th= ursday, April 6, 2017 10:28 AM
To: Ben Wilson <ben.wilson@digicert.com>; pkix@ietf.org
Subject: Re: [pkix] Amendment to CA= BF Baseline Requirements

 

Given these ASN.1 upper bounds are automatically = enforced by ASN.1 compiler generated code, how do we hand wave this away? Th= ese changes are a recipe for interoperability pain. <= /p>

 

From: = pkix <pkix-bounces@ietf.org>= ; on behalf of Ben Wilson <ben.w= ilson@digicert.com>
Date: Thursday, April 6, 2017 at 12:24 = PM
To: "pkix@ietf.org" <pkix@ietf.org>
Subject: [pkix] A= mendment to CABF Baseline Requirements

=  

= Does anyone want to comment on my draft amendment to the CA/Browser Forum= 217;s Baseline Requirements for SSL/TLS Certificates which would remove the = 64-character limit on the commonName and organizationName,  as an excep= tion to RFC 5280?  The text of the relevant Baseline Requirement provis= ion is found below with the proposed additional language in ALL CAPS.  = The reason for the first change (commonName) is there are FQDNs (in Subject = Alternative Names) that are longer than 64 characters.  The reason for = the second change (organizationName) is that there are organizations with na= mes longer than 64 characters.

 =

7.1.4.2.2.    &n= bsp;        Subject Distinguished Name Fi= elds

a.     =        Certificate Field: subject:commonName (= OID 2.5.4.3) 

Required/Optional= : Deprecated (Discouraged, but not prohibited)

Contents: If present, this field MUST contain a single IP address = or Fully-Qualified Domain Name that is one of the values contained in the Ce= rtificate’s subjectAltName extension (see Section 7.1.4.2.1).

MAXIMUM LENGTH:  NO STIPULATION.  (= THIS IS AN EXCEPTION TO RFC 5280 WHICH SPECIFIES AN UPPER BOUND OF 64 CHARAC= TERS.)

b.    &nbs= p;       Certificate Field: subject:organizati= onName (OID 2.5.4.10)

Optional. =

Contents: If present, the subject:o= rganizationName field MUST contain either the Subject’s name or DBA as= verified under Section 3.2.2.2. The CA may include information in this fiel= d that differs slightly from the verified name, such as common variations or= abbreviations, provided that the CA documents the difference and any abbrev= iations used are locally accepted abbreviations; e.g., if the official recor= d shows “Company Name Incorporated”, the CA MAY use “Compa= ny Name Inc.” or “Company Name”.  Because Subject nam= e attributes for individuals (e.g. givenName (2.5.4.42) and surname (2.5.4.4= )) are not broadly supported by application software, the CA MAY use the sub= ject:organizationName field to convey a natural person Subject’s name = or DBA.

MAXIMUM LENGTH:  256 CHA= RACTERS (THIS IS AN EXCEPTION TO RFC 5280 WHICH SPECIFIES AN UPPER BOUND OF = 64 CHARACTERS.)

 

Thanks,

Ben Wilson

______________________________________________= _ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/l= istinfo/pkix

--B_3574328871_1660522-- --B_3574328871_1635205 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIQvQYJKoZIhvcNAQcCoIIQrjCCEKoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg46MIIFSTCCBDGgAwIBAgIQE+rZ43XmnLGBoakCp6SJhzANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMH U2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBT SEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3 MDEwMjAwMDAwMFoXDTE4MDEwMjIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZY2FybEByZWRo b3VuZHNvZnR3YXJlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOca1OAR OvlN1ZZ/S38O3HNQhCnEfjRCn45ByxjxUEBbdejXij5YPR3myo7ZfvwLnaXeEE44FXkovwRK KGMDCcMl1B3ADERolvICcJDjBboHeFCOSoBEyNm4Zd3c3Q6NWWcHJ2dmMWm43g/omiHgovER WR+vAN/XfeHBVlwSPsH/VLHhztF+y0sTWKpPuRsIbQSE5iN0GWHcFE+5JbIzcYOzJ9mLB3kD PfXiF2B1lxtggsE2JnfhJnKi85nnt2QOz3/krTbu5BAQEfC80V9jWKDPM42mgHvmWNeuyUQu sPkANSWvX49+KeVP8vr8abdi6eR05VHrcwRhg5aYaH1ixt8CAwEAAaOCAfcwggHzMB8GA1Ud IwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBRzxy9a50r4LtXhlDot2RaP xXASHzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcD BAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGy MQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0G A1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGD MIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZD bGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJAYDVR0RBB0wG4EZY2FybEByZWRob3VuZHNvZnR3 YXJlLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAE1fc62aQQP4uc/f3SijuW8mBJj95vhapATvC hyIxEnrMZwdNY0O6SXjndCJyyoAZclZCqebopLR9RXhz8EepxhzVfzaupK3HCG6R/FDY5JZ5 BXDrJ6zsht5C4dx243v7h5mDIp7XwDhCyFySTAXHufY35ZMCWgAX2PJ+ZWMLRJ1swGhVB1Xy Q7rjHhnlmfJP0ZsRLXqGMqoXOtvdZiipv7zJtHRMFksfpkS8/kuhtYzFNwfFpfOLdEVhQCy5 t8t522hxSvZv667vhD67Mrdw5xxOeT6qVnIGMeSJTqHmHErTox2QmzS7B2q4t1/bCxfdYHAg GgcXD0+THFVlPCgSlzCCBK8wggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3 DQEBCwUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMd QWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVy bmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW51Gr8fBaE0kVo7SMG2C8 elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JDFnyvMlDIpk9a6QjY z5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUIkzqcKlOjENs9 IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7AzaS1D6/rW pfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZAP8vk 4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYG BFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0 cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjt zVXzqmthK8AJECOZD8Vmam+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC 6tVNhPv+gpjPWBvjImOcUvi7BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOy qC3U2LtCS5BphRDbpjc06HvgARClnMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER 0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurR OgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7mzCCBDYwggMeoAMCAQICAQEwDQYJKoZIhvcN AQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1B ZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJu YWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYT AlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwg VFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7emxEz l6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkm GJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4 ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8V srh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1Qa MAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3 +sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIx JjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRU cnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IP lgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa 4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY 0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1Aq2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBD PJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiDyx8x8URMxgRzSXZgD8f4vReAay7p zEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMYICRzCCAkMCAQEwgbAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQE+rZ43XmnLGBoakC p6SJhzANBglghkgBZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCAGMnTj4UDtERFFrb7jGl25 Rwj8cb18v1XwawE23CA3XTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xNzA0MDYxNzA3NTFaMA0GCSqGSIb3DQEBAQUABIIBALZ+rLvwx1JJWLPNft2etL5k Btqg5apzq8CogP+4zHdisI+8oXh0uJnb5UBsbeMsg7NpLd9wBZ5lTg1KV+scAsddzDtemubC c0XrHzV9C6a8z2FCXr5cbdYUsHv0U3dp7g8d2MmRtwKCg2QOSbw02c2IbmtYDkSv7g1DR7Q9 M2V/IxG/Hiv93vwkht3UpKvFnT8UND4Pe6VUx8tA4YsNgrLMob93bZ1jGGi7C4kjzEILOLxo 6Jp61vREX1VlrjNhuaXs338QNk3MHWnN9rdgHlhu7tiL6IVqUwKRIZw8S9qI3S9XW2XhGEbE wZBamL73TGMRN3D78Wd33YDTW+JptiI= --B_3574328871_1635205-- From nobody Thu Apr 6 11:55:40 2017 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 2F89C128DF6 for ; Thu, 6 Apr 2017 11:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxYTZP4abrXt for ; Thu, 6 Apr 2017 11:55:35 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E1A129469 for ; Thu, 6 Apr 2017 11:55:34 -0700 (PDT) From: Ben Wilson DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1491504934; bh=oisDzNJKaz+Nn61cpdX4tn7zjNuTOw4U1L5fIfPaPhU=; h=From:To:Subject:Date:References:In-Reply-To; b=yQ3eBOhKd79VvTNRhmiimK+0tD58iT7wxiyAQ4ATj7fYoEsxwHE+W7sjtfRxgTJ3o Q8iIz83a9SUJNk0QfOgXzSvWcCWIYF4K9u20PQxwqKTmweW7oDz09ifp/X6+8FBfIc fBBgb5LITigrf6Ym+2Xtd65NGp4KZYtSThcMFIuE= To: Michael StJohns , "pkix@ietf.org" Thread-Topic: [pkix] Amendment to CABF Baseline Requirements Thread-Index: AdKu7+4NHc0VCiezSMq6lazH8C48qgAOOMeAAAjFYFA= Date: Thu, 6 Apr 2017 18:55:32 +0000 Message-ID: <27e9bc684735472bbd6d7f82b5e2823b@EX2.corp.digicert.com> References: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.137.52.8] Content-Type: multipart/signed; boundary="----=_NextPart_000_0019_01D2AED5.131A6650"; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1 MIME-Version: 1.0 Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 18:55:39 -0000 ------=_NextPart_000_0019_01D2AED5.131A6650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks, Michael. Is it relevant that Annex C to X.520 (2012) states, "(This annex does not form an integral part of this Recommendation | International Standard.)" whereas before (1988) it stated, "This Annex = is part of the Recommendation."? From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Michael StJohns Sent: Thursday, April 6, 2017 10:55 AM To: pkix@ietf.org Subject: Re: [pkix] Amendment to CABF Baseline Requirements Hi Ben -=20 IETF 5280 et al are profiles of the X.509 documents.=A0 The upper length bounds for orgnaizationName and commonName fields in 5280 is no = different than the upper bounds specified in X.509 (at least as of the 2014 document).=A0 I would suggest that you will pretty much break any and = all implementations of X.509 clients that rely or enforce this limit as well = as any code that generates certificate requests. I will note that overloading text fields with structured data is = generally not a good idea - as you've found.=A0=20 Mike On 4/6/2017 12:24 PM, Ben Wilson wrote: Does anyone want to comment on my draft amendment to the CA/Browser = Forum=92s Baseline Requirements for SSL/TLS Certificates which would remove the 64-character limit on the commonName and organizationName,=A0 as an = exception to RFC 5280?=A0 The text of the relevant Baseline Requirement provision = is found below with the proposed additional language in ALL CAPS.=A0 The = reason for the first change (commonName) is there are FQDNs (in Subject = Alternative Names) that are longer than 64 characters.=A0 The reason for the second = change (organizationName) is that there are organizations with names longer = than 64 characters. =A0 7.1.4.2.2.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Subject Distinguished = Name Fields a.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Certificate Field: = subject:commonName (OID 2.5.4.3)=A0=20 Required/Optional: Deprecated (Discouraged, but not prohibited) Contents: If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate=92s subjectAltName extension (see Section 7.1.4.2.1). MAXIMUM LENGTH:=A0 NO STIPULATION.=A0 (THIS IS AN EXCEPTION TO RFC 5280 = WHICH SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) b.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Certificate Field: = subject:organizationName (OID 2.5.4.10) Optional.=A0=20 Contents: If present, the subject:organizationName field MUST contain = either the Subject=92s name or DBA as verified under Section 3.2.2.2. The CA = may include information in this field that differs slightly from the = verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g., if the official record shows =93Company Name Incorporated=94, the CA MAY use =93Company Name Inc.=94 or =93Company = Name=94.=A0 Because Subject name attributes for individuals (e.g. givenName = (2.5.4.42) and surname (2.5.4.4)) are not broadly supported by application = software, the CA MAY use the subject:organizationName field to convey a natural = person Subject=92s name or DBA. MAXIMUM LENGTH:=A0 256 CHARACTERS (THIS IS AN EXCEPTION TO RFC 5280 = WHICH SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) =A0 Thanks, Ben Wilson _______________________________________________ pkix mailing list mailto:pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_000_0019_01D2AED5.131A6650 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD20w ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFXDCCBESgAwIBAgIQ DBtqhdfCp4/itnID2GXpozANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTQwODE4MDAwMDAwWhcNMTcxMTE1MTIwMDAwWjB7MQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxEzARBgNVBAMTCkJlbiBXaWxzb24xJjAkBgkqhkiG9w0BCQEWF2Jlbi53aWxzb25AZGlnaWNl cnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArwRfbeSkglaSOZjpLHbeC10l ZRntHvHOK0Y2q42FFCx9V4q+3T+m9F1z5NIq2PnyRDS1DUEhJS46OvlsHhN4gKihQyvJHND3xCVr tKQrBERfpi3JKpmX6+Nz4m5bRf3kDHRoeNh7XekP7MseZsZO6bA1/Fs2Lb+PUR47+0haaXWxoP+c wui9Za4KE93TDgLLgTG/djoGyXQ4Qh6FtMDDUxvaQECKg//px3vQNWAGqsvPwL6RZoh8umhtPAPz /DCsazQA200XHcPHPzGx8xEeQTXjQWSaF/yiA7Uz+Gd7Y7NAlRUBEthrXnIgOWnmtxEMgVF+NNFc NoRNSrd08d4ClwIDAQABo4IB8DCCAewwHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkw HQYDVR0OBBYEFJQrTCsMjaRP5JSSbO9e0xo0G1QjMCIGA1UdEQQbMBmBF2Jlbi53aWxzb25AZGln aWNlcnQuY29tMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQw gYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEy QXNzdXJlZElEQ0EtZzEuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EtZzEuY3JsMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsG AQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMHkGCCsGAQUFBwEBBG0wazAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2Fj ZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EuY3J0MAwGA1UdEwEB/wQC MAAwDQYJKoZIhvcNAQELBQADggEBAImgBd3IuYGL4jD2KZ9IMpsnvgU/aED75k4Sibdh4MJfzUy8 FJAYqU6vvWUxa6Ihd/e/2VjKOWmXIqrMBbkVVlvS/uUQgSg2dL3FLx7vkwgLRzC81wvFG13RncOx xMkM7SAG9T7oiPzsPTF+rqr7Xg+kXN79uThElibNcww9ehgMV2KChZnR0qGf9zXCTqocuXLSX6MO XTRpBZP46xWAgxthXmElm8LXhGix7qOIVwDGH4z+uU9SVyjTlb93cfU/Xg99nT7ups9G6IH54j9N O0Zfp8UtOXFnC9WMLhJR1YZ9uypVKlweXRkZgF45I5Et7mlZitXF4onN4Uqn6HO/+OgwggZOMIIF NqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUw EwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMT G0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODExMDUxMjAw MDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5k aWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093pCLOPoxw 8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjXPUT5IHxg rhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1vWK52PuO RQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9Sp307JMO0 wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzCn3MCAwEA AaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsGAQUFBwEB BCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3Js MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGmMIIBogYK YIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMw ggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBl AHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQA YQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABh AG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUA bgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAg AGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8GA1UdIwQY MBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0dh3d+DygF kPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpEV8Q0j21z HzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtdGwSBnqci 4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgoGVMRRLxH ICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBXBMBgojXV JJ5mNwlJz9X4ZbPg4m7CMYIDvzCCA7sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBT SEEyIEFzc3VyZWQgSUQgQ0ECEAwbaoXXwqeP4rZyA9hl6aMwDQYJYIZIAWUDBAIBBQCgggIXMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDQwNjE4NTUzMVowLwYJ KoZIhvcNAQkEMSIEIDQgGQL1roKgpuGb0P09tVvhtOevZt6hhVvt7gQZ0UsHMIGIBgkrBgEEAYI3 EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3 dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDBtq hdfCp4/itnID2GXpozCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQK EwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lD ZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDBtqhdfCp4/itnID2GXpozCBkwYJKoZIhvcNAQkPMYGF MIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJYIZIAWUDBAIDMAsG CWCGSAFlAwQCAjAHBgUrDgMCGjANBgkqhkiG9w0BAQEFAASCAQArXF4K8L09OscuRCqIwoKuSYcP 1SkXURA5dBpx/6Ht0oy3UDMLWal/AQc89i6Yf5ROVxZZVxWspRJB6sxfFQ8QeZgU9GCHRB4AoPau 9VVOb7UESy/mi1HG3WMcyHUJJo6bbLeg7zM+g37zU5iFLbQcS2xOGZp6sFgmH/1WUqYHpW4MCIFx Lr64d32aj6Y1i5noE9jyRmgamYWsKAAoM7JpCFSCaZV5ykt1/t6X7GVDn97YOGleLmOKvTPaTkmI FfVrZ6UmPQQDtm5W896MQUA3hfK65eg72BBH2sH5VUzAsLr9nfQ18vlx4j4mbUO2MG0TgQYuGdDm evbkRBsAwuPBAAAAAAAA ------=_NextPart_000_0019_01D2AED5.131A6650-- From nobody Thu Apr 6 12:24:42 2017 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 0E70D127871 for ; Thu, 6 Apr 2017 12:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UN2VOJfoT3Ca for ; Thu, 6 Apr 2017 12:24:37 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5780B129479 for ; Thu, 6 Apr 2017 12:24:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B8231300445 for ; Thu, 6 Apr 2017 15:24:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bTW5lg8CIX8t for ; Thu, 6 Apr 2017 15:24:34 -0400 (EDT) Received: from new-host-4.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id C373F300229; Thu, 6 Apr 2017 15:24:34 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <27e9bc684735472bbd6d7f82b5e2823b@EX2.corp.digicert.com> Date: Thu, 6 Apr 2017 15:24:34 -0400 Cc: IETF PKIX Content-Transfer-Encoding: quoted-printable Message-Id: <662C0D5C-EF34-4BD1-B3BC-B7B9A84B4990@vigilsec.com> References: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> <27e9bc684735472bbd6d7f82b5e2823b@EX2.corp.digicert.com> To: Ben Wilson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 19:24:40 -0000 The comment in the UpperBounds ASN.1 module (the 8th edition) says: -- EXPORTS All=20 -- The types and values defined in this module are exported for use in = the other ASN.1 -- modules contained within these Directory Specifications, and for the = use of other -- applications which will use them to access Directory services. Other = applications -- may use them for their own purposes, but this will not constrain = extensions and -- modifications needed to maintain or improve the Directory service. X.509 is part of the Directory Specifications, so they are not advisory. It looks like ITU-T increased the length of the organizational unit name = in the most recent edition. RFC 5280 says: ub-organization-name-length INTEGER ::=3D 64 ub-organizational-unit-name-length INTEGER ::=3D 32 The UpperBounds ASN.1 module (the 8th edition) says: ub-organization-name INTEGER ::=3D 64 ub-organizational-unit-name INTEGER ::=3D 64 So, we may already be in a place where implementations conforming to = X.509 will produce a certificate that cannot be decoded by an = implementation that conforms to RFC 5280. I wish we gad gotten a heads-up =E2=80=A6 Russ > On Apr 6, 2017, at 2:55 PM, Ben Wilson = wrote: >=20 > Thanks, Michael. Is it relevant that Annex C to X.520 (2012) = states, > "(This annex does not form an integral part of this Recommendation | > International Standard.)" whereas before (1988) it stated, "This = Annex is > part of the Recommendation."? >=20 > From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Michael StJohns > Sent: Thursday, April 6, 2017 10:55 AM > To: pkix@ietf.org > Subject: Re: [pkix] Amendment to CABF Baseline Requirements >=20 > Hi Ben -=20 >=20 > IETF 5280 et al are profiles of the X.509 documents. The upper length > bounds for orgnaizationName and commonName fields in 5280 is no = different > than the upper bounds specified in X.509 (at least as of the 2014 > document). I would suggest that you will pretty much break any and = all > implementations of X.509 clients that rely or enforce this limit as = well as > any code that generates certificate requests. >=20 > I will note that overloading text fields with structured data is = generally > not a good idea - as you've found. =20 >=20 > Mike >=20 >=20 >=20 > On 4/6/2017 12:24 PM, Ben Wilson wrote: > Does anyone want to comment on my draft amendment to the CA/Browser = Forum=C2=92s > Baseline Requirements for SSL/TLS Certificates which would remove the > 64-character limit on the commonName and organizationName, as an = exception > to RFC 5280? The text of the relevant Baseline Requirement provision = is > found below with the proposed additional language in ALL CAPS. The = reason > for the first change (commonName) is there are FQDNs (in Subject = Alternative > Names) that are longer than 64 characters. The reason for the second = change > (organizationName) is that there are organizations with names longer = than 64 > characters. > =20 > 7.1.4.2.2. Subject Distinguished Name Fields > a. Certificate Field: subject:commonName (OID 2.5.4.3) =20 > Required/Optional: Deprecated (Discouraged, but not prohibited) > Contents: If present, this field MUST contain a single IP address or > Fully-Qualified Domain Name that is one of the values contained in the > Certificate=C2=92s subjectAltName extension (see Section 7.1.4.2.1). > MAXIMUM LENGTH: NO STIPULATION. (THIS IS AN EXCEPTION TO RFC 5280 = WHICH > SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) > b. Certificate Field: subject:organizationName (OID = 2.5.4.10) > Optional. =20 > Contents: If present, the subject:organizationName field MUST contain = either > the Subject=C2=92s name or DBA as verified under Section 3.2.2.2. The = CA may > include information in this field that differs slightly from the = verified > name, such as common variations or abbreviations, provided that the CA > documents the difference and any abbreviations used are locally = accepted > abbreviations; e.g., if the official record shows =C2=93Company Name > Incorporated=C2=94, the CA MAY use =C2=93Company Name Inc.=C2=94 or = =C2=93Company Name=C2=94.=20 > Because Subject name attributes for individuals (e.g. givenName = (2.5.4.42) > and surname (2.5.4.4)) are not broadly supported by application = software, > the CA MAY use the subject:organizationName field to convey a natural = person > Subject=C2=92s name or DBA. > MAXIMUM LENGTH: 256 CHARACTERS (THIS IS AN EXCEPTION TO RFC 5280 = WHICH > SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) > =20 > Thanks, > Ben Wilson >=20 >=20 >=20 > _______________________________________________ > pkix mailing list > mailto:pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From nobody Thu Apr 6 13:39:24 2017 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 24B17128954 for ; Thu, 6 Apr 2017 13:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8CLNBboCE0w for ; Thu, 6 Apr 2017 13:39:20 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4054127097 for ; Thu, 6 Apr 2017 13:39:19 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id f193so65312646oib.2 for ; Thu, 06 Apr 2017 13:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wep4YthLcVBgzbJlDfPIeuYjstLcA8O4OBbXgC3fYjk=; b=rRVrRQNNTSk0pRJSJwej5Ng14hiCWAmnLBS40Tzi5jmQKVy3SV6GghiGixw+CNYiVm QlCwI95ejRKZGOLaodEvVHx1JX8lnf+Ts5Ap5Gr/qsaR4rkqG7J8Fa/fKU0l0TsEKQw2 gv2rsdP9mT2Nw9QV56lWyjoO9Nilnc3w7cpptyOl0yptNd8iWBYzXl3/NPg0eBs7JZUH Dyfx72WmveHeKFAwd0iqZ2pN+D7KJlc9GZ2ucq9j51xAO0CoHqGHYof490+F5QX3HsIO KvKsdKaOZ7kn5USjuiHKWmaz92Qzg8w9OGFpQ+VRKjzc/ZZa+F/sr7+9sGhpZGtCBGiY JrEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Wep4YthLcVBgzbJlDfPIeuYjstLcA8O4OBbXgC3fYjk=; b=oWphOlh9zhXvKbhSm4e2LSwC6RaoEcvlr7fZk5O6pwfaJwMOBKCAcxF1dTQkgSHv7v nMYPwul/2hlbxX59uf0TwK221ttgnusIYNsxM6otwN42ux5OOM0sWuXS9sSDNxkRVdFg 0EPGCU5K6TfII6ydaiw/bOWSa8YMBb1S5orSaRwkBZtPgkeWmew0RM5on4aCnVBy+yyP 9+ICpXGrQUIP6miWPKlfFTkjAm4n6kP+V8LzXDRiTOP+wE7M0DRg1YkalT7Lp2tcAwOs DR+q3S9UuzWDa/EDdlVtBD82y+Kdi1YGtwTT1jHxZDB6TvcWfc9bG5UeUTL52M0MFmae AobQ== X-Gm-Message-State: AFeK/H1Ld4Wzyu95Ima162d7mtiHJoa2rj+SnGCFGERVTuKh6VIUBbSxA14HCdCSOALQAGshtXRiwJ2vNLQjrA== X-Received: by 10.157.52.116 with SMTP id v107mr12400187otb.38.1491511159179; Thu, 06 Apr 2017 13:39:19 -0700 (PDT) MIME-Version: 1.0 References: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> <27e9bc684735472bbd6d7f82b5e2823b@EX2.corp.digicert.com> <662C0D5C-EF34-4BD1-B3BC-B7B9A84B4990@vigilsec.com> In-Reply-To: <662C0D5C-EF34-4BD1-B3BC-B7B9A84B4990@vigilsec.com> From: Peter Bowen Date: Thu, 06 Apr 2017 20:39:08 +0000 Message-ID: To: Ben Wilson , Russ Housley Cc: IETF PKIX Content-Type: multipart/alternative; boundary=001a1141563cd24f9d054c85809e Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 20:39:23 -0000 --001a1141563cd24f9d054c85809e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 6, 2017 at 12:24 PM Russ Housley wrote: > The comment in the UpperBounds ASN.1 module (the 8th edition) says: > > -- EXPORTS All > -- The types and values defined in this module are exported for use in th= e > other ASN.1 > -- modules contained within these Directory Specifications, and for the > use of other > -- applications which will use them to access Directory services. Other > applications > -- may use them for their own purposes, but this will not constrain > extensions and > -- modifications needed to maintain or improve the Directory service. > > X.509 is part of the Directory Specifications, so they are not advisory. > > It looks like ITU-T increased the length of the organizational unit name > in the most recent edition. > > RFC 5280 says: > > ub-organization-name-length INTEGER ::=3D 64 > ub-organizational-unit-name-length INTEGER ::=3D 32 > > The UpperBounds ASN.1 module (the 8th edition) says: > > ub-organization-name INTEGER ::=3D 64 > ub-organizational-unit-name INTEGER ::=3D 64 > > So, we may already be in a place where implementations conforming to X.50= 9 > will produce a certificate that cannot be decoded by an implementation th= at > conforms to RFC 5280. > > I wish we gad gotten a heads-up =E2=80=A6 It is even worse. 7th and 8th (and maybe prior releases) removed the usage of ub- from the schema. The schema itself no longer bounds DirectoryStrings and X.509 explicitly says they are unbounded. > > Russ > > > > > On Apr 6, 2017, at 2:55 PM, Ben Wilson wrote: > > > > Thanks, Michael. Is it relevant that Annex C to X.520 (2012) states, > > "(This annex does not form an integral part of this Recommendation | > > International Standard.)" whereas before (1988) it stated, "This Annex > is > > part of the Recommendation."? > > > > From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Michael StJohns > > Sent: Thursday, April 6, 2017 10:55 AM > > To: pkix@ietf.org > > Subject: Re: [pkix] Amendment to CABF Baseline Requirements > > > > Hi Ben - > > > > IETF 5280 et al are profiles of the X.509 documents. The upper length > > bounds for orgnaizationName and commonName fields in 5280 is no differe= nt > > than the upper bounds specified in X.509 (at least as of the 2014 > > document). I would suggest that you will pretty much break any and all > > implementations of X.509 clients that rely or enforce this limit as wel= l > as > > any code that generates certificate requests. > > > > I will note that overloading text fields with structured data is > generally > > not a good idea - as you've found. > > > > Mike > > > > > > > > On 4/6/2017 12:24 PM, Ben Wilson wrote: > > Does anyone want to comment on my draft amendment to the CA/Browser > Forum=E2=80=99s > > Baseline Requirements for SSL/TLS Certificates which would remove the > > 64-character limit on the commonName and organizationName, as an > exception > > to RFC 5280? The text of the relevant Baseline Requirement provision i= s > > found below with the proposed additional language in ALL CAPS. The > reason > > for the first change (commonName) is there are FQDNs (in Subject > Alternative > > Names) that are longer than 64 characters. The reason for the second > change > > (organizationName) is that there are organizations with names longer > than 64 > > characters. > > > > 7.1.4.2.2. Subject Distinguished Name Fields > > a. Certificate Field: subject:commonName (OID 2.5.4.3) > > Required/Optional: Deprecated (Discouraged, but not prohibited) > > Contents: If present, this field MUST contain a single IP address or > > Fully-Qualified Domain Name that is one of the values contained in the > > Certificate=E2=80=99s subjectAltName extension (see Section 7.1.4.2.1). > > MAXIMUM LENGTH: NO STIPULATION. (THIS IS AN EXCEPTION TO RFC 5280 WHI= CH > > SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) > > b. Certificate Field: subject:organizationName (OID 2.5.4.10= ) > > Optional. > > Contents: If present, the subject:organizationName field MUST contain > either > > the Subject=E2=80=99s name or DBA as verified under Section 3.2.2.2. Th= e CA may > > include information in this field that differs slightly from the verifi= ed > > name, such as common variations or abbreviations, provided that the CA > > documents the difference and any abbreviations used are locally accepte= d > > abbreviations; e.g., if the official record shows =E2=80=9CCompany Name > > Incorporated=E2=80=9D, the CA MAY use =E2=80=9CCompany Name Inc.=E2=80= =9D or =E2=80=9CCompany Name=E2=80=9D. > > Because Subject name attributes for individuals (e.g. givenName > (2.5.4.42) > > and surname (2.5.4.4)) are not broadly supported by application softwar= e, > > the CA MAY use the subject:organizationName field to convey a natural > person > > Subject=E2=80=99s name or DBA. > > MAXIMUM LENGTH: 256 CHARACTERS (THIS IS AN EXCEPTION TO RFC 5280 WHICH > > SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) > > > > Thanks, > > Ben Wilson > > > > > > > > _______________________________________________ > > pkix mailing list > > mailto:pkix@ietf.org > > https://www.ietf.org/mailman/listinfo/pkix > > > > _______________________________________________ > > pkix mailing list > > pkix@ietf.org > > https://www.ietf.org/mailman/listinfo/pkix > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --001a1141563cd24f9d054c85809e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Apr 6, 2017 at 12:24 PM Ru= ss Housley <housley@vigilsec.com= > wrote:
The comment in the = UpperBounds ASN.1 module (the 8th edition) says:

-- EXPORTS All
-- The types and values defined in this module are exported for use in the = other ASN.1
-- modules contained within these Directory Specifications, and for the use= of other
-- applications which will use them to access Directory services. Other app= lications
-- may use them for their own purposes, but this will not constrain extensi= ons and
-- modifications needed to maintain or improve the Directory service.

X.509 is part of the Directory Specifications, so they are not advisory.
It looks like ITU-T increased the length of the organizational unit name in= the most recent edition.

RFC 5280 says:

ub-organization-name-length INTEGER ::=3D 64
ub-organizational-unit-name-length INTEGER ::=3D 32

The UpperBounds ASN.1 module (the 8th edition) says:

ub-organization-name=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0INTEGER ::=3D 64
ub-organizational-unit-name=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 INTEGER ::=3D 64

So, we may already be in a place where implementations conforming to X.509 = will produce a certificate that cannot be decoded by an implementation that= conforms to RFC 5280.

I wish we gad gotten a heads-up =E2=80=A6

I= t is even worse. 7th and 8th (and maybe prior releases) removed the usage o= f ub- from the schema. The schema itself no longer bounds DirectoryStrings = and X.509 explicitly says they are unbounded.=C2=A0




Russ



> On Apr 6, 2017, at 2:55 PM, Ben Wilson <ben.wilson@digicert.c= om> wrote:
>
> Thanks, Michael.=C2=A0 =C2=A0 Is it relevant that Annex C to X.520 (20= 12) states,
> "(This annex does not form an integral part of this Recommendatio= n |
> International Standard.)" whereas before (1988) it stated,=C2=A0 = "This Annex is
> part of the Recommendation."?
>
> From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Michael= StJohns
> Sent: Thursday, April 6, 2017 10:55 AM
> To: pkix@ietf.org
> Subject: Re: [pkix] Amendment to CABF Baseline Requirements
>
> Hi Ben -
>
> IETF 5280 et al are profiles of the X.509 documents.=C2=A0 The upper l= ength
> bounds for orgnaizationName and commonName fields in 5280 is no differ= ent
> than the upper bounds specified in X.509 (at least as of the 2014
> document).=C2=A0 I would suggest that you will pretty much break any a= nd all
> implementations of X.509 clients that rely or enforce this limit as we= ll as
> any code that generates certificate requests.
>
> I will note that overloading text fields with structured data is gener= ally
> not a good idea - as you've found.
>
> Mike
>
>
>
> On 4/6/2017 12:24 PM, Ben Wilson wrote:
> Does anyone want to comment on my draft amendment to the CA/Browser Fo= rum=E2=80=99s
> Baseline Requirements for SSL/TLS Certificates which would remove the<= br class=3D"gmail_msg"> > 64-character limit on the commonName and organizationName,=C2=A0 as an= exception
> to RFC 5280?=C2=A0 The text of the relevant Baseline Requirement provi= sion is
> found below with the proposed additional language in ALL CAPS.=C2=A0 T= he reason
> for the first change (commonName) is there are FQDNs (in Subject Alter= native
> Names) that are longer than 64 characters.=C2=A0 The reason for the se= cond change
> (organizationName) is that there are organizations with names longer t= han 64
> characters.
>
> 7.1.4.2.2.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subject Dist= inguished Name Fields
> a.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Certificate Field: subject= :commonName (OID 2.5.4.3)
> Required/Optional: Deprecated (Discouraged, but not prohibited)
> Contents: If present, this field MUST contain a single IP address or > Fully-Qualified Domain Name that is one of the values contained in the=
> Certificate=E2=80=99s subjectAltName extension (see Section 7.1.4.2.1)= .
> MAXIMUM LENGTH:=C2=A0 NO STIPULATION.=C2=A0 (THIS IS AN EXCEPTION TO R= FC 5280 WHICH
> SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.)
> b.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Certificate Field: subject= :organizationName (OID 2.5.4.10)
> Optional.
> Contents: If present, the subject:organizationName field MUST contain = either
> the Subject=E2=80=99s name or DBA as verified under Section 3.2.2.2. T= he CA may
> include information in this field that differs slightly from the verif= ied
> name, such as common variations or abbreviations, provided that the CA=
> documents the difference and any abbreviations used are locally accept= ed
> abbreviations; e.g., if the official record shows =E2=80=9CCompany Nam= e
> Incorporated=E2=80=9D, the CA MAY use =E2=80=9CCompany Name Inc.=E2=80= =9D or =E2=80=9CCompany Name=E2=80=9D.
> Because Subject name attributes for individuals (e.g. givenName (2.5.4= .42)
> and surname (2.5.4.4)) are not broadly supported by application softwa= re,
> the CA MAY use the subject:organizationName field to convey a natural = person
> Subject=E2=80=99s name or DBA.
> MAXIMUM LENGTH:=C2=A0 256 CHARACTERS (THIS IS AN EXCEPTION TO RFC 5280= WHICH
> SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.)
>
> Thanks,
> Ben Wilson
>
>
>
> _______________________________________________
> pkix mailing list
> mailto:pkix@ietf.org
> https://www.ietf.org/mailman/list= info/pkix
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/list= info/pkix

_______________________________________________
pkix mailing list
pkix= @ietf.org
https://www.ietf.org/mailman/listinfo/= pkix
--001a1141563cd24f9d054c85809e-- From nobody Fri Apr 7 00:15:31 2017 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 50A8E128CFF for ; Fri, 7 Apr 2017 00:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5IXZl3eW7_h for ; Fri, 7 Apr 2017 00:15:27 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 044FB1288B8 for ; Fri, 7 Apr 2017 00:15:27 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id h67so56274740qke.0 for ; Fri, 07 Apr 2017 00:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a8SqjnVWxS2YpPbTZl6pH3VsLJOYBk+cFi9rre2xzHU=; b=XLuD6SKQaCAk/c1Rtb6LWOjsjYR/NJ5sOie5MOgKgLuOHz6m1S7x7+IEgc/DZCxgjv aOMiT1/Vvo9zVkzo9KSh3o9jrfSGOzy+ATZLA90L9Ul642x7gPogoTRiHudws/2XZ8r9 LsO/CVX+svLXomZeh+Kx53VzKwZ4r7fmR2N4RF8jPeNaiP9O0vT5jH95zm3tilnOSjXn KyXu6pryUqO9r27q0MPteuwiYlgy1bpskncDV19FElYrh+ZGH+V07GugrQjdOErQlven oBmW0k6iaR4BoRTCbQ3MKE4SGw8DFKMxy/tBgMvczDgSD4fTHJqfvz7AtdtCyYSebeRr IwcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a8SqjnVWxS2YpPbTZl6pH3VsLJOYBk+cFi9rre2xzHU=; b=gNyf6mlBhl2GuwRVNIDiMaO+rcQwvH3xuYeQE8RTyAKuB9M7ptG7iKHnpuy8GvqQQN K3mNNd6rkrrNXOSsvLp85EcEsIPN7NDjpan4vPY7loqb9MF0nKrD/y9RXdZKjavlg5F4 Yr/sNw8upG8ibKPVO4tSKGCAmm/wwzvsg12eU71lcENaMt7rGX8jkffjgN10zSiOvWfz W3E3FoAzDmv5LzkrXPcU42wchKnra9PttnKoipjv5yx+8r8+drlCjE7ICiPiIuGvjnXM lvl888kbAb4kcDcfnmI2xN8skOqwfzkx6n7V3SkR5A3JlXZR1ZUOfnQyHkP1d73NXKbG 3YCw== X-Gm-Message-State: AFeK/H1EELZQr+3QNfGgIXCpICVnbkmz1LmFhz/fcVQ2fabxX3aJ42VYvbiJVOU3++sPewSFi22q4094rygjLA== X-Received: by 10.55.104.14 with SMTP id d14mr34900536qkc.299.1491549326101; Fri, 07 Apr 2017 00:15:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.32.182 with HTTP; Fri, 7 Apr 2017 00:15:25 -0700 (PDT) In-Reply-To: References: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> <27e9bc684735472bbd6d7f82b5e2823b@EX2.corp.digicert.com> <662C0D5C-EF34-4BD1-B3BC-B7B9A84B4990@vigilsec.com> From: Erwann Abalea Date: Fri, 7 Apr 2017 09:15:25 +0200 Message-ID: To: Peter Bowen Cc: Ben Wilson , Russ Housley , IETF PKIX Content-Type: multipart/alternative; boundary=94eb2c057254bf65aa054c8e630a Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 07:15:29 -0000 --94eb2c057254bf65aa054c8e630a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bonjour, 2017-04-06 22:39 GMT+02:00 Peter Bowen : > > On Thu, Apr 6, 2017 at 12:24 PM Russ Housley wrote= : > >> The comment in the UpperBounds ASN.1 module (the 8th edition) says: >> >> -- EXPORTS All >> -- The types and values defined in this module are exported for use in >> the other ASN.1 >> -- modules contained within these Directory Specifications, and for the >> use of other >> -- applications which will use them to access Directory services. Other >> applications >> -- may use them for their own purposes, but this will not constrain >> extensions and >> -- modifications needed to maintain or improve the Directory service. >> >> X.509 is part of the Directory Specifications, so they are not advisory. >> >> It looks like ITU-T increased the length of the organizational unit name >> in the most recent edition. >> >> RFC 5280 says: >> >> ub-organization-name-length INTEGER ::=3D 64 >> ub-organizational-unit-name-length INTEGER ::=3D 32 >> >> The UpperBounds ASN.1 module (the 8th edition) says: >> >> ub-organization-name INTEGER ::=3D 64 >> ub-organizational-unit-name INTEGER ::=3D 64 >> >> So, we may already be in a place where implementations conforming to >> X.509 will produce a certificate that cannot be decoded by an >> implementation that conforms to RFC 5280. >> >> I wish we gad gotten a heads-up =E2=80=A6 > > > It is even worse. 7th and 8th (and maybe prior releases) removed the usag= e > of ub- from the schema. The schema itself no longer bounds DirectoryStrin= gs > and X.509 explicitly says they are unbounded. > X.520 2005 defines the attributes using the DirectoryString{} parameterized type, while the 2008 edition uses the UnboundedDirectoryString type. RFC5912, which proposes ASN.1 modules for certificates and other related things, still uses the DirectoryString{} variant. --=20 Erwann. --94eb2c057254bf65aa054c8e630a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bonjour,

2017-04-06 22:39 GMT+02:00 Peter Bowen <<= a href=3D"mailto:pzbowen@gmail.com" target=3D"_blank">pzbowen@gmail.com= >:

On Thu, Apr 6, 2017 at 12:24 PM Russ Housley = <housley@vigil= sec.com> wrote:
The comment = in the UpperBounds ASN.1 module (the 8th edition) says:

-- EXPORTS All
-- The types and values defined in this module are exported for use in the = other ASN.1
-- modules contained within these Directory Specifications, and for the use= of other
-- applications which will use them to access Directory services. Other app= lications
-- may use them for their own purposes, but this will not constrain extensi= ons and
-- modifications needed to maintain or improve the Directory service.

X.509 is part of the Directory Specifications, so they are not advisory.
It looks like ITU-T increased the length of the organizational unit name in= the most recent edition.

RFC 5280 says:

ub-organization-name-length INTEGER ::=3D 64
ub-organizational-unit-name-length INTEGER ::=3D 32

The UpperBounds ASN.1 module (the 8th edition) says:

ub-organization-name=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0INTEGER ::=3D 64
ub-organizational-unit-name=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 INTEGER ::=3D 64

So, we may already be in a place where implementations conforming to X.509 = will produce a certificate that cannot be decoded by an implementation that= conforms to RFC 5280.

I wish we gad gotten a heads-up =E2=80=A6

It is even worse. 7th and 8th (and maybe prior releases) removed the = usage of ub- from the schema. The schema itself no longer bounds DirectoryS= trings and X.509 explicitly says they are unbounded.=C2=A0

X.520 2005 defines the attributes using t= he DirectoryString{} parameterized type, while the 2008 edition uses the Un= boundedDirectoryString type.

RFC5912, which propos= es ASN.1 modules for certificates and other related things, still uses the = DirectoryString{} variant.

--
Erwann.
--94eb2c057254bf65aa054c8e630a-- From nobody Fri Apr 7 01:11:19 2017 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 3F13F128CD5 for ; Fri, 7 Apr 2017 01:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKe1f7jZ5V_C for ; Fri, 7 Apr 2017 01:11:14 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 097F9127011 for ; Fri, 7 Apr 2017 01:11:13 -0700 (PDT) Received: from Morten ([62.44.135.123]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id 3201704071011084698; Fri, 07 Apr 2017 10:11:08 +0200 From: "Erik Andersen" To: "'Russ Housley'" , "'Ben Wilson'" Cc: "'IETF PKIX'" References: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> <27e9bc684735472bbd6d7f82b5e2823b@EX2.corp.digicert.com> <662C0D5C-EF34-4BD1-B3BC-B7B9A84B4990@vigilsec.com> In-Reply-To: <662C0D5C-EF34-4BD1-B3BC-B7B9A84B4990@vigilsec.com> Date: Fri, 7 Apr 2017 10:11:06 +0200 Message-ID: <000001d2af76$824be7a0$86e3b6e0$@x500.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLbax/O6ZBps7Ft6UeYTkOEFrZPhAFLVKgvAbGqP3EBulwnnp+CWgZQ Content-Language: en-gb Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 08:11:18 -0000 Hi Russ, We have not changed upper bounds. I just checked the second edition = (1993). It has 64 octets in both cases. RFC 5280 must have made a copy = mistake. We removed upper bounds from the directory specifications to be = compatible with LDAP that does not have upper bounds. Either we are = compatible with LDAP or with RFC 5280, but with both is not possible. Erik -----Oprindelig meddelelse----- Fra: pkix [mailto:pkix-bounces@ietf.org] P=C3=A5 vegne af Russ Housley Sendt: 06 April 2017 21:25 Til: Ben Wilson Cc: IETF PKIX Emne: Re: [pkix] Amendment to CABF Baseline Requirements The comment in the UpperBounds ASN.1 module (the 8th edition) says: -- EXPORTS All -- The types and values defined in this module are exported for use in = the other ASN.1 -- modules contained within these Directory Specifications, and for the = use of other -- applications which will use them to access Directory services. Other = applications -- may use them for their own purposes, but this will not constrain = extensions and -- modifications needed to maintain or improve the Directory service. X.509 is part of the Directory Specifications, so they are not advisory. It looks like ITU-T increased the length of the organizational unit name = in the most recent edition. RFC 5280 says: ub-organization-name-length INTEGER ::=3D 64 = ub-organizational-unit-name-length INTEGER ::=3D 32 The UpperBounds ASN.1 module (the 8th edition) says: ub-organization-name INTEGER ::=3D 64 ub-organizational-unit-name INTEGER ::=3D 64 So, we may already be in a place where implementations conforming to = X.509 will produce a certificate that cannot be decoded by an = implementation that conforms to RFC 5280. I wish we gad gotten a heads-up =E2=80=A6 Russ > On Apr 6, 2017, at 2:55 PM, Ben Wilson = wrote: >=20 > Thanks, Michael. Is it relevant that Annex C to X.520 (2012) = states, > "(This annex does not form an integral part of this Recommendation |=20 > International Standard.)" whereas before (1988) it stated, "This=20 > Annex is part of the Recommendation."? >=20 > From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Michael StJohns > Sent: Thursday, April 6, 2017 10:55 AM > To: pkix@ietf.org > Subject: Re: [pkix] Amendment to CABF Baseline Requirements >=20 > Hi Ben - >=20 > IETF 5280 et al are profiles of the X.509 documents. The upper length = > bounds for orgnaizationName and commonName fields in 5280 is no=20 > different than the upper bounds specified in X.509 (at least as of the = > 2014 document). I would suggest that you will pretty much break any=20 > and all implementations of X.509 clients that rely or enforce this=20 > limit as well as any code that generates certificate requests. >=20 > I will note that overloading text fields with structured data is=20 > generally not a good idea - as you've found. >=20 > Mike >=20 >=20 >=20 > On 4/6/2017 12:24 PM, Ben Wilson wrote: > Does anyone want to comment on my draft amendment to the CA/Browser=20 > Forum=E2=80=99s Baseline Requirements for SSL/TLS Certificates which = would=20 > remove the 64-character limit on the commonName and organizationName, = > as an exception to RFC 5280? The text of the relevant Baseline=20 > Requirement provision is found below with the proposed additional=20 > language in ALL CAPS. The reason for the first change (commonName) is = > there are FQDNs (in Subject Alternative > Names) that are longer than 64 characters. The reason for the second=20 > change > (organizationName) is that there are organizations with names longer=20 > than 64 characters. > =20 > 7.1.4.2.2. Subject Distinguished Name Fields > a. Certificate Field: subject:commonName (OID 2.5.4.3) =20 > Required/Optional: Deprecated (Discouraged, but not prohibited) > Contents: If present, this field MUST contain a single IP address or=20 > Fully-Qualified Domain Name that is one of the values contained in the = > Certificate=E2=80=99s subjectAltName extension (see Section = 7.1.4.2.1). > MAXIMUM LENGTH: NO STIPULATION. (THIS IS AN EXCEPTION TO RFC 5280=20 > WHICH SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) > b. Certificate Field: subject:organizationName (OID = 2.5.4.10) > Optional. =20 > Contents: If present, the subject:organizationName field MUST contain=20 > either the Subject=E2=80=99s name or DBA as verified under Section = 3.2.2.2.=20 > The CA may include information in this field that differs slightly=20 > from the verified name, such as common variations or abbreviations,=20 > provided that the CA documents the difference and any abbreviations=20 > used are locally accepted abbreviations; e.g., if the official record=20 > shows =E2=80=9CCompany Name Incorporated=E2=80=9D, the CA MAY use = =E2=80=9CCompany Name Inc.=E2=80=9D or =E2=80=9CCompany Name=E2=80=9D. > Because Subject name attributes for individuals (e.g. givenName=20 > (2.5.4.42) and surname (2.5.4.4)) are not broadly supported by=20 > application software, the CA MAY use the subject:organizationName=20 > field to convey a natural person Subject=E2=80=99s name or DBA. > MAXIMUM LENGTH: 256 CHARACTERS (THIS IS AN EXCEPTION TO RFC 5280=20 > WHICH SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) > =20 > Thanks, > Ben Wilson >=20 >=20 >=20 > _______________________________________________ > pkix mailing list > mailto:pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From nobody Fri Apr 7 05:54:32 2017 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 E5E77127010 for ; Fri, 7 Apr 2017 05:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdOnJ16EQ27o for ; Fri, 7 Apr 2017 05:54:24 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B5A129478 for ; Fri, 7 Apr 2017 05:54:23 -0700 (PDT) Received: (qmail 1271 invoked by uid 1004); 7 Apr 2017 12:54:20 -0000 Received: from rmdccgwarp1.reyn.mcr.dc.comodo.net (HELO maileu.comodo.net) (10.1.72.82) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 07 Apr 2017 13:54:20 +0100 Received: from [192.168.0.58] ([192.168.0.58]) by maileu.comodo.net (IceWarp 11.4.5.0 DEB8 x64) with ASMTP (SSL) id 201704071354207110; Fri, 07 Apr 2017 13:54:20 +0100 To: Russ Housley , Ben Wilson References: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> <27e9bc684735472bbd6d7f82b5e2823b@EX2.corp.digicert.com> <662C0D5C-EF34-4BD1-B3BC-B7B9A84B4990@vigilsec.com> Cc: IETF PKIX From: Rob Stradling Message-ID: <1c4a4745-1865-a142-fc25-514b37c602d3@comodo.com> Date: Fri, 7 Apr 2017 13:54:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <662C0D5C-EF34-4BD1-B3BC-B7B9A84B4990@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 12:54:31 -0000 Russ, RFC5280 includes all of the following: ub-organization-name INTEGER ::= 64 ub-organizational-unit-name INTEGER ::= 64 ub-organization-name-length INTEGER ::= 64 ub-organizational-unit-name-length INTEGER ::= 32 The *-name upper bounds apply to X.500 DNs, whereas IINM the *-name-length upper bounds apply to the x400Address GeneralName type. On 06/04/17 20:24, Russ Housley wrote: > The comment in the UpperBounds ASN.1 module (the 8th edition) says: > > -- EXPORTS All > -- The types and values defined in this module are exported for use in the other ASN.1 > -- modules contained within these Directory Specifications, and for the use of other > -- applications which will use them to access Directory services. Other applications > -- may use them for their own purposes, but this will not constrain extensions and > -- modifications needed to maintain or improve the Directory service. > > X.509 is part of the Directory Specifications, so they are not advisory. > > It looks like ITU-T increased the length of the organizational unit name in the most recent edition. > > RFC 5280 says: > > ub-organization-name-length INTEGER ::= 64 > ub-organizational-unit-name-length INTEGER ::= 32 > > The UpperBounds ASN.1 module (the 8th edition) says: > > ub-organization-name INTEGER ::= 64 > ub-organizational-unit-name INTEGER ::= 64 > > So, we may already be in a place where implementations conforming to X.509 will produce a certificate that cannot be decoded by an implementation that conforms to RFC 5280. > > I wish we gad gotten a heads-up … > > Russ > > > >> On Apr 6, 2017, at 2:55 PM, Ben Wilson wrote: >> >> Thanks, Michael. Is it relevant that Annex C to X.520 (2012) states, >> "(This annex does not form an integral part of this Recommendation | >> International Standard.)" whereas before (1988) it stated, "This Annex is >> part of the Recommendation."? >> >> From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Michael StJohns >> Sent: Thursday, April 6, 2017 10:55 AM >> To: pkix@ietf.org >> Subject: Re: [pkix] Amendment to CABF Baseline Requirements >> >> Hi Ben - >> >> IETF 5280 et al are profiles of the X.509 documents. The upper length >> bounds for orgnaizationName and commonName fields in 5280 is no different >> than the upper bounds specified in X.509 (at least as of the 2014 >> document). I would suggest that you will pretty much break any and all >> implementations of X.509 clients that rely or enforce this limit as well as >> any code that generates certificate requests. >> >> I will note that overloading text fields with structured data is generally >> not a good idea - as you've found. >> >> Mike >> >> >> >> On 4/6/2017 12:24 PM, Ben Wilson wrote: >> Does anyone want to comment on my draft amendment to the CA/Browser ForumÂ’s >> Baseline Requirements for SSL/TLS Certificates which would remove the >> 64-character limit on the commonName and organizationName, as an exception >> to RFC 5280? The text of the relevant Baseline Requirement provision is >> found below with the proposed additional language in ALL CAPS. The reason >> for the first change (commonName) is there are FQDNs (in Subject Alternative >> Names) that are longer than 64 characters. The reason for the second change >> (organizationName) is that there are organizations with names longer than 64 >> characters. >> >> 7.1.4.2.2. Subject Distinguished Name Fields >> a. Certificate Field: subject:commonName (OID 2.5.4.3) >> Required/Optional: Deprecated (Discouraged, but not prohibited) >> Contents: If present, this field MUST contain a single IP address or >> Fully-Qualified Domain Name that is one of the values contained in the >> CertificateÂ’s subjectAltName extension (see Section 7.1.4.2.1). >> MAXIMUM LENGTH: NO STIPULATION. (THIS IS AN EXCEPTION TO RFC 5280 WHICH >> SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) >> b. Certificate Field: subject:organizationName (OID 2.5.4.10) >> Optional. >> Contents: If present, the subject:organizationName field MUST contain either >> the SubjectÂ’s name or DBA as verified under Section 3.2.2.2. The CA may >> include information in this field that differs slightly from the verified >> name, such as common variations or abbreviations, provided that the CA >> documents the difference and any abbreviations used are locally accepted >> abbreviations; e.g., if the official record shows “Company Name >> Incorporated”, the CA MAY use “Company Name Inc.” or “Company Name”. >> Because Subject name attributes for individuals (e.g. givenName (2.5.4.42) >> and surname (2.5.4.4)) are not broadly supported by application software, >> the CA MAY use the subject:organizationName field to convey a natural person >> SubjectÂ’s name or DBA. >> MAXIMUM LENGTH: 256 CHARACTERS (THIS IS AN EXCEPTION TO RFC 5280 WHICH >> SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) >> >> Thanks, >> Ben Wilson -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Apr 7 06:01:51 2017 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 81676127977 for ; Fri, 7 Apr 2017 06:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_-20eCTP4MO for ; Fri, 7 Apr 2017 06:01:48 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C274B1201F8 for ; Fri, 7 Apr 2017 06:01:32 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3w008C0Y5jz25w7; Fri, 7 Apr 2017 15:01:31 +0200 (CEST) X-purgate-ID: 152705::1491570091-00003836-172B3310/0/0 X-purgate-size: 1689 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3w008B4CkpzGq1S; Fri, 7 Apr 2017 15:01:30 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 87CC81A684; Fri, 7 Apr 2017 15:01:30 +0200 (CEST) In-Reply-To: To: Peter Bowen Date: Fri, 7 Apr 2017 15:01:30 +0200 (CEST) CC: Ben Wilson , Russ Housley , IETF PKIX Reply-To: mrex@sap.com 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: <20170407130130.87CC81A684@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements< X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 13:01:50 -0000 Peter Bowen wrote: > > Russ Housley wrote: >> >> RFC 5280 says: >> >> ub-organization-name-length INTEGER ::= 64 >> ub-organizational-unit-name-length INTEGER ::= 32 >> >> The UpperBounds ASN.1 module (the 8th edition) says: >> >> ub-organization-name INTEGER ::= 64 >> ub-organizational-unit-name INTEGER ::= 64 >> >> So, we may already be in a place where implementations conforming to X.509 >> will produce a certificate that cannot be decoded by an implementation that >> conforms to RFC 5280. >> >> I wish we gad gotten a heads-up ? > > It is even worse. 7th and 8th (and maybe prior releases) removed the usage > of ub- from the schema. The schema itself no longer bounds DirectoryStrings > and X.509 explicitly says they are unbounded. It's actually worse than that. What newer revisions of X.509 and X.520 say is explicitly irrelevant for rfc5280. rfc5280 is firmly bolted onto the limits of the 08/2005 edition of X.509 ! A while ago I wanted rfc5280-update to adopt the X.509 11/2008 fix for the CRL processing semantics of what is a formally provable specification defect in X.509 08/2005 and rfc5280 -- and I was faced with violent oppostion in PKIX WG (potentially by implementors of the broken semantics), which insisted on the broken semantics to remain wedlocked to the defect in X.509 08/2005. With respect to the suggested change of lifting the limitations: I'm violently opposed to removing these limits, because subject DNames exceeding these limits are likely going to face interop problems with the installed base of our (non-browser) software. -Martin From nobody Fri Apr 7 06:23:18 2017 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 746A6129487 for ; Fri, 7 Apr 2017 06:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9B05Ti9OcqR for ; Fri, 7 Apr 2017 06:23:13 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EE82127010 for ; Fri, 7 Apr 2017 06:23:12 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id v3so10700247qtd.3 for ; Fri, 07 Apr 2017 06:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=RTaUSovGmLuR+knQJUc7QFy/T7Jzr9vyIN05GM3YkOM=; b=oB9/V3VWl72fnQlpGvjdvumPSebab+12juYVqqu+BI+teDmf8ypDG/DigAAKyQLeT6 PRtch3RvPH/0y2zVnrlqYjdZDQNooCbXAgpGaeKgTNQ1JdDeLj3y+zmU+wpbJZ8KYOjl BEfjhUZNGTRcil3e5g0PulXb9UqmZdVMBoFhLjMaravFOzQ+ZeDQDMauw3Y5FzU7pdln TMVJKCrBquENS1lDPDqjsAJA24pI9/Bn+/eY8t/VPmQKeO0Z/hZAc7pmv1Dsk9X00z4b YZ3Wyc5vuYCyRl4GA4sr4JbTiOgEUrMmrW/B+6JuOblmKnaHkX88XFGFZTKgqW9JODjr UqBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=RTaUSovGmLuR+knQJUc7QFy/T7Jzr9vyIN05GM3YkOM=; b=aPyNYhingh2CDdc1qIn9LjPWV0hIW+LZJsgratlrrhpW0sbJlWwXD9LZmtbfjNKseU SA7ZEWx/xtAPjKF1l6hhfXe88lKz9chUlkQg+hZFsSIuV/x/2poVasGdfwS7Kuocci7r BLioKs2N0skX3BrjcT8wTIYkS8PkoywA3IppCYdz4qBTPa2n5xMmEIaUhJCPns2gtJep mLfIFkO/rpMazYV+5r+T+OhMp01TY5d1hs4N7flje33GkwSZt+B9Zo+T+yU/CTuJ1yj3 8sCkzd0hltJzW59YPKYp3ckfIeVxi/0aUW00JH7H2zg2SkQG1Q1rrwPfTozwtenHYiiu J3Ig== X-Gm-Message-State: AFeK/H3UE9R5pRK+tPIjhTEdbYcubmi/Cv1osUhLWDrzl1DVxLKXyfxcDwn+jsuUNU07Wg== X-Received: by 10.237.62.234 with SMTP id o39mr42272733qtf.87.1491571391160; Fri, 07 Apr 2017 06:23:11 -0700 (PDT) Received: from ?IPv6:2601:152:4400:a2e0::159b? ([2601:152:4400:a2e0::159b]) by smtp.gmail.com with ESMTPSA id 1sm3017926qty.69.2017.04.07.06.23.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 06:23:10 -0700 (PDT) To: pkix@ietf.org References: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> <27e9bc684735472bbd6d7f82b5e2823b@EX2.corp.digicert.com> <662C0D5C-EF34-4BD1-B3BC-B7B9A84B4990@vigilsec.com> <000001d2af76$824be7a0$86e3b6e0$@x500.eu> From: Michael StJohns Message-ID: <66170894-a0e0-34af-1089-f2c9db4464da@nthpermutation.com> Date: Fri, 7 Apr 2017 09:23:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <000001d2af76$824be7a0$86e3b6e0$@x500.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 13:23:16 -0000 On 4/7/2017 4:11 AM, Erik Andersen wrote: > Hi Russ, > > We have not changed upper bounds. I just checked the second edition (1993). It has 64 octets in both cases. RFC 5280 must have made a copy mistake. > > We removed upper bounds from the directory specifications to be compatible with LDAP that does not have upper bounds. Either we are compatible with LDAP or with RFC 5280, but with both is not possible. That's not actually a correct statement. You can store a compliant X.509 certificate in a non-compliant LDAP directory without any problems. It's storing a non-compliant (e.g. 256 byte commonName) X.509 certificate in a compliant LDAP or X.500 directory using the common name as part of the key that might be the problem. I.e., a compliant X.509 or PKIX certificate is compatible with LDAP regardless of LDAPs waiving of the limits. Mike > > Erik > > -----Oprindelig meddelelse----- > Fra: pkix [mailto:pkix-bounces@ietf.org] PÃ¥ vegne af Russ Housley > Sendt: 06 April 2017 21:25 > Til: Ben Wilson > Cc: IETF PKIX > Emne: Re: [pkix] Amendment to CABF Baseline Requirements > > The comment in the UpperBounds ASN.1 module (the 8th edition) says: > > -- EXPORTS All > -- The types and values defined in this module are exported for use in the other ASN.1 > -- modules contained within these Directory Specifications, and for the use of other > -- applications which will use them to access Directory services. Other applications > -- may use them for their own purposes, but this will not constrain extensions and > -- modifications needed to maintain or improve the Directory service. > > X.509 is part of the Directory Specifications, so they are not advisory. > > It looks like ITU-T increased the length of the organizational unit name in the most recent edition. > > RFC 5280 says: > > ub-organization-name-length INTEGER ::= 64 ub-organizational-unit-name-length INTEGER ::= 32 > > The UpperBounds ASN.1 module (the 8th edition) says: > > ub-organization-name INTEGER ::= 64 > ub-organizational-unit-name INTEGER ::= 64 > > So, we may already be in a place where implementations conforming to X.509 will produce a certificate that cannot be decoded by an implementation that conforms to RFC 5280. > > I wish we gad gotten a heads-up … > > Russ > > > >> On Apr 6, 2017, at 2:55 PM, Ben Wilson wrote: >> >> Thanks, Michael. Is it relevant that Annex C to X.520 (2012) states, >> "(This annex does not form an integral part of this Recommendation | >> International Standard.)" whereas before (1988) it stated, "This >> Annex is part of the Recommendation."? >> >> From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Michael StJohns >> Sent: Thursday, April 6, 2017 10:55 AM >> To: pkix@ietf.org >> Subject: Re: [pkix] Amendment to CABF Baseline Requirements >> >> Hi Ben - >> >> IETF 5280 et al are profiles of the X.509 documents. The upper length >> bounds for orgnaizationName and commonName fields in 5280 is no >> different than the upper bounds specified in X.509 (at least as of the >> 2014 document). I would suggest that you will pretty much break any >> and all implementations of X.509 clients that rely or enforce this >> limit as well as any code that generates certificate requests. >> >> I will note that overloading text fields with structured data is >> generally not a good idea - as you've found. >> >> Mike >> >> >> >> On 4/6/2017 12:24 PM, Ben Wilson wrote: >> Does anyone want to comment on my draft amendment to the CA/Browser >> Forum’s Baseline Requirements for SSL/TLS Certificates which would >> remove the 64-character limit on the commonName and organizationName, >> as an exception to RFC 5280? The text of the relevant Baseline >> Requirement provision is found below with the proposed additional >> language in ALL CAPS. The reason for the first change (commonName) is >> there are FQDNs (in Subject Alternative >> Names) that are longer than 64 characters. The reason for the second >> change >> (organizationName) is that there are organizations with names longer >> than 64 characters. >> >> 7.1.4.2.2. Subject Distinguished Name Fields >> a. Certificate Field: subject:commonName (OID 2.5.4.3) >> Required/Optional: Deprecated (Discouraged, but not prohibited) >> Contents: If present, this field MUST contain a single IP address or >> Fully-Qualified Domain Name that is one of the values contained in the >> Certificate’s subjectAltName extension (see Section 7.1.4.2.1). >> MAXIMUM LENGTH: NO STIPULATION. (THIS IS AN EXCEPTION TO RFC 5280 >> WHICH SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) >> b. Certificate Field: subject:organizationName (OID 2.5.4.10) >> Optional. >> Contents: If present, the subject:organizationName field MUST contain >> either the Subject’s name or DBA as verified under Section 3.2.2.2. >> The CA may include information in this field that differs slightly >> from the verified name, such as common variations or abbreviations, >> provided that the CA documents the difference and any abbreviations >> used are locally accepted abbreviations; e.g., if the official record >> shows “Company Name Incorporatedâ€, the CA MAY use “Company Name Inc.†or “Company Nameâ€. >> Because Subject name attributes for individuals (e.g. givenName >> (2.5.4.42) and surname (2.5.4.4)) are not broadly supported by >> application software, the CA MAY use the subject:organizationName >> field to convey a natural person Subject’s name or DBA. >> MAXIMUM LENGTH: 256 CHARACTERS (THIS IS AN EXCEPTION TO RFC 5280 >> WHICH SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) >> >> Thanks, >> Ben Wilson >> >> >> >> _______________________________________________ >> pkix mailing list >> mailto:pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From nobody Fri Apr 7 13:44:07 2017 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 832691200C1 for ; Fri, 7 Apr 2017 13:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOlT-BQmSszm for ; Fri, 7 Apr 2017 13:43:32 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5461289B0 for ; Fri, 7 Apr 2017 13:43:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 38A3A30043B for ; Fri, 7 Apr 2017 16:43:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id r-8bdEDXi1_u for ; Fri, 7 Apr 2017 16:43:24 -0400 (EDT) Received: from new-host-7.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 91D64300261 for ; Fri, 7 Apr 2017 16:43:24 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_DA4BBDC2-B8B7-49D7-A677-EBD199198BDE" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 7 Apr 2017 16:43:24 -0400 References: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> <27e9bc684735472bbd6d7f82b5e2823b@EX2.corp.digicert.com> <662C0D5C-EF34-4BD1-B3BC-B7B9A84B4990@vigilsec.com> To: IETF PKIX In-Reply-To: Message-Id: <09BE38C5-7B5B-45B0-BC5F-5FCB1164F864@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 20:43:37 -0000 --Apple-Mail=_DA4BBDC2-B8B7-49D7-A677-EBD199198BDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The ASN.1 modules that were posted by Erik confirm that the upper bounds = have been removed for all of the naming attributes in the = SelectedAttributeTypes module. UnboundedDirectoryString ::=3D CHOICE { teletexString TeletexString(SIZE (1..MAX)), printableString PrintableString(SIZE (1..MAX)), bmpString BMPString(SIZE (1..MAX)), universalString UniversalString(SIZE (1..MAX)), uTF8String UTF8String(SIZE (1..MAX)) } Russ > On Apr 7, 2017, at 3:15 AM, Erwann Abalea wrote: >=20 > Bonjour, >=20 > 2017-04-06 22:39 GMT+02:00 Peter Bowen >: >=20 > On Thu, Apr 6, 2017 at 12:24 PM Russ Housley > wrote: > The comment in the UpperBounds ASN.1 module (the 8th edition) says: >=20 > -- EXPORTS All > -- The types and values defined in this module are exported for use in = the other ASN.1 > -- modules contained within these Directory Specifications, and for = the use of other > -- applications which will use them to access Directory services. = Other applications > -- may use them for their own purposes, but this will not constrain = extensions and > -- modifications needed to maintain or improve the Directory service. >=20 > X.509 is part of the Directory Specifications, so they are not = advisory. >=20 > It looks like ITU-T increased the length of the organizational unit = name in the most recent edition. >=20 > RFC 5280 says: >=20 > ub-organization-name-length INTEGER ::=3D 64 > ub-organizational-unit-name-length INTEGER ::=3D 32 >=20 > The UpperBounds ASN.1 module (the 8th edition) says: >=20 > ub-organization-name INTEGER ::=3D 64 > ub-organizational-unit-name INTEGER ::=3D 64 >=20 > So, we may already be in a place where implementations conforming to = X.509 will produce a certificate that cannot be decoded by an = implementation that conforms to RFC 5280. >=20 > I wish we gad gotten a heads-up =E2=80=A6 >=20 > It is even worse. 7th and 8th (and maybe prior releases) removed the = usage of ub- from the schema. The schema itself no longer bounds = DirectoryStrings and X.509 explicitly says they are unbounded.=20 >=20 > X.520 2005 defines the attributes using the DirectoryString{} = parameterized type, while the 2008 edition uses the = UnboundedDirectoryString type. >=20 > RFC5912, which proposes ASN.1 modules for certificates and other = related things, still uses the DirectoryString{} variant. >=20 > --=20 > Erwann. --Apple-Mail=_DA4BBDC2-B8B7-49D7-A677-EBD199198BDE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The ASN.1 modules that were posted by Erik confirm that the = upper bounds have been removed for all of the naming attributes in the = SelectedAttributeTypes module.

UnboundedDirectoryString ::=3D CHOICE = {
  teletexString   =  TeletexString(SIZE (1..MAX)),
  = printableString  PrintableString(SIZE (1..MAX)),
  bmpString        BMPString(SIZE = (1..MAX)),
  universalString =  UniversalString(SIZE (1..MAX)),
  = uTF8String       UTF8String(SIZE (1..MAX)) = }

Russ


On Apr 7, 2017, at 3:15 AM, Erwann Abalea <eabalea@gmail.com> = wrote:

Bonjour,

2017-04-06= 22:39 GMT+02:00 Peter Bowen <pzbowen@gmail.com>:

On Thu, Apr 6, = 2017 at 12:24 PM Russ Housley <housley@vigilsec.com> wrote:
The comment in the = UpperBounds ASN.1 module (the 8th edition) says:

-- EXPORTS All
-- The types and values defined in this module are exported for use in = the other ASN.1
-- modules contained within these Directory Specifications, and for the = use of other
-- applications which will use them to access Directory services. Other = applications
-- may use them for their own purposes, but this will not constrain = extensions and
-- modifications needed to maintain or improve the Directory service.

X.509 is part of the Directory Specifications, so they are not = advisory.

It looks like ITU-T increased the length of the organizational unit name = in the most recent edition.

RFC 5280 says:

ub-organization-name-length INTEGER ::=3D 64
ub-organizational-unit-name-length INTEGER ::=3D 32

The UpperBounds ASN.1 module (the 8th edition) says:

ub-organization-name              =          INTEGER ::=3D 64
ub-organizational-unit-name            =     INTEGER ::=3D 64

So, we may already be in a place where implementations conforming to = X.509 will produce a certificate that cannot be decoded by an = implementation that conforms to RFC 5280.

I wish we gad gotten a heads-up =E2=80=A6

It is even worse. 7th and 8th = (and maybe prior releases) removed the usage of ub- from the schema. The = schema itself no longer bounds DirectoryStrings and X.509 explicitly = says they are unbounded. 

X.520 2005 defines the = attributes using the DirectoryString{} parameterized type, while the = 2008 edition uses the UnboundedDirectoryString type.

RFC5912, which proposes = ASN.1 modules for certificates and other related things, still uses the = DirectoryString{} variant.

--
Erwann.

= --Apple-Mail=_DA4BBDC2-B8B7-49D7-A677-EBD199198BDE-- From nobody Fri Apr 7 13:51:32 2017 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 6968D120454 for ; Fri, 7 Apr 2017 13:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GDlv7x8bn1L for ; Fri, 7 Apr 2017 13:51:28 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60D5F1200C1 for ; Fri, 7 Apr 2017 13:51:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A2EE130043B for ; Fri, 7 Apr 2017 16:51:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZsR61CbQ0KHT for ; Fri, 7 Apr 2017 16:51:25 -0400 (EDT) Received: from new-host-7.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 5CD7F300261; Fri, 7 Apr 2017 16:51:25 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <1c4a4745-1865-a142-fc25-514b37c602d3@comodo.com> Date: Fri, 7 Apr 2017 16:51:24 -0400 Cc: Ben Wilson , IETF PKIX Content-Transfer-Encoding: quoted-printable Message-Id: References: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> <27e9bc684735472bbd6d7f82b5e2823b@EX2.corp.digicert.com> <662C0D5C-EF34-4BD1-B3BC-B7B9A84B4990@vigilsec.com> <1c4a4745-1865-a142-fc25-514b37c602d3@comodo.com> To: Rob Stradling X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 20:51:30 -0000 Rob: You are absolutely correct! Thanks for posting the correction. Russ > On Apr 7, 2017, at 8:54 AM, Rob Stradling = wrote: >=20 > Russ, RFC5280 includes all of the following: >=20 > ub-organization-name INTEGER ::=3D 64 > ub-organizational-unit-name INTEGER ::=3D 64 > ub-organization-name-length INTEGER ::=3D 64 > ub-organizational-unit-name-length INTEGER ::=3D 32 >=20 > The *-name upper bounds apply to X.500 DNs, whereas IINM the = *-name-length upper bounds apply to the x400Address GeneralName type. >=20 > On 06/04/17 20:24, Russ Housley wrote: >> The comment in the UpperBounds ASN.1 module (the 8th edition) says: >>=20 >> -- EXPORTS All >> -- The types and values defined in this module are exported for use = in the other ASN.1 >> -- modules contained within these Directory Specifications, and for = the use of other >> -- applications which will use them to access Directory services. = Other applications >> -- may use them for their own purposes, but this will not constrain = extensions and >> -- modifications needed to maintain or improve the Directory service. >>=20 >> X.509 is part of the Directory Specifications, so they are not = advisory. >>=20 >> It looks like ITU-T increased the length of the organizational unit = name in the most recent edition. >>=20 >> RFC 5280 says: >>=20 >> ub-organization-name-length INTEGER ::=3D 64 >> ub-organizational-unit-name-length INTEGER ::=3D 32 >>=20 >> The UpperBounds ASN.1 module (the 8th edition) says: >>=20 >> ub-organization-name INTEGER ::=3D 64 >> ub-organizational-unit-name INTEGER ::=3D 64 >>=20 >> So, we may already be in a place where implementations conforming to = X.509 will produce a certificate that cannot be decoded by an = implementation that conforms to RFC 5280. >>=20 >> I wish we gad gotten a heads-up =E2=80=A6 >>=20 >> Russ >>=20 >>=20 >>=20 >>> On Apr 6, 2017, at 2:55 PM, Ben Wilson = wrote: >>>=20 >>> Thanks, Michael. Is it relevant that Annex C to X.520 (2012) = states, >>> "(This annex does not form an integral part of this Recommendation | >>> International Standard.)" whereas before (1988) it stated, "This = Annex is >>> part of the Recommendation."? >>>=20 >>> From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Michael = StJohns >>> Sent: Thursday, April 6, 2017 10:55 AM >>> To: pkix@ietf.org >>> Subject: Re: [pkix] Amendment to CABF Baseline Requirements >>>=20 >>> Hi Ben - >>>=20 >>> IETF 5280 et al are profiles of the X.509 documents. The upper = length >>> bounds for orgnaizationName and commonName fields in 5280 is no = different >>> than the upper bounds specified in X.509 (at least as of the 2014 >>> document). I would suggest that you will pretty much break any and = all >>> implementations of X.509 clients that rely or enforce this limit as = well as >>> any code that generates certificate requests. >>>=20 >>> I will note that overloading text fields with structured data is = generally >>> not a good idea - as you've found. >>>=20 >>> Mike >>>=20 >>>=20 >>>=20 >>> On 4/6/2017 12:24 PM, Ben Wilson wrote: >>> Does anyone want to comment on my draft amendment to the CA/Browser = Forum=C2=92s >>> Baseline Requirements for SSL/TLS Certificates which would remove = the >>> 64-character limit on the commonName and organizationName, as an = exception >>> to RFC 5280? The text of the relevant Baseline Requirement = provision is >>> found below with the proposed additional language in ALL CAPS. The = reason >>> for the first change (commonName) is there are FQDNs (in Subject = Alternative >>> Names) that are longer than 64 characters. The reason for the = second change >>> (organizationName) is that there are organizations with names longer = than 64 >>> characters. >>>=20 >>> 7.1.4.2.2. Subject Distinguished Name Fields >>> a. Certificate Field: subject:commonName (OID 2.5.4.3) >>> Required/Optional: Deprecated (Discouraged, but not prohibited) >>> Contents: If present, this field MUST contain a single IP address or >>> Fully-Qualified Domain Name that is one of the values contained in = the >>> Certificate=C2=92s subjectAltName extension (see Section 7.1.4.2.1). >>> MAXIMUM LENGTH: NO STIPULATION. (THIS IS AN EXCEPTION TO RFC 5280 = WHICH >>> SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) >>> b. Certificate Field: subject:organizationName (OID = 2.5.4.10) >>> Optional. >>> Contents: If present, the subject:organizationName field MUST = contain either >>> the Subject=C2=92s name or DBA as verified under Section 3.2.2.2. = The CA may >>> include information in this field that differs slightly from the = verified >>> name, such as common variations or abbreviations, provided that the = CA >>> documents the difference and any abbreviations used are locally = accepted >>> abbreviations; e.g., if the official record shows =C2=93Company Name >>> Incorporated=C2=94, the CA MAY use =C2=93Company Name Inc.=C2=94 or = =C2=93Company Name=C2=94. >>> Because Subject name attributes for individuals (e.g. givenName = (2.5.4.42) >>> and surname (2.5.4.4)) are not broadly supported by application = software, >>> the CA MAY use the subject:organizationName field to convey a = natural person >>> Subject=C2=92s name or DBA. >>> MAXIMUM LENGTH: 256 CHARACTERS (THIS IS AN EXCEPTION TO RFC 5280 = WHICH >>> SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) >>>=20 >>> Thanks, >>> Ben Wilson >=20 > --=20 > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online >=20 From nobody Sat Apr 8 01:20:56 2017 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 2F2A31293EB for ; Sat, 8 Apr 2017 01:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wX7pRLQdYymC for ; Sat, 8 Apr 2017 01:20:51 -0700 (PDT) Received: from mail04.dandomain.dk (mail04.dandomain.dk [194.150.112.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF10E128D2E for ; Sat, 8 Apr 2017 01:20:50 -0700 (PDT) Received: from Morten ([62.44.135.123]) by mail04.dandomain.dk (DanDomain Mailserver) with ASMTP id 4201704081020451805 for ; Sat, 08 Apr 2017 10:20:45 +0200 From: "Erik Andersen" To: "'IETF PKIX'" References: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> <27e9bc684735472bbd6d7f82b5e2823b@EX2.corp.digicert.com> <662C0D5C-EF34-4BD1-B3BC-B7B9A84B4990@vigilsec.com> <09BE38C5-7B5B-45B0-BC5F-5FCB1164F864@vigilsec.com> In-Reply-To: <09BE38C5-7B5B-45B0-BC5F-5FCB1164F864@vigilsec.com> Date: Sat, 8 Apr 2017 10:20:44 +0200 Message-ID: <000001d2b041$050c2310$0f246930$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D2B051.C895DD70" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLbax/O6ZBps7Ft6UeYTkOEFrZPhAFLVKgvAbGqP3EBulwnngL84uHQAprq/+MCV8zYqJ9Eap8g Content-Language: en-gb Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 08:20:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D2B051.C895DD70 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The change was made in the sixth edition of X.520 (2008). It was = primarily driven by Hoyt Kesterson and by some X.500/LDAP vendors. Hoyt = was generally against such limitations, as the future is difficult to = predict. X.500/LDAP vendors were concerned about interworking between = X.500 and LDAP (that does not have upper bounds). You may have noticed = that ASN.1 information objects now also contains LDAP specific fields = allowing also new attribute types to be usable also in an LDAP = environment without the need for additional specifications. =20 I insisted that the upper bounds should be kept in an informative annex = to be used by those having a requirement to limit the sizes. =20 I could, if you feel it relevant, try to suggest a Defect Report to = X.509 saying that it is strongly recommend to observe the upper bounds = specified in X.520. I will also try to get such a statement into any = smart grid security standard that references X.509. =20 Erik Fra: pkix [mailto:pkix-bounces@ietf.org] P=C3=A5 vegne af Russ Housley Sendt: 07 April 2017 22:43 Til: IETF PKIX Emne: Re: [pkix] Amendment to CABF Baseline Requirements =20 The ASN.1 modules that were posted by Erik confirm that the upper bounds = have been removed for all of the naming attributes in the = SelectedAttributeTypes module. =20 UnboundedDirectoryString ::=3D CHOICE { teletexString TeletexString(SIZE (1..MAX)), printableString PrintableString(SIZE (1..MAX)), bmpString BMPString(SIZE (1..MAX)), universalString UniversalString(SIZE (1..MAX)), uTF8String UTF8String(SIZE (1..MAX)) } =20 Russ =20 =20 On Apr 7, 2017, at 3:15 AM, Erwann Abalea > wrote: =20 Bonjour, =20 2017-04-06 22:39 GMT+02:00 Peter Bowen >: =20 On Thu, Apr 6, 2017 at 12:24 PM Russ Housley > wrote: The comment in the UpperBounds ASN.1 module (the 8th edition) says: -- EXPORTS All -- The types and values defined in this module are exported for use in = the other ASN.1 -- modules contained within these Directory Specifications, and for the = use of other -- applications which will use them to access Directory services. Other = applications -- may use them for their own purposes, but this will not constrain = extensions and -- modifications needed to maintain or improve the Directory service. X.509 is part of the Directory Specifications, so they are not advisory. It looks like ITU-T increased the length of the organizational unit name = in the most recent edition. RFC 5280 says: ub-organization-name-length INTEGER ::=3D 64 ub-organizational-unit-name-length INTEGER ::=3D 32 The UpperBounds ASN.1 module (the 8th edition) says: ub-organization-name INTEGER ::=3D 64 ub-organizational-unit-name INTEGER ::=3D 64 So, we may already be in a place where implementations conforming to = X.509 will produce a certificate that cannot be decoded by an = implementation that conforms to RFC 5280. I wish we gad gotten a heads-up =E2=80=A6 =20 It is even worse. 7th and 8th (and maybe prior releases) removed the = usage of ub- from the schema. The schema itself no longer bounds = DirectoryStrings and X.509 explicitly says they are unbounded.=20 =20 X.520 2005 defines the attributes using the DirectoryString{} = parameterized type, while the 2008 edition uses the = UnboundedDirectoryString type. =20 RFC5912, which proposes ASN.1 modules for certificates and other related = things, still uses the DirectoryString{} variant. =20 --=20 Erwann. =20 ------=_NextPart_000_0001_01D2B051.C895DD70 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The change was made in the sixth edition of = X.520 (2008). It was primarily driven by Hoyt Kesterson and by some = X.500/LDAP vendors. Hoyt was generally against such limitations, as the = future is difficult to predict. X.500/LDAP vendors were concerned about = interworking between X.500 and LDAP (that does not have upper bounds). = You may have noticed that ASN.1 information objects now also contains = LDAP specific fields allowing also new attribute types to be usable also = in an LDAP environment without the need for additional = specifications.

 

I insisted that the upper bounds should be = kept in an informative annex to be used by those having a requirement to = limit the sizes.

 

I could, if you feel it relevant, try to = suggest a Defect Report to X.509 saying that it is strongly recommend to = observe the upper bounds specified in X.520. I will also try to get such = a statement into any smart grid security standard that references = X.509.

 

Erik

Fra: = pkix [mailto:pkix-bounces@ietf.org] P=C3=A5 vegne af Russ = Housley
Sendt: 07 April 2017 22:43
Til: IETF PKIX = <pkix@ietf.org>
Emne: Re: [pkix] Amendment to CABF = Baseline Requirements

 

The ASN.1 = modules that were posted by Erik confirm that the upper bounds have been = removed for all of the naming attributes in the SelectedAttributeTypes = module.

 

UnboundedDirectoryString ::=3D CHOICE = {

  teletexString =    TeletexString(SIZE (1..MAX)),

  printableString  PrintableString(SIZE = (1..MAX)),

  = bmpString        BMPString(SIZE = (1..MAX)),

  = universalString  UniversalString(SIZE = (1..MAX)),

  = uTF8String       UTF8String(SIZE (1..MAX)) = }

 

Russ

 

 

On Apr 7, 2017, at 3:15 AM, Erwann Abalea <eabalea@gmail.com> = wrote:

 

Bonjour,

 

2017-04-06 22:39 GMT+02:00 Peter Bowen <pzbowen@gmail.com>:

 

On = Thu, Apr 6, 2017 at 12:24 PM Russ Housley <housley@vigilsec.com> = wrote:

The = comment in the UpperBounds ASN.1 module (the 8th edition) = says:

-- EXPORTS All
-- The types and values defined in this = module are exported for use in the other ASN.1
-- modules contained = within these Directory Specifications, and for the use of other
-- = applications which will use them to access Directory services. Other = applications
-- may use them for their own purposes, but this will = not constrain extensions and
-- modifications needed to maintain or = improve the Directory service.

X.509 is part of the Directory = Specifications, so they are not advisory.

It looks like ITU-T = increased the length of the organizational unit name in the most recent = edition.

RFC 5280 says:

ub-organization-name-length = INTEGER ::=3D 64
ub-organizational-unit-name-length INTEGER ::=3D = 32

The UpperBounds ASN.1 module (the 8th edition) = says:

ub-organization-name          =              INTEGER ::=3D = 64
ub-organizational-unit-name          =       INTEGER ::=3D 64

So, we may already be in a = place where implementations conforming to X.509 will produce a = certificate that cannot be decoded by an implementation that conforms to = RFC 5280.

I wish we gad gotten a heads-up = =E2=80=A6

 

It is even worse. 7th and 8th (and maybe prior = releases) removed the usage of ub- from the schema. The schema itself no = longer bounds DirectoryStrings and X.509 explicitly says they are = unbounded. 

 

X.520 2005 defines the attributes using the = DirectoryString{} parameterized type, while the 2008 edition uses the = UnboundedDirectoryString type.

 

RFC5912, which proposes ASN.1 modules for certificates = and other related things, still uses the DirectoryString{} = variant.

 

-- =

Erwann.

 

------=_NextPart_000_0001_01D2B051.C895DD70-- From nobody Sat Apr 8 07:01:26 2017 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 3BF5E1273B1 for ; Sat, 8 Apr 2017 07:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8J0Uoyl4smU for ; Sat, 8 Apr 2017 07:01:22 -0700 (PDT) Received: from mail2.safelayer.com (mail2.safelayer.com [213.37.153.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCE5A126C83 for ; Sat, 8 Apr 2017 07:01:22 -0700 (PDT) Received: from [192.168.8.23] (port=58193 helo=mailmad.safelayer.lan) by mail2.safelayer.com with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cwqvW-0000I7-0y for pkix@ietf.org; Sat, 08 Apr 2017 16:01:18 +0200 Auto-Submitted: auto-generated From: Cesar Armenta To: pkix@ietf.org Message-ID: Date: Sat, 8 Apr 2017 16:01:18 +0200 X-MIMETrack: Serialize by Router on mailmad/SFLY(Release 9.0.1FP7|August 17, 2016) at 08/04/2017 16:01:18 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Archived-At: Subject: [pkix] AUTO: Cesar Armenta is out of office (returning 18/04/2017) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 14:01:24 -0000 I am out of the office until 18/04/2017. Me encuentro fuera de la oficina hasta el 18/04/2017. Si se trata de alguna cuesti=F3n urgente, por favor, escriba a support@safelayer.com I am out of the office until April 18th 2017 For any urgent matters, please contact support@safelayer.com Note: This is an automated response to your message "pkix Digest, Vol = 93, Issue 7" sent on 08/04/2017 10:20:55. This is the only notification you will receive while this person is awa= y.= From nobody Sat Apr 8 10:46:55 2017 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 2E863129449 for ; Sat, 8 Apr 2017 10:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCBI-1JqMdPk for ; Sat, 8 Apr 2017 10:46:51 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792F0127863 for ; Sat, 8 Apr 2017 10:46:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9338630043B for ; Sat, 8 Apr 2017 13:46:45 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qVhckjpqCu3r for ; Sat, 8 Apr 2017 13:46:42 -0400 (EDT) Received: from new-host-7.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id CAE1D30042F; Sat, 8 Apr 2017 13:46:42 -0400 (EDT) From: Russ Housley Message-Id: <2D820AC4-81D0-44AC-BBE8-B8C74BD43BB0@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_12293A4A-8D75-4B96-A233-80C8E88B10A5" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 8 Apr 2017 13:46:42 -0400 In-Reply-To: <000001d2b041$050c2310$0f246930$@x500.eu> Cc: IETF PKIX To: Erik Andersen References: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> <27e9bc684735472bbd6d7f82b5e2823b@EX2.corp.digicert.com> <662C0D5C-EF34-4BD1-B3BC-B7B9A84B4990@vigilsec.com> <09BE38C5-7B5B-45B0-BC5F-5FCB1164F864@vigilsec.com> <000001d2b041$050c2310$0f246930$@x500.eu> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 17:46:54 -0000 --Apple-Mail=_12293A4A-8D75-4B96-A233-80C8E88B10A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Erik: The CA/Browser Forum seems to be finding the upper bounds in the X.500 = 5th edition and RFC 5280. I=E2=80=99m not sure how to relax them = without introducing interoperability concerns. Russ > On Apr 8, 2017, at 4:20 AM, Erik Andersen wrote: >=20 > The change was made in the sixth edition of X.520 (2008). It was = primarily driven by Hoyt Kesterson and by some X.500/LDAP vendors. Hoyt = was generally against such limitations, as the future is difficult to = predict. X.500/LDAP vendors were concerned about interworking between = X.500 and LDAP (that does not have upper bounds). You may have noticed = that ASN.1 information objects now also contains LDAP specific fields = allowing also new attribute types to be usable also in an LDAP = environment without the need for additional specifications. > =20 > I insisted that the upper bounds should be kept in an informative = annex to be used by those having a requirement to limit the sizes. > =20 > I could, if you feel it relevant, try to suggest a Defect Report to = X.509 saying that it is strongly recommend to observe the upper bounds = specified in X.520. I will also try to get such a statement into any = smart grid security standard that references X.509. > =20 > Erik > Fra: pkix [mailto:pkix-bounces@ietf.org = ] P=C3=A5 vegne af Russ Housley > Sendt: 07 April 2017 22:43 > Til: IETF PKIX > > Emne: Re: [pkix] Amendment to CABF Baseline Requirements > =20 > The ASN.1 modules that were posted by Erik confirm that the upper = bounds have been removed for all of the naming attributes in the = SelectedAttributeTypes module. > =20 > UnboundedDirectoryString ::=3D CHOICE { > teletexString TeletexString(SIZE (1..MAX)), > printableString PrintableString(SIZE (1..MAX)), > bmpString BMPString(SIZE (1..MAX)), > universalString UniversalString(SIZE (1..MAX)), > uTF8String UTF8String(SIZE (1..MAX)) } > =20 > Russ > =20 > =20 >> On Apr 7, 2017, at 3:15 AM, Erwann Abalea > wrote: >> =20 >> Bonjour, >> =20 >> 2017-04-06 22:39 GMT+02:00 Peter Bowen >: >>> =20 >>> On Thu, Apr 6, 2017 at 12:24 PM Russ Housley > wrote: >>>> The comment in the UpperBounds ASN.1 module (the 8th edition) says: >>>>=20 >>>> -- EXPORTS All >>>> -- The types and values defined in this module are exported for use = in the other ASN.1 >>>> -- modules contained within these Directory Specifications, and for = the use of other >>>> -- applications which will use them to access Directory services. = Other applications >>>> -- may use them for their own purposes, but this will not constrain = extensions and >>>> -- modifications needed to maintain or improve the Directory = service. >>>>=20 >>>> X.509 is part of the Directory Specifications, so they are not = advisory. >>>>=20 >>>> It looks like ITU-T increased the length of the organizational unit = name in the most recent edition. >>>>=20 >>>> RFC 5280 says: >>>>=20 >>>> ub-organization-name-length INTEGER ::=3D 64 >>>> ub-organizational-unit-name-length INTEGER ::=3D 32 >>>>=20 >>>> The UpperBounds ASN.1 module (the 8th edition) says: >>>>=20 >>>> ub-organization-name INTEGER ::=3D 64 >>>> ub-organizational-unit-name INTEGER ::=3D 64 >>>>=20 >>>> So, we may already be in a place where implementations conforming = to X.509 will produce a certificate that cannot be decoded by an = implementation that conforms to RFC 5280. >>>>=20 >>>> I wish we gad gotten a heads-up =E2=80=A6 >>> =20 >>> It is even worse. 7th and 8th (and maybe prior releases) removed the = usage of ub- from the schema. The schema itself no longer bounds = DirectoryStrings and X.509 explicitly says they are unbounded.=20 >> =20 >> X.520 2005 defines the attributes using the DirectoryString{} = parameterized type, while the 2008 edition uses the = UnboundedDirectoryString type. >> =20 >> RFC5912, which proposes ASN.1 modules for certificates and other = related things, still uses the DirectoryString{} variant. >> =20 >> --=20 >> Erwann. >=20 > =20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix = --Apple-Mail=_12293A4A-8D75-4B96-A233-80C8E88B10A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Erik:

The = CA/Browser Forum seems to be finding the upper bounds in the X.500 5th = edition and RFC 5280.  I=E2=80=99m not sure how to relax them = without introducing interoperability concerns.

Russ


On Apr 8, 2017, at 4:20 AM, = Erik Andersen <era@x500.eu> wrote:

The change was made in = the sixth edition of X.520 (2008). It was primarily driven by Hoyt = Kesterson and by some X.500/LDAP vendors. Hoyt was generally against = such limitations, as the future is difficult to predict. X.500/LDAP = vendors were concerned about interworking between X.500 and LDAP (that = does not have upper bounds). You may have noticed that ASN.1 information = objects now also contains LDAP specific fields allowing also new = attribute types to be usable also in an LDAP environment without the = need for additional specifications.
 
I insisted that the = upper bounds should be kept in an informative annex to be used by those = having a requirement to limit the sizes.
 
I could, if you feel it = relevant, try to suggest a Defect Report to X.509 saying that it is = strongly recommend to observe the upper bounds specified in X.520. I = will also try to get such a statement into any smart grid security = standard that references X.509.
 
Erik
Fra: pkix [mailto:pkix-bounces@ietf.org] P=C3=A5 vegne = af Russ Housley
Sendt: 07 April 2017 22:43
Til: IETF PKIX <pkix@ietf.org>
Emne: Re:= [pkix] Amendment to CABF Baseline Requirements
 
The ASN.1 modules that were posted by Erik confirm that the = upper bounds have been removed for all of the naming attributes in the = SelectedAttributeTypes module.
 
UnboundedDirectoryString ::=3D CHOICE = {
  teletexString    TeletexString(SIZE = (1..MAX)),
  printableString =  PrintableString(SIZE (1..MAX)),
  bmpString        BMPString(SIZE = (1..MAX)),
  universalString =  UniversalString(SIZE (1..MAX)),
  uTF8String       UTF8String(SIZE = (1..MAX)) }
 
Russ
 
 
On Apr 7, 2017, at 3:15 AM, Erwann Abalea <eabalea@gmail.com> = wrote:
 
Bonjour,
 
2017-04-06 22:39 = GMT+02:00 Peter Bowen <pzbowen@gmail.com>:
 
On Thu, Apr 6, 2017 = at 12:24 PM Russ Housley <housley@vigilsec.com> wrote:
The = comment in the UpperBounds ASN.1 module (the 8th edition) says:

-- EXPORTS All
-- The types and = values defined in this module are exported for use in the other ASN.1
-- modules contained within these Directory Specifications, = and for the use of other
-- applications which will use = them to access Directory services. Other applications
-- = may use them for their own purposes, but this will not constrain = extensions and
-- modifications needed to maintain or = improve the Directory service.

X.509 is = part of the Directory Specifications, so they are not advisory.

It looks like ITU-T increased the length of = the organizational unit name in the most recent edition.
RFC 5280 says:

ub-organization-name-length INTEGER ::=3D 64
ub-organizational-unit-name-length INTEGER ::=3D 32

The UpperBounds ASN.1 module (the 8th edition) = says:

ub-organization-name    =                   =  INTEGER ::=3D 64
ub-organizational-unit-name  =               INTEGER ::=3D 64

So, we may already be in a place where = implementations conforming to X.509 will produce a certificate that = cannot be decoded by an implementation that conforms to RFC 5280.

I wish we gad gotten a heads-up =E2=80=A6
 
It is even worse. 7th = and 8th (and maybe prior releases) removed the usage of ub- from the = schema. The schema itself no longer bounds DirectoryStrings and X.509 = explicitly says they are unbounded. 
 
X.520 2005 defines the attributes using the = DirectoryString{} parameterized type, while the 2008 edition uses the = UnboundedDirectoryString type.
 
RFC5912, which proposes ASN.1 modules for = certificates and other related things, still uses the DirectoryString{} = variant.
 
-- 
Erwann.
 
_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
= --Apple-Mail=_12293A4A-8D75-4B96-A233-80C8E88B10A5-- From nobody Mon Apr 10 08:13:40 2017 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 ABDED12953F for ; Mon, 10 Apr 2017 08:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMvNDczFWxOc for ; Mon, 10 Apr 2017 08:13:20 -0700 (PDT) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED0E5129536 for ; Mon, 10 Apr 2017 08:13:16 -0700 (PDT) Received: from Morten ([62.44.134.150]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id 2201704101713121242 for ; Mon, 10 Apr 2017 17:13:12 +0200 From: "Erik Andersen" To: References: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> In-Reply-To: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> Date: Mon, 10 Apr 2017 17:13:11 +0200 Message-ID: <000001d2b20c$f8031930$e8094b90$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D2B21D.BB9007E0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLbax/O6ZBps7Ft6UeYTkOEFrZPhJ+tOOjQ Content-Language: en-gb Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 15:13:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D2B21D.BB9007E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ben and others, I responded to the upper bound issue before reading Ben=92s question. I = have a comment not related to the commonName attribute type. The commonName is being (mis)used for all kind of things, so you cannot know what the = syntax really is, which should cause interworking problems. The use of = commonName should possibly be deprecated. As to use the commonName for holding an FQDN, it is a little = problematic. The matching rule for FQDNs is a little more complicated than the one = for commonName. X.520 has a dsnName attribute type and as it is rather new = it has not upper bound specification. It is defined as: 6.2.15 Domain name A value of attribute type dnsName is used for holding a DNS domain name, which may be an internationalized domain name (IDN). =20 dnsName ATTRIBUTE ::=3D { WITH SYNTAX DomainName EQUALITY MATCHING RULE dnsNameMatch LDAP-SYNTAX dnsString.&id LDAP-NAME {"DNS name"} ID id-at-dnsName } =20 DomainName ::=3D UTF8String (CONSTRAINED BY { -- Conforms to the format = of a (internationalized) domain name. -- }) A value of the DomainName data type shall be in the syntax, as specified = by section 2.3.1 of IETF RFC 5890 meaning that a domain name is a sequence = of labels in the letters, digits, hyphen (LDH) format separated by dots. A label may be in three formats: a) All characters in the label are from the Basic Latin collection = as defined by ISO/IEC 10646 (i.e., having code points in the ranges 002D, 0030-0039, 0041-005A and 0061-007A) and it does not start with "xn--". = The maximum length is 63 octets. b) It is an A-label as defined in IETF RFC 5890, i.e., it starts = with the "xn--" and is a U-label converted to valid ASCII characters as in = item a) using the Punycode algorithm defined by IETF RFC 3492. The converted string shall be maximum 59 octets. To be valid, it shall be possible for = an A-label to be converted to a valid U-label. NOTE 1 =96 An A-label is normally not human readable. c) It is a U-label as defined in IETF RFC 5890, i.e., it contains characters outside the Basic Latin collection. A valid U-label shall not include any characters that are not included in the restricted Unicode repertoire as defined by IETF RFC 5892 and it shall be convertible to a valid A-label as defined in item b). A valid U-label may be more than 63 octets. NOTE 2 =96 In a constraint environment, it is recommended to use a = domain name whenever possible, according to item a). NOTE 3 =96 When used as a naming attribute, a unique distinguished name = may be constructed using only this attribute type. An attribute of type dnsName to be used as a distinguished name in a public-key certificate or in an attribute certificate shall be a fully-qualified domain name (FQDN), i.e., it shall identify a particular entity. An FQDN may have an asterisk ('*') as an additional leftmost = label, which is a substitute (wildcard) for all labels at the next levels of subdomains of the domain identified by the FQDN without the asterisk. An attribute of type dnsName holding an FQDN with a wildcard label may in = some cases be used in the subject component of an end-entity public-key certificate. The corresponding matching rule is defined as: 8.9.2 DNS name match The dnsNameMatch compares two values of type dnsName for equality and is defined as: =20 dnsNameMatch MATCHING-RULE ::=3D { SYNTAX DomainName LDAP-SYNTAX dnsString.&id LDAP-NAME {"dnsNameMatch"} ID id-mr-dnsNameMatch } The equality matching is performed label for label. If the number of the labels in the two attribute values are different, the rule shall return FALSE. The rule shall return TRUE for each pair of labels matched for = the rule to return TRUE for the two values. Otherwise, it shall return = FALSE. The matching of the individual labels shall be performed as follows: a) If one of the labels to be compared is of the type defined in = item a) of clause 6.2.15 and the other label is either an A-label or a U-label = as defined in IETF RFC 5890, the rule shall return FALSE. b) If the two labels are of the same type, they shall be compared following the rules for caseIgnoreMatch. c) If one the labels is of type A-label and the other one is of type U-label, the latter shall be converted to an A-label before comparison following the rules for caseIgnoreMatch. In addition, the following applies if one or both of the values have wildcard ('*') labels: d) If at least one of the values contains more than one wildcard = label or if a wildcard label is not the leftmost label, the rule shall return FALSE. e) If one or both the values has a wildcard as the leftmost label, = the remaining labels shall be matched as stated in a) to c) above and shall return TRUE or FALSE accordingly. NOTE =96 The effect of the wildcard match is that *.example.com will = match a.example.com and b.example.com but not a.b.example.com nor example.com. =20 Erik Fra: pkix [mailto:pkix-bounces@ietf.org] P=E5 vegne af Ben Wilson Sendt: 06 April 2017 18:24 Til: pkix@ietf.org Emne: [pkix] Amendment to CABF Baseline Requirements =20 Does anyone want to comment on my draft amendment to the CA/Browser = Forum=92s Baseline Requirements for SSL/TLS Certificates which would remove the 64-character limit on the commonName and organizationName, as an = exception to RFC 5280? The text of the relevant Baseline Requirement provision is found below with the proposed additional language in ALL CAPS. The = reason for the first change (commonName) is there are FQDNs (in Subject = Alternative Names) that are longer than 64 characters. The reason for the second = change (organizationName) is that there are organizations with names longer = than 64 characters. =20 7.1.4.2.2. Subject Distinguished Name Fields a. Certificate Field: subject:commonName (OID 2.5.4.3) =20 Required/Optional: Deprecated (Discouraged, but not prohibited) Contents: If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate=92s subjectAltName extension (see Section 7.1.4.2.1). MAXIMUM LENGTH: NO STIPULATION. (THIS IS AN EXCEPTION TO RFC 5280 = WHICH SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) b. Certificate Field: subject:organizationName (OID 2.5.4.10) Optional. =20 Contents: If present, the subject:organizationName field MUST contain = either the Subject=92s name or DBA as verified under Section 3.2.2.2. The CA = may include information in this field that differs slightly from the = verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g., if the official record shows =93Company Name Incorporated=94, the CA MAY use =93Company Name Inc.=94 or =93Company = Name=94. Because Subject name attributes for individuals (e.g. givenName = (2.5.4.42) and surname (2.5.4.4)) are not broadly supported by application = software, the CA MAY use the subject:organizationName field to convey a natural = person Subject=92s name or DBA. MAXIMUM LENGTH: 256 CHARACTERS (THIS IS AN EXCEPTION TO RFC 5280 WHICH SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) =20 Thanks, Ben Wilson ------=_NextPart_000_0001_01D2B21D.BB9007E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ben and = others,

I responded to the = upper bound issue before reading Ben’s question. I have a comment = not related to the commonName attribute type. The commonName is being = (mis)used for all kind of things, so you cannot know what the syntax = really is, which should cause interworking problems. The use of = commonName should possibly be deprecated.

As to use the = commonName for holding an FQDN, it is a little problematic. The matching = rule for FQDNs is a little more complicated than the one for commonName. = X.520 has a dsnName attribute type and as it is rather new it has not = upper bound specification. It is defined = as:

6.2.15=A0=A0=A0=A0=A0 Domain = name

A value of attribute type dnsName is used = for holding a DNS domain name, which may be an internationalized domain = name (IDN).

 

dnsName ATTRIBUTE ::=3D {

=A0 = WITH SYNTAX=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = DomainName

=A0 EQUALITY MATCHING RULE=A0 = dnsNameMatch

=A0 = LDAP-SYNTAX=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = dnsString.&id

=A0 = LDAP-NAME=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0{"DNS = name"}

=A0 = ID=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = id-at-dnsName }

 

DomainName ::=3D UTF8String (CONSTRAINED BY { -- Conforms = to the format of a (internationalized) domain name. -- = })

A value of the DomainName data = type shall be in the syntax, as specified by section 2.3.1 of IETF RFC = 5890 meaning that a domain name is a sequence of labels in the letters, = digits, hyphen (LDH) format separated by dots.

A label may be in three formats:

a)=A0=A0=A0=A0 All characters in the label are from the = Basic Latin collection as defined by ISO/IEC 10646 (i.e., having code = points in the ranges 002D, = 0030-0039, 0041-005A and 0061-007A) and it does not start with = "xn--". The maximum length is 63 = octets.

b)=A0=A0=A0=A0 It is an A-label as = defined in IETF RFC 5890, i.e., it starts with the "xn--" and = is a U-label converted to valid ASCII characters as in item a) using the = Punycode algorithm defined by IETF RFC 3492. The converted string shall = be maximum 59 octets. To be valid, it shall be possible for an A-label = to be converted to a valid U-label.

NOTE 1 – = An A-label is normally not human readable.

c)=A0=A0=A0=A0 It is a U-label as = defined in IETF RFC 5890, i.e., it contains characters outside the = Basic Latin collection. A valid U-label shall not include = any characters that are not included in the restricted Unicode = repertoire as defined by IETF RFC 5892 and it shall be convertible to a = valid A-label as defined in item b). A valid U-label may be more than 63 = octets.

NOTE 2 – In a constraint = environment, it is recommended to use a domain name whenever possible, = according to item a).

NOTE 3 – When used as a = naming attribute, a unique distinguished name may be constructed using = only this attribute type.

An = attribute of type dnsName to be = used as a distinguished name in a public-key certificate or in an = attribute certificate shall be a fully-qualified domain name (FQDN), = i.e., it shall identify a particular entity. An FQDN may have an = asterisk ('*') as an additional leftmost label, which is a substitute = (wildcard) for all labels at the next levels of subdomains of the domain = identified by the FQDN without the asterisk. An attribute of type dnsName holding = an FQDN with a wildcard label may in some cases be used in the subject = component of an end-entity public-key certificate.

The corresponding = matching rule is defined = as:

8.9.2=A0=A0=A0=A0=A0=A0=A0 DNS name = match

The dnsNameMatch = compares two values of type dnsName for = equality and is defined as:

 

dnsNameMatch = MATCHING-RULE ::=3D {

=A0 = SYNTAX=A0=A0=A0=A0=A0=A0 DomainName

=A0 = LDAP-SYNTAX=A0 dnsString.&id

=A0 = LDAP-NAME =A0=A0=A0{"dnsNameMatch"}

=A0 ID=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 id-mr-dnsNameMatch = }

The equality matching is performed = label for label. If the number of the labels in the two attribute values = are different, the rule shall return FALSE. The rule shall return TRUE = for each pair of labels matched for the rule to return TRUE for the two = values. Otherwise, it shall return FALSE. The matching of the individual = labels shall be performed as follows:

a)=A0=A0=A0=A0 If one of the labels to be compared is = of the type defined in item a) of clause 6.2.15 and the other label is = either an A-label or a U-label as defined in IETF RFC 5890, the rule = shall return FALSE.

b)=A0=A0=A0=A0 If = the two labels are of the same type, they shall be compared following = the rules for caseIgnoreMatch.

c)=A0=A0=A0=A0 If one the labels is of type A-label = and the other one is of type U-label, the latter shall be converted to = an A-label before comparison following the rules for caseIgnoreMatch.

In addition, the following applies if one or both of = the values have wildcard ('*') labels:

d)=A0=A0=A0=A0 If at least one of the values contains = more than one wildcard label or if a wildcard label is not the leftmost = label, the rule shall return FALSE.

e)=A0=A0=A0=A0 If one or both the values has a wildcard = as the leftmost label, the remaining labels shall be matched as stated = in a) to c) above and shall return TRUE or FALSE = accordingly.

NOTE – The effect of = the wildcard match is that *.example.com will match a.example.com and = b.example.com but not a.b.example.com nor example.com.

 

Erik=

<= span lang=3DDA>Fra: pkix = [mailto:pkix-bounces@ietf.org] P=E5 vegne af Ben = Wilson
Sendt: 06 April 2017 18:24
Til: = pkix@ietf.org
Emne: [pkix] Amendment to CABF Baseline = Requirements

 

Does = anyone want to comment on my draft amendment to the CA/Browser = Forum’s Baseline Requirements for SSL/TLS Certificates which would = remove the 64-character limit on the commonName and = organizationName,  as an exception to RFC 5280?  The text of = the relevant Baseline Requirement provision is found below with the = proposed additional language in ALL CAPS.  The reason for the first = change (commonName) is there are FQDNs (in Subject Alternative Names) = that are longer than 64 characters.  The reason for the second = change (organizationName) is that there are organizations with names = longer than 64 characters.

 

7.1.4.2.2.        &n= bsp;    Subject Distinguished Name = Fields

a.         &nbs= p;  Certificate Field: subject:commonName (OID 2.5.4.3)  =

Required/Optional: Deprecated (Discouraged, but not = prohibited)

Contents: If present, this field MUST contain a single IP = address or Fully-Qualified Domain Name that is one of the values = contained in the Certificate’s subjectAltName extension (see = Section 7.1.4.2.1).

MAXIMUM LENGTH:  NO STIPULATION.  (THIS IS AN = EXCEPTION TO RFC 5280 WHICH SPECIFIES AN UPPER BOUND OF 64 = CHARACTERS.)

b.         &nbs= p;  Certificate Field: subject:organizationName (OID = 2.5.4.10)

Optional. 

Contents: If present, the subject:organizationName field = MUST contain either the Subject’s name or DBA as verified under = Section 3.2.2.2. The CA may include information in this field that = differs slightly from the verified name, such as common variations or = abbreviations, provided that the CA documents the difference and any = abbreviations used are locally accepted abbreviations; e.g., if the = official record shows “Company Name Incorporated”, the CA = MAY use “Company Name Inc.” or “Company = Name”.  Because Subject name attributes for individuals (e.g. = givenName (2.5.4.42) and surname (2.5.4.4)) are not broadly supported by = application software, the CA MAY use the subject:organizationName field = to convey a natural person Subject’s name or = DBA.

MAXIMUM LENGTH:  256 CHARACTERS (THIS IS AN EXCEPTION = TO RFC 5280 WHICH SPECIFIES AN UPPER BOUND OF 64 = CHARACTERS.)

 

Thanks,

Ben Wilson

------=_NextPart_000_0001_01D2B21D.BB9007E0-- From nobody Mon Apr 10 09:23:38 2017 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 C6A8A129562 for ; Mon, 10 Apr 2017 09:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmrT2cZtm1O8 for ; Mon, 10 Apr 2017 09:23:34 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E72129544 for ; Mon, 10 Apr 2017 09:23:34 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 00960B81749; Mon, 10 Apr 2017 09:23:30 -0700 (PDT) To: philliph@comodo.com, rob.stradling@comodo.com, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, kent@bbn.com, stefan@aaa-sec.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: phill@hallambaker.com, pkix@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170410162331.00960B81749@rfc-editor.org> Date: Mon, 10 Apr 2017 09:23:30 -0700 (PDT) Archived-At: Subject: [pkix] [Technical Errata Reported] RFC6844 (4992) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 16:23:37 -0000 The following errata report has been submitted for RFC6844, "DNS Certification Authority Authorization (CAA) Resource Record". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6844&eid=4992 -------------------------------------- Type: Technical Reported by: Phillip Hallam-Baker Section: 4 Original Text ------------- Let CAA(X) be the record set returned in response to performing a CAA record query on the label X, P(X) be the DNS label immediately above X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME alias record specified at the label X. o If CAA(X) is not empty, R(X) = CAA (X), otherwise o If A(X) is not null, and R(A(X)) is not empty, then R(X) = R(A(X)), otherwise o If X is not a top-level domain, then R(X) = R(P(X)), otherwise o R(X) is empty. Corrected Text -------------- Let CAA(X) be the record set returned in response to performing a CAA record query on the label X, P(X) be the DNS label immediately above X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME alias record chain specified at the label X. o If CAA(X) is not empty, R(X) = CAA (X), otherwise o If A(X) is not null, and CAA(A(X)), then R(X) = CAA(A(X)), otherwise o If X is not a top-level domain, then R(X) = R(P(X)), otherwise o R(X) is empty. Thus, when a search at node X returns a CNAME record, the CA will follow the CNAME record to its target. If the target label contains a CAA record, it is returned. otherwise, the CA continues the search at the parent of node X. Note that the search does not include the parent of a target of a CNAME record (except when the CNAME points back to its own path). If the target of a CNAME record is itself a CNAME record, the CA MAY follow it or MAY ignore it. In either case, the search continues at the parent of the label containing the initial CNAME. Processing for DNAME is exactly the same as for CNAME. Note that since DNAME records are implemented by creating the corresponding CNAME records on the fly, it is only necessary for DNAME records to appear on the wire for purposes of DNSSEC. Notes ----- This is a correction to Errata 4998 which is withdrawn. This is a fuller response to the issue raised in 4515. Note that the algorithm stated in RFC6844 was the algorithm intended at the time it was written. Subsequent implementation has shown that the approach described here is preferable. This is a breaking change and thus the intended disposition is Hold for Document Update. The principle purpose of this errata is to provide a stable reference for the benefit of CABForum which publishes certificate validation guidelines that mandate CAA. This in turn will avoid the need for work being proposed to provide a full solution to the problem to have to address backwards compatibility with an approach now seen as undesirable. The issue arises because CNAME records are commonly used for the purpose of host delegation and name delegation and no distinction is made between the two. Nor does the use of DNAME records allow such distinction be made in practice. Further, the limitation that CNAME be the only record in a zone is a liability. The original algorithm was designed to provide an administrative convenience for the name delegation case. Subsequent discussion with CDNs has shown that the host delegation use is sufficiently widespread for this approach to be unsatisfactory. After discussion in the LAMPS working group, a new approach is being considered which allows both sets of requirements to be met using an extended search algorithm. Until this is done, it is best that implementations do not perform the recursive portion. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6844 (draft-ietf-pkix-caa-15) -------------------------------------- Title : DNS Certification Authority Authorization (CAA) Resource Record Publication Date : January 2013 Author(s) : P. Hallam-Baker, R. Stradling Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From nobody Mon Apr 10 09:41:24 2017 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 61F90129566 for ; Mon, 10 Apr 2017 09:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qSokRGfcy6n for ; Mon, 10 Apr 2017 09:41:11 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2631296B3 for ; Mon, 10 Apr 2017 09:41:03 -0700 (PDT) From: Jeremy Rowley DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1491842464; bh=yhFcYE7HKUi1HzRTIwMXM63UWRTAQfvhtn8tLe+Emvc=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=i7k8fh5cjn+a4WgVd2XMX6OT5H31/dZEtm1mRbebtjKi08c5YEOLJ0GeT0hfaQ2DO RIGNU6fkeFisoSZPde5bXwIWyj5RO8eDUx4clQG6OBEcMsu9jNN/qkn1QuoeWpUPU1 vYsmr3FFSSl3rOjAJ/6g3jTJY/1yH74pf6+iRfns= To: Russ Housley , Erik Andersen CC: IETF PKIX Thread-Topic: [pkix] Amendment to CABF Baseline Requirements Thread-Index: AdKu7+4NHc0VCiezSMq6lazH8C48qgAOOMeAAAjFYFD//+OgAIAAFNUAgACxx4CAAOG/AIAAwtUAgACeIQD//VKmkA== Date: Mon, 10 Apr 2017 16:41:01 +0000 Message-ID: References: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> <27e9bc684735472bbd6d7f82b5e2823b@EX2.corp.digicert.com> <662C0D5C-EF34-4BD1-B3BC-B7B9A84B4990@vigilsec.com> <09BE38C5-7B5B-45B0-BC5F-5FCB1164F864@vigilsec.com> <000001d2b041$050c2310$0f246930$@x500.eu> <2D820AC4-81D0-44AC-BBE8-B8C74BD43BB0@vigilsec.com> In-Reply-To: <2D820AC4-81D0-44AC-BBE8-B8C74BD43BB0@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.137.52.7] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0085_01D2B1E6.F225E590" MIME-Version: 1.0 Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 16:41:23 -0000 ------=_NextPart_000_0085_01D2B1E6.F225E590 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0086_01D2B1E6.F225E590" ------=_NextPart_001_0086_01D2B1E6.F225E590 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Russ - Considering the CA/Browser Forum rules only applies to browser = user agents, are you aware of any actual interoperability issues? =20 From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Russ Housley Sent: Saturday, April 8, 2017 11:47 AM To: Erik Andersen Cc: IETF PKIX Subject: Re: [pkix] Amendment to CABF Baseline Requirements =20 Erik: =20 The CA/Browser Forum seems to be finding the upper bounds in the X.500 = 5th edition and RFC 5280. I=E2=80=99m not sure how to relax them = without introducing interoperability concerns. =20 Russ =20 =20 On Apr 8, 2017, at 4:20 AM, Erik Andersen > wrote: =20 The change was made in the sixth edition of X.520 (2008). It was = primarily driven by Hoyt Kesterson and by some X.500/LDAP vendors. Hoyt = was generally against such limitations, as the future is difficult to = predict. X.500/LDAP vendors were concerned about interworking between = X.500 and LDAP (that does not have upper bounds). You may have noticed = that ASN.1 information objects now also contains LDAP specific fields = allowing also new attribute types to be usable also in an LDAP = environment without the need for additional specifications. =20 I insisted that the upper bounds should be kept in an informative annex = to be used by those having a requirement to limit the sizes. =20 I could, if you feel it relevant, try to suggest a Defect Report to = X.509 saying that it is strongly recommend to observe the upper bounds = specified in X.520. I will also try to get such a statement into any = smart grid security standard that references X.509. =20 Erik Fra: pkix [ mailto:pkix-bounces@ietf.org] = P=C3=A5 vegne af Russ Housley Sendt: 07 April 2017 22:43 Til: IETF PKIX < pkix@ietf.org> Emne: Re: [pkix] Amendment to CABF Baseline Requirements =20 The ASN.1 modules that were posted by Erik confirm that the upper bounds = have been removed for all of the naming attributes in the = SelectedAttributeTypes module. =20 UnboundedDirectoryString ::=3D CHOICE { teletexString TeletexString(SIZE (1..MAX)), printableString PrintableString(SIZE (1..MAX)), bmpString BMPString(SIZE (1..MAX)), universalString UniversalString(SIZE (1..MAX)), uTF8String UTF8String(SIZE (1..MAX)) } =20 Russ =20 =20 On Apr 7, 2017, at 3:15 AM, Erwann Abalea < = eabalea@gmail.com> wrote: =20 Bonjour, =20 2017-04-06 22:39 GMT+02:00 Peter Bowen < = pzbowen@gmail.com>: =20 On Thu, Apr 6, 2017 at 12:24 PM Russ Housley < = housley@vigilsec.com> wrote: The comment in the UpperBounds ASN.1 module (the 8th edition) says: -- EXPORTS All -- The types and values defined in this module are exported for use in = the other ASN.1 -- modules contained within these Directory Specifications, and for the = use of other -- applications which will use them to access Directory services. Other = applications -- may use them for their own purposes, but this will not constrain = extensions and -- modifications needed to maintain or improve the Directory service. X.509 is part of the Directory Specifications, so they are not advisory. It looks like ITU-T increased the length of the organizational unit name = in the most recent edition. RFC 5280 says: ub-organization-name-length INTEGER ::=3D 64 ub-organizational-unit-name-length INTEGER ::=3D 32 The UpperBounds ASN.1 module (the 8th edition) says: ub-organization-name INTEGER ::=3D 64 ub-organizational-unit-name INTEGER ::=3D 64 So, we may already be in a place where implementations conforming to = X.509 will produce a certificate that cannot be decoded by an = implementation that conforms to RFC 5280. I wish we gad gotten a heads-up =E2=80=A6 =20 It is even worse. 7th and 8th (and maybe prior releases) removed the = usage of ub- from the schema. The schema itself no longer bounds = DirectoryStrings and X.509 explicitly says they are unbounded.=20 =20 X.520 2005 defines the attributes using the DirectoryString{} = parameterized type, while the 2008 edition uses the = UnboundedDirectoryString type. =20 RFC5912, which proposes ASN.1 modules for certificates and other related = things, still uses the DirectoryString{} variant. =20 --=20 Erwann. =20 _______________________________________________ pkix mailing list pkix@ietf.org = https://www.ietf.org/mailman/listinfo/pkix =20 ------=_NextPart_001_0086_01D2B1E6.F225E590 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Russ - = Considering the CA/Browser Forum rules only applies to browser user = agents, are you aware of any actual interoperability = issues?

 

From:<= /b> = pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Russ = Housley
Sent: Saturday, April 8, 2017 11:47 AM
To: = Erik Andersen <era@x500.eu>
Cc: IETF PKIX = <pkix@ietf.org>
Subject: Re: [pkix] Amendment to CABF = Baseline Requirements

 

Erik:

 

The CA/Browser Forum seems to be finding the upper = bounds in the X.500 5th edition and RFC 5280.  I=E2=80=99m not sure = how to relax them without introducing interoperability = concerns.

 

Russ

 

 

On Apr 8, 2017, at 4:20 AM, Erik Andersen <era@x500.eu> = wrote:

 

The change was made in the sixth edition of X.520 (2008). It was = primarily driven by Hoyt Kesterson and by some X.500/LDAP vendors. Hoyt = was generally against such limitations, as the future is difficult to = predict. X.500/LDAP vendors were concerned about interworking between = X.500 and LDAP (that does not have upper bounds). You may have noticed = that ASN.1 information objects now also contains LDAP specific fields = allowing also new attribute types to be usable also in an LDAP = environment without the need for additional = specifications.

 

I insisted that the upper bounds should be kept in an informative annex = to be used by those having a requirement to limit the = sizes.

 

I could, if you feel it relevant, try to suggest a Defect Report to = X.509 saying that it is strongly recommend to observe the upper bounds = specified in X.520. I will also try to get such a statement into any = smart grid security standard that references = X.509.

 

Erik

Fra: = pkix [mailto:pkix-bounces@ietf.org] P=C3=A5 vegne af Russ = Housley
Sendt: 07 April 2017 = 22:43
Til: IETF PKIX <pkix@ietf.org>
Emne: Re: [pkix] Amendment to CABF = Baseline Requirements

 

The ASN.1 modules that were posted by Erik confirm = that the upper bounds have been removed for all of the naming attributes = in the SelectedAttributeTypes module.

 

UnboundedDirectoryString ::=3D CHOICE = {

  = teletexString    TeletexString(SIZE = (1..MAX)),

  printableString  PrintableString(SIZE = (1..MAX)),

  bmpString       =  BMPString(SIZE (1..MAX)),

  universalString  UniversalString(SIZE = (1..MAX)),

  uTF8String       UTF8String(SIZE = (1..MAX)) }

 

Russ

 

 

On Apr 7, 2017, at 3:15 AM, Erwann Abalea <eabalea@gmail.com> = wrote:

 

Bonjour,

 

2017-04-06 22:39 GMT+02:00 Peter Bowen <pzbowen@gmail.com>:

 

On Thu, Apr 6, 2017 at 12:24 PM Russ Housley <housley@vigilsec.com> = wrote:

The comment in the UpperBounds ASN.1 = module (the 8th edition) says:

-- EXPORTS All
-- The types and = values defined in this module are exported for use in the other = ASN.1
-- modules contained within these Directory Specifications, and = for the use of other
-- applications which will use them to access = Directory services. Other applications
-- may use them for their own = purposes, but this will not constrain extensions and
-- modifications = needed to maintain or improve the Directory service.

X.509 is = part of the Directory Specifications, so they are not = advisory.

It looks like ITU-T increased the length of the = organizational unit name in the most recent edition.

RFC 5280 = says:

ub-organization-name-length INTEGER ::=3D = 64
ub-organizational-unit-name-length INTEGER ::=3D 32

The = UpperBounds ASN.1 module (the 8th edition) = says:

ub-organization-name          =              INTEGER ::=3D = 64
ub-organizational-unit-name          =       INTEGER ::=3D 64

So, we may already be in a = place where implementations conforming to X.509 will produce a = certificate that cannot be decoded by an implementation that conforms to = RFC 5280.

I wish we gad gotten a heads-up = =E2=80=A6

 

It is even worse. 7th and 8th (and maybe prior = releases) removed the usage of ub- from the schema. The schema itself no = longer bounds DirectoryStrings and X.509 explicitly says they are = unbounded. 

=

 

X.520 2005 defines the attributes using the = DirectoryString{} parameterized type, while the 2008 edition uses the = UnboundedDirectoryString type.

 

RFC5912, which proposes ASN.1 modules for certificates = and other related things, still uses the DirectoryString{} = variant.

 

-- 

Erwann.

 

____________= ___________________________________
pkix mailing list
pkix@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/pkix">https://www.ietf.org/mailman/listinfo/pkix

 

------=_NextPart_001_0086_01D2B1E6.F225E590-- ------=_NextPart_000_0085_01D2B1E6.F225E590 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8 inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf /K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF 5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093 pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1 vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDEwMTY0MTAxWjAj BgkqhkiG9w0BCQQxFgQUduORBGHixwXcdMyAXxGRg0AykCMwgYgGCSsGAQQBgjcQBDF7MHkwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK 2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAD6kQHE8eE9D5fkXS4MK+Ew9stASk9gDioK14BKC gNZZdhmaAz7busOOfBpu5Xt1CTDE/YXLa/qLx6kbav8NrUqMdv63ZSg/vie/DR6T8EFk8MRAtZoy U9f+XCwWkq6UMFAJ+ak2yaLQ5v7e98NFTsKIDfoRMgwSEr4SsuHI68DNYb88/ANgnmwANiqhly+5 PrLUI19102rBfXp7t2BxoD+bZkD/mq2lQDgiFqaIZMn0qsunfEO4asqmEl8Uezv05OTljsrNUje9 rj3iOCxvg31MhNelYAyDtnsWlqozFrxwj5rMBuEnMPH7GvVAb6KsqU3WlXQdz8KeCuzi4LUpR4oA AAAAAAA= ------=_NextPart_000_0085_01D2B1E6.F225E590-- From nobody Mon Apr 10 09:54:53 2017 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 A3518129A92 for ; Mon, 10 Apr 2017 09:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HM0W4jSHbSrm for ; Mon, 10 Apr 2017 09:54:47 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5FD2129562 for ; Mon, 10 Apr 2017 09:54:45 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id m36so8702202qtb.0 for ; Mon, 10 Apr 2017 09:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zW2+G2b9yUVPk33xPg2wh5RPa2btZ9Qhnyug3g7uNMo=; b=VGVz9ZSnRbnuFFSwPpFykzkAM5IkQ4BL0r6JOIXOs+NFiEX9+AEAUzHzHI4C6Kf4UA IOLM/u91g9a+mzkGvGu6e5YwWHmbTEN1TzIf806Qd2tLcGCu7bYBBph1oAC9Z1g1mlHC jcw1WBjsXLDHXiIGacOP60vQpnBjnL4W3duxY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zW2+G2b9yUVPk33xPg2wh5RPa2btZ9Qhnyug3g7uNMo=; b=fS//aVeMPeh6maLVxoYK4v2rI3Cn28dShAI1d2YhbQu4hMq6A4NOIePFXuEKnITwrB Pp7fnaZXzt+sQBhEtr22/pzo5iMLfGZY9qo8VBhRKB7q5gE459OahBQ3FUQsfrxlxgBI CQdfo/3KZqfwV9YBGMz/WAJme8kCQOKm7DQ6+S/WRfEr52Hm0BMRRUYzlUVEKvZ37h9w aYhQ90ojC5dBu7Cf0lXb5xuFdWP/oAxQQbJsPjXMIJIeZKwF+/oi1J9489grStw0OURH S4pL9BVaq6jeI5QrhpkpmexC0h/O5SvuHez+6if2BUWtXziz7RCUH9QjJAKK7CAMIg8t xdVw== X-Gm-Message-State: AFeK/H3clUeKpNgFEDztnfiKK8QIFY/rSwoGAW1EQPKyk6qGT5vYKkTvkSaMKT+cbfCn/Q== X-Received: by 10.200.44.100 with SMTP id e33mr55352464qta.192.1491843284654; Mon, 10 Apr 2017 09:54:44 -0700 (PDT) Received: from ?IPv6:2600:1000:b020:5545:8d3d:deb4:3c8c:18c8? ([2600:1000:b020:5545:8d3d:deb4:3c8c:18c8]) by smtp.gmail.com with ESMTPSA id 1sm4073485qtm.59.2017.04.10.09.54.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Apr 2017 09:54:44 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-6899419B-D201-4DF0-A624-5D0FE8C2E525 Mime-Version: 1.0 (1.0) From: Carl Wallace X-Mailer: iPhone Mail (14B100) In-Reply-To: Date: Mon, 10 Apr 2017 12:54:43 -0400 Cc: Russ Housley , Erik Andersen , IETF PKIX Content-Transfer-Encoding: 7bit Message-Id: <57D53EAF-A9BF-4916-9D0A-5A7B20CB24AB@redhoundsoftware.com> References: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> <27e9bc684735472bbd6d7f82b5e2823b@EX2.corp.digicert.com> <662C0D5C-EF34-4BD1-B3BC-B7B9A84B4990@vigilsec.com> <09BE38C5-7B5B-45B0-BC5F-5FCB1164F864@vigilsec.com> <000001d2b041$050c2310$0f246930$@x500.eu> <2D820AC4-81D0-44AC-BBE8-B8C74BD43BB0@vigilsec.com> To: Jeremy Rowley Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 16:54:51 -0000 --Apple-Mail-6899419B-D201-4DF0-A624-5D0FE8C2E525 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Is mutual auth (even server to server) of no concern? > On Apr 10, 2017, at 12:41 PM, Jeremy Rowley w= rote: >=20 > Hi Russ - Considering the CA/Browser Forum rules only applies to browser u= ser agents, are you aware of any actual interoperability issues? > =20 > From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Russ Housley > Sent: Saturday, April 8, 2017 11:47 AM > To: Erik Andersen > Cc: IETF PKIX > Subject: Re: [pkix] Amendment to CABF Baseline Requirements > =20 > Erik: > =20 > The CA/Browser Forum seems to be finding the upper bounds in the X.500 5th= edition and RFC 5280. I=E2=80=99m not sure how to relax them without intro= ducing interoperability concerns. > =20 > Russ > =20 > =20 > On Apr 8, 2017, at 4:20 AM, Erik Andersen wrote: > =20 > The change was made in the sixth edition of X.520 (2008). It was primarily= driven by Hoyt Kesterson and by some X.500/LDAP vendors. Hoyt was generally= against such limitations, as the future is difficult to predict. X.500/LDAP= vendors were concerned about interworking between X.500 and LDAP (that does= not have upper bounds). You may have noticed that ASN.1 information objects= now also contains LDAP specific fields allowing also new attribute types to= be usable also in an LDAP environment without the need for additional speci= fications. > =20 > I insisted that the upper bounds should be kept in an informative annex to= be used by those having a requirement to limit the sizes. > =20 > I could, if you feel it relevant, try to suggest a Defect Report to X.509 s= aying that it is strongly recommend to observe the upper bounds specified in= X.520. I will also try to get such a statement into any smart grid security= standard that references X.509. > =20 > Erik > Fra: pkix [mailto:pkix-bounces@ietf.org] P=C3=A5 vegne af Russ Housley > Sendt: 07 April 2017 22:43 > Til: IETF PKIX > Emne: Re: [pkix] Amendment to CABF Baseline Requirements > =20 > The ASN.1 modules that were posted by Erik confirm that the upper bounds h= ave been removed for all of the naming attributes in the SelectedAttributeTy= pes module. > =20 > UnboundedDirectoryString ::=3D CHOICE { > teletexString TeletexString(SIZE (1..MAX)), > printableString PrintableString(SIZE (1..MAX)), > bmpString BMPString(SIZE (1..MAX)), > universalString UniversalString(SIZE (1..MAX)), > uTF8String UTF8String(SIZE (1..MAX)) } > =20 > Russ > =20 > =20 > On Apr 7, 2017, at 3:15 AM, Erwann Abalea wrote: > =20 > Bonjour, > =20 > 2017-04-06 22:39 GMT+02:00 Peter Bowen : > =20 > On Thu, Apr 6, 2017 at 12:24 PM Russ Housley wrote:= > The comment in the UpperBounds ASN.1 module (the 8th edition) says: >=20 > -- EXPORTS All > -- The types and values defined in this module are exported for use in the= other ASN.1 > -- modules contained within these Directory Specifications, and for the us= e of other > -- applications which will use them to access Directory services. Other ap= plications > -- may use them for their own purposes, but this will not constrain extens= ions and > -- modifications needed to maintain or improve the Directory service. >=20 > X.509 is part of the Directory Specifications, so they are not advisory. >=20 > It looks like ITU-T increased the length of the organizational unit name i= n the most recent edition. >=20 > RFC 5280 says: >=20 > ub-organization-name-length INTEGER ::=3D 64 > ub-organizational-unit-name-length INTEGER ::=3D 32 >=20 > The UpperBounds ASN.1 module (the 8th edition) says: >=20 > ub-organization-name INTEGER ::=3D 64 > ub-organizational-unit-name INTEGER ::=3D 64 >=20 > So, we may already be in a place where implementations conforming to X.509= will produce a certificate that cannot be decoded by an implementation that= conforms to RFC 5280. >=20 > I wish we gad gotten a heads-up =E2=80=A6 > =20 > It is even worse. 7th and 8th (and maybe prior releases) removed the usage= of ub- from the schema. The schema itself no longer bounds DirectoryStrings= and X.509 explicitly says they are unbounded.=20 > =20 > X.520 2005 defines the attributes using the DirectoryString{} parameterize= d type, while the 2008 edition uses the UnboundedDirectoryString type. > =20 > RFC5912, which proposes ASN.1 modules for certificates and other related t= hings, still uses the DirectoryString{} variant. > =20 > --=20 > Erwann. > =20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > =20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail-6899419B-D201-4DF0-A624-5D0FE8C2E525 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Is mutual auth (even server= to server) of no concern?

On Apr 10, 2017, at 12:41 PM, Jerem= y Rowley <jeremy.rowley@dig= icert.com> wrote:

Hi Russ - Considering the CA/Browser Forum rules only applies to br= owser user agents, are you aware of any actual interoperability issues?=

&nb= sp;

=

From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of <= /b>Russ Housley
Sent: Saturday, April 8, 2017 11:47 AM
To: Erik Andersen <era@x500.eu>
<= b>Cc: IETF PKIX <pkix@ietf.org&g= t;
Subject: Re: [pkix] Amendment to CABF Baseline Requirements

 

Erik:

&n= bsp;

The CA/Browser Forum seems t= o be finding the upper bounds in the X.500 5th edition and RFC 5280.  I= =E2=80=99m not sure how to relax them without introducing interoperability c= oncerns.

 

Russ

 

&nbs= p;

=

On Apr 8, 2017, at 4:20 AM, Erik Andersen <era@x500.eu> wrote:

=

 

The change was made in the sixth edition of X.520 (2008). It w= as primarily driven by Hoyt Kesterson and by some X.500/LDAP vendors. Hoyt w= as generally against such limitations, as the future is difficult to predict= . X.500/LDAP vendors were concerned about interworking between X.500 and LDA= P (that does not have upper bounds). You may have noticed that ASN.1 informa= tion objects now also contains LDAP specific fields allowing also new attrib= ute types to be usable also in an LDAP environment without the need for addi= tional specifications.

 

I insisted that the upper bounds should be kept in an inform= ative annex to be used by those having a requirement to limit the sizes.

 

I could, i= f you feel it relevant, try to suggest a Defect Report to X.509 saying that i= t is strongly recommend to observe the upper bounds specified in X.520. I wi= ll also try to get such a statement into any smart grid security standard th= at references X.509.

=  

= Erik

Fra: pkix [mailto:pkix-bounces@ietf.org] P=C3=A5 vegne af Russ Housley
Sendt: 07 April 2017 22:43
Til: IETF PKIX <pkix@ietf.org>
Emne= : Re: [pkix] Amendment= to CABF Baseline Requirements

<= p class=3D"MsoNormal"> 

The ASN.1 modules that were posted by Erik confirm that the upper bounds ha= ve been removed for all of the naming attributes in the SelectedAttributeTyp= es module.

 <= /o:p>

UnboundedDirector= yString ::=3D CHOICE {

  teletexString    TeletexString(SIZE (1..MAX)),

  printableString &= nbsp;PrintableString(SIZE (1..MAX)),

  bmpString        BMPString(SIZ= E (1..MAX)),

&nbs= p; universalString  UniversalString(SIZE (1..MAX)),

  uTF8String     &nbs= p; UTF8String(SIZE (1..MAX)) }

 

Russ

&nb= sp;

 

On Apr 7, 2017, at 3:15 AM, Erwann Abalea= <eabal= ea@gmail.com> wrote:

 

Bonjour,

 

2017-04-06 22:39 GMT+02:= 00 Peter Bowen <pzbowen@gmail.com>:

<= /div>

 

On Thu, Apr 6, 2017 at 12:24 PM Russ H= ousley <housley@vigilsec.com> wrote:<= /p>

The comment in the Up= perBounds ASN.1 module (the 8th edition) says:

-- EXPORTS All
-- T= he types and values defined in this module are exported for use in the other= ASN.1
-- modules contained within these Directory Specifications, and fo= r the use of other
-- applications which will use them to access Director= y services. Other applications
-- may use them for their own purposes, bu= t this will not constrain extensions and
-- modifications needed to maint= ain or improve the Directory service.

X.509 is part of the Directory S= pecifications, so they are not advisory.

It looks like ITU-T increase= d the length of the organizational unit name in the most recent edition.
=
RFC 5280 says:

ub-organization-name-length INTEGER ::=3D 64
ub= -organizational-unit-name-length INTEGER ::=3D 32

The UpperBounds ASN= .1 module (the 8th edition) says:

ub-organization-name    &= nbsp;                  INTEGER := :=3D 64
ub-organizational-unit-name          &nb= sp;     INTEGER ::=3D 64

So, we may already be in a place w= here implementations conforming to X.509 will produce a certificate that can= not be decoded by an implementation that conforms to RFC 5280.

I wish= we gad gotten a heads-up =E2=80=A6

 

It is even worse. 7th and 8th (and maybe prior releases) rem= oved the usage of ub- from the schema. The schema itself no longer bounds Di= rectoryStrings and X.509 explicitly says they are unbounded. 

&= nbsp;

X.520 2005 d= efines the attributes using the DirectoryString{} parameterized type, while t= he 2008 edition uses the UnboundedDirectoryString type.

=

 

RFC5912, which proposes ASN.1 modules for certi= ficates and other related things, still uses the DirectoryString{} variant.<= o:p>

 =

-- 

Erwann.

=

 

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

 

_______= ________________________________________
pkix mailing list
pkix@ietf.org
= https://www.iet= f.org/mailman/listinfo/pkix
= --Apple-Mail-6899419B-D201-4DF0-A624-5D0FE8C2E525-- From nobody Mon Apr 10 10:55:11 2017 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 60EAC12947E for ; Mon, 10 Apr 2017 10:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=texastechuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2d5Dv8mMvEz for ; Mon, 10 Apr 2017 10:55:06 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0176.outbound.protection.outlook.com [216.32.180.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B53A128BB6 for ; Mon, 10 Apr 2017 10:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=TexasTechUniversity.onmicrosoft.com; s=selector1-ttu-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Hm9patq0ZFAFccacMMvAwlg+pDXN+uZgJgjQMu2hH9I=; b=UinegdPwpioN3TPuReSep9kmtA3C3C2G6KV89rj8OND+dI1aNqu9t+EqVPECMLxXqLV63obVuNQAWn0Hh35EE1TIYo8hg2bHkE+ewQOS9EhRmDgePTfMiAJcm2J+zf8/m0e6BTaxL+V3uEU3847Uwxof1ItEKv/EO0VBkCxHK3Y= Received: from CO2PR06MB891.namprd06.prod.outlook.com (10.141.227.16) by CO2PR06MB889.namprd06.prod.outlook.com (10.141.227.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Mon, 10 Apr 2017 17:55:04 +0000 Received: from CO2PR06MB891.namprd06.prod.outlook.com ([10.141.227.16]) by CO2PR06MB891.namprd06.prod.outlook.com ([10.141.227.16]) with mapi id 15.01.1005.025; Mon, 10 Apr 2017 17:55:03 +0000 From: "Sill, Alan" To: Erik Andersen CC: "Sill, Alan" , "pkix@ietf.org" Thread-Topic: [pkix] Amendment to CABF Baseline Requirements Thread-Index: AdKu7+4NHc0VCiezSMq6lazH8C48qgDHQmGAAAWnDQA= Date: Mon, 10 Apr 2017 17:55:03 +0000 Message-ID: <5408AFDF-D15A-4B5B-842B-1BC533D1DF58@ttu.edu> References: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> <000001d2b20c$f8031930$e8094b90$@x500.eu> In-Reply-To: <000001d2b20c$f8031930$e8094b90$@x500.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: x500.eu; dkim=none (message not signed) header.d=none;x500.eu; dmarc=none action=none header.from=ttu.edu; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.118.91.83] x-microsoft-exchange-diagnostics: 1; CO2PR06MB889; 7:2Kgioy/hipaSxj1a05RZl/UC35js4SUYPwyudRHn44z9u9SD9ufOdPRE69jn5Hoiv2gMzvkkP4bJ9IbOboRHAf0BTwbmG6vGqEtHz+8XxqIA+lD452PSDI4YtA0y2FT1SXvY7eN7u3K806NUDleoDRN49CKd0SfbnHbkzmJh3B8pev9qMSecZPJd0ZMh5Rxy0esI0zPlSlmRRChlViJJ7oLtRbLj0wCJpMf2F55BsDxEG8qwmd9xsOE0R1UQQDPfR7nZHbrIsgo7D7wEoPcleWpS2bw6Qb+lQpLOOAzC9yw9AIseRAFGBpoUP23dU63mU47ohtwrnvAtFfCqBiqW9w== x-ms-office365-filtering-correlation-id: ea324d37-c9e6-4d2a-3340-08d4803ab75d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CO2PR06MB889; x-techmail-edge-route: EOP x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(10322497157591); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123562025)(6072148); SRVR:CO2PR06MB889; BCL:0; PCL:0; RULEID:; SRVR:CO2PR06MB889; x-forefront-prvs: 027367F73D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39850400002)(39400400002)(39410400002)(39840400002)(377454003)(24454002)(8676002)(50986999)(81166006)(6246003)(76176999)(54356999)(75432002)(2900100001)(99286003)(236005)(54906002)(6512007)(6306002)(189998001)(5660300001)(77096006)(6506006)(6486002)(6436002)(229853002)(53936002)(33656002)(2906002)(102836003)(6116002)(3846002)(25786009)(38730400002)(6916009)(53376002)(110136004)(2950100002)(122556002)(36756003)(7736002)(3280700002)(88552002)(4326008)(3660700001)(66066001)(86362001)(8936002)(7906003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR06MB889; H:CO2PR06MB891.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_5408AFDFD15A4B5B842B1BC533D1DF58ttuedu_" MIME-Version: 1.0 X-OriginatorOrg: ttu.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2017 17:55:03.6857 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 178a51bf-8b20-49ff-b655-56245d5c173c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR06MB889 Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 17:55:10 -0000 --_000_5408AFDFD15A4B5B842B1BC533D1DF58ttuedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJpaywNCg0KQmVmb3JlIHByb2NlZWRpbmcgd2l0aCBhbnkgYXR0ZW1wdCB0byBkZXByZWNhdGUg dGhlIHVzZSBvZiBjb21tb25OYW1lLCBtYXkgSSByZWNvbW1lbmQgdGhhdCB5b3UgcmVhZCB0aGUg Y29udGVudHMgb2YgdGhlIE9HRuKAmXMg4oCcSW50ZXJvcGVyYWJsZSBDZXJ0aWZpY2F0ZSBQcm9m aWxl4oCdIHRoYXQgZm9jdXNlcyBvbiBub24tYnJvd3NlciBhcHBsaWNhdGlvbnMgb2YgdXNlIG9m IGRpcmVjdG9yeSBuYW1lcywgYXR0cmlidXRlcywgYW5kIGV4dGVuc2lvbnMgaW4gWC41MDkgY2Vy dGlmaWNhdGVzLCBzdWNoIHRoYXQgdGhleSBhcmUgdXNhYmxlIGJ5IHRoZSBtYWpvcml0eSBvZiBz Y2llbnRpZmljIGN5YmVyLWluZnJhc3RydWN0dXJlcyBhcyBzdXBwb3J0ZWQgYnkgdGhlIElHVEY/ DQoNClRoaXMgZG9jdW1lbnQgaXMgYXZhaWxhYmxlIGluIGl0cyBtb3N0IHJlY2VudCBmb3JtIGF0 IGh0dHBzOi8vd3d3Lm9nZi5vcmcvZG9jdW1lbnRzL2dmZC4yMjUucGRmDQoNCkluIHBhcnRpY3Vs YXIsIGNvbW1vbk5hbWUgaXMgYSByZXF1aXJlZCBjb21wb25lbnQgb2YgY2VydGlmaWNhdGVzIHVz ZWQgaW4gc3VjaCBpbmZyYXN0cnVjdHVyZXMgYW5kIGRlcHJlY2F0aW9uIHdvdWxkIGNhdXNlIGEg Z3JlYXQgZGVhbCBvZiBkYW1hZ2UgdG8gZGVwbG95ZWQgaW5mcmFzdHJ1Y3R1cmVzIGZvciBsYXJn ZS1zY2FsZSBncmlkIGFuZCBjbG91ZCBjb21wdXRpbmcuDQoNClRoYW5rcywNCkFsYQ0KDQoNCk9u IEFwciAxMCwgMjAxNywgYXQgMTA6MTMgQU0sIEVyaWsgQW5kZXJzZW4gPGVyYUB4NTAwLmV1PG1h aWx0bzplcmFAeDUwMC5ldT4+IHdyb3RlOg0KDQpIaSBCZW4gYW5kIG90aGVycywNCkkgcmVzcG9u ZGVkIHRvIHRoZSB1cHBlciBib3VuZCBpc3N1ZSBiZWZvcmUgcmVhZGluZyBCZW7igJlzIHF1ZXN0 aW9uLiBJIGhhdmUgYSBjb21tZW50IG5vdCByZWxhdGVkIHRvIHRoZSBjb21tb25OYW1lIGF0dHJp YnV0ZSB0eXBlLiBUaGUgY29tbW9uTmFtZSBpcyBiZWluZyAobWlzKXVzZWQgZm9yIGFsbCBraW5k IG9mIHRoaW5ncywgc28geW91IGNhbm5vdCBrbm93IHdoYXQgdGhlIHN5bnRheCByZWFsbHkgaXMs IHdoaWNoIHNob3VsZCBjYXVzZSBpbnRlcndvcmtpbmcgcHJvYmxlbXMuIFRoZSB1c2Ugb2YgY29t bW9uTmFtZSBzaG91bGQgcG9zc2libHkgYmUgZGVwcmVjYXRlZC4NCkFzIHRvIHVzZSB0aGUgY29t bW9uTmFtZSBmb3IgaG9sZGluZyBhbiBGUUROLCBpdCBpcyBhIGxpdHRsZSBwcm9ibGVtYXRpYy4g VGhlIG1hdGNoaW5nIHJ1bGUgZm9yIEZRRE5zIGlzIGEgbGl0dGxlIG1vcmUgY29tcGxpY2F0ZWQg dGhhbiB0aGUgb25lIGZvciBjb21tb25OYW1lLiBYLjUyMCBoYXMgYSBkc25OYW1lIGF0dHJpYnV0 ZSB0eXBlIGFuZCBhcyBpdCBpcyByYXRoZXIgbmV3IGl0IGhhcyBub3QgdXBwZXIgYm91bmQgc3Bl Y2lmaWNhdGlvbi4gSXQgaXMgZGVmaW5lZCBhczoNCjYuMi4xNSAgICAgIERvbWFpbiBuYW1lDQpB IHZhbHVlIG9mIGF0dHJpYnV0ZSB0eXBlIGRuc05hbWUgaXMgdXNlZCBmb3IgaG9sZGluZyBhIERO UyBkb21haW4gbmFtZSwgd2hpY2ggbWF5IGJlIGFuIGludGVybmF0aW9uYWxpemVkIGRvbWFpbiBu YW1lIChJRE4pLg0KDQpkbnNOYW1lIEFUVFJJQlVURSA6Oj0gew0KICBXSVRIIFNZTlRBWCAgICAg ICAgICAgICBEb21haW5OYW1lDQogIEVRVUFMSVRZIE1BVENISU5HIFJVTEUgIGRuc05hbWVNYXRj aA0KICBMREFQLVNZTlRBWCAgICAgICAgICAgICBkbnNTdHJpbmcuJmlkDQogIExEQVAtTkFNRSAg ICAgICAgICAgICAgIHsiRE5TIG5hbWUifQ0KICBJRCAgICAgICAgICAgICAgICAgICAgICBpZC1h dC1kbnNOYW1lIH0NCg0KRG9tYWluTmFtZSA6Oj0gVVRGOFN0cmluZyAoQ09OU1RSQUlORUQgQlkg eyAtLSBDb25mb3JtcyB0byB0aGUgZm9ybWF0IG9mIGEgKGludGVybmF0aW9uYWxpemVkKSBkb21h aW4gbmFtZS4gLS0gfSkNCkEgdmFsdWUgb2YgdGhlIERvbWFpbk5hbWUgZGF0YSB0eXBlIHNoYWxs IGJlIGluIHRoZSBzeW50YXgsIGFzIHNwZWNpZmllZCBieSBzZWN0aW9uIDIuMy4xIG9mIElFVEYg UkZDIDU4OTAgbWVhbmluZyB0aGF0IGEgZG9tYWluIG5hbWUgaXMgYSBzZXF1ZW5jZSBvZiBsYWJl bHMgaW4gdGhlIGxldHRlcnMsIGRpZ2l0cywgaHlwaGVuIChMREgpIGZvcm1hdCBzZXBhcmF0ZWQg YnkgZG90cy4NCkEgbGFiZWwgbWF5IGJlIGluIHRocmVlIGZvcm1hdHM6DQoNCmEpICAgICBBbGwg Y2hhcmFjdGVycyBpbiB0aGUgbGFiZWwgYXJlIGZyb20gdGhlIEJhc2ljIExhdGluIGNvbGxlY3Rp b24gYXMgZGVmaW5lZCBieSBJU08vSUVDIDEwNjQ2IChpLmUuLCBoYXZpbmcgY29kZSBwb2ludHMg aW4gdGhlIHJhbmdlcyAwMDJELCAwMDMwLTAwMzksIDAwNDEtMDA1QSBhbmQgMDA2MS0wMDdBKSBh bmQgaXQgZG9lcyBub3Qgc3RhcnQgd2l0aCAieG4tLSIuIFRoZSBtYXhpbXVtIGxlbmd0aCBpcyA2 MyBvY3RldHMuDQoNCmIpICAgICBJdCBpcyBhbiBBLWxhYmVsIGFzIGRlZmluZWQgaW4gSUVURiBS RkMgNTg5MCwgaS5lLiwgaXQgc3RhcnRzIHdpdGggdGhlICJ4bi0tIiBhbmQgaXMgYSBVLWxhYmVs IGNvbnZlcnRlZCB0byB2YWxpZCBBU0NJSSBjaGFyYWN0ZXJzIGFzIGluIGl0ZW0gYSkgdXNpbmcg dGhlIFB1bnljb2RlIGFsZ29yaXRobSBkZWZpbmVkIGJ5IElFVEYgUkZDIDM0OTIuIFRoZSBjb252 ZXJ0ZWQgc3RyaW5nIHNoYWxsIGJlIG1heGltdW0gNTkgb2N0ZXRzLiBUbyBiZSB2YWxpZCwgaXQg c2hhbGwgYmUgcG9zc2libGUgZm9yIGFuIEEtbGFiZWwgdG8gYmUgY29udmVydGVkIHRvIGEgdmFs aWQgVS1sYWJlbC4NCg0KTk9URSAxIOKAkyBBbiBBLWxhYmVsIGlzIG5vcm1hbGx5IG5vdCBodW1h biByZWFkYWJsZS4NCg0KYykgICAgIEl0IGlzIGEgVS1sYWJlbCBhcyBkZWZpbmVkIGluIElFVEYg UkZDIDU4OTAsIGkuZS4sIGl0IGNvbnRhaW5zIGNoYXJhY3RlcnMgb3V0c2lkZSB0aGUgQmFzaWMg TGF0aW4gY29sbGVjdGlvbi4gQSB2YWxpZCBVLWxhYmVsIHNoYWxsIG5vdCBpbmNsdWRlIGFueSBj aGFyYWN0ZXJzIHRoYXQgYXJlIG5vdCBpbmNsdWRlZCBpbiB0aGUgcmVzdHJpY3RlZCBVbmljb2Rl IHJlcGVydG9pcmUgYXMgZGVmaW5lZCBieSBJRVRGIFJGQyA1ODkyIGFuZCBpdCBzaGFsbCBiZSBj b252ZXJ0aWJsZSB0byBhIHZhbGlkIEEtbGFiZWwgYXMgZGVmaW5lZCBpbiBpdGVtIGIpLiBBIHZh bGlkIFUtbGFiZWwgbWF5IGJlIG1vcmUgdGhhbiA2MyBvY3RldHMuDQoNCk5PVEUgMiDigJMgSW4g YSBjb25zdHJhaW50IGVudmlyb25tZW50LCBpdCBpcyByZWNvbW1lbmRlZCB0byB1c2UgYSBkb21h aW4gbmFtZSB3aGVuZXZlciBwb3NzaWJsZSwgYWNjb3JkaW5nIHRvIGl0ZW0gYSkuDQoNCk5PVEUg MyDigJMgV2hlbiB1c2VkIGFzIGEgbmFtaW5nIGF0dHJpYnV0ZSwgYSB1bmlxdWUgZGlzdGluZ3Vp c2hlZCBuYW1lIG1heSBiZSBjb25zdHJ1Y3RlZCB1c2luZyBvbmx5IHRoaXMgYXR0cmlidXRlIHR5 cGUuDQpBbiBhdHRyaWJ1dGUgb2YgdHlwZSBkbnNOYW1lIHRvIGJlIHVzZWQgYXMgYSBkaXN0aW5n dWlzaGVkIG5hbWUgaW4gYSBwdWJsaWMta2V5IGNlcnRpZmljYXRlIG9yIGluIGFuIGF0dHJpYnV0 ZSBjZXJ0aWZpY2F0ZSBzaGFsbCBiZSBhIGZ1bGx5LXF1YWxpZmllZCBkb21haW4gbmFtZSAoRlFE TiksIGkuZS4sIGl0IHNoYWxsIGlkZW50aWZ5IGEgcGFydGljdWxhciBlbnRpdHkuIEFuIEZRRE4g bWF5IGhhdmUgYW4gYXN0ZXJpc2sgKCcqJykgYXMgYW4gYWRkaXRpb25hbCBsZWZ0bW9zdCBsYWJl bCwgd2hpY2ggaXMgYSBzdWJzdGl0dXRlICh3aWxkY2FyZCkgZm9yIGFsbCBsYWJlbHMgYXQgdGhl IG5leHQgbGV2ZWxzIG9mIHN1YmRvbWFpbnMgb2YgdGhlIGRvbWFpbiBpZGVudGlmaWVkIGJ5IHRo ZSBGUUROIHdpdGhvdXQgdGhlIGFzdGVyaXNrLiBBbiBhdHRyaWJ1dGUgb2YgdHlwZSBkbnNOYW1l IGhvbGRpbmcgYW4gRlFETiB3aXRoIGEgd2lsZGNhcmQgbGFiZWwgbWF5IGluIHNvbWUgY2FzZXMg YmUgdXNlZCBpbiB0aGUgc3ViamVjdCBjb21wb25lbnQgb2YgYW4gZW5kLWVudGl0eSBwdWJsaWMt a2V5IGNlcnRpZmljYXRlLg0KVGhlIGNvcnJlc3BvbmRpbmcgbWF0Y2hpbmcgcnVsZSBpcyBkZWZp bmVkIGFzOg0KOC45LjIgICAgICAgIEROUyBuYW1lIG1hdGNoDQpUaGUgZG5zTmFtZU1hdGNoIGNv bXBhcmVzIHR3byB2YWx1ZXMgb2YgdHlwZSBkbnNOYW1lIGZvciBlcXVhbGl0eSBhbmQgaXMgZGVm aW5lZCBhczoNCg0KZG5zTmFtZU1hdGNoIE1BVENISU5HLVJVTEUgOjo9IHsNCiAgU1lOVEFYICAg ICAgIERvbWFpbk5hbWUNCiAgTERBUC1TWU5UQVggIGRuc1N0cmluZy4maWQNCiAgTERBUC1OQU1F ICAgIHsiZG5zTmFtZU1hdGNoIn0NCiAgSUQgICAgICAgICAgIGlkLW1yLWRuc05hbWVNYXRjaCB9 DQpUaGUgZXF1YWxpdHkgbWF0Y2hpbmcgaXMgcGVyZm9ybWVkIGxhYmVsIGZvciBsYWJlbC4gSWYg dGhlIG51bWJlciBvZiB0aGUgbGFiZWxzIGluIHRoZSB0d28gYXR0cmlidXRlIHZhbHVlcyBhcmUg ZGlmZmVyZW50LCB0aGUgcnVsZSBzaGFsbCByZXR1cm4gRkFMU0UuIFRoZSBydWxlIHNoYWxsIHJl dHVybiBUUlVFIGZvciBlYWNoIHBhaXIgb2YgbGFiZWxzIG1hdGNoZWQgZm9yIHRoZSBydWxlIHRv IHJldHVybiBUUlVFIGZvciB0aGUgdHdvIHZhbHVlcy4gT3RoZXJ3aXNlLCBpdCBzaGFsbCByZXR1 cm4gRkFMU0UuIFRoZSBtYXRjaGluZyBvZiB0aGUgaW5kaXZpZHVhbCBsYWJlbHMgc2hhbGwgYmUg cGVyZm9ybWVkIGFzIGZvbGxvd3M6DQoNCmEpICAgICBJZiBvbmUgb2YgdGhlIGxhYmVscyB0byBi ZSBjb21wYXJlZCBpcyBvZiB0aGUgdHlwZSBkZWZpbmVkIGluIGl0ZW0gYSkgb2YgY2xhdXNlIDYu Mi4xNSBhbmQgdGhlIG90aGVyIGxhYmVsIGlzIGVpdGhlciBhbiBBLWxhYmVsIG9yIGEgVS1sYWJl bCBhcyBkZWZpbmVkIGluIElFVEYgUkZDIDU4OTAsIHRoZSBydWxlIHNoYWxsIHJldHVybiBGQUxT RS4NCg0KYikgICAgIElmIHRoZSB0d28gbGFiZWxzIGFyZSBvZiB0aGUgc2FtZSB0eXBlLCB0aGV5 IHNoYWxsIGJlIGNvbXBhcmVkIGZvbGxvd2luZyB0aGUgcnVsZXMgZm9yIGNhc2VJZ25vcmVNYXRj aC4NCg0KYykgICAgIElmIG9uZSB0aGUgbGFiZWxzIGlzIG9mIHR5cGUgQS1sYWJlbCBhbmQgdGhl IG90aGVyIG9uZSBpcyBvZiB0eXBlIFUtbGFiZWwsIHRoZSBsYXR0ZXIgc2hhbGwgYmUgY29udmVy dGVkIHRvIGFuIEEtbGFiZWwgYmVmb3JlIGNvbXBhcmlzb24gZm9sbG93aW5nIHRoZSBydWxlcyBm b3IgY2FzZUlnbm9yZU1hdGNoLg0KSW4gYWRkaXRpb24sIHRoZSBmb2xsb3dpbmcgYXBwbGllcyBp ZiBvbmUgb3IgYm90aCBvZiB0aGUgdmFsdWVzIGhhdmUgd2lsZGNhcmQgKCcqJykgbGFiZWxzOg0K DQpkKSAgICAgSWYgYXQgbGVhc3Qgb25lIG9mIHRoZSB2YWx1ZXMgY29udGFpbnMgbW9yZSB0aGFu IG9uZSB3aWxkY2FyZCBsYWJlbCBvciBpZiBhIHdpbGRjYXJkIGxhYmVsIGlzIG5vdCB0aGUgbGVm dG1vc3QgbGFiZWwsIHRoZSBydWxlIHNoYWxsIHJldHVybiBGQUxTRS4NCg0KZSkgICAgIElmIG9u ZSBvciBib3RoIHRoZSB2YWx1ZXMgaGFzIGEgd2lsZGNhcmQgYXMgdGhlIGxlZnRtb3N0IGxhYmVs LCB0aGUgcmVtYWluaW5nIGxhYmVscyBzaGFsbCBiZSBtYXRjaGVkIGFzIHN0YXRlZCBpbiBhKSB0 byBjKSBhYm92ZSBhbmQgc2hhbGwgcmV0dXJuIFRSVUUgb3IgRkFMU0UgYWNjb3JkaW5nbHkuDQoN Ck5PVEUg4oCTIFRoZSBlZmZlY3Qgb2YgdGhlIHdpbGRjYXJkIG1hdGNoIGlzIHRoYXQgKi5leGFt cGxlLmNvbTxodHRwOi8vZXhhbXBsZS5jb20vPiB3aWxsIG1hdGNoIGEuZXhhbXBsZS5jb208aHR0 cDovL2EuZXhhbXBsZS5jb20vPiBhbmQgYi5leGFtcGxlLmNvbTxodHRwOi8vYi5leGFtcGxlLmNv bS8+IGJ1dCBub3QgYS5iLmV4YW1wbGUuY29tPGh0dHA6Ly9hLmIuZXhhbXBsZS5jb20vPiBub3Ig ZXhhbXBsZS5jb208aHR0cDovL2V4YW1wbGUuY29tLz4uDQoNCg0KRXJpaw0KRnJhOiBwa2l4IFtt YWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnXSBQw6UgdmVnbmUgYWYgQmVuIFdpbHNvbg0KU2Vu ZHQ6IDA2IEFwcmlsIDIwMTcgMTg6MjQNClRpbDogcGtpeEBpZXRmLm9yZzxtYWlsdG86cGtpeEBp ZXRmLm9yZz4NCkVtbmU6IFtwa2l4XSBBbWVuZG1lbnQgdG8gQ0FCRiBCYXNlbGluZSBSZXF1aXJl bWVudHMNCg0KRG9lcyBhbnlvbmUgd2FudCB0byBjb21tZW50IG9uIG15IGRyYWZ0IGFtZW5kbWVu dCB0byB0aGUgQ0EvQnJvd3NlciBGb3J1beKAmXMgQmFzZWxpbmUgUmVxdWlyZW1lbnRzIGZvciBT U0wvVExTIENlcnRpZmljYXRlcyB3aGljaCB3b3VsZCByZW1vdmUgdGhlIDY0LWNoYXJhY3RlciBs aW1pdCBvbiB0aGUgY29tbW9uTmFtZSBhbmQgb3JnYW5pemF0aW9uTmFtZSwgIGFzIGFuIGV4Y2Vw dGlvbiB0byBSRkMgNTI4MD8gIFRoZSB0ZXh0IG9mIHRoZSByZWxldmFudCBCYXNlbGluZSBSZXF1 aXJlbWVudCBwcm92aXNpb24gaXMgZm91bmQgYmVsb3cgd2l0aCB0aGUgcHJvcG9zZWQgYWRkaXRp b25hbCBsYW5ndWFnZSBpbiBBTEwgQ0FQUy4gIFRoZSByZWFzb24gZm9yIHRoZSBmaXJzdCBjaGFu Z2UgKGNvbW1vbk5hbWUpIGlzIHRoZXJlIGFyZSBGUUROcyAoaW4gU3ViamVjdCBBbHRlcm5hdGl2 ZSBOYW1lcykgdGhhdCBhcmUgbG9uZ2VyIHRoYW4gNjQgY2hhcmFjdGVycy4gIFRoZSByZWFzb24g Zm9yIHRoZSBzZWNvbmQgY2hhbmdlIChvcmdhbml6YXRpb25OYW1lKSBpcyB0aGF0IHRoZXJlIGFy ZSBvcmdhbml6YXRpb25zIHdpdGggbmFtZXMgbG9uZ2VyIHRoYW4gNjQgY2hhcmFjdGVycy4NCg0K Ny4xLjQuMi4yLiAgICAgICAgICAgICBTdWJqZWN0IERpc3Rpbmd1aXNoZWQgTmFtZSBGaWVsZHMN CmEuICAgICAgICAgICAgQ2VydGlmaWNhdGUgRmllbGQ6IHN1YmplY3Q6Y29tbW9uTmFtZSAoT0lE IDIuNS40LjMpDQpSZXF1aXJlZC9PcHRpb25hbDogRGVwcmVjYXRlZCAoRGlzY291cmFnZWQsIGJ1 dCBub3QgcHJvaGliaXRlZCkNCkNvbnRlbnRzOiBJZiBwcmVzZW50LCB0aGlzIGZpZWxkIE1VU1Qg Y29udGFpbiBhIHNpbmdsZSBJUCBhZGRyZXNzIG9yIEZ1bGx5LVF1YWxpZmllZCBEb21haW4gTmFt ZSB0aGF0IGlzIG9uZSBvZiB0aGUgdmFsdWVzIGNvbnRhaW5lZCBpbiB0aGUgQ2VydGlmaWNhdGXi gJlzIHN1YmplY3RBbHROYW1lIGV4dGVuc2lvbiAoc2VlIFNlY3Rpb24gNy4xLjQuMi4xKS4NCk1B WElNVU0gTEVOR1RIOiAgTk8gU1RJUFVMQVRJT04uICAoVEhJUyBJUyBBTiBFWENFUFRJT04gVE8g UkZDIDUyODAgV0hJQ0ggU1BFQ0lGSUVTIEFOIFVQUEVSIEJPVU5EIE9GIDY0IENIQVJBQ1RFUlMu KQ0KYi4gICAgICAgICAgICBDZXJ0aWZpY2F0ZSBGaWVsZDogc3ViamVjdDpvcmdhbml6YXRpb25O YW1lIChPSUQgMi41LjQuMTApDQpPcHRpb25hbC4NCkNvbnRlbnRzOiBJZiBwcmVzZW50LCB0aGUg c3ViamVjdDpvcmdhbml6YXRpb25OYW1lIGZpZWxkIE1VU1QgY29udGFpbiBlaXRoZXIgdGhlIFN1 YmplY3TigJlzIG5hbWUgb3IgREJBIGFzIHZlcmlmaWVkIHVuZGVyIFNlY3Rpb24gMy4yLjIuMi4g VGhlIENBIG1heSBpbmNsdWRlIGluZm9ybWF0aW9uIGluIHRoaXMgZmllbGQgdGhhdCBkaWZmZXJz IHNsaWdodGx5IGZyb20gdGhlIHZlcmlmaWVkIG5hbWUsIHN1Y2ggYXMgY29tbW9uIHZhcmlhdGlv bnMgb3IgYWJicmV2aWF0aW9ucywgcHJvdmlkZWQgdGhhdCB0aGUgQ0EgZG9jdW1lbnRzIHRoZSBk aWZmZXJlbmNlIGFuZCBhbnkgYWJicmV2aWF0aW9ucyB1c2VkIGFyZSBsb2NhbGx5IGFjY2VwdGVk IGFiYnJldmlhdGlvbnM7IGUuZy4sIGlmIHRoZSBvZmZpY2lhbCByZWNvcmQgc2hvd3Mg4oCcQ29t cGFueSBOYW1lIEluY29ycG9yYXRlZOKAnSwgdGhlIENBIE1BWSB1c2Ug4oCcQ29tcGFueSBOYW1l IEluYy7igJ0gb3Ig4oCcQ29tcGFueSBOYW1l4oCdLiAgQmVjYXVzZSBTdWJqZWN0IG5hbWUgYXR0 cmlidXRlcyBmb3IgaW5kaXZpZHVhbHMgKGUuZy4gZ2l2ZW5OYW1lICgyLjUuNC40MikgYW5kIHN1 cm5hbWUgKDIuNS40LjQpKSBhcmUgbm90IGJyb2FkbHkgc3VwcG9ydGVkIGJ5IGFwcGxpY2F0aW9u IHNvZnR3YXJlLCB0aGUgQ0EgTUFZIHVzZSB0aGUgc3ViamVjdDpvcmdhbml6YXRpb25OYW1lIGZp ZWxkIHRvIGNvbnZleSBhIG5hdHVyYWwgcGVyc29uIFN1YmplY3TigJlzIG5hbWUgb3IgREJBLg0K TUFYSU1VTSBMRU5HVEg6ICAyNTYgQ0hBUkFDVEVSUyAoVEhJUyBJUyBBTiBFWENFUFRJT04gVE8g UkZDIDUyODAgV0hJQ0ggU1BFQ0lGSUVTIEFOIFVQUEVSIEJPVU5EIE9GIDY0IENIQVJBQ1RFUlMu KQ0KDQpUaGFua3MsDQpCZW4gV2lsc29uDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KcGtpeCBtYWlsaW5nIGxpc3QNCnBraXhAaWV0Zi5vcmc8bWFpbHRv OnBraXhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Br aXgNCg0K --_000_5408AFDFD15A4B5B842B1BC533D1DF58ttuedu_ Content-Type: text/html; charset="utf-8" Content-ID: <889401E604A8284C9151A7D51A49E02C@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRXJpaywNCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJlZm9yZSBwcm9jZWVkaW5nIHdp dGggYW55IGF0dGVtcHQgdG8gZGVwcmVjYXRlIHRoZSB1c2Ugb2YgY29tbW9uTmFtZSwgbWF5IEkg cmVjb21tZW5kIHRoYXQgeW91IHJlYWQgdGhlIGNvbnRlbnRzIG9mIHRoZSBPR0bigJlzIOKAnElu dGVyb3BlcmFibGUgQ2VydGlmaWNhdGUgUHJvZmlsZeKAnSB0aGF0IGZvY3VzZXMgb24gbm9uLWJy b3dzZXIgYXBwbGljYXRpb25zIG9mIHVzZSBvZiBkaXJlY3RvcnkgbmFtZXMsIGF0dHJpYnV0ZXMs DQogYW5kIGV4dGVuc2lvbnMgaW4gWC41MDkgY2VydGlmaWNhdGVzLCBzdWNoIHRoYXQgdGhleSBh cmUgdXNhYmxlIGJ5IHRoZSBtYWpvcml0eSBvZiBzY2llbnRpZmljIGN5YmVyLWluZnJhc3RydWN0 dXJlcyBhcyBzdXBwb3J0ZWQgYnkgdGhlIElHVEY/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGlzIGRvY3VtZW50IGlzIGF2YWlsYWJs ZSBpbiBpdHMgbW9zdCByZWNlbnQgZm9ybSBhdCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3Lm9n Zi5vcmcvZG9jdW1lbnRzL2dmZC4yMjUucGRmIiBjbGFzcz0iIj5odHRwczovL3d3dy5vZ2Yub3Jn L2RvY3VtZW50cy9nZmQuMjI1LnBkZjwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkluIHBhcnRpY3VsYXIsIGNvbW1vbk5hbWUgaXMg YSByZXF1aXJlZCBjb21wb25lbnQgb2YgY2VydGlmaWNhdGVzIHVzZWQgaW4gc3VjaCBpbmZyYXN0 cnVjdHVyZXMgYW5kIGRlcHJlY2F0aW9uIHdvdWxkIGNhdXNlIGEgZ3JlYXQgZGVhbCBvZiBkYW1h Z2UgdG8gZGVwbG95ZWQgaW5mcmFzdHJ1Y3R1cmVzIGZvciBsYXJnZS1zY2FsZSBncmlkIGFuZCBj bG91ZCBjb21wdXRpbmcuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkFsYTwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj5PbiBBcHIgMTAsIDIwMTcsIGF0IDEwOjEzIEFNLCBFcmlrIEFuZGVyc2VuICZsdDs8 YSBocmVmPSJtYWlsdG86ZXJhQHg1MDAuZXUiIGNsYXNzPSIiPmVyYUB4NTAwLmV1PC9hPiZndDsg d3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRT ZWN0aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSA4cHQ7IGxpbmUtaGVpZ2h0OiAxNS4z OTk5OTk2MTg1MzAyNzNweDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xh c3M9IiI+SGkgQmVuIGFuZCBvdGhlcnMsPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSA4cHQ7IGxpbmUtaGVp Z2h0OiAxNS4zOTk5OTk2MTg1MzAyNzNweDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyIgY2xhc3M9IiI+SSByZXNwb25kZWQgdG8gdGhlIHVwcGVyIGJvdW5kIGlzc3VlIGJlZm9y ZSByZWFkaW5nIEJlbuKAmXMgcXVlc3Rpb24uIEkgaGF2ZSBhIGNvbW1lbnQgbm90IHJlbGF0ZWQg dG8gdGhlIGNvbW1vbk5hbWUgYXR0cmlidXRlIHR5cGUuIFRoZSBjb21tb25OYW1lIGlzIGJlaW5n IChtaXMpdXNlZCBmb3IgYWxsIGtpbmQgb2YgdGhpbmdzLCBzbyB5b3UgY2Fubm90IGtub3cgd2hh dA0KIHRoZSBzeW50YXggcmVhbGx5IGlzLCB3aGljaCBzaG91bGQgY2F1c2UgaW50ZXJ3b3JraW5n IHByb2JsZW1zLiBUaGUgdXNlIG9mIGNvbW1vbk5hbWUgc2hvdWxkIHBvc3NpYmx5IGJlIGRlcHJl Y2F0ZWQuPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSA4cHQ7IGxpbmUtaGVpZ2h0OiAxNS4zOTk5OTk2MTg1 MzAyNzNweDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+QXMg dG8gdXNlIHRoZSBjb21tb25OYW1lIGZvciBob2xkaW5nIGFuIEZRRE4sIGl0IGlzIGEgbGl0dGxl IHByb2JsZW1hdGljLiBUaGUgbWF0Y2hpbmcgcnVsZSBmb3IgRlFETnMgaXMgYSBsaXR0bGUgbW9y ZSBjb21wbGljYXRlZCB0aGFuIHRoZSBvbmUgZm9yIGNvbW1vbk5hbWUuIFguNTIwIGhhcyBhIGRz bk5hbWUgYXR0cmlidXRlIHR5cGUgYW5kIGFzIGl0IGlzIHJhdGhlcg0KIG5ldyBpdCBoYXMgbm90 IHVwcGVyIGJvdW5kIHNwZWNpZmljYXRpb24uIEl0IGlzIGRlZmluZWQgYXM6PG86cCBjbGFzcz0i Ij48L286cD48L3NwYW4+PC9wPg0KPGgzIHN0eWxlPSJtYXJnaW46IDkuMDVwdCAwY20gMC4wMDAx cHQgMzkuN3B0OyB0ZXh0LWFsaWduOiBqdXN0aWZ5OyB0ZXh0LWluZGVudDogLTM5LjdwdDsgYnJl YWstYWZ0ZXI6IGF2b2lkLXBhZ2U7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KNi4yLjE1Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IERvbWFpbiBuYW1lPG86cCBjbGFzcz0iIj48L286cD48L2gzPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSA4cHQ7IGxpbmUtaGVpZ2h0OiAx NS4zOTk5OTk2MTg1MzAyNzNweDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiPg0KQSB2YWx1ZSBvZiBhdHRyaWJ1dGUgdHlwZTxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iQVNOMWJvbGRj aGFyIiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IGZvbnQtd2VpZ2h0OiBib2xk OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBsaW5lLWhlaWdodDogMTIuNjAwMDAwMzgx NDY5NzI3cHg7IiBjbGFzcz0iIj5kbnNOYW1lPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iQXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+aXMNCiB1c2VkIGZvciBob2xkaW5nIGEg RE5TIGRvbWFpbiBuYW1lLCB3aGljaCBtYXkgYmUgYW4gaW50ZXJuYXRpb25hbGl6ZWQgZG9tYWlu IG5hbWUgKElETikuPG86cCBjbGFzcz0iIj48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIg TmV3JzsgZm9udC13ZWlnaHQ6IGJvbGQ7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7 PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgZm9udC13ZWlnaHQ6IGJvbGQ7 IiBjbGFzcz0iIj4NCmRuc05hbWUgQVRUUklCVVRFIDo6PSB7PG86cCBjbGFzcz0iIj48L286cD48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiA5 cHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyBmb250LXdlaWdodDogYm9sZDsiIGNsYXNz PSIiPg0KJm5ic3A7IFdJVEggU1lOVEFYJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERvbWFpbk5hbWU8bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IGZvbnQtd2VpZ2h0 OiBib2xkOyIgY2xhc3M9IiI+DQombmJzcDsgRVFVQUxJVFkgTUFUQ0hJTkcgUlVMRSZuYnNwOyBk bnNOYW1lTWF0Y2g8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVy IE5ldyc7IGZvbnQtd2VpZ2h0OiBib2xkOyIgY2xhc3M9IiI+DQombmJzcDsgTERBUC1TWU5UQVgm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgZG5zU3RyaW5nLiZhbXA7aWQ8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDlwdDsg Zm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IGZvbnQtd2VpZ2h0OiBib2xkOyIgY2xhc3M9IiI+ DQombmJzcDsgTERBUC1OQU1FJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwO3smcXVvdDtETlMg bmFtZSZxdW90O308bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVy IE5ldyc7IGZvbnQtd2VpZ2h0OiBib2xkOyIgY2xhc3M9IiI+DQombmJzcDsgSUQmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgaWQtYXQtZG5zTmFtZSB9PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAn Q291cmllciBOZXcnOyBmb250LXdlaWdodDogYm9sZDsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0i Ij4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyBmb250LXdlaWdo dDogYm9sZDsiIGNsYXNzPSIiPg0KRG9tYWluTmFtZSA6Oj0gVVRGOFN0cmluZyAoQ09OU1RSQUlO RUQgQlkgeyAtLSBDb25mb3JtcyB0byB0aGUgZm9ybWF0IG9mIGEgKGludGVybmF0aW9uYWxpemVk KSBkb21haW4gbmFtZS4gLS0gfSk8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSA4cHQ7IGxpbmUtaGVpZ2h0OiAxNS4z OTk5OTk2MTg1MzAyNzNweDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiPg0KQSB2YWx1ZSBvZiB0aGU8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9IkFTTjFib2xkY2hhciIgc3R5bGU9ImZv bnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyBmb250LXdlaWdodDogYm9sZDsiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDlwdDsgbGluZS1oZWlnaHQ6IDEyLjYwMDAwMDM4MTQ2OTcyN3B4OyIgY2xh c3M9IiI+RG9tYWluTmFtZTwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmRhdGENCiB0eXBlIHNoYWxsIGJlIGluIHRoZSBzeW50YXgs IGFzIHNwZWNpZmllZCBieSBzZWN0aW9uIDIuMy4xIG9mIElFVEYgUkZDIDU4OTAgbWVhbmluZyB0 aGF0IGEgZG9tYWluIG5hbWUgaXMgYSBzZXF1ZW5jZSBvZiBsYWJlbHMgaW4gdGhlIGxldHRlcnMs IGRpZ2l0cywgaHlwaGVuIChMREgpIGZvcm1hdCBzZXBhcmF0ZWQgYnkgZG90cy48bzpwIGNsYXNz PSIiPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gOHB0OyBsaW5lLWhlaWdodDogMTUuMzk5OTk5NjE4NTMwMjczcHg7IGZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCkEgbGFiZWwgbWF5IGJlIGlu IHRocmVlIGZvcm1hdHM6PG86cCBjbGFzcz0iIj48L286cD48L3A+DQo8cCBjbGFzcz0iZW51bWxl djEiIHN0eWxlPSJtYXJnaW46IDQuM3B0IDBjbSAwLjAwMDFwdCA1OS41NXB0OyB0ZXh0LWFsaWdu OiBqdXN0aWZ5OyB0ZXh0LWluZGVudDogLTE5Ljg1cHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KYSkmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgQWxsIGNoYXJhY3RlcnMgaW4gdGhlIGxhYmVsIGFyZSBmcm9tIHRoZSBCYXNpYyBMYXRp biBjb2xsZWN0aW9uIGFzIGRlZmluZWQgYnkgSVNPL0lFQyAxMDY0NiAoaS5lLiwgaGF2aW5nIGNv ZGUgcG9pbnRzIGluIHRoZSByYW5nZXMgMDA8c3BhbiBjbGFzcz0iIj4yRCwgMDAzMC0wMDM5LCAw MDQxLTAwNUEgYW5kIDAwNjEtMDA3QSkgYW5kIGl0IGRvZXMgbm90IHN0YXJ0IHdpdGggJnF1b3Q7 eG4tLSZxdW90Oy4gVGhlIG1heGltdW0gbGVuZ3RoIGlzIDYzIG9jdGV0cy48bzpwIGNsYXNzPSIi PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iZW51bWxldjEiIHN0eWxlPSJtYXJnaW46IDQu M3B0IDBjbSAwLjAwMDFwdCA1OS41NXB0OyB0ZXh0LWFsaWduOiBqdXN0aWZ5OyB0ZXh0LWluZGVu dDogLTE5Ljg1cHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiPg0KPHNwYW4gY2xhc3M9IiI+YikmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg SXQgaXMgYW4gQS1sYWJlbCBhcyBkZWZpbmVkIGluIElFVEYgUkZDIDU4OTAsIGkuZS4sIGl0IHN0 YXJ0cyB3aXRoIHRoZSAmcXVvdDt4bi0tJnF1b3Q7IGFuZCBpcyBhIFUtbGFiZWwgY29udmVydGVk IHRvIHZhbGlkIEFTQ0lJIGNoYXJhY3RlcnMgYXMgaW4gaXRlbSBhKSB1c2luZyB0aGUgUHVueWNv ZGUgYWxnb3JpdGhtIGRlZmluZWQgYnkgSUVURiBSRkMgMzQ5Mi4gVGhlIGNvbnZlcnRlZCBzdHJp bmcgc2hhbGwgYmUgbWF4aW11bQ0KIDU5IG9jdGV0cy4gVG8gYmUgdmFsaWQsIGl0IHNoYWxsIGJl IHBvc3NpYmxlIGZvciBhbiBBLWxhYmVsIHRvIGJlIGNvbnZlcnRlZCB0byBhIHZhbGlkIFUtbGFi ZWwuPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik5vdGUyIiBzdHls ZT0ibWFyZ2luOiAzcHQgMGNtIDAuMDAwMXB0IDUzLjg1cHQ7IHRleHQtYWxpZ246IGp1c3RpZnk7 IGZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+ DQo8c3BhbiBjbGFzcz0iIj5OT1RFIDEg4oCTIEFuIEEtbGFiZWwgaXMgbm9ybWFsbHkgbm90IGh1 bWFuIHJlYWRhYmxlLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJl bnVtbGV2MSIgc3R5bGU9Im1hcmdpbjogNC4zcHQgMGNtIDAuMDAwMXB0IDU5LjU1cHQ7IHRleHQt YWxpZ246IGp1c3RpZnk7IHRleHQtaW5kZW50OiAtMTkuODVwdDsgZm9udC1zaXplOiAxMHB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBjbGFzcz0iIj5j KSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJdCBpcyBhIFUtbGFiZWwgYXMgZGVmaW5lZCBpbiBJ RVRGIFJGQyA1ODkwLCBpLmUuLCBpdCBjb250YWlucyBjaGFyYWN0ZXJzIG91dHNpZGUgdGhlPHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5CYXNp YyBMYXRpbiBjb2xsZWN0aW9uPHNwYW4gY2xhc3M9IiI+LiBBIHZhbGlkIFUtbGFiZWwgc2hhbGwg bm90IGluY2x1ZGUgYW55IGNoYXJhY3RlcnMgdGhhdCBhcmUgbm90DQogaW5jbHVkZWQgaW4gdGhl IHJlc3RyaWN0ZWQgVW5pY29kZSByZXBlcnRvaXJlIGFzIGRlZmluZWQgYnkgSUVURiBSRkMgNTg5 MiBhbmQgaXQgc2hhbGwgYmUgY29udmVydGlibGUgdG8gYSB2YWxpZCBBLWxhYmVsIGFzIGRlZmlu ZWQgaW4gaXRlbSBiKS4gQSB2YWxpZCBVLWxhYmVsIG1heSBiZSBtb3JlIHRoYW4gNjMgb2N0ZXRz LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJOb3RlMSIgc3R5bGU9 Im1hcmdpbjogM3B0IDBjbSAwLjAwMDFwdCAxNC4ycHQ7IHRleHQtYWxpZ246IGp1c3RpZnk7IGZv bnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8 c3BhbiBjbGFzcz0iIj5OT1RFIDIg4oCTIEluIGEgY29uc3RyYWludCBlbnZpcm9ubWVudCwgaXQg aXMgcmVjb21tZW5kZWQgdG8gdXNlIGEgZG9tYWluIG5hbWUgd2hlbmV2ZXIgcG9zc2libGUsIGFj Y29yZGluZyB0byBpdGVtIGEpLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJOb3RlMSIgc3R5bGU9Im1hcmdpbjogM3B0IDBjbSAwLjAwMDFwdCAxNC4ycHQ7IHRleHQt YWxpZ246IGp1c3RpZnk7IGZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyI+DQo8c3BhbiBjbGFzcz0iIj5OT1RFIDMg4oCTIFdoZW4gdXNlZCBhcyBh IG5hbWluZyBhdHRyaWJ1dGUsIGEgdW5pcXVlIGRpc3Rpbmd1aXNoZWQgbmFtZSBtYXkgYmUgY29u c3RydWN0ZWQgdXNpbmcgb25seSB0aGlzIGF0dHJpYnV0ZSB0eXBlLjxvOnAgY2xhc3M9IiI+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gOHB0OyBsaW5lLWhlaWdodDogMTUuMzk5OTk5NjE4NTMwMjczcHg7IGZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCkFuIGF0dHJpYnV0ZSBvZiB0 eXBlPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxzcGFu IGNsYXNzPSJBU04xYm9sZGNoYXIiIHN0eWxlPSJmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3Jzsg Zm9udC13ZWlnaHQ6IGJvbGQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGxpbmUtaGVp Z2h0OiAxMi42MDAwMDAzODE0Njk3MjdweDsiIGNsYXNzPSIiPmRuc05hbWU8L3NwYW4+PC9zcGFu PjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj50bw0KIGJl IHVzZWQgYXMgYSBkaXN0aW5ndWlzaGVkIG5hbWUgaW4gYSBwdWJsaWMta2V5IGNlcnRpZmljYXRl IG9yIGluIGFuIGF0dHJpYnV0ZSBjZXJ0aWZpY2F0ZSBzaGFsbCBiZSBhIGZ1bGx5LXF1YWxpZmll ZCBkb21haW4gbmFtZSAoRlFETiksIGkuZS4sIGl0IHNoYWxsIGlkZW50aWZ5IGEgcGFydGljdWxh ciBlbnRpdHkuIEFuIEZRRE4gbWF5IGhhdmUgYW4gYXN0ZXJpc2sgKCcqJykgYXMgYW4gYWRkaXRp b25hbCBsZWZ0bW9zdCBsYWJlbCwgd2hpY2gNCiBpcyBhIHN1YnN0aXR1dGUgKHdpbGRjYXJkKSBm b3IgYWxsIGxhYmVscyBhdCB0aGUgbmV4dCBsZXZlbHMgb2Ygc3ViZG9tYWlucyBvZiB0aGUgZG9t YWluIGlkZW50aWZpZWQgYnkgdGhlIEZRRE4gd2l0aG91dCB0aGUgYXN0ZXJpc2suIEFuIGF0dHJp YnV0ZSBvZiB0eXBlPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxzcGFuIGNsYXNzPSJBU04xYm9sZGNoYXIiIHN0eWxlPSJmb250LWZhbWlseTogJ0NvdXJp ZXIgTmV3JzsgZm9udC13ZWlnaHQ6IGJvbGQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7 IGxpbmUtaGVpZ2h0OiAxMi42MDAwMDAzODE0Njk3MjdweDsiIGNsYXNzPSIiPmRuc05hbWU8c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvc3Bh bj5ob2xkaW5nDQogYW4gRlFETiB3aXRoIGEgd2lsZGNhcmQgbGFiZWwgbWF5IGluIHNvbWUgY2Fz ZXMgYmUgdXNlZCBpbiB0aGU8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PHNwYW4gY2xhc3M9IkFTTjFib2xkY2hhciIgc3R5bGU9ImZvbnQtZmFtaWx5OiAn Q291cmllciBOZXcnOyBmb250LXdlaWdodDogYm9sZDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDlwdDsgbGluZS1oZWlnaHQ6IDEyLjYwMDAwMDM4MTQ2OTcyN3B4OyIgY2xhc3M9IiI+c3ViamVj dDwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPmNvbXBvbmVudA0KIG9mIGFuIGVuZC1lbnRpdHkgcHVibGljLWtleSBjZXJ0aWZpY2F0 ZS48c3BhbiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDhwdDsgbGluZS1oZWlnaHQ6IDE1 LjM5OTk5OTYxODUzMDI3M3B4OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBj bGFzcz0iIj5UaGUgY29ycmVzcG9uZGluZyBtYXRjaGluZyBydWxlIGlzIGRlZmluZWQgYXM6PG86 cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9wPg0KPGgzIHN0eWxlPSJtYXJnaW46IDkuMDVwdCAw Y20gMC4wMDAxcHQgMzkuN3B0OyB0ZXh0LWFsaWduOiBqdXN0aWZ5OyB0ZXh0LWluZGVudDogLTM5 LjdwdDsgYnJlYWstYWZ0ZXI6IGF2b2lkLXBhZ2U7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KOC45LjImbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRE5TIG5hbWUgbWF0Y2g8bzpwIGNsYXNz PSIiPjwvbzpwPjwvaDM+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDhwdDsgbGluZS1oZWlnaHQ6IDE1LjM5OTk5OTYxODUzMDI3M3B4OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQpUaGU8c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9IkFTTjFib2xk Y2hhciIgc3R5bGU9ImZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyBmb250LXdlaWdodDogYm9s ZDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgbGluZS1oZWlnaHQ6IDEyLjYwMDAwMDM4 MTQ2OTcyN3B4OyIgY2xhc3M9IiI+ZG5zTmFtZU1hdGNoPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFz cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Y29tcGFyZXMNCiB0d28gdmFs dWVzIG9mIHR5cGU8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PHNwYW4gY2xhc3M9IkFTTjFib2xkY2hhciIgc3R5bGU9ImZvbnQtZmFtaWx5OiAnQ291cmll ciBOZXcnOyBmb250LXdlaWdodDogYm9sZDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsg bGluZS1oZWlnaHQ6IDEyLjYwMDAwMDM4MTQ2OTcyN3B4OyIgY2xhc3M9IiI+ZG5zTmFtZTwvc3Bh bj48L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PmZvcg0KIGVxdWFsaXR5IGFuZCBpcyBkZWZpbmVkIGFzOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDlwdDsg Zm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IGZvbnQtd2VpZ2h0OiBib2xkOyIgY2xhc3M9IiI+ DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5l dyc7IGZvbnQtd2VpZ2h0OiBib2xkOyIgY2xhc3M9IiI+DQpkbnNOYW1lTWF0Y2ggTUFUQ0hJTkct UlVMRSA6Oj0gezxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIg TmV3JzsgZm9udC13ZWlnaHQ6IGJvbGQ7IiBjbGFzcz0iIj4NCiZuYnNwOyBTWU5UQVgmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRG9tYWluTmFtZTxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogOXB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgZm9udC13ZWlnaHQ6IGJvbGQ7IiBj bGFzcz0iIj4NCiZuYnNwOyBMREFQLVNZTlRBWCZuYnNwOyBkbnNTdHJpbmcuJmFtcDtpZDxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgZm9udC13ZWln aHQ6IGJvbGQ7IiBjbGFzcz0iIj4NCiZuYnNwOyBMREFQLU5BTUUgJm5ic3A7Jm5ic3A7Jm5ic3A7 eyZxdW90O2Ruc05hbWVNYXRjaCZxdW90O308bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDlwdDsgZm9udC1m YW1pbHk6ICdDb3VyaWVyIE5ldyc7IGZvbnQtd2VpZ2h0OiBib2xkOyIgY2xhc3M9IiI+DQombmJz cDsgSUQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgaWQtbXItZG5zTmFtZU1hdGNoIH08bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSA4cHQ7IGxpbmUtaGVp Z2h0OiAxNS4zOTk5OTk2MTg1MzAyNzNweDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KVGhlIGVxdWFsaXR5IG1hdGNoaW5nIGlzIHBlcmZvcm1l ZCBsYWJlbCBmb3IgbGFiZWwuIElmIHRoZSBudW1iZXIgb2YgdGhlIGxhYmVscyBpbiB0aGUgdHdv IGF0dHJpYnV0ZSB2YWx1ZXMgYXJlIGRpZmZlcmVudCwgdGhlIHJ1bGUgc2hhbGwgcmV0dXJuIEZB TFNFLiBUaGUgcnVsZSBzaGFsbCByZXR1cm4gVFJVRSBmb3IgZWFjaCBwYWlyIG9mIGxhYmVscyBt YXRjaGVkIGZvciB0aGUgcnVsZSB0byByZXR1cm4gVFJVRSBmb3IgdGhlIHR3byB2YWx1ZXMuDQog T3RoZXJ3aXNlLCBpdCBzaGFsbCByZXR1cm4gRkFMU0UuIFRoZSBtYXRjaGluZyBvZiB0aGUgaW5k aXZpZHVhbCBsYWJlbHMgc2hhbGwgYmUgcGVyZm9ybWVkIGFzIGZvbGxvd3M6PG86cCBjbGFzcz0i Ij48L286cD48L3A+DQo8cCBjbGFzcz0iZW51bWxldjEiIHN0eWxlPSJtYXJnaW46IDQuM3B0IDBj bSAwLjAwMDFwdCA1OS41NXB0OyB0ZXh0LWFsaWduOiBqdXN0aWZ5OyB0ZXh0LWluZGVudDogLTE5 Ljg1cHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiPg0KYSkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSWYgb25lIG9mIHRoZSBsYWJlbHMg dG8gYmUgY29tcGFyZWQgaXMgb2YgdGhlIHR5cGUgZGVmaW5lZCBpbiBpdGVtIGEpIG9mIGNsYXVz ZSA2LjIuMTUgYW5kIHRoZSBvdGhlciBsYWJlbCBpcyBlaXRoZXIgYW4gQS1sYWJlbCBvciBhIFUt bGFiZWwgYXMgZGVmaW5lZCBpbiBJRVRGIFJGQyA1ODkwLCB0aGUgcnVsZSBzaGFsbCByZXR1cm4g RkFMU0UuPG86cCBjbGFzcz0iIj48L286cD48L3A+DQo8cCBjbGFzcz0iZW51bWxldjEiIHN0eWxl PSJtYXJnaW46IDQuM3B0IDBjbSAwLjAwMDFwdCA1OS41NXB0OyB0ZXh0LWFsaWduOiBqdXN0aWZ5 OyB0ZXh0LWluZGVudDogLTE5Ljg1cHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KYikmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSWYg dGhlIHR3byBsYWJlbHMgYXJlIG9mIHRoZSBzYW1lIHR5cGUsIHRoZXkgc2hhbGwgYmUgY29tcGFy ZWQgZm9sbG93aW5nIHRoZSBydWxlcyBmb3I8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9IkFTTjFib2xkY2hhciIgc3R5bGU9ImZvbnQt ZmFtaWx5OiAnQ291cmllciBOZXcnOyBmb250LXdlaWdodDogYm9sZDsiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDlwdDsiIGNsYXNzPSIiPmNhc2VJZ25vcmVNYXRjaDwvc3Bhbj48L3NwYW4+Ljxv OnAgY2xhc3M9IiI+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImVudW1sZXYxIiBzdHlsZT0ibWFyZ2lu OiA0LjNwdCAwY20gMC4wMDAxcHQgNTkuNTVwdDsgdGV4dC1hbGlnbjoganVzdGlmeTsgdGV4dC1p bmRlbnQ6IC0xOS44NXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7Ij4NCmMpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElmIG9uZSB0aGUg bGFiZWxzIGlzIG9mIHR5cGUgQS1sYWJlbCBhbmQgdGhlIG90aGVyIG9uZSBpcyBvZiB0eXBlIFUt bGFiZWwsIHRoZSBsYXR0ZXIgc2hhbGwgYmUgY29udmVydGVkIHRvIGFuIEEtbGFiZWwgYmVmb3Jl IGNvbXBhcmlzb24gZm9sbG93aW5nIHRoZSBydWxlcyBmb3I8c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9IkFTTjFib2xkY2hhciIgc3R5 bGU9ImZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyBmb250LXdlaWdodDogYm9sZDsiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDlwdDsiIGNsYXNzPSIiPmNhc2VJZ25vcmVNYXRjaDwvc3Bhbj48 L3NwYW4+LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSA4cHQ7IGxpbmUtaGVpZ2h0OiAxNS4zOTk5OTk2MTg1MzAyNzNw eDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0K SW4gYWRkaXRpb24sIHRoZSBmb2xsb3dpbmcgYXBwbGllcyBpZiBvbmUgb3IgYm90aCBvZiB0aGUg dmFsdWVzIGhhdmUgd2lsZGNhcmQgKCcqJykgbGFiZWxzOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9ImVudW1sZXYxIiBzdHlsZT0ibWFyZ2luOiA0LjNwdCAwY20gMC4wMDAxcHQg NTkuNTVwdDsgdGV4dC1hbGlnbjoganVzdGlmeTsgdGV4dC1pbmRlbnQ6IC0xOS44NXB0OyBmb250 LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCmQp Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElmIGF0IGxlYXN0IG9uZSBvZiB0aGUgdmFsdWVzIGNv bnRhaW5zIG1vcmUgdGhhbiBvbmUgd2lsZGNhcmQgbGFiZWwgb3IgaWYgYSB3aWxkY2FyZCBsYWJl bCBpcyBub3QgdGhlIGxlZnRtb3N0IGxhYmVsLCB0aGUgcnVsZSBzaGFsbCByZXR1cm4gRkFMU0Uu PG86cCBjbGFzcz0iIj48L286cD48L3A+DQo8cCBjbGFzcz0iZW51bWxldjEiIHN0eWxlPSJtYXJn aW46IDQuM3B0IDBjbSAwLjAwMDFwdCA1OS41NXB0OyB0ZXh0LWFsaWduOiBqdXN0aWZ5OyB0ZXh0 LWluZGVudDogLTE5Ljg1cHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiPg0KZSkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSWYgb25lIG9y IGJvdGggdGhlIHZhbHVlcyBoYXMgYSB3aWxkY2FyZCBhcyB0aGUgbGVmdG1vc3QgbGFiZWwsIHRo ZSByZW1haW5pbmcgbGFiZWxzIHNoYWxsIGJlIG1hdGNoZWQgYXMgc3RhdGVkIGluIGEpIHRvIGMp IGFib3ZlIGFuZCBzaGFsbCByZXR1cm4gVFJVRSBvciBGQUxTRSBhY2NvcmRpbmdseS48bzpwIGNs YXNzPSIiPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJOb3RlMiIgc3R5bGU9Im1hcmdpbjogM3B0IDBj bSAwLjAwMDFwdCA1My44NXB0OyB0ZXh0LWFsaWduOiBqdXN0aWZ5OyBmb250LXNpemU6IDlwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KTk9URSDigJMgVGhlIGVm ZmVjdCBvZiB0aGUgd2lsZGNhcmQgbWF0Y2ggaXMgdGhhdCAqLjxhIGhyZWY9Imh0dHA6Ly9leGFt cGxlLmNvbS8iIHN0eWxlPSJjb2xvcjogcmdiKDE0OSwgNzksIDExNCk7IHRleHQtZGVjb3JhdGlv bjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+ZXhhbXBsZS5jb208L2E+PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndpbGwgbWF0Y2g8c3BhbiBjbGFzcz0iQXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL2EuZXhhbXBs ZS5jb20vIiBzdHlsZT0iY29sb3I6IHJnYigxNDksIDc5LCAxMTQpOyB0ZXh0LWRlY29yYXRpb246 IHVuZGVybGluZTsiIGNsYXNzPSIiPmEuZXhhbXBsZS5jb208L2E+PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmFuZDxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vYi5leGFtcGxlLmNvbS8i IHN0eWxlPSJjb2xvcjogcmdiKDE0OSwgNzksIDExNCk7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJs aW5lOyIgY2xhc3M9IiI+Yi5leGFtcGxlLmNvbTwvYT48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+YnV0DQogbm90PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9hLmIuZXhhbXBsZS5jb20v IiBzdHlsZT0iY29sb3I6IHJnYigxNDksIDc5LCAxMTQpOyB0ZXh0LWRlY29yYXRpb246IHVuZGVy bGluZTsiIGNsYXNzPSIiPmEuYi5leGFtcGxlLmNvbTwvYT48c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+bm9yPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNvbS8iIHN0eWxl PSJjb2xvcjogcmdiKDE0OSwgNzksIDExNCk7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIg Y2xhc3M9IiI+ZXhhbXBsZS5jb208L2E+LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik5vdGUyIiBzdHlsZT0ibWFyZ2luOiAzcHQgMGNtIDAuMDAwMXB0IDUzLjg1cHQ7IHRleHQt YWxpZ246IGp1c3RpZnk7IGZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gOHB0OyBsaW5lLWhlaWdodDogMTUu Mzk5OTk5NjE4NTMwMjczcHg7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNs YXNzPSIiPkVyaWs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci10b3At d2lkdGg6IDFwdDsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDIyNSwgMjI1LCAyMjUpOyBwYWRkaW5n OiAzcHQgMGNtIDBjbTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj48c3BhbiBsYW5n PSJEQSIgY2xhc3M9IiI+RnJhOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iREEiIGNsYXNzPSIiPjxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5wa2l4IFs8YSBo cmVmPSJtYWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86cGtpeC1i b3VuY2VzQGlldGYub3JnPC9hPl08c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGIgY2xhc3M9IiI+UMOlDQogdmVnbmUgYWY8c3BhbiBjbGFzcz0iQXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkJlbiBXaWxzb248YnIgY2xhc3M9IiI+ DQo8YiBjbGFzcz0iIj5TZW5kdDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjA2IEFwcmlsIDIwMTcgMTg6MjQ8YnIgY2xhc3M9IiI+DQo8YiBjbGFz cz0iIj5UaWw6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJtYWlsdG86cGtpeEBpZXRmLm9yZyIgY2xhc3M9IiI+cGtpeEBpZXRmLm9y ZzwvYT48YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5FbW5lOjwvYj48c3BhbiBjbGFzcz0iQXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+W3BraXhdIEFtZW5kbWVudCB0byBDQUJG IEJhc2VsaW5lIFJlcXVpcmVtZW50czxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gOHB0OyBsaW5lLWhlaWdodDogMTUuMzk5OTk5NjE4NTMwMjczcHg7IGZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxvOnAgY2xhc3M9IiI+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSA2cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj5Eb2Vz IGFueW9uZSB3YW50IHRvIGNvbW1lbnQgb24gbXkgZHJhZnQgYW1lbmRtZW50IHRvIHRoZSBDQS9C cm93c2VyIEZvcnVt4oCZcyBCYXNlbGluZSBSZXF1aXJlbWVudHMgZm9yIFNTTC9UTFMgQ2VydGlm aWNhdGVzIHdoaWNoIHdvdWxkIHJlbW92ZSB0aGUgNjQtY2hhcmFjdGVyIGxpbWl0IG9uIHRoZSBj b21tb25OYW1lIGFuZCBvcmdhbml6YXRpb25OYW1lLCZuYnNwOyBhcyBhbiBleGNlcHRpb24gdG8g UkZDDQogNTI4MD8mbmJzcDsgVGhlIHRleHQgb2YgdGhlIHJlbGV2YW50IEJhc2VsaW5lIFJlcXVp cmVtZW50IHByb3Zpc2lvbiBpcyBmb3VuZCBiZWxvdyB3aXRoIHRoZSBwcm9wb3NlZCBhZGRpdGlv bmFsIGxhbmd1YWdlIGluIEFMTCBDQVBTLiZuYnNwOyBUaGUgcmVhc29uIGZvciB0aGUgZmlyc3Qg Y2hhbmdlIChjb21tb25OYW1lKSBpcyB0aGVyZSBhcmUgRlFETnMgKGluIFN1YmplY3QgQWx0ZXJu YXRpdmUgTmFtZXMpIHRoYXQgYXJlIGxvbmdlciB0aGFuIDY0IGNoYXJhY3RlcnMuJm5ic3A7DQog VGhlIHJlYXNvbiBmb3IgdGhlIHNlY29uZCBjaGFuZ2UgKG9yZ2FuaXphdGlvbk5hbWUpIGlzIHRo YXQgdGhlcmUgYXJlIG9yZ2FuaXphdGlvbnMgd2l0aCBuYW1lcyBsb25nZXIgdGhhbiA2NCBjaGFy YWN0ZXJzLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gNnB0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8c3BhbiBs YW5nPSJFTi1VUyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSA2cHQ7IGxpbmUt aGVpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj43LjEuNC4yLjIuJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFN1YmplY3QgRGlzdGluZ3Vpc2hlZCBOYW1lIEZpZWxkczxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBj bSAwY20gNnB0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+ YS4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgQ2VydGlmaWNhdGUgRmllbGQ6IHN1YmplY3Q6Y29tbW9uTmFtZSAoT0lEIDIu NS40LjMpJm5ic3A7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gNnB0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8c3BhbiBsYW5n PSJFTi1VUyIgY2xhc3M9IiI+UmVxdWlyZWQvT3B0aW9uYWw6IERlcHJlY2F0ZWQgKERpc2NvdXJh Z2VkLCBidXQgbm90IHByb2hpYml0ZWQpPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSA2cHQ7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj5Db250ZW50czogSWYgcHJlc2Vu dCwgdGhpcyBmaWVsZCBNVVNUIGNvbnRhaW4gYSBzaW5nbGUgSVAgYWRkcmVzcyBvciBGdWxseS1R dWFsaWZpZWQgRG9tYWluIE5hbWUgdGhhdCBpcyBvbmUgb2YgdGhlIHZhbHVlcyBjb250YWluZWQg aW4gdGhlIENlcnRpZmljYXRl4oCZcyBzdWJqZWN0QWx0TmFtZSBleHRlbnNpb24gKHNlZSBTZWN0 aW9uIDcuMS40LjIuMSkuPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSA2cHQ7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4N CjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj5NQVhJTVVNIExFTkdUSDombmJzcDsgTk8gU1RJ UFVMQVRJT04uJm5ic3A7IChUSElTIElTIEFOIEVYQ0VQVElPTiBUTyBSRkMgNTI4MCBXSElDSCBT UEVDSUZJRVMgQU4gVVBQRVIgQk9VTkQgT0YgNjQgQ0hBUkFDVEVSUy4pPG86cCBjbGFzcz0iIj48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSA2cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj5i LiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBDZXJ0aWZpY2F0ZSBGaWVsZDogc3ViamVjdDpvcmdhbml6YXRpb25OYW1lIChP SUQgMi41LjQuMTApPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSA2cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxz cGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj5PcHRpb25hbC4mbmJzcDs8c3BhbiBjbGFzcz0iQXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSA2cHQ7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj5Db250ZW50czog SWYgcHJlc2VudCwgdGhlIHN1YmplY3Q6b3JnYW5pemF0aW9uTmFtZSBmaWVsZCBNVVNUIGNvbnRh aW4gZWl0aGVyIHRoZSBTdWJqZWN04oCZcyBuYW1lIG9yIERCQSBhcyB2ZXJpZmllZCB1bmRlciBT ZWN0aW9uIDMuMi4yLjIuIFRoZSBDQSBtYXkgaW5jbHVkZSBpbmZvcm1hdGlvbiBpbiB0aGlzIGZp ZWxkIHRoYXQgZGlmZmVycyBzbGlnaHRseSBmcm9tIHRoZSB2ZXJpZmllZCBuYW1lLA0KIHN1Y2gg YXMgY29tbW9uIHZhcmlhdGlvbnMgb3IgYWJicmV2aWF0aW9ucywgcHJvdmlkZWQgdGhhdCB0aGUg Q0EgZG9jdW1lbnRzIHRoZSBkaWZmZXJlbmNlIGFuZCBhbnkgYWJicmV2aWF0aW9ucyB1c2VkIGFy ZSBsb2NhbGx5IGFjY2VwdGVkIGFiYnJldmlhdGlvbnM7IGUuZy4sIGlmIHRoZSBvZmZpY2lhbCBy ZWNvcmQgc2hvd3Mg4oCcQ29tcGFueSBOYW1lIEluY29ycG9yYXRlZOKAnSwgdGhlIENBIE1BWSB1 c2Ug4oCcQ29tcGFueSBOYW1lIEluYy7igJ0gb3Ig4oCcQ29tcGFueQ0KIE5hbWXigJ0uJm5ic3A7 IEJlY2F1c2UgU3ViamVjdCBuYW1lIGF0dHJpYnV0ZXMgZm9yIGluZGl2aWR1YWxzIChlLmcuIGdp dmVuTmFtZSAoMi41LjQuNDIpIGFuZCBzdXJuYW1lICgyLjUuNC40KSkgYXJlIG5vdCBicm9hZGx5 IHN1cHBvcnRlZCBieSBhcHBsaWNhdGlvbiBzb2Z0d2FyZSwgdGhlIENBIE1BWSB1c2UgdGhlIHN1 YmplY3Q6b3JnYW5pemF0aW9uTmFtZSBmaWVsZCB0byBjb252ZXkgYSBuYXR1cmFsIHBlcnNvbiBT dWJqZWN04oCZcyBuYW1lIG9yIERCQS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDZwdDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPk1BWElNVU0gTEVOR1RIOiZuYnNw OyAyNTYgQ0hBUkFDVEVSUyAoVEhJUyBJUyBBTiBFWENFUFRJT04gVE8gUkZDIDUyODAgV0hJQ0gg U1BFQ0lGSUVTIEFOIFVQUEVSIEJPVU5EIE9GIDY0IENIQVJBQ1RFUlMuKTxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBj bSAwY20gOHB0OyBsaW5lLWhlaWdodDogMTUuMzk5OTk5NjE4NTMwMjczcHg7IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIGxhbmc9IkVO LVVTIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDhwdDsgbGluZS1oZWlnaHQ6 IDE1LjM5OTk5OTYxODUzMDI3M3B4OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+VGhhbmtzLDxv OnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW46IDBjbSAwY20gOHB0OyBsaW5lLWhlaWdodDogMTUuMzk5OTk5NjE4NTMwMjczcHg7 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxz cGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj5CZW4gV2lsc29uPG86cCBjbGFzcz0iIj48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xh c3M9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3Nw YW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9 IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxv YXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+cGtpeA0KIG1h aWxpbmcgbGlzdDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFz cz0iIj48YSBocmVmPSJtYWlsdG86cGtpeEBpZXRmLm9yZyIgY2xhc3M9IiI+cGtpeEBpZXRmLm9y ZzwvYT48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wa2l4IiBjbGFz cz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BraXg8L2E+PC9zcGFu PjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_5408AFDFD15A4B5B842B1BC533D1DF58ttuedu_-- From nobody Mon Apr 10 10:59:23 2017 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 A1EC3129564 for ; Mon, 10 Apr 2017 10:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S-uK6o1mu6s for ; Mon, 10 Apr 2017 10:59:18 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5BAA129517 for ; Mon, 10 Apr 2017 10:59:17 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01D2B1E9.7CA54D30" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1491847154; h=from:subject:to:date:message-id; bh=JQD2lQA66F7bThtTxu37j8PQTQxfwTCTwVoIumPZMkA=; b=V7EW7FpMkm/YUR7vj9mbJHhYqDtX/HCZX2g9CWVkdGkUS290x7uYbLW3x4Cl+9KprVUCPON1ofB 67gT+iX7h6lgi/Y5tGlhA+l0iUd+6KN/tkVoFUy6w33BE20w0sfkr6RsiC+HG+tQS9rJmUQyGiDxz gA4VmAafdmjsZ2uY9tcxEnlkBXTe5FP4H6ENNcuQvECvjCM/35UsTkG7hz2hbkKPGT/4JoqfEqI3A 4ihCU89eVQF5M47tI45VJ0K8mQn2WiLGLwO4HQcGi+mz4XBRXFDtnmEOxPwL/lsm31mFghJ7gTQCt o4Ea9k1C8Jk/6DNWQb4bpIm8i0LOvMOkkFDA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Apr 2017 10:59:13 -0700 Received: from hebrews (192.168.0.98) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Apr 2017 10:59:11 -0700 From: Jim Schaad To: 'Jeremy Rowley' , 'Russ Housley' , 'Erik Andersen' CC: 'IETF PKIX' References: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> <27e9bc684735472bbd6d7f82b5e2823b@EX2.corp.digicert.com> <662C0D5C-EF34-4BD1-B3BC-B7B9A84B4990@vigilsec.com> <09BE38C5-7B5B-45B0-BC5F-5FCB1164F864@vigilsec.com> <000001d2b041$050c2310$0f246930$@x500.eu> <2D820AC4-81D0-44AC-BBE8-B8C74BD43BB0@vigilsec.com> In-Reply-To: Date: Mon, 10 Apr 2017 10:59:09 -0700 Message-ID: <002b01d2b224$28ff4330$7afdc990$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLbax/O6ZBps7Ft6UeYTkOEFrZPhAFLVKgvAbGqP3EBulwnngL84uHQAprq/+MCV8zYqAFrXzRzAXgCaooBc1RbvJ8lhEhQ X-Originating-IP: [192.168.0.98] Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 17:59:22 -0000 ------=_NextPart_000_002C_01D2B1E9.7CA54D30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 Jeremy, =20 My expectation is that this would be a relaxation on the issuing of = certificates for web servers. =20 I would worry that the relaxation would be general rather than just = focused on web servers. Additionally, things other than browsers will = attempt to contact these servers =20 Jim =20 From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Jeremy Rowley Sent: Monday, April 10, 2017 9:41 AM To: Russ Housley ; Erik Andersen Cc: IETF PKIX Subject: Re: [pkix] Amendment to CABF Baseline Requirements =20 Hi Russ - Considering the CA/Browser Forum rules only applies to browser = user agents, are you aware of any actual interoperability issues? =20 From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Russ Housley Sent: Saturday, April 8, 2017 11:47 AM To: Erik Andersen > Cc: IETF PKIX > Subject: Re: [pkix] Amendment to CABF Baseline Requirements =20 Erik: =20 The CA/Browser Forum seems to be finding the upper bounds in the X.500 = 5th edition and RFC 5280. I=E2=80=99m not sure how to relax them = without introducing interoperability concerns. =20 Russ =20 =20 On Apr 8, 2017, at 4:20 AM, Erik Andersen > wrote: =20 The change was made in the sixth edition of X.520 (2008). It was = primarily driven by Hoyt Kesterson and by some X.500/LDAP vendors. Hoyt = was generally against such limitations, as the future is difficult to = predict. X.500/LDAP vendors were concerned about interworking between = X.500 and LDAP (that does not have upper bounds). You may have noticed = that ASN.1 information objects now also contains LDAP specific fields = allowing also new attribute types to be usable also in an LDAP = environment without the need for additional specifications. =20 I insisted that the upper bounds should be kept in an informative annex = to be used by those having a requirement to limit the sizes. =20 I could, if you feel it relevant, try to suggest a Defect Report to = X.509 saying that it is strongly recommend to observe the upper bounds = specified in X.520. I will also try to get such a statement into any = smart grid security standard that references X.509. =20 Erik Fra: pkix [ mailto:pkix-bounces@ietf.org] = P=C3=A5 vegne af Russ Housley Sendt: 07 April 2017 22:43 Til: IETF PKIX < pkix@ietf.org> Emne: Re: [pkix] Amendment to CABF Baseline Requirements =20 The ASN.1 modules that were posted by Erik confirm that the upper bounds = have been removed for all of the naming attributes in the = SelectedAttributeTypes module. =20 UnboundedDirectoryString ::=3D CHOICE { teletexString TeletexString(SIZE (1..MAX)), printableString PrintableString(SIZE (1..MAX)), bmpString BMPString(SIZE (1..MAX)), universalString UniversalString(SIZE (1..MAX)), uTF8String UTF8String(SIZE (1..MAX)) } =20 Russ =20 =20 On Apr 7, 2017, at 3:15 AM, Erwann Abalea < = eabalea@gmail.com> wrote: =20 Bonjour, =20 2017-04-06 22:39 GMT+02:00 Peter Bowen < = pzbowen@gmail.com>: =20 On Thu, Apr 6, 2017 at 12:24 PM Russ Housley < = housley@vigilsec.com> wrote: The comment in the UpperBounds ASN.1 module (the 8th edition) says: -- EXPORTS All -- The types and values defined in this module are exported for use in = the other ASN.1 -- modules contained within these Directory Specifications, and for the = use of other -- applications which will use them to access Directory services. Other = applications -- may use them for their own purposes, but this will not constrain = extensions and -- modifications needed to maintain or improve the Directory service. X.509 is part of the Directory Specifications, so they are not advisory. It looks like ITU-T increased the length of the organizational unit name = in the most recent edition. RFC 5280 says: ub-organization-name-length INTEGER ::=3D 64 ub-organizational-unit-name-length INTEGER ::=3D 32 The UpperBounds ASN.1 module (the 8th edition) says: ub-organization-name INTEGER ::=3D 64 ub-organizational-unit-name INTEGER ::=3D 64 So, we may already be in a place where implementations conforming to = X.509 will produce a certificate that cannot be decoded by an = implementation that conforms to RFC 5280. I wish we gad gotten a heads-up =E2=80=A6 =20 It is even worse. 7th and 8th (and maybe prior releases) removed the = usage of ub- from the schema. The schema itself no longer bounds = DirectoryStrings and X.509 explicitly says they are unbounded.=20 =20 X.520 2005 defines the attributes using the DirectoryString{} = parameterized type, while the 2008 edition uses the = UnboundedDirectoryString type. =20 RFC5912, which proposes ASN.1 modules for certificates and other related = things, still uses the DirectoryString{} variant. =20 --=20 Erwann. =20 _______________________________________________ pkix mailing list pkix@ietf.org = https://www.ietf.org/mailman/listinfo/pkix =20 ------=_NextPart_000_002C_01D2B1E9.7CA54D30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

Jeremy,<= /o:p>

 

My = expectation is that this would be a relaxation on the issuing of = certificates for web servers.

 

I would = worry that the relaxation would be general rather than just focused on = web servers.=C2=A0 Additionally, things other than browsers will attempt = to contact these servers

 

Jim

 

From:<= /b> = pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Jeremy = Rowley
Sent: Monday, April 10, 2017 9:41 AM
To: Russ = Housley <housley@vigilsec.com>; Erik Andersen = <era@x500.eu>
Cc: IETF PKIX = <pkix@ietf.org>
Subject: Re: [pkix] Amendment to CABF = Baseline Requirements

 

Hi Russ - = Considering the CA/Browser Forum rules only applies to browser user = agents, are you aware of any actual interoperability = issues?

 

From:<= /b> = pkix [mailto:pkix-bounces@ietf.org] = On Behalf Of Russ Housley
Sent: Saturday, April 8, 2017 = 11:47 AM
To: Erik Andersen <era@x500.eu>
Cc: IETF PKIX = <pkix@ietf.org>
Subject: = Re: [pkix] Amendment to CABF Baseline = Requirements

 

Erik:

 

The CA/Browser Forum seems to be finding the upper = bounds in the X.500 5th edition and RFC 5280.  I=E2=80=99m not sure = how to relax them without introducing interoperability = concerns.

 

Russ

 

 

On Apr 8, 2017, at 4:20 AM, Erik Andersen <era@x500.eu> = wrote:

 

The change was made in the sixth edition of X.520 (2008). It was = primarily driven by Hoyt Kesterson and by some X.500/LDAP vendors. Hoyt = was generally against such limitations, as the future is difficult to = predict. X.500/LDAP vendors were concerned about interworking between = X.500 and LDAP (that does not have upper bounds). You may have noticed = that ASN.1 information objects now also contains LDAP specific fields = allowing also new attribute types to be usable also in an LDAP = environment without the need for additional = specifications.

 

I insisted that the upper bounds should be kept in an informative annex = to be used by those having a requirement to limit the = sizes.

 

I could, if you feel it relevant, try to suggest a Defect Report to = X.509 saying that it is strongly recommend to observe the upper bounds = specified in X.520. I will also try to get such a statement into any = smart grid security standard that references = X.509.

 

Erik

Fra: = pkix [mailto:pkix-bounces@ietf.org] P=C3=A5 vegne af Russ = Housley
Sendt: 07 April 2017 = 22:43
Til: IETF PKIX <pkix@ietf.org>
Emne: Re: [pkix] Amendment to CABF = Baseline Requirements

 

The ASN.1 modules that were posted by Erik confirm = that the upper bounds have been removed for all of the naming attributes = in the SelectedAttributeTypes module.

 

UnboundedDirectoryString ::=3D CHOICE = {

  = teletexString    TeletexString(SIZE = (1..MAX)),

  printableString  PrintableString(SIZE = (1..MAX)),

  bmpString       =  BMPString(SIZE (1..MAX)),

  universalString  UniversalString(SIZE = (1..MAX)),

  uTF8String       UTF8String(SIZE = (1..MAX)) }

 

Russ

 

 

On Apr 7, 2017, at 3:15 AM, Erwann Abalea <eabalea@gmail.com> = wrote:

 

Bonjour,

 

2017-04-06 22:39 GMT+02:00 Peter Bowen <pzbowen@gmail.com>:

 

On Thu, Apr 6, 2017 at 12:24 PM Russ Housley <housley@vigilsec.com> = wrote:

The comment in the UpperBounds ASN.1 = module (the 8th edition) says:

-- EXPORTS All
-- The types and = values defined in this module are exported for use in the other = ASN.1
-- modules contained within these Directory Specifications, and = for the use of other
-- applications which will use them to access = Directory services. Other applications
-- may use them for their own = purposes, but this will not constrain extensions and
-- modifications = needed to maintain or improve the Directory service.

X.509 is = part of the Directory Specifications, so they are not = advisory.

It looks like ITU-T increased the length of the = organizational unit name in the most recent edition.

RFC 5280 = says:

ub-organization-name-length INTEGER ::=3D = 64
ub-organizational-unit-name-length INTEGER ::=3D 32

The = UpperBounds ASN.1 module (the 8th edition) = says:

ub-organization-name          =              INTEGER ::=3D = 64
ub-organizational-unit-name          =       INTEGER ::=3D 64

So, we may already be in a = place where implementations conforming to X.509 will produce a = certificate that cannot be decoded by an implementation that conforms to = RFC 5280.

I wish we gad gotten a heads-up = =E2=80=A6

 

It is even worse. 7th and 8th (and maybe prior = releases) removed the usage of ub- from the schema. The schema itself no = longer bounds DirectoryStrings and X.509 explicitly says they are = unbounded. 

=

 

X.520 2005 defines the attributes using the = DirectoryString{} parameterized type, while the 2008 edition uses the = UnboundedDirectoryString type.

 

RFC5912, which proposes ASN.1 modules for certificates = and other related things, still uses the DirectoryString{} = variant.

 

-- 

Erwann.

 

____________= ___________________________________
pkix mailing list
pkix@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/pkix">https://www.ietf.org/mailman/listinfo/pkix

 

------=_NextPart_000_002C_01D2B1E9.7CA54D30-- From nobody Mon Apr 10 14:31:48 2017 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 8A7D8126C22 for ; Mon, 10 Apr 2017 14:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UE-Ohc7GLhoI for ; Mon, 10 Apr 2017 14:31:44 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B2D126BF7 for ; Mon, 10 Apr 2017 14:31:43 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id d131so11972239qkc.3 for ; Mon, 10 Apr 2017 14:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VphNL8D64UXJ7JzYoFIM9BVRWlDuHHJTd+PCDfr1XMU=; b=Zj8PmbJMMCxVEq7IZ/BLkRWILzEp+8YLBI0+rf58qRXBAjGrqBqjYiIEyHbNXdaKoX gTlNDF6XsiU7u+S+HKbaDETraSuLnv/mfC4aSvcfn2LfH4cIjo3jVAqSn6IfWoMRu9mT t09jYHB2M8Mx06qaPkSu3q8ApdW3bwc1l13MU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VphNL8D64UXJ7JzYoFIM9BVRWlDuHHJTd+PCDfr1XMU=; b=g7Lr/S0BmGM5X6s6+uWW1jDslyKBbp9cMvhoB4x13ewJ6nhMHsHTvBFqNc0m01NPTP 5VHih5/IpvuvTqvXZqZM7cvW2prjGAiPmHBaUHgEBDGyIsZkdG5oZtBvGSws8ZOVLUKQ lJNhNjETpW9p96fYO/KTxqKeyvw9hAeqe8dObMXo6DoO/L4YwbAb66x4ENmiUGiDgtUS p59SvsvH2UeG2t608qHQO2o7r7wb+40LuRBhORdjjkwPbHvXnJyPwhyILxW0YPFJ6p8t tDbwvjCcq9jlyBIgz1YbGLEel7fIeM0jL2mXjjIp5IN+k7ewB/12B6xwv7Sft5uDpBRm RP2A== X-Gm-Message-State: AFeK/H0H4i7BqdXFzUa4jXQOJiGotlhn3JEajjhw9hJU1qCZfbW4fMeP6WxXAl4niYkc5g== X-Received: by 10.55.134.2 with SMTP id i2mr52308547qkd.43.1491859902757; Mon, 10 Apr 2017 14:31:42 -0700 (PDT) Received: from ?IPv6:2600:1000:b020:5545:8d3d:deb4:3c8c:18c8? ([2600:1000:b020:5545:8d3d:deb4:3c8c:18c8]) by smtp.gmail.com with ESMTPSA id x33sm3080948qtc.22.2017.04.10.14.31.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Apr 2017 14:31:42 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-AA83D147-C8E9-4878-A43F-DDDF3DD65D22 Mime-Version: 1.0 (1.0) From: Carl Wallace X-Mailer: iPhone Mail (14B100) In-Reply-To: <002b01d2b224$28ff4330$7afdc990$@augustcellars.com> Date: Mon, 10 Apr 2017 17:31:41 -0400 Cc: Jeremy Rowley , Russ Housley , Erik Andersen , IETF PKIX Content-Transfer-Encoding: 7bit Message-Id: References: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> <27e9bc684735472bbd6d7f82b5e2823b@EX2.corp.digicert.com> <662C0D5C-EF34-4BD1-B3BC-B7B9A84B4990@vigilsec.com> <09BE38C5-7B5B-45B0-BC5F-5FCB1164F864@vigilsec.com> <000001d2b041$050c2310$0f246930$@x500.eu> <2D820AC4-81D0-44AC-BBE8-B8C74BD43BB0@vigilsec.com> <002b01d2b224$28ff4330$7afdc990$@augustcellars.com> To: Jim Schaad Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 21:31:47 -0000 --Apple-Mail-AA83D147-C8E9-4878-A43F-DDDF3DD65D22 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Defining new OIDs for the new jumbo values seems like the right thing to do.= =20 > On Apr 10, 2017, at 1:59 PM, Jim Schaad wrote: >=20 > =20 > Jeremy, > =20 > My expectation is that this would be a relaxation on the issuing of certif= icates for web servers. > =20 > I would worry that the relaxation would be general rather than just focuse= d on web servers. Additionally, things other than browsers will attempt to c= ontact these servers > =20 > Jim > =20 > From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Jeremy Rowley > Sent: Monday, April 10, 2017 9:41 AM > To: Russ Housley ; Erik Andersen > Cc: IETF PKIX > Subject: Re: [pkix] Amendment to CABF Baseline Requirements > =20 > Hi Russ - Considering the CA/Browser Forum rules only applies to browser u= ser agents, are you aware of any actual interoperability issues? > =20 > From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Russ Housley > Sent: Saturday, April 8, 2017 11:47 AM > To: Erik Andersen > Cc: IETF PKIX > Subject: Re: [pkix] Amendment to CABF Baseline Requirements > =20 > Erik: > =20 > The CA/Browser Forum seems to be finding the upper bounds in the X.500 5th= edition and RFC 5280. I=E2=80=99m not sure how to relax them without intro= ducing interoperability concerns. > =20 > Russ > =20 > =20 > On Apr 8, 2017, at 4:20 AM, Erik Andersen wrote: > =20 > The change was made in the sixth edition of X.520 (2008). It was primarily= driven by Hoyt Kesterson and by some X.500/LDAP vendors. Hoyt was generally= against such limitations, as the future is difficult to predict. X.500/LDAP= vendors were concerned about interworking between X.500 and LDAP (that does= not have upper bounds). You may have noticed that ASN.1 information objects= now also contains LDAP specific fields allowing also new attribute types to= be usable also in an LDAP environment without the need for additional speci= fications. > =20 > I insisted that the upper bounds should be kept in an informative annex to= be used by those having a requirement to limit the sizes. > =20 > I could, if you feel it relevant, try to suggest a Defect Report to X.509 s= aying that it is strongly recommend to observe the upper bounds specified in= X.520. I will also try to get such a statement into any smart grid security= standard that references X.509. > =20 > Erik > Fra: pkix [mailto:pkix-bounces@ietf.org] P=C3=A5 vegne af Russ Housley > Sendt: 07 April 2017 22:43 > Til: IETF PKIX > Emne: Re: [pkix] Amendment to CABF Baseline Requirements > =20 > The ASN.1 modules that were posted by Erik confirm that the upper bounds h= ave been removed for all of the naming attributes in the SelectedAttributeTy= pes module. > =20 > UnboundedDirectoryString ::=3D CHOICE { > teletexString TeletexString(SIZE (1..MAX)), > printableString PrintableString(SIZE (1..MAX)), > bmpString BMPString(SIZE (1..MAX)), > universalString UniversalString(SIZE (1..MAX)), > uTF8String UTF8String(SIZE (1..MAX)) } > =20 > Russ > =20 > =20 > On Apr 7, 2017, at 3:15 AM, Erwann Abalea wrote: > =20 > Bonjour, > =20 > 2017-04-06 22:39 GMT+02:00 Peter Bowen : > =20 > On Thu, Apr 6, 2017 at 12:24 PM Russ Housley wrote:= > The comment in the UpperBounds ASN.1 module (the 8th edition) says: >=20 > -- EXPORTS All > -- The types and values defined in this module are exported for use in the= other ASN.1 > -- modules contained within these Directory Specifications, and for the us= e of other > -- applications which will use them to access Directory services. Other ap= plications > -- may use them for their own purposes, but this will not constrain extens= ions and > -- modifications needed to maintain or improve the Directory service. >=20 > X.509 is part of the Directory Specifications, so they are not advisory. >=20 > It looks like ITU-T increased the length of the organizational unit name i= n the most recent edition. >=20 > RFC 5280 says: >=20 > ub-organization-name-length INTEGER ::=3D 64 > ub-organizational-unit-name-length INTEGER ::=3D 32 >=20 > The UpperBounds ASN.1 module (the 8th edition) says: >=20 > ub-organization-name INTEGER ::=3D 64 > ub-organizational-unit-name INTEGER ::=3D 64 >=20 > So, we may already be in a place where implementations conforming to X.509= will produce a certificate that cannot be decoded by an implementation that= conforms to RFC 5280. >=20 > I wish we gad gotten a heads-up =E2=80=A6 > =20 > It is even worse. 7th and 8th (and maybe prior releases) removed the usage= of ub- from the schema. The schema itself no longer bounds DirectoryStrings= and X.509 explicitly says they are unbounded.=20 > =20 > X.520 2005 defines the attributes using the DirectoryString{} parameterize= d type, while the 2008 edition uses the UnboundedDirectoryString type. > =20 > RFC5912, which proposes ASN.1 modules for certificates and other related t= hings, still uses the DirectoryString{} variant. > =20 > --=20 > Erwann. > =20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > =20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail-AA83D147-C8E9-4878-A43F-DDDF3DD65D22 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Defining new OIDs for the n= ew jumbo values seems like the right thing to do. 

On Apr= 10, 2017, at 1:59 PM, Jim Schaad <ietf@augustcellars.com> wrote:

 

Jeremy,

 

My expectation is that this would be a relaxation on the issuing o= f certificates for web servers.

= =  

I would worry that the re= laxation would be general rather than just focused on web servers.  Add= itionally, things other than browsers will attempt to contact these servers<= o:p>

 

Jim

&nbs= p;

From: pkix [mailto:pkix-bounces@ietf.o= rg] On Behalf Of Jeremy Rowley
Sent: Monday, April 10, 2= 017 9:41 AM
To: Russ Housley <housley@vigilsec.com>; Erik Andersen <era@x500.eu>
Cc: IETF PKIX <pkix@ietf.org>
Subject: Re: [pkix] Amendment= to CABF Baseline Requirements

 

Hi Russ - Considering= the CA/Browser Forum rules only applies to browser user agents, are you awa= re of any actual interoperability issues?

 

From: pkix [mail= to:pkix-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Saturday, April 8, 2017 11:47 AM
To: Erik Andersen <era@x500.eu>
Cc: IETF PKIX <pkix@ietf.org>
Subject: Re: [pkix= ] Amendment to CABF Baseline Requirements

<= p class=3D"MsoNormal"> 

Erik:=

 

The CA/Browser Forum seems to be finding the upper bounds i= n the X.500 5th edition and RFC 5280.  I=E2=80=99m not sure how to rela= x them without introducing interoperability concerns.

 

Russ

 <= /p>

 

On= Apr 8, 2017, at 4:20 AM, Erik Andersen <e= ra@x500.eu> wrote:

&n= bsp;

The change was m= ade in the sixth edition of X.520 (2008). It was primarily driven by Hoyt Ke= sterson and by some X.500/LDAP vendors. Hoyt was generally against such limi= tations, as the future is difficult to predict. X.500/LDAP vendors were conc= erned about interworking between X.500 and LDAP (that does not have upper bo= unds). You may have noticed that ASN.1 information objects now also contains= LDAP specific fields allowing also new attribute types to be usable also in= an LDAP environment without the need for additional specifications.<= o:p>

 <= o:p>

I insisted tha= t the upper bounds should be kept in an informative annex to be used by thos= e having a requirement to limit the sizes.

<= p class=3D"MsoNormal"> 

<= p class=3D"MsoNormal">I could, if you feel it relevant, try to= suggest a Defect Report to X.509 saying that it is strongly recommend to ob= serve the upper bounds specified in X.520. I will also try to get such a sta= tement into any smart grid security standard that references X.509.

 

Erik

Fra:=  pkix [mailto:pkix-bounce= s@ietf.org] = P=C3=A5 vegne af Russ H= ousley
Sendt: 07= April 2017 22:43
Til: = IETF PKIX <pkix@ietf.org>
Emne: Re: [pkix] Amendment to CABF Baseline Requirements=

 

The ASN.1 modules that were p= osted by Erik confirm that the upper bounds have been removed for all of the= naming attributes in the SelectedAttributeTypes module.

 

UnboundedDirectoryString ::=3D CHOICE {

  teletexString &nb= sp;  TeletexString(SIZE (1..MAX)),

=

  printableString  PrintableString(SIZE (1.= .MAX)),

  bm= pString        BMPString(SIZE (1..MAX)),

<= /div>

  universalString  Uni= versalString(SIZE (1..MAX)),

  uTF8String       UTF8String(SIZE (1..MAX))= }

 

Russ

 

 

On Apr 7, 2017, at 3:15 AM, Erwann Abalea <eabalea@gmail.com>= wrote:

 

Bonjour,

 

2017-04-06 22:39 GMT+02:00 Peter Bowen <pzbowen@gmail.com>:

 

On Thu, Apr 6, 2017 at 12:24 PM Russ Housley <hous= ley@vigilsec.com> wrote:

The comment in the UpperBounds ASN.1 module (th= e 8th edition) says:

-- EXPORTS All
-- The types and values define= d in this module are exported for use in the other ASN.1
-- modules conta= ined within these Directory Specifications, and for the use of other
-- a= pplications which will use them to access Directory services. Other applicat= ions
-- may use them for their own purposes, but this will not constrain e= xtensions and
-- modifications needed to maintain or improve the Director= y service.

X.509 is part of the Directory Specifications, so they are= not advisory.

It looks like ITU-T increased the length of the organi= zational unit name in the most recent edition.

RFC 5280 says:

= ub-organization-name-length INTEGER ::=3D 64
ub-organizational-unit-name-= length INTEGER ::=3D 32

The UpperBounds ASN.1 module (the 8th edition= ) says:

ub-organization-name           =            INTEGER ::=3D 64
ub-organizatio= nal-unit-name                INTEGER= ::=3D 64

So, we may already be in a place where implementations conf= orming to X.509 will produce a certificate that cannot be decoded by an impl= ementation that conforms to RFC 5280.

I wish we gad gotten a heads-up= =E2=80=A6

 

It is eve= n worse. 7th and 8th (and maybe prior releases) removed the usage of ub- fro= m the schema. The schema itself no longer bounds DirectoryStrings and X.509 e= xplicitly says they are unbounded. 

 

=

X.520 2005 defines the attributes usi= ng the DirectoryString{} parameterized type, while the 2008 edition uses the= UnboundedDirectoryString type.

 

RFC5912, which proposes ASN.1 modules for certificates and other relate= d things, still uses the DirectoryString{} variant.

 

-- 

Erwann.<= /p>

 

_________= ______________________________________
pkix mailing list
pkix@ietf.org
https:= //www.ietf.org/mailman/listinfo/pkix

 

_______________________= ________________________
pkix mailing list
<= a href=3D"mailto:pkix@ietf.org">pkix@ietf.org
https://www.ietf.org/mailman/li= stinfo/pkix
= --Apple-Mail-AA83D147-C8E9-4878-A43F-DDDF3DD65D22-- From nobody Tue Apr 11 07:41:11 2017 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 7C9931294F5 for ; Tue, 11 Apr 2017 07:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gFndBgVeybF for ; Tue, 11 Apr 2017 07:41:05 -0700 (PDT) Received: from mail04.dandomain.dk (mail04.dandomain.dk [194.150.112.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9BD129C43 for ; Tue, 11 Apr 2017 07:41:04 -0700 (PDT) Received: from Morten ([62.44.134.242]) by mail04.dandomain.dk (DanDomain Mailserver) with ASMTP id 4201704111640596212; Tue, 11 Apr 2017 16:40:59 +0200 From: "Erik Andersen" To: "'Sill, Alan'" Cc: References: <906f1c1dde4f44789646197d887da312@EX2.corp.digicert.com> <000001d2b20c$f8031930$e8094b90$@x500.eu> <5408AFDF-D15A-4B5B-842B-1BC533D1DF58@ttu.edu> In-Reply-To: <5408AFDF-D15A-4B5B-842B-1BC533D1DF58@ttu.edu> Date: Tue, 11 Apr 2017 16:40:58 +0200 Message-ID: <000001d2b2d1$a24b2b70$e6e18250$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D2B2E2.65D92B90" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLbax/O6ZBps7Ft6UeYTkOEFrZPhAGf44tjAkMwlZ+fjzjN0A== Content-Language: en-gb Archived-At: Subject: Re: [pkix] Amendment to CABF Baseline Requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 14:41:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D2B2E2.65D92B90 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Alan, =20 I have no intention to deprecate commonName. It was a kind of = provocation, but I could consider recommending it not to be used in = specific environments. =20 The basic ideas for an attribute specification was that it has a = specific syntax and in particular, an associated semantics independent = of the environment. By using commonName for all kind of syntaxes and all = kind of semantics, this principle has been violated. =20 Erik =20 Fra: Sill, Alan [mailto:alan.sill@ttu.edu]=20 Sendt: 10 April 2017 19:55 Til: Erik Andersen Cc: Sill, Alan ; pkix@ietf.org Emne: Re: [pkix] Amendment to CABF Baseline Requirements =20 Erik,=20 =20 Before proceeding with any attempt to deprecate the use of commonName, = may I recommend that you read the contents of the OGF=E2=80=99s = =E2=80=9CInteroperable Certificate Profile=E2=80=9D that focuses on = non-browser applications of use of directory names, attributes, and = extensions in X.509 certificates, such that they are usable by the = majority of scientific cyber-infrastructures as supported by the IGTF? =20 This document is available in its most recent form at = https://www.ogf.org/documents/gfd.225.pdf =20 In particular, commonName is a required component of certificates used = in such infrastructures and deprecation would cause a great deal of = damage to deployed infrastructures for large-scale grid and cloud = computing. =20 Thanks, Ala =20 =20 On Apr 10, 2017, at 10:13 AM, Erik Andersen > wrote: =20 Hi Ben and others, I responded to the upper bound issue before reading Ben=E2=80=99s = question. I have a comment not related to the commonName attribute type. = The commonName is being (mis)used for all kind of things, so you cannot = know what the syntax really is, which should cause interworking = problems. The use of commonName should possibly be deprecated. As to use the commonName for holding an FQDN, it is a little = problematic. The matching rule for FQDNs is a little more complicated = than the one for commonName. X.520 has a dsnName attribute type and as = it is rather new it has not upper bound specification. It is defined as: 6.2.15 Domain name A value of attribute type dnsName is used for holding a DNS domain name, = which may be an internationalized domain name (IDN). =20 dnsName ATTRIBUTE ::=3D { WITH SYNTAX DomainName EQUALITY MATCHING RULE dnsNameMatch LDAP-SYNTAX dnsString.&id LDAP-NAME {"DNS name"} ID id-at-dnsName } =20 DomainName ::=3D UTF8String (CONSTRAINED BY { -- Conforms to the format = of a (internationalized) domain name. -- }) A value of the DomainName data type shall be in the syntax, as specified = by section 2.3.1 of IETF RFC 5890 meaning that a domain name is a = sequence of labels in the letters, digits, hyphen (LDH) format separated = by dots. A label may be in three formats: a) All characters in the label are from the Basic Latin collection = as defined by ISO/IEC 10646 (i.e., having code points in the ranges = 002D, 0030-0039, 0041-005A and 0061-007A) and it does not start with = "xn--". The maximum length is 63 octets. b) It is an A-label as defined in IETF RFC 5890, i.e., it starts = with the "xn--" and is a U-label converted to valid ASCII characters as = in item a) using the Punycode algorithm defined by IETF RFC 3492. The = converted string shall be maximum 59 octets. To be valid, it shall be = possible for an A-label to be converted to a valid U-label. NOTE 1 =E2=80=93 An A-label is normally not human readable. c) It is a U-label as defined in IETF RFC 5890, i.e., it contains = characters outside the Basic Latin collection. A valid U-label shall not = include any characters that are not included in the restricted Unicode = repertoire as defined by IETF RFC 5892 and it shall be convertible to a = valid A-label as defined in item b). A valid U-label may be more than 63 = octets. NOTE 2 =E2=80=93 In a constraint environment, it is recommended to use a = domain name whenever possible, according to item a). NOTE 3 =E2=80=93 When used as a naming attribute, a unique distinguished = name may be constructed using only this attribute type. An attribute of type dnsName to be used as a distinguished name in a = public-key certificate or in an attribute certificate shall be a = fully-qualified domain name (FQDN), i.e., it shall identify a particular = entity. An FQDN may have an asterisk ('*') as an additional leftmost = label, which is a substitute (wildcard) for all labels at the next = levels of subdomains of the domain identified by the FQDN without the = asterisk. An attribute of type dnsName holding an FQDN with a wildcard = label may in some cases be used in the subject component of an = end-entity public-key certificate. The corresponding matching rule is defined as: 8.9.2 DNS name match The dnsNameMatch compares two values of type dnsName for equality and is = defined as: =20 dnsNameMatch MATCHING-RULE ::=3D { SYNTAX DomainName LDAP-SYNTAX dnsString.&id LDAP-NAME {"dnsNameMatch"} ID id-mr-dnsNameMatch } The equality matching is performed label for label. If the number of the = labels in the two attribute values are different, the rule shall return = FALSE. The rule shall return TRUE for each pair of labels matched for = the rule to return TRUE for the two values. Otherwise, it shall return = FALSE. The matching of the individual labels shall be performed as = follows: a) If one of the labels to be compared is of the type defined in = item a) of clause 6.2.15 and the other label is either an A-label or a = U-label as defined in IETF RFC 5890, the rule shall return FALSE. b) If the two labels are of the same type, they shall be compared = following the rules for caseIgnoreMatch. c) If one the labels is of type A-label and the other one is of type = U-label, the latter shall be converted to an A-label before comparison = following the rules for caseIgnoreMatch. In addition, the following applies if one or both of the values have = wildcard ('*') labels: d) If at least one of the values contains more than one wildcard = label or if a wildcard label is not the leftmost label, the rule shall = return FALSE. e) If one or both the values has a wildcard as the leftmost label, = the remaining labels shall be matched as stated in a) to c) above and = shall return TRUE or FALSE accordingly. NOTE =E2=80=93 The effect of the wildcard match is that *. = example.com will match = a.example.com and b.example.com but not = a.b.example.com nor = example.com. =20 Erik Fra: pkix [ mailto:pkix-bounces@ietf.org] = P=C3=A5 vegne af Ben Wilson Sendt: 06 April 2017 18:24 Til: pkix@ietf.org Emne: [pkix] Amendment to CABF Baseline Requirements =20 Does anyone want to comment on my draft amendment to the CA/Browser = Forum=E2=80=99s Baseline Requirements for SSL/TLS Certificates which = would remove the 64-character limit on the commonName and = organizationName, as an exception to RFC 5280? The text of the = relevant Baseline Requirement provision is found below with the proposed = additional language in ALL CAPS. The reason for the first change = (commonName) is there are FQDNs (in Subject Alternative Names) that are = longer than 64 characters. The reason for the second change = (organizationName) is that there are organizations with names longer = than 64 characters. =20 7.1.4.2.2. Subject Distinguished Name Fields a. Certificate Field: subject:commonName (OID 2.5.4.3) =20 Required/Optional: Deprecated (Discouraged, but not prohibited) Contents: If present, this field MUST contain a single IP address or = Fully-Qualified Domain Name that is one of the values contained in the = Certificate=E2=80=99s subjectAltName extension (see Section 7.1.4.2.1). MAXIMUM LENGTH: NO STIPULATION. (THIS IS AN EXCEPTION TO RFC 5280 = WHICH SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) b. Certificate Field: subject:organizationName (OID 2.5.4.10) Optional. =20 Contents: If present, the subject:organizationName field MUST contain = either the Subject=E2=80=99s name or DBA as verified under Section = 3.2.2.2. The CA may include information in this field that differs = slightly from the verified name, such as common variations or = abbreviations, provided that the CA documents the difference and any = abbreviations used are locally accepted abbreviations; e.g., if the = official record shows =E2=80=9CCompany Name Incorporated=E2=80=9D, the = CA MAY use =E2=80=9CCompany Name Inc.=E2=80=9D or =E2=80=9CCompany = Name=E2=80=9D. Because Subject name attributes for individuals (e.g. = givenName (2.5.4.42) and surname (2.5.4.4)) are not broadly supported by = application software, the CA MAY use the subject:organizationName field = to convey a natural person Subject=E2=80=99s name or DBA. MAXIMUM LENGTH: 256 CHARACTERS (THIS IS AN EXCEPTION TO RFC 5280 WHICH = SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.) =20 Thanks, Ben Wilson _______________________________________________ pkix mailing list pkix@ietf.org = https://www.ietf.org/mailman/listinfo/pkix =20 ------=_NextPart_000_0001_01D2B2E2.65D92B90 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Alan,

 

I have no intention to deprecate commonName. = It was a kind of provocation, but I could consider recommending it not = to be used in specific environments.

 

The basic ideas for an attribute = specification was that it has a specific syntax and in particular, an = associated semantics independent of the environment. By using commonName = for all kind of syntaxes and all kind of semantics, this principle has = been violated.

 

Erik

 

Fra: = Sill, Alan [mailto:alan.sill@ttu.edu]
Sendt: 10 April 2017 = 19:55
Til: Erik Andersen <era@x500.eu>
Cc: = Sill, Alan <alan.sill@ttu.edu>; pkix@ietf.org
Emne: Re: = [pkix] Amendment to CABF Baseline = Requirements

 

Erik, =

 

Before proceeding with any attempt to deprecate the = use of commonName, may I recommend that you read the contents of the = OGF=E2=80=99s =E2=80=9CInteroperable Certificate Profile=E2=80=9D that = focuses on non-browser applications of use of directory names, = attributes, and extensions in X.509 certificates, such that they are = usable by the majority of scientific cyber-infrastructures as supported = by the IGTF?

 

This document is available in its most recent form = at https://www.ogf.org/do= cuments/gfd.225.pdf

 

In particular, commonName is a required component of = certificates used in such infrastructures and deprecation would cause a = great deal of damage to deployed infrastructures for large-scale grid = and cloud computing.

 

Thanks,

Ala

 

 

On Apr 10, 2017, at 10:13 AM, Erik Andersen <era@x500.eu> = wrote:

 

Hi Ben and others,

I responded to the upper bound issue before reading Ben=E2=80=99s = question. I have a comment not related to the commonName attribute type. = The commonName is being (mis)used for all kind of things, so you cannot = know what the syntax really is, which should cause interworking = problems. The use of commonName should possibly be = deprecated.

As to use the commonName for holding an FQDN, it is a little = problematic. The matching rule for FQDNs is a little more complicated = than the one for commonName. X.520 has a dsnName attribute type and as = it is rather new it has not upper bound specification. It is defined = as:

6.2.15      Domain = name

A value of = attribute type dnsName = is used for = holding a DNS domain name, which may be an internationalized domain name = (IDN).

 

dnsName ATTRIBUTE ::=3D {

  WITH = SYNTAX           &= nbsp; DomainName

  EQUALITY MATCHING RULE  = dnsNameMatch

  = LDAP-SYNTAX          &n= bsp;  dnsString.&id

  = LDAP-NAME          &nbs= p;    {"DNS = name"}

  = ID            = ;          id-at-dnsName = }

 

DomainName ::=3D UTF8String (CONSTRAINED BY { -- Conforms to the = format of a (internationalized) domain name. -- = })

A value of = the DomainName = data type = shall be in the syntax, as specified by section 2.3.1 of IETF RFC 5890 = meaning that a domain name is a sequence of labels in the letters, = digits, hyphen (LDH) format separated by dots.

A label may = be in three formats:

a)     All = characters in the label are from the Basic Latin collection as defined = by ISO/IEC 10646 (i.e., having code points in the ranges 002D, = 0030-0039, 0041-005A and 0061-007A) and it does not start with = "xn--". The maximum length is 63 = octets.

b)     It is = an A-label as defined in IETF RFC 5890, i.e., it starts with the = "xn--" and is a U-label converted to valid ASCII characters as = in item a) using the Punycode algorithm defined by IETF RFC 3492. The = converted string shall be maximum 59 octets. To be valid, it shall be = possible for an A-label to be converted to a valid = U-label.

NOTE 1 =E2=80=93 An A-label is normally not = human readable.

c)     It is = a U-label as defined in IETF RFC 5890, i.e., it contains characters = outside the Basic Latin = collection. A valid U-label shall not include any characters that are = not included in the restricted Unicode repertoire as defined by IETF RFC = 5892 and it shall be convertible to a valid A-label as defined in item = b). A valid U-label may be more than 63 octets.

NOTE 2 =E2=80=93 In a constraint environment, = it is recommended to use a domain name whenever possible, according to = item a).

NOTE 3 =E2=80=93 When used as a naming = attribute, a unique distinguished name may be constructed using only = this attribute type.

An attribute = of type dnsName = to be used = as a distinguished name in a public-key certificate or in an attribute = certificate shall be a fully-qualified domain name (FQDN), i.e., it = shall identify a particular entity. An FQDN may have an asterisk ('*') = as an additional leftmost label, which is a substitute (wildcard) for = all labels at the next levels of subdomains of the domain identified by = the FQDN without the asterisk. An attribute of type dnsName holding an = FQDN with a wildcard label may in some cases be used in the subject = component of = an end-entity public-key certificate.

The corresponding matching rule is defined as:

8.9.2       = ; DNS name match

The dnsNameMatch = compares two = values of type dnsName = for equality = and is defined as:

 

dnsNameMatch MATCHING-RULE ::=3D = {

  = SYNTAX       = DomainName

  LDAP-SYNTAX  = dnsString.&id

  LDAP-NAME =    {"dnsNameMatch"}

  = ID           = id-mr-dnsNameMatch }

The equality = matching is performed label for label. If the number of the labels in = the two attribute values are different, the rule shall return FALSE. The = rule shall return TRUE for each pair of labels matched for the rule to = return TRUE for the two values. Otherwise, it shall return FALSE. The = matching of the individual labels shall be performed as = follows:

a)     If one = of the labels to be compared is of the type defined in item a) of clause = 6.2.15 and the other label is either an A-label or a U-label as defined = in IETF RFC 5890, the rule shall return FALSE.

b)     If the = two labels are of the same type, they shall be compared following the = rules for caseIgnoreMatch.

c)     If one = the labels is of type A-label and the other one is of type U-label, the = latter shall be converted to an A-label before comparison following the = rules for caseIgnoreMatch.

In addition, = the following applies if one or both of the values have wildcard ('*') = labels:

d)     If at = least one of the values contains more than one wildcard label or if a = wildcard label is not the leftmost label, the rule shall return = FALSE.

e)     If one = or both the values has a wildcard as the leftmost label, the remaining = labels shall be matched as stated in a) to c) above and shall return = TRUE or FALSE accordingly.

NOTE =E2=80=93 The effect of the wildcard = match is that *.example.com will match a.example.com and b.example.com but not a.b.example.com nor example.com.

 

Erik

Fra: = pkix = [mailto:pkix-b= ounces@ietf.org] P=C3=A5 vegne af Ben = Wilson
Sendt: 06 April 2017 = 18:24
Til: pkix@ietf.org=
Emne:<= /b> [pkix] Amendment to = CABF Baseline Requirements

 

Does anyone = want to comment on my draft amendment to the CA/Browser Forum=E2=80=99s = Baseline Requirements for SSL/TLS Certificates which would remove the = 64-character limit on the commonName and organizationName,  as an = exception to RFC 5280?  The text of the relevant Baseline = Requirement provision is found below with the proposed additional = language in ALL CAPS.  The reason for the first change (commonName) = is there are FQDNs (in Subject Alternative Names) that are longer than = 64 characters.  The reason for the second change (organizationName) = is that there are organizations with names longer than 64 = characters.

 =

7.1.4.2.2.&nb= sp;            = Subject Distinguished Name Fields

a.  = ;          Certificate = Field: subject:commonName (OID 2.5.4.3)  

Required/Opti= onal: Deprecated (Discouraged, but not prohibited)

Contents: If = present, this field MUST contain a single IP address or Fully-Qualified = Domain Name that is one of the values contained in the = Certificate=E2=80=99s subjectAltName extension (see Section = 7.1.4.2.1).

MAXIMUM = LENGTH:  NO STIPULATION.  (THIS IS AN EXCEPTION TO RFC 5280 = WHICH SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.)

b.  = ;          Certificate = Field: subject:organizationName (OID 2.5.4.10)

Optional.&nbs= p; 

Contents: If = present, the subject:organizationName field MUST contain either the = Subject=E2=80=99s name or DBA as verified under Section 3.2.2.2. The CA = may include information in this field that differs slightly from the = verified name, such as common variations or abbreviations, provided that = the CA documents the difference and any abbreviations used are locally = accepted abbreviations; e.g., if the official record shows = =E2=80=9CCompany Name Incorporated=E2=80=9D, the CA MAY use = =E2=80=9CCompany Name Inc.=E2=80=9D or =E2=80=9CCompany = Name=E2=80=9D.  Because Subject name attributes for individuals = (e.g. givenName (2.5.4.42) and surname (2.5.4.4)) are not broadly = supported by application software, the CA MAY use the = subject:organizationName field to convey a natural person = Subject=E2=80=99s name or DBA.

MAXIMUM = LENGTH:  256 CHARACTERS (THIS IS AN EXCEPTION TO RFC 5280 WHICH = SPECIFIES AN UPPER BOUND OF 64 CHARACTERS.)

 =

Thanks,

Ben = Wilson

____________= ___________________________________
pkix mailing list
pkix@ietf.or= g
<= a href=3D"https://www.ietf.org/mailman/listinfo/pkix">https://www.= ietf.org/mailman/listinfo/pkix

 

------=_NextPart_000_0001_01D2B2E2.65D92B90--