Re: [Sidrops] proposed, revised text for Section 6

Tim Bruijnzeels <tim@nlnetlabs.nl> Thu, 07 May 2020 09:00 UTC

Return-Path: <tim@nlnetlabs.nl>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524BE3A085D for <sidrops@ietfa.amsl.com>; Thu, 7 May 2020 02:00:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=nlnetlabs.nl
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 s2TFYtow39YH for <sidrops@ietfa.amsl.com>; Thu, 7 May 2020 02:00:41 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (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 D1BA03A084A for <sidrops@ietf.org>; Thu, 7 May 2020 02:00:40 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:1cf9:f327:7f8b:f81b] (unknown [IPv6:2001:981:4b52:1:1cf9:f327:7f8b:f81b]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id E8D422D12C; Thu, 7 May 2020 11:00:38 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1588842038; bh=wb3UeW1Gfc0E/FsCdE9RWF7haH8uMJALzhGLNijHpes=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=p9f2rPBqGBzapOeGDO92mtqL84zQYRoEDD5+kSi8JckUjCpf87yGpDcNad1WZWxSY Yr+vcCMQCCqAWxlM7q/YEBjpq2HgTcTxnu3PDDIke9H2mj2FbgMD05EbHp4cSPsRqx jGqzlxJyJbOuvyc9CHDfBM/voPd4k9FKENgFNGSs=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <507640b8-30e7-9f95-e6ed-adba12efb090@verizon.net>
Date: Thu, 7 May 2020 11:00:38 +0200
Cc: Oleg Muravskiy <oleg@ripe.net>, "sidrops@ietf.org" <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7A134E0C-52E1-4FAD-A4E6-D971EFCDC63E@nlnetlabs.nl>
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net> <1065C1CC-191A-4CFF-A87C-4F1CB165F303@ripe.net> <507640b8-30e7-9f95-e6ed-adba12efb090@verizon.net>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/LjPjXNjeTkh64JuzTrotuBDdHbA>
Subject: Re: [Sidrops] proposed, revised text for Section 6
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 May 2020 09:00:42 -0000

Hi Steve,

> On 6 May 2020, at 22:09, Stephen Kent <stkent=40verizon.net@dmarc.ietf.org> wrote:
> 
>> I wonder how far we should get with listing all possible inconsistencies in this document, but from my developer’s perspective I think  we should list as much as possible, if we want RP software to behave in the same way.
> agreed.  I will try to address the inconsistencies you noted; feel free to suggest others.
>> 
>> Going through what we described in RFC8488, one of such inconsistencies is when manifest contains more than one CRL entry.
> RFC 8488 talks only about the requirement to omit the optional CRL filed in the generic CMS format we adopted. It does not address the issue you mention here, i.e., what if the manifest includes more than one CRL. But, I agree that there does not appear to be an explicit prohibition of having more than one CRL enumerated in a manifest. We should say this explicitly. Next question: what do we do if we encounter more than one?
>> Another is when the manifest is not in the publication point of a CA certificate. There are two distinct links from the CA certificate – one to the publication point, and one to the manifest. 
> yes, and 6487 does not say that the manifest must be in the directory specified by the pub point URI (id-ad-caRepository) Maybe we should revise 6487 to make that a requirement. I can address that here as well.
>> Technically, the manifest link could contain different directory than a publication point link. If you discover a manifest by following the manifest link, and follow the rules applied above, using the link from the CA cert (and not the location of the manifest), you would not catch this discrepancy.
>> Also note  that similar discrepancy could exist with the CRL location (as it also has its own link from the cert), but that one is covered by the new text above.
> yes, 6487 does not require the CRLDP to point to a file in the pub point specified by the id-ad-caRepository URL in the CA cert. Again, how about a revision to 6487 to clarify this? It would make life simpler.
> 

I agree.

I think all CA implementations already do the following, which is implied by RFC 6487 and 6481 in particular. But the text is not sufficiently explicit. Updates will help, especially RP software.

* There is only ever one (1!) *current* CA certificate issued for a given key (implied by RFC6492)
* This CA certificate has the following SIA entries:
    - id-ad-caRepository pointing to its full publication point
    - id-ad-rpkiManifest pointing to a manifest in that publication point
    - (still optionally) id-ad-rpkiNotify pointing to the RRDP (RFC 8182) notification file

* For a CA certificate (i.e. a single key) there will be ONE current MFT only
* For a CA certificate (i.e. a single key) there will be ONE current CRL only
* That CRL name and hash MUST match the one and only .crl file on the MFT
* Any issued (EE or CA) certificate under this CA certificate (single key) MUST use a CRLDP that matches the name of this .crl file, under the issuing CA certificate's id-ad-caRepository

Did I miss anything still?

Tim