Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed;
 boundary="Apple-Mail=_F8D5961F-E6A1-478B-93A8-87A154064F04";
 protocol="application/pgp-signature"; micalg=pgp-sha512
From: Sandra Murphy <sandy@tislabs.com>
In-Reply-To: <a7252aa1-c522-ff42-979c-1b09c6c06406@bbn.com>
Date: Tue, 19 Jul 2016 12:32:43 -0400
Message-Id: <8F7345B9-7F4E-45E2-A74B-808BBE93BB96@tislabs.com>
References: <20160708091943.32156.30842.idtracker@ietfa.amsl.com>
 <C570AE8F-A764-43ED-B273-005DABBDC836@ripe.net>
 <a7252aa1-c522-ff42-979c-1b09c6c06406@bbn.com>
To: Stephen Kent <kent@bbn.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/VlXYmNU7Vh1KW2_de5LezsvL6WM>
Cc: sidr@ietf.org, Sandra Murphy <sandy@tislabs.com>
Subject: Re: [sidr] I-D Action:
 draft-ietf-sidr-rpki-validation-reconsidered-06.txt
Precedence: list


--Apple-Mail=_F8D5961F-E6A1-478B-93A8-87A154064F04
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Speaking as regular ol=92 member:

> On Jul 15, 2016, at 1:28 PM, Stephen Kent <kent@bbn.com> wrote:
>=20
> Tim,
>=20
> I reviewed the -06 version and am attaching a pdf of the MS Word file =
with suggested edits. I can send you the word file itself if you wish.
>=20
> I have provided text to my co-author, Sean, to include in the =
bgpsec-pki-profile doc to address your concern. I suggested the =
following text at the beginning of section 3 :
>=20
>    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)
> , but using the
>    constraints applied come from this specification.

I can=92t parse =93but using the constraints applied come from this =
specification=94.  Can you clarify?

>=20
>=20
> Sean added an implementation considerations section which I suggest =
will say:
>=20
>    Operators MAY choose to issue separate BGPsec Router Certificates =
for
>    different ASNs. Doing so may prevent a BGPsec Router Certificate =
from
>    becoming invalid if one of the ASNs is removed from any superior CA =
certificate
>    along the path to a trust anchor.

I quibble about this wording.  why do you say =93may=94?  Is it because =
if the ASN in one of the separate router certificates is one of the ASNs =
that is removed, then it still becomes invalid?

I think you mean:


This document permits the operator to include a list of ASNs in a BGPsec =
Router Certificate.
In that case, the router certificate would become invalid if any one of =
the ASNs is removed
from any superior CA certificate along the path to a trust anchor.  =
Operators MAY choose
to avoid this possibility by issuing a separate BGPsec Router =
Certificate for each distinct
ASN, so that the router certificates for ASNs that are retained in the =
superior CA certificate
would remain valid.

I=92m not sure you meant a normative =93MAY choose=94 ("there are =
reasons, <listed here,> to make this choice=94) or =93could possibly =
choose=94

>=20
>=20
> I hope these changes avoid the need to say anything about router certs =
in your doc.
>=20
> I'm not sure there is a need to change the ROA spec. If we agree that =
all prefixes in the ROA MUST be contained in the EE cert for that ROA, =
then the current text in the ROA spec does not need to change.

Well=85=85

The ROA RFC says validation of the ROA must satisfy:

   o  The IP address delegation extension [RFC3779] is present in the
      end-entity (EE) certificate (contained within the ROA), and each
      IP address prefix(es) in the ROA is contained within the set of IP
      addresses specified by the EE certificate's IP address delegation
      extension.

If the EE certificate and the ROA mention a /18, and a /19 is removed =
from a =93superior CA certificate=94, then there is/are only a /19 of =
the EE certificate that is/are VRP.  And every prefix in the ROA is =
still contained in the EE cert, so this validation step is satisfied.  =
What does this ROA now authorized?  How would it be applied in BGP route =
validation?

=97Sandy, speaking as regular ol=92 member

>=20
> Steve
>=20
> =
<draft-ietf-sidr-rpki-validation-reconsidered-06.pdf>_____________________=
__________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr


--Apple-Mail=_F8D5961F-E6A1-478B-93A8-87A154064F04
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJXjlY5AAoJEHplpQeet0IZfyYQAKsXZpMNwy7j9rcHCvPwgcSb
OraA+coog1Bmlh2+W+lMX7ueOCz/MI8li5PGuvUp7CvNT+mLrT2DUH+0EZaksMe+
NKo7FJGv/FBniYZuTDEaYxg6/IO61dcETxO9GTIBtCVqREbP5MqcDpXhKZl+RS4p
EVAob1g4j9AD+7EbsGvQ7fIzEaRcavrBLkYSbeLG/xOxvuTKB14NT3R9X6lhmnF6
agXPekcTjdEkgLr1cLF+3u+6NtHcQOH24y/o1hEsQw8mabit1SRay3ckIFOhO3b8
OqNKTM4X++6FOfOpJn/DXgKqcPvAZAJp4U7VyZbtLzybaqc8zObEXsTgLIYUbENU
F9nj4pyacEVgBKeGdxTKG0VmtFG2LNnZu3pVTj25TC84EuyflZGXmn51ecT7bWY2
udM/K5VM1gK3t4otWgnxdnbQzgrSaMV9jffwg2xf3AFsdqgjy2HgmyzQbg717mFg
4uY1eCd5pbY9wljGG7PmKQPpbGq6X3L8+oFFP1MxTuWfl53bcYW6iZSuCoQ4xIQh
eBFYyY1I/oi3GgL3nZwRIqGUAE9CXMd1Evjx4N4JLSdU1KD17XSbpx7BonrcffgG
KRp21y8f7FPxZQMToSoua+YuS+F2rEbQI+cbHfU3zGaeL/x5GybEGPShRrGvWKJy
obJQXMjSEuzLxKth4sTc
=4Yhk
-----END PGP SIGNATURE-----

--Apple-Mail=_F8D5961F-E6A1-478B-93A8-87A154064F04--