On Aug 13, 2014, at 12:42, Sandra Murphy <sa...@tislabs.com> wrote: > 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?)
Yep the issuer always gets to determine the subject name as per RFC 6487 s4.5 so how about we just leave that bit out and make that sentence a note: Note that more than one certificate can be issued to an AS (i.e., more than one router can get a certificate for the AS and hence the private key is shared among more than one router). I guess the follow on question is whether we also point out that a router could support more than one AS but having key pairs for each AS: Also note that routers can support multiple ASs with separate keys pairs one for each AS. or something like that? spt > --Sandy, speaking as regular ol' member > > > On Aug 12, 2014, at 8:47 PM, Sean Turner <turn...@ieca.com> wrote: > >> 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, internet-dra...@ietf.org wrote: >> >>> >>> 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/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> i-d-annou...@ietf.org >>> 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 >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
