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

[internet-drafts]

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 of the IETF.

Title   : A Profile for BGPsec Router Certificates, Certificate 
Revocation Lists, and Certification Requests
Authors : Mark Reynolds
  Sean Turner
  Stephen Kent
Filename: draft-ietf-sidr-bgpsec-pki-profiles-18.txt
Pages   : 13
Date: 2016-07-21

Abstract:
   This document defines a standard profile for X.509 certificates used
   to enable 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 the standard for inter-domain routing in the
   Internet; it is the "glue" that holds the Internet together. BGPsec
   is being developed as one component of a solution that addresses the
   requirement to provide security for BGP.  The goal of BGPsec is to
   provide full AS path validation based on the use of strong
   cryptographic primitives.  The end-entity (EE) certificates specified
   by this profile are issued (to routers within an Autonomous System).
   Each of these certificates is issued under a Resource Public Key
   Infrastructure (RPKI) Certification Authority (CA) certificate.
   These CA certificates and EE certificates both contain the AS
   Identifier Delegation extension.  An EE certificate of this type
   asserts that the router(s) holding the corresponding private key are
   authorized to emit secure route advertisements on behalf of the
   AS(es) specified in the certificate.  This document also profiles the
   format of certification requests, and specifies Relying Party (RP)
   certificate path validation procedures for these EE certificates.
   This 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:
https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-18

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


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/

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

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

[Sean Turner]

Changes as a result of discussions inspired by the validation reconsidered 
draft.

spt

> On Jul 21, 2016, at 04:49, 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 of the IETF.
> 
>Title   : A Profile for BGPsec Router Certificates, 
> Certificate Revocation Lists, and Certification Requests
>Authors : Mark Reynolds
>  Sean Turner
>  Stephen Kent
>   Filename: draft-ietf-sidr-bgpsec-pki-profiles-18.txt
>   Pages   : 13
>   Date: 2016-07-21
> 
> Abstract:
>   This document defines a standard profile for X.509 certificates used
>   to enable 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 the standard for inter-domain routing in the
>   Internet; it is the "glue" that holds the Internet together. BGPsec
>   is being developed as one component of a solution that addresses the
>   requirement to provide security for BGP.  The goal of BGPsec is to
>   provide full AS path validation based on the use of strong
>   cryptographic primitives.  The end-entity (EE) certificates specified
>   by this profile are issued (to routers within an Autonomous System).
>   Each of these certificates is issued under a Resource Public Key
>   Infrastructure (RPKI) Certification Authority (CA) certificate.
>   These CA certificates and EE certificates both contain the AS
>   Identifier Delegation extension.  An EE certificate of this type
>   asserts that the router(s) holding the corresponding private key are
>   authorized to emit secure route advertisements on behalf of the
>   AS(es) specified in the certificate.  This document also profiles the
>   format of certification requests, and specifies Relying Party (RP)
>   certificate path validation procedures for these EE certificates.
>   This 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:
> https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-18
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-18
> 
> 
> 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/
> 
> ___
> 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

Re: [sidr] Validation reconsidered and X.509v3 extension OIDs

[Russ Housley]

On Jul 19, 2016, at 9:14 AM, Rob Austein  wrote:

> At Tue, 19 Jul 2016 08:43:00 -0400, Russ Housley wrote:
>> 
>> Does this apply to the Certificate Policy OID too?  If memory is
>> correct, the current CP has a normative pinter to RFC 3779.
> 
> Good catch.
> 
> Not sure a policy OID change is necessary, although might be simplest.
> If there's a reference, we either need to change the OID or change the
> definition of what the OID means.
> 
> IIRC, the OpenSSL library code doesn't do anything RFC-3779-specific
> for the policy OID, it just follows the usual rules; it's the RP code
> built on top of the library that demands that particular policy OID.
> So at least in the OpenSSL case, changing the policy OID may not have
> any noticeable effect on correctness of software behavior.

During the SIDR session today, there seemed to be some confusion about which 
OIDs we are taking about.

The first two are from RFC 3779.  They appear here in the IANA registry:
http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1

The two OIDs are: 
1.3.6.1.5.5.7.1.7   id-pe-ipAddrBlocks
1.3.6.1.5.5.7.1.8   id-pe-autonomousSysIds  

In addition, RFC 6484 assigned an OID for the certificate policy.  It appears 
here in the IANA registry:
http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.14

The OID is:
1.3.6.1.5.5.7.14.2  id-cp-ipAddr-asNumber

I think this is a very good candidate for early IANA code point allocation.  I 
think that our AD can assist with that.

Russ

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation reconsidered and X.509v3 extension OIDs

[Tim Bruijnzeels]

Hi Russ,

Thank you for the pointers. I am traveling now but I will get back to it.

Thanks
Tim

> On 21 Jul 2016, at 10:56, Russ Housley  wrote:
> 
> 
> On Jul 19, 2016, at 9:14 AM, Rob Austein  > wrote:
> 
>> At Tue, 19 Jul 2016 08:43:00 -0400, Russ Housley wrote:
>>> 
>>> Does this apply to the Certificate Policy OID too?  If memory is
>>> correct, the current CP has a normative pinter to RFC 3779.
>> 
>> Good catch.
>> 
>> Not sure a policy OID change is necessary, although might be simplest.
>> If there's a reference, we either need to change the OID or change the
>> definition of what the OID means.
>> 
>> IIRC, the OpenSSL library code doesn't do anything RFC-3779-specific
>> for the policy OID, it just follows the usual rules; it's the RP code
>> built on top of the library that demands that particular policy OID.
>> So at least in the OpenSSL case, changing the policy OID may not have
>> any noticeable effect on correctness of software behavior.
> 
> During the SIDR session today, there seemed to be some confusion about which 
> OIDs we are taking about.
> 
> The first two are from RFC 3779.  They appear here in the IANA registry:
> http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1
>  
> 
> 
> The two OIDs are: 
>   1.3.6.1.5.5.7.1.7   id-pe-ipAddrBlocks
>   1.3.6.1.5.5.7.1.8   id-pe-autonomousSysIds  
> 
> In addition, RFC 6484 assigned an OID for the certificate policy.  It appears 
> here in the IANA registry:
> http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.14
>  
> 
> 
> The OID is:
>   1.3.6.1.5.5.7.14.2  id-cp-ipAddr-asNumber
> 
> I think this is a very good candidate for early IANA code point allocation.  
> I think that our AD can assist with that.
> 
> Russ
> 
> ___
> 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

[sidr] two stranded docuemnts - stake time

[Chris Morrow]

We are going to officially stake:
  1) draft-ietf-sidr-slurm
  2) draft-ietf-sidr-lta-use-cases

These are not being progressed currently, and won't be in the future
it seems. We'll do the process bits next week to remove them from
SIDR's work queue.

-chris

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] SIDR operations area proposed Charter

[Chris Morrow]

Howdy!
as promised in the meeting today (berlin july 21 2016):
  

I believe this is the current proposed charter for a group in the
ops-area, I (and sandy) would appreciate comments/questions/help/text
on this proposal, as we would like to close out discussion/editing by
September 1, 2016.

Thanks!
-chris
(sidr-co-chair)

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] two stranded docuemnts - stake time

[Sandra Murphy]

> On Jul 21, 2016, at 6:36 AM, Chris Morrow  wrote:
> 
> 
> We are going to officially stake:
>  1) draft-ietf-sidr-slurm

Hasn’t had energy in a while, but not so long that I can say there’s no 
possibility of resurrection.  (e.g., keyroll had a two year gap in there.  But 
then the need was clear.)


>  2) draft-ietf-sidr-lta-use-cases
> 
> These are not being progressed currently, and won't be in the future
> it seems. We'll do the process bits next week to remove them from
> SIDR's work queue.

I’d like to hear from the authors (we’ve heard from Randy) whether they have a 
possibility of continuing.

And I’d think the wg has to declare there’s no interest - if there’s a reason, 
and a new author volunteers…

—Sandy

> 
> -chris



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] two stranded docuemnts - stake time

[Sandra Murphy]

> On Jul 21, 2016, at 11:59 AM, Sandra Murphy  wrote:
> 
> 
>> On Jul 21, 2016, at 6:36 AM, Chris Morrow  wrote:
>> 
>> 
>> We are going to officially stake:
>> 1) draft-ietf-sidr-slurm
> 
> Hasn’t had energy in a while, but not so long that I can say there’s no 
> possibility of resurrection.  (e.g., keyroll had a two year gap in there.  
> But then the need was clear.)
> 
> 
>> 2) draft-ietf-sidr-lta-use-cases
>> 
>> These are not being progressed currently, and won't be in the future
>> it seems. We'll do the process bits next week to remove them from
>> SIDR's work queue.
> 
> I’d like to hear from the authors (we’ve heard from Randy) whether they have 
> a possibility of continuing.
> 
> And I’d think the wg has to declare there’s no interest - if there’s a 
> reason, and a new author volunteers…

Chris, I suppose that’s what you meant by “the process bits”

—Sandy

> 
> —Sandy
> 
>> 
>> -chris
> 
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] two stranded docuemnts - stake time

[Stephen Kent]

Sandy & Chris,

I believe Chris' declaration is premature.

I anticipate that Dr. Ma may want to take over slurm, with David's 
permission.


With a few minor tweaks the use cases doc can be done.

Steve


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] two stranded docuemnts - stake time

[Chris Morrow]

At Thu, 21 Jul 2016 13:42:07 -0400,
Stephen Kent  wrote:
> 
> Sandy & Chris,
> 
> I believe Chris' declaration is premature.
> 
> I anticipate that Dr. Ma may want to take over slurm, with David's
> permission.
> 
> With a few minor tweaks the use cases doc can be done.

ok, let's put some dates around the 2 items then:
  1) use-cases - decide on tweaks & rev-document: Aug 1
 review and WGLC  Aug 14
 send to IESG Sept 1

  2) Get hand-over on SLURM - Aug 1
 New revision Aug 14
 Discussion and next steps Sept 1

Propose alternate dates, 'no-date' is not valid as an answer... we
need to march toward conclusion.

-chris

> 
> Steve
> 

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr