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

Stewart Bryant <stbryant@cisco.com> Mon, 06 May 2013 13:16 UTC

Return-Path: <stbryant@cisco.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 39A8D21F8F17 for <sidr@ietfa.amsl.com>; Mon, 6 May 2013 06:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.949
X-Spam-Level:
X-Spam-Status: No, score=-109.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZFoCgsguWz4 for <sidr@ietfa.amsl.com>; Mon, 6 May 2013 06:16:30 -0700 (PDT)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 555F321F8FAF for <sidr@ietf.org>; Mon, 6 May 2013 06:16:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1754; q=dns/txt; s=iport; t=1367846190; x=1369055790; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=d3bl9WLclkHPGECSH6PZDnkrQstOcyjbGGOreIuw6vY=; b=U8kXKRE0XIvO8iTlS0e0FRVbgoMykaqStdwxiNvwnLQlbaokSkfgpNbH 556obQA7Iv0fW8S0S+oM9ISLzWdDLoCHsAFMEDGKdAfCTiJka/9XdtPFe CRkN9QDpLmzyOOLbBrgUr4+C0swh8YTfK/IxHpY4kjWaZHzRPa1G5SR8f M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjEFAIysh1GQ/khL/2dsb2JhbABQgwe8UoJngQQWdIIfAQEBBDhAARALDgoJFg8JAwIBAgFFBg0BBwEBiAi/V41kgU0Hg1MDly6RNIMO
X-IronPort-AV: E=Sophos;i="4.87,621,1363132800"; d="scan'208";a="13298516"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 06 May 2013 13:16:20 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r46DGIqu016771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 May 2013 13:16:18 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r46DGFe1011499; Mon, 6 May 2013 14:16:15 +0100 (BST)
Message-ID: <5187AD1F.7010109@cisco.com>
Date: Mon, 06 May 2013 14:16:15 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: David Mandelberg <dmandelb@bbn.com>
References: <20120403182631.92C0072E004@rfc-editor.org> <0B52207B-078C-4651-BEB2-3A667934E6B7@apnic.net> <1333560064.10619.36.camel@titan>
In-Reply-To: <1333560064.10619.36.camel@titan>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Sandra.Murphy@sparta.com, morrowc@ops-netman.net, sidr@ietf.org, ggm@apnic.net, RFC Errata System <rfc-editor@rfc-editor.org>
Subject: Re: [sidr] [Technical Errata Reported] RFC6487 (3174)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
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: Mon, 06 May 2013 13:16:36 -0000

On 04/04/2012 18:21, David Mandelberg wrote:
> On Wed, 2012-04-04 at 09:27 +1000, Geoff Huston wrote:
>> I'm tending to a "reject". Section 4.8.3 does not precisely apply to CRLs, so to accept this would then require a further errata notice to amend this errata to narrow down the scope of the AIA further.
> AKI, not AIA. I just meant that the CRL AKI should have the same format
> and meaning as in 4.8.3, i.e. it should use the SHA-1 hash of the
> issuer's public key with neither authorityCertIssuer nor
> authorityCertSerialNumber fields present. Maybe the errata should be
> rejected and resubmitted with text copied and edited from 4.8.3, instead
> of referencing 4.8.3?
>
>
>> Given that the text already says:  "The algorithm used in CRLs issued under this profile is specified in [RFC6485]." then I'm not not what futerhe specification is required here.
> What part of RFC6485 says anything about CRL AKIs? The closest I can
> find is in Section 2:
>
>           NOTE: The exception to the above hashing algorithm is the use
>           of SHA-1 [SHS] when Certification Authorities (CAs) generate
>           authority and subject key identifiers [RFC6487].
>
> That maybe could be interpreted as saying that CRL AKIs should use
> SHA-1, but it doesn't say that authorityCertIssuer and
> authorityCertSerialNumber must be absent. It also doesn't explicitly say
> what to take the SHA-1 of when generating a CRL AKI.
>

As far as I can see the thread died at this point.

I have rejected the errata.

I see two ways forward, either submit a new errata that describes the
correction in a way that has consensus, or roll the change into the
update required to address the issue raised in errata 3168.

- Stewart