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

[Sean Turner <[e-mail]>]

On Aug 13, 2014, at 12:42, Sandra Murphy <[e-mail]> 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 <[e-mail]> 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, [e-mail] 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
>>> [e-mail]
>>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidr
>