Re: [pkix] [Editorial Errata Reported] RFC5280 (4274)
Carl Wallace <carl@redhoundsoftware.com> Fri, 20 February 2015 18:43 UTC
Return-Path: <carl@redhoundsoftware.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E781A0074 for <pkix@ietfa.amsl.com>; Fri, 20 Feb 2015 10:43:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.6
X-Spam-Level:
X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RdjV5LkqtEc for <pkix@ietfa.amsl.com>; Fri, 20 Feb 2015 10:43:28 -0800 (PST)
Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CEDE1A3BA9 for <pkix@ietf.org>; Fri, 20 Feb 2015 10:43:23 -0800 (PST)
Received: by qcvp6 with SMTP id p6so2180893qcv.9 for <pkix@ietf.org>; Fri, 20 Feb 2015 10:43:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-type:content-transfer-encoding; bh=IUxYJTZBmrWCtw1Hk+tMHbwNxTKFDYsblJZH7g7Gvq8=; b=YjwXgQuab9jLxNrxZO0AHaUS1VQdmCXedmuXucr1D4cClP5Eu8mUF4ZAPdFn4xFPdp R9sqdYXovDl+OhQbqbM5ckHZJe8EKjwKdksHZIRySQzwrq8Pl49hJFao/xgJAdSIpGJ4 7YYSL7HOCqf8/fqZFMbicnUfHS77ctv97W7O+HcfGpnnRhfPQ6FvBEgzKRJc0Zm86UXr 6uvEIJjMh/klGjfvPSiyPpo+CJK2NVBSdZ0lsaLoi1wiSKvV/JHG4mUq8gYnZoyyZ5SH iaaCDq8a/WYr2i9Cbc3NpIrKyo92p+o/jdDN3ujPB6jiyykbRs/zIiseV9cYC8+kSfAX aq/A==
X-Gm-Message-State: ALoCoQk8pBJVSyv5IUkmWe9R+me6z1c7MhG0QTihpReKFXHVdZ/x+HDBofV8rvrh520kBhIrHaqU
X-Received: by 10.140.216.201 with SMTP id m192mr27679005qhb.26.1424457802660; Fri, 20 Feb 2015 10:43:22 -0800 (PST)
Received: from [192.168.2.27] (pool-96-255-230-90.washdc.fios.verizon.net. [96.255.230.90]) by mx.google.com with ESMTPSA id 7sm12325978qhv.8.2015.02.20.10.43.21 for <pkix@ietf.org> (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 20 Feb 2015 10:43:22 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.4.7.141117
Date: Fri, 20 Feb 2015 13:43:19 -0500
From: Carl Wallace <carl@redhoundsoftware.com>
To: pkix@ietf.org
Message-ID: <D10CEA25.2E32D%carl@redhoundsoftware.com>
Thread-Topic: [pkix] [Editorial Errata Reported] RFC5280 (4274)
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/2edoGevxAi1XrWEcJD8msQ5DOt0>
Subject: Re: [pkix] [Editorial Errata Reported] RFC5280 (4274)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Feb 2015 18:43:30 -0000
<resending because first attempt yesterday got routed to the moderator’s queue> Is this really an errata? Seems more like an invitation to interoperability problems. Same issues will apply to 5912 too if this route is pursued. On 2/19/15, 8:33 PM, "Stefan Santesson" <stefan@aaa-sec.com> wrote: >These size limitations are gone in the >current edition of X.520 > >In X.520 2001 edition, surname as example was defined as: > >surname ATTRIBUTE ::= { >SUBTYPE OF name >WITH SYNTAX DirectoryString{ub-surname} >ID id-at-surname >} > > >Where Directory string is size limited by the upper bound ub-surname > >ub-surname >INTEGER ::= 64 > >In the current edition of X.520 (102012) the definition is instead: > >surname ATTRIBUTE ::= { >SUBTYPE OF name >WITH SYNTAX UnboundedDirectoryString >LDAP-SYNTAX directoryString.&id >LDAP-NAME {"sn"} >ID id-at-surname >} > > >Where UnboundedDirectoryString no longer is bounded to the old ub-surname >size limit. > >The same is true for all attributes listed in this errata. > >/Stefan > > > >On 19/02/15 11:43, "RFC Errata System" <rfc-editor@rfc-editor.org> wrote: > >>The following errata report has been submitted for RFC5280, >>"Internet X.509 Public Key Infrastructure Certificate and Certificate >>Revocation List (CRL) Profile". >> >>-------------------------------------- >>You may review the report below and at: >>http://www.rfc-editor.org/errata_search.php?rfc=5280&eid=4274 >> >>-------------------------------------- >>Type: Editorial >>Reported by: Ilya V. Matveychikov <i.matveychikov@securitycode.ru> >> >>Section: A.1 >> >>Original Text >>------------- >>-- Naming attributes of type X520CommonName: >>-- X520CommonName ::= DirectoryName (SIZE (1..ub-common-name)) >> >>... >> >>-- Naming attributes of type X520LocalityName: >>-- X520LocalityName ::= DirectoryName (SIZE (1..ub-locality-name)) >> >>... >> >>-- Naming attributes of type X520StateOrProvinceName: >>-- X520StateOrProvinceName ::= DirectoryName (SIZE (1..ub-state-name)) >> >>... >> >>-- Naming attributes of type X520OrganizationName: >>-- X520OrganizationName ::= >>-- DirectoryName (SIZE (1..ub-organization-name)) >> >>... >> >>-- Naming attributes of type X520OrganizationalUnitName: >>-- X520OrganizationalUnitName ::= >>-- DirectoryName (SIZE (1..ub-organizational-unit-name)) >> >>... >> >>-- Naming attributes of type X520Title: >>-- X520Title ::= DirectoryName (SIZE (1..ub-title)) >> >>... >> >>-- Naming attributes of type X520Pseudonym: >>-- X520Pseudonym ::= DirectoryName (SIZE (1..ub-pseudonym)) >> >> >>Corrected Text >>-------------- >>-- Naming attributes of type X520CommonName: >>-- X520CommonName ::= DirectoryString (SIZE (1..ub-common-name)) >> >>... >> >>-- Naming attributes of type X520LocalityName: >>-- X520LocalityName ::= DirectoryString (SIZE (1..ub-locality-name)) >> >>... >> >>-- Naming attributes of type X520StateOrProvinceName: >>-- X520StateOrProvinceName ::= >>-- DirectoryString (SIZE (1..ub-state-name)) >> >>... >> >>-- Naming attributes of type X520OrganizationName: >>-- X520OrganizationName ::= >>-- DirectoryString (SIZE (1..ub-organization-name)) >> >>... >> >>-- Naming attributes of type X520OrganizationalUnitName: >>-- X520OrganizationalUnitName ::= >>-- DirectoryString (SIZE (1..ub-organizational-unit-name)) >> >>... >> >>-- Naming attributes of type X520Title: >>-- X520Title ::= DirectoryString (SIZE (1..ub-title)) >> >>... >> >>-- Naming attributes of type X520Pseudonym: >>-- X520Pseudonym ::= DirectoryString (SIZE (1..ub-pseudonym)) >> >> >>Notes >>----- >>Appendix B. ASN.1 Notes says that: >> >> For many of the attribute types defined in [X.520], the >> AttributeValue uses the DirectoryString type. Of the attributes >> specified in Appendix A, the name, surname, givenName, initials, >> generationQualifier, commonName, localityName, stateOrProvinceName, >> organizationName, organizationalUnitName, title, and pseudonym >> attributes all use the DirectoryString type. X.520 uses a >> parameterized type definition [X.683] of DirectoryString to specify >> the syntax for each of these attributes. The parameter is used to >> indicate the maximum string length allowed for the attribute. In >> Appendix A, in order to avoid the use of parameterized type >> definitions, the DirectoryString type is written in its expanded form >> for the definition of each of these attribute types. So, the ASN.1 >> in Appendix A describes the syntax for each of these attributes as >> being a CHOICE of TeletexString, PrintableString, UniversalString, >> UTF8String, and BMPString, with the appropriate constraints on the >> string length applied to each of the types in the CHOICE, rather than >> using the ASN.1 type DirectoryString to describe the syntax. >> >>There is nothing about DirectoryName type here. So comments in ASN.1 in >>A.1 are wrong and DirectoryName should be fixed to DirectoryString. >> >>Instructions: >>------------- >>This erratum is currently posted as "Reported". If necessary, please >>use "Reply All" to discuss whether it should be verified or >>rejected. When a decision is reached, the verifying party (IESG) >>can log in to change the status and edit the report, if necessary. >> >>-------------------------------------- >>RFC5280 (draft-ietf-pkix-rfc3280bis-11) >>-------------------------------------- >>Title : Internet X.509 Public Key Infrastructure >>Certificate and Certificate Revocation List (CRL) Profile >>Publication Date : May 2008 >>Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. >>Housley, W. Polk >>Category : PROPOSED STANDARD >>Source : Public-Key Infrastructure (X.509) >>Area : Security >>Stream : IETF >>Verifying Party : IESG >> > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix
- [pkix] [Errata Held for Document Update] RFC5280 … RFC Errata System
- [pkix] [Editorial Errata Reported] RFC5280 (4274) RFC Errata System
- Re: [pkix] [Editorial Errata Reported] RFC5280 (4… Stefan Santesson
- Re: [pkix] [Editorial Errata Reported] RFC5280 (4… Carl Wallace
- Re: [pkix] [Editorial Errata Reported] RFC5280 (4… Carl Wallace
- Re: [pkix] [Editorial Errata Reported] RFC5280 (4… Martin Rex
- Re: [pkix] [Editorial Errata Reported] RFC5280 (4… Stefan Santesson
- Re: [pkix] [Editorial Errata Reported] RFC5280 (4… Erik Andersen
- [pkix] FW: [Editorial Errata Reported] RFC5280 (4… Sharon Boeyen
- Re: [pkix] [Editorial Errata Reported] RFC5280 (4… Stephen Kent
- Re: [pkix] [Editorial Errata Reported] RFC5280 (4… Jeremy Rowley
- Re: [pkix] [Editorial Errata Reported] RFC5280 (4… Carl Wallace
- Re: [pkix] [Editorial Errata Reported] RFC5280 (4… Jeremy Rowley