Re: [sidr] [Technical Errata Reported] RFC6487 (3238)

Randy Bush <randy@psg.com> Thu, 31 May 2012 22:55 UTC

Return-Path: <randy@psg.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8884A21F861C for <sidr@ietfa.amsl.com>; Thu, 31 May 2012 15:55:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.501
X-Spam-Level:
X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHdGZvqeObsv for <sidr@ietfa.amsl.com>; Thu, 31 May 2012 15:55:48 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 077AC21F85D7 for <sidr@ietf.org>; Thu, 31 May 2012 15:55:48 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <randy@psg.com>) id 1SaEHT-000Ixu-GJ for sidr@ietf.org; Thu, 31 May 2012 22:55:47 +0000
Date: Fri, 01 Jun 2012 07:55:46 +0900
Message-ID: <m2vcjcq7t9.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: sidr wg list <sidr@ietf.org>
In-Reply-To: <2BAE4694-60C2-4301-BFAF-05DF49054BF4@cisco.com>
References: <20120531145543.F363272E004@rfc-editor.org> <2BAE4694-60C2-4301-BFAF-05DF49054BF4@cisco.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: [sidr] [Technical Errata Reported] RFC6487 (3238)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 May 2012 22:55:48 -0000

>> The following errata report has been submitted for RFC6487,
>> "A Profile for X.509 PKIX Resource Certificates".
>> 
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=6487&eid=3238
>> 
>> --------------------------------------
>> Type: Technical
>> Reported by: Stephen Kent <kent@bbn.com>
>> 
>> Section: 6.3
>> 
>> Original Text
>> -------------
>> ExtendedKeyUsage
>>         The CA MAY honor ExtendedKeyUsage extensions of keyCertSign and
>>         cRLSign if present, as long as this is consistent with the
>>         BasicConstraints SubjectType sub-field, when specified.
>> 
>> Corrected Text
>> --------------
>> ExtendedKeyUsage
>>         The CA MAY honor ExtendedKeyUsage extensions in requests for EE
>>         certificates that are issued to routers or other devices, consistent with values
>>         specified in Standards Track RFCs that adopt this profile and that identify
>>         application-specific requirements that motivate the use of such EKUs.
>> 
> 
> I agree that this correction make sense. I also agree on the restriction to uses that are compatible with this profile rather than the complete registry list. We already have RFC 6494 as example.
> 
> Roque
> 
> 
> 
> 
>> Notes
>> -----
>> The current text appears to be the result of a "cut and paste" error. It is essentially identical to the text 
>> for the Key Usage extension, and names two fields that appear in that extension, not in an EKU extension. The text I propose above parallels what appears in Section 4.8.5, which describes how an
>> EKU MAY be used in RPKI certificates.
>> 
>> Instructions:
>> -------------
>> This errata is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary. 
>> 
>> --------------------------------------
>> RFC6487 (draft-ietf-sidr-res-certs-22)
>> --------------------------------------
>> Title               : A Profile for X.509 PKIX Resource Certificates
>> Publication Date    : February 2012
>> Author(s)           : G. Huston, G. Michaelson, R. Loomans
>> Category            : PROPOSED STANDARD
>> Source              : Secure Inter-Domain Routing
>> Area                : Routing
>> Stream              : IETF
>> Verifying Party     : IESG

while i agree that the change is correct, this is not an erratum, but an
actual change in semantics.

randy