Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-08.txt

From: [email-masked]
Date: Tue, 12 Aug 2014 17:44:42 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF.

        Title           : A Profile for BGPSEC Router Certificates, Certificate Revocation Lists, and Certification Requests
        Authors         : Mark Reynolds
                          Sean Turner
                          Steve Kent
	Filename        : draft-ietf-sidr-bgpsec-pki-profiles-08.txt
	Pages           : 13
	Date            : 2014-08-12

Abstract:
   This document defines a standard profile for X.509 certificates for
   the purposes of supporting validation of Autonomous System (AS) paths
   in the Border Gateway Protocol (BGP), as part of an extension to that
   protocol known as BGPSEC.  BGP is a critical component for the proper
   operation of the Internet as a whole.  The BGPSEC protocol is under
   development as a component to address the requirement to provide
   security for the BGP protocol.  The goal of BGPSEC is to design a
   protocol for full AS path validation based on the use of strong
   cryptographic primitives.  The End-Entity (EE) certificates specified
   by this profile are issued under Resource Public Key Infrastructure
   (RPKI) Certification Authority (CA) certificates, containing the AS
   Identifier Delegation extension, to routers within the Autonomous
   System (AS).  The certificate asserts that the router(s) holding the
   private key are authorized to send out secure route advertisements on
   behalf of the specified AS.  This document also profiles the
   Certificate Revocation List (CRL), profiles the format of
   certification requests, and specifies Relying Party certificate path
   validation procedures.  The document extends the RPKI; therefore,
   this documents updates the RPKI Resource Certificates Profile (RFC
   6487).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-08

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Sean Turner <[email-masked]>
Date: Tue, 12 Aug 2014 20:47:35 -0400

This version incorporates the change discussed at IETF 90 - namely include one and only one AS in the certificate.

The working version is also available at:
   https://github.com/seanturner/draft-ietf-sidr-bgpsec-pki-profiles

spt

On Aug 12, 2014, at 20:44, [email-masked] wrote:

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 13 Aug 2014 12:42:29 -0400

speaking as regular ol' member

A question about wording.

I understand the wording change in 3.1.1 (used to be 3.1.1.1) that results from the change from multiple ASs in a cert to a single AS in a cert.

But there is also a wording change having to do with multiple routers sharing the same key pair.

The wording went from:

                                   If the same certificate is issued to more
   than one router (hence the private key is shared among these
   routers), the choice of the router ID used in this name is at the
   discretion of the Issuer.

to:

                                                      If more than one certificate
   for an AS is issued (i.e., more than one router gets a certificate
   for the AS and hence the private key is shared among more than one
   router), the choice of the router ID used in Subject name is at the
   discretion of the Issuer.

I don't understand the new wording.  If all routers in an AS have different keys, then there would be multiple certificates issued for the AS, but no sharing of keys and no confusion over the router ID to be used in each router's cert.  Right?

Apologies if I'm just not parsing the new sentence correctly.  The previous wording was fine with me.

[The certificate request format does not include the subject name anyway, so it looks to me like the subject name is ALWAYS at the discretion of the issuer.  No?)

--Sandy, speaking as regular ol' member

On Aug 12, 2014, at 8:47 PM, Sean Turner <[email-masked]> wrote:

> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr