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

Stewart Bryant <> Mon, 06 May 2013 13:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39A8D21F8F17 for <>; Mon, 6 May 2013 06:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -109.949
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yZFoCgsguWz4 for <>; Mon, 6 May 2013 06:16:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 555F321F8FAF for <>; Mon, 6 May 2013 06:16:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; 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 ([]) by with ESMTP; 06 May 2013 13:16:20 +0000
Received: from ( []) by (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 []) by (8.14.4+Sun/8.8.8) with ESMTP id r46DGFe1011499; Mon, 6 May 2013 14:16:15 +0100 (BST)
Message-ID: <>
Date: Mon, 06 May 2013 14:16:15 +0100
From: Stewart Bryant <>
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 <>
References: <> <> <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:,,,, RFC Errata System <>
Subject: Re: [sidr] [Technical Errata Reported] RFC6487 (3174)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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