Re: [sidr] [Gen-art] Review of draft-ietf-sidr-bgpsec-pki-profiles-19

Jari Arkko <jari.arkko@piuha.net> Thu, 05 January 2017 11:10 UTC

Return-Path: <jari.arkko@piuha.net>
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 1D58312946E; Thu, 5 Jan 2017 03:10:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5
X-Spam-Level:
X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no
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 a8GvAqXloNfy; Thu, 5 Jan 2017 03:10:41 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCF412943F; Thu, 5 Jan 2017 03:10:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9C1852D291; Thu, 5 Jan 2017 13:10:40 +0200 (EET) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVm8NeDMpQ1k; Thu, 5 Jan 2017 13:10:40 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id F3D9B2D290; Thu, 5 Jan 2017 13:10:39 +0200 (EET) (envelope-from jari.arkko@piuha.net)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_454B6028-C164-4E50-B231-A60C76316BBB"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <148346011373.28055.14231244831041167421.idtracker@ietfa.amsl.com>
Date: Thu, 05 Jan 2017 13:10:39 +0200
Message-Id: <AA19FD72-E9F8-4CC5-BC21-D5CCDFB9C53E@piuha.net>
References: <148346011373.28055.14231244831041167421.idtracker@ietfa.amsl.com>
To: Dale Worley <worley@ariadne.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/YvSlZnzegArolpJ81a-71lPDsDs>
Cc: gen-art@ietf.org, draft-ietf-sidr-bgpsec-pki-profiles.all@ietf.org, ietf@ietf.org, sidr@ietf.org
Subject: Re: [sidr] [Gen-art] Review of draft-ietf-sidr-bgpsec-pki-profiles-19
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 05 Jan 2017 11:10:43 -0000

Dale, all,

Thanks for the review, re-review, and changes. I’m posting a No Objection position for this draft in today’s IESG telechat.

But:

> 3.1.1.  Subject
> 
>   However, each
>   certificate issued by an individual CA MUST contain a Subject name
>   that is unique to that CA context.
> 
> E-mail from Sean Turner on 22 Dec 2016 says:
> 
>    I think this is just a case of a missing "CA" in front of the
> word
>    "context" so tweaking it to: ".... that is unique to that CA
>    context".  The certs only need to be unique on a per CA basis the
>    subject name does not need to be unique across the whole of the
>    RPKI.  The combination of issuer+subject+serial # plus all the
>    parent certs provides the uniqueness.
> 
> However, there doesn't seem to be a standard meaning of the phrase
> "CA
> context".  I can't find any occurrences in any RFC or in any I-D
> other
> than draft-ietf-trans-threat-analysis-NN.

Is a good question.

> It seems to me that the best solution is to put a cleaned-up version
> of Sean's statement "The combination of issuer+subject+serial # plus
> all parent certs provides the uniqueness." into the draft, as that is
> admirably clear.  (Unless, of course, there is a standard PKI phrase
> for that requirement, in which case that could be used.)  For
> instance:
> 
>   However, the combination of subject name, serial number, issuer,
>   and certification path must be globally unique.

That would be clearer for me, assuming that is what was actually meant, of course :-)

> 3.3.  BGPsec Router Certificate Validation
> 
>   The validation procedure used for BGPsec Router Certificates is
>   identical to the validation procedure described in Section 7 of
>   [RFC6487] (and any RFC that updates this procedure), as modified
>   below.  For example, in step 3: "The certificate contains all
> field
>   that must be present" - refers to the fields that are required by
>   this specification.
> 
> This picks up the changes from Sean Turner's e-mail of 22 Dec 2016
> except it omits changing "that updates this procedure" to "that
> updates that procedure", which seems to me to necessary to make the
> wording correct.

I think that’s right.

>   step 3: "The certificate contains all field that must be present"
> 
> This doesn't match the text in RFC 6487, despite claiming to be
> quoted:
> s/all field/all fields/ and s/must/MUST/.

Right.

> 7.  IANA Considerations
> 
>   No IANA allocations are request of IANA, ...
> 
> I think this should be "No IANA allocations are requested of IANA",
> or
> probably better "No allocations are requested of IANA".
> 
> E-mail from Sean Turner on 22 Dec 2016 says "Alvaro had a similar
> comment on the IANA considerations and he suggested the first
> option.", but no change has been made.

OK

Jari