Apologies for just finding this now …
I seem to remember a WG discussion about whether this draft should be BCP or
ST. We discussed BCP addressing both what the IETF wanted to be the best
practice as well as what is the actual current practice. Since BGPsec was/is
new it was/is hard to say
> On Sep 19, 2018, at 14:40, Warren Kumari wrote:
>
>
>
> On Wed, Sep 19, 2018 at 2:17 AM Christopher Morrow
> wrote:
> Howdy sidrops folks, this document was left hanging in SIDR, it probably was
> better fit to sidr-ops, so let's get Sean to re-spin a re-named document,
> auto-adopt
item of the Secure Inter-Domain Routing WG of the IETF.
>
>Title : Router Keying for BGPsec
>Authors : Randy Bush
> Sean Turner
> Keyur Patel
> Filename: draft-ietf-sidr-rtr-keying
Apologies for taking so long to get back to these. I’ve gone ahead and posted
-15; -14 was about to expire. I suspect that there will be a -16 to address
changes that result from resolving #3-5 and #9.
spt
> On Nov 14, 2017, at 21:07, Sandra Murphy wrote:
>
> Well.
>
Yep, but mark it HFDU (Hold For Document Update).
spt
> On Nov 28, 2017, at 10:09, Christopher Morrow wrote:
>
> seems legit.
>
> On Tue, Nov 28, 2017 at 9:28 AM, RFC Errata System
> wrote:
> The following errata report has been submitted
Just going to run through them in order but grouping some together.
0)
In the operator-driven method, the operator generates the private/
public key-pair and sends it to the router, perhaps in a PKCS#8
[ob] "perhaps" As implementer, this is somewhat confusing.
package [RFC5958].
[spt]
> On Mar 2, 2017, at 03:36, Shucheng LIU wrote:
>
> ** Editorial **
>
> *Section 4
>
>> BGPsec Router Certificates always include the BGPsec Rouer EKU
>>value; therefore, request without the value result in
> certificates
>>with the value; and,
>
>
ter-Domain Routing of the IETF.
>
>Title : BGPsec Algorithms, Key Formats, & Signature Formats
> Authors : Sean Turner
> Oliver Borchert
> Filename: draft-ietf-sidr-bgpsec-algs-17.txt
> Pages :
Unless there’s any comments, Wednesday I’ll cut these into the
draft-ietf-sidr-bgpsec-pki-algs draft.
spt
> On Feb 21, 2017, at 10:13 AM, Borchert, Oliver (Fed)
> wrote:
>
> Attached is the latest version of the examples. Here we added an IPv6 BGP
> update to the
> On Jan 12, 2017, at 17:33, Randy Bush wrote:
>
> mornin' oliver,
>
>> This most likely would set a bad example for others that might start
>> issuing certificates with “infinite” life spans.
>
> 'zactly
>
>> In this regards what about a Validity of 365 days within the
>>
> On Jan 11, 2017, at 12:44, Sriram, Kotikalapudi (Fed)
> wrote:
>
>> - I was surprised not to see an example message or two in this document.
>
> Sean is working together with Oliver and me on providing
> example messages in the draft-ietf-sidr-bgpsec-algs.
>
uthors : Mark Reynolds
> Sean Turner
> Stephen Kent
> Filename: draft-ietf-sidr-bgpsec-pki-profiles-20.txt
> Pages : 12
> Date: 2017-01-04
>
> Abstract:
> This document defines a stan
> On Jan 3, 2017, at 16:47, Yaron Sheffer <yar...@gmx.com> wrote:
>
> Hi Sean,
>
> Please see below.
>
> On 03/01/17 18:12, Sean Turner wrote:
>> Yaron,
>>
>> Thanks for the review.
>>
>>
>>> On Jan 1, 2017, at 11:26, Y
In my editor’s copy.
spt
> On Jan 4, 2017, at 19:19, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
>
>
> Hiya,
>
> Yep, I guess the text below is good enough.
>
> Thanks,
> S.
>
> On 04/01/17 23:56, Sean Turner wrote:
>> Co
> On Jan 4, 2017, at 19:39, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
>
>
> Hiya,
>
> On 05/01/17 00:34, Sean Turner wrote:
>>> -
> --
> COMMENT:
> --
>
>
> - section 2: I think this is a bit badly written: "The use
> of BGPsec Router Certificates in no way affects RPKI RPs
> that process
Jumping here
> On Jan 4, 2017, at 18:11, Stephen Farrell wrote:
>
> Hiya,
>
> On 04/01/17 22:15, Rob Austein wrote:
>> At Wed, 4 Jan 2017 20:57:24 +, Stephen Farrell wrote:
> (1) 3.1.1: Why MUST a CA ensure that the CA name and
> Subject name combination is
> On Jan 4, 2017, at 18:19, Ben Campbell <b...@nostrum.com> wrote:
>
> On 4 Jan 2017, at 16:37, Sean Turner wrote:
>
>> -2: draft-ietf-sidr-bgpsec-protocol explicitly excludes non-capitalized
>>> versions of 2119 words. This draft does not. It seems di
> On Jan 4, 2017, at 16:07, Ben Campbell wrote:
>
> Ben Campbell has entered the following ballot position for
> draft-ietf-sidr-bgpsec-pki-profiles-19: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To
> On Jan 4, 2017, at 05:09, Randy Bush wrote:
>
>> +1 to the comment from Suresh about order. I though that something like
>> what he proposed will minimize memcopies and possibly use of memory why
>> hashing. So I am also curious to know answer to his question.
>
> a vendor
Yaron,
Thanks for the review.
> On Jan 1, 2017, at 11:26, Yaron Sheffer wrote:
>
> Reviewer: Yaron Sheffer
> Review result: Has Nits
>
> * 3.1.1: The serial number in RFC 6487 is still a real, unique serial
> number that uniquely identifies the certificate. Here it is used as
uthors : Mark Reynolds
> Sean Turner
> Stephen Kent
> Filename: draft-ietf-sidr-bgpsec-pki-profiles-19.txt
> Pages : 13
> Date: 2016-12-30
>
> Abstract:
> This document defines a stan
Dale,
Thanks for the review. Responses inline. And, assuming Steve agrees I’ll
submit a version that incorporates these and other changes before the IESG does
its eval.
spt
> On Dec 13, 2016, at 16:45, Dale Worley wrote:
>
> Reviewer: Dale Worley
> Review result: Ready
On Dec 13, 2016, at 06:54, Stephen Farrell wrote:
>
> Stephen Farrell has entered the following ballot position for
> draft-ietf-sidr-bgpsec-algs-16: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in
her ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/
>
>
>
> --
> COMMENT:
> --
>
&g
> On Dec 10, 2016, at 08:56, Alexey Melnikov <aamelni...@fastmail.fm> wrote:
>
>
>> On 10 Dec 2016, at 12:40, Sean Turner <s...@sn3rd.com> wrote:
>>
>>> On Dec 10, 2016, at 06:50, Alexey Melnikov <aamelni...@fastmail.fm> wrote:
>>&g
> On Dec 10, 2016, at 06:50, Alexey Melnikov wrote:
>
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-sidr-bgpsec-algs-16: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in
I concur and I’ve got an editor’s copy with all the changes incorporated.
Unless I hear otherwise I’ll hold off on posting until we’ve collected and
addressed all of the other IETF LC comments.
spt
> On Dec 05, 2016, at 11:37, Steve KENT wrote:
>
> Alvaro,
>
>
is draft is a work item of the Secure Inter-Domain Routing of the IETF.
>
>Title : BGPsec Algorithms, Key Formats, & Signature Formats
> Author : Sean Turner
> Filename: draft-ietf-sidr-bgpsec-algs-16.txt
> Pages : 7
I didn’t compile it, but it looks right to me. And for what it’s worth, you
did exactly what I would have done by copying the syntax into the mainbody in
order to explain it, but imposing it directly from 3779/6268 in the module.
spt
> On Oct 26, 2016, at 11:32, Tim Bruijnzeels
This whole concept is analogous to existing DAP/LDAP mechanism and the “delta”
concept in CRLs. Considering this protocol is run over https it seems like a
step in the right direction away from unsecured rsync. So the idea seems
sensible and after re-reading the draft I think we are a go for
> On Aug 22, 2016, at 17:03, joel jaeggli wrote:
>
> On 8/17/16 7:43 PM, Declan Ma wrote:
>> Joel,
>>
>> When we are talking about SIDROPS, we are referring to that BGP speakers
>> are resorting to RPKI relying party to get verified INR authorization
>> information, which
-autonomousSysIds-v2
}
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe TBD5 }
-- Validation Reconsidered Autonomous System Identifier Delegation Extension
Syntax --
-- Syntax is imported from [RFC6268] --
END
> - Original Message -
> From: "Sean Turner&qu
ecure Inter-Domain Routing of the IETF.
>
>Title : A Profile for BGPsec Router Certificates,
> Certificate Revocation Lists, and Certification Requests
>Authors : Mark Reynolds
> Sean Turner
>
> On Jul 08, 2016, at 09:00, Sean Turner <s...@sn3rd.com> wrote:
>
>
>> On Jul 08, 2016, at 05:35, Tim Bruijnzeels <t...@ripe.net> wrote:
>>
>> Stephen Kent comment on -04 of this document saying that it should not
>> attempt to update the BGPSec R
> On Jul 08, 2016, at 05:35, Tim Bruijnzeels wrote:
>
> Stephen Kent comment on -04 of this document saying that it should not
> attempt to update the BGPSec Router Certificate I-D because it's not an RFC,
> just yet. It's currently in IESG Processing. The current document
I read this document and it looks good to progress.
If you get some other editor comments along the way you might slip in a
reference to s4 of RFC 4648 for Base64, but please don’t stop progressing this
document to wait for this nitty comment.
spt
> On Jul 02, 2016, at 14:59, Sandra Murphy
: An Overview of BGPsec
>Authors : Matt Lepinski
> Sean Turner
> Filename: draft-ietf-sidr-bgpsec-overview-08.txt
> Pages : 10
> Date: 2016-06-23
>
> Abstract:
> This docum
I read it and think it answer the mail. Ship it.
spt
> On Jun 15, 2016, at 08:35, Sandra Murphy wrote:
>
> It is a short document. The sentences are not complicated. It reads quickly.
>
> There’s been little/no wg comment on this, certainly no controversy, over the
>
gt; directories.
> This draft is a work item of the Secure Inter-Domain Routing of the IETF.
>
>Title : Router Keying for BGPsec
>Authors : Randy Bush
> Sean Turner
> Keyur Patel
> Filename
outing of the IETF.
>
>Title : A Profile for BGPsec Router Certificates,
> Certificate Revocation Lists, and Certification Requests
>Authors : Mark Reynolds
> Sean Turner
> Stephen Kent
> Filen
I’ll post a new version shortly.
There were also some other tweaks that got added to better future proof the
draft like deleting the paragraph in s1 that said what other drafts point to
the draft. I also finally read the id-nits and addresses the out-dated,
missing, and extra references.
spt
I re-read the draft and looked at the diffs from -14 and I think this draft is
ready to progress.
spt
> On Mar 17, 2016, at 09:33, Sandra Murphy wrote:
>
> This starts a two week wglc for draft-ietf-sidr-bgpsec-15.
>
> The draft is available at
>
Since RFC6916 was the algorithm agility procedures RFC we’d all been waiting
for, it makes sense to now point to it directly from the 6485bis. It’s an
informative reference to RFC6919, but RFC6916 is a BCP so it’s probably fine.
Let’s progress this one.
spt
> On Mar 21, 2016, at 17:20,
Off-list, Rob correctly pointed out that there are two PKCS#10-related issues
that are not describedt; both arise from requirements for BGPsec certificate
extensions:
1) SIA extension is forbidden in BGPsec certificates.
2) EKU extension is required in BGPsec certificates with a particular
e still dealt with in the same manner as before.
> I hope that helps.
>
> Oliver
>
>
>
>
>
>
> On 2/23/16, 10:07 PM, "Sean Turner" <s...@sn3rd.com> wrote:
>
>> Oliver & Michael,
>>
>> I see that the Algorithm Suite
Oliver & Michael,
I see that the Algorithm Suite Identifier is now included just once, which
saves one byte per signature segment, and that’s great, but how’s this new
structure going to work if there’s an an algorithm transition? How will you
support indicating the “old” and “new” algorithm?
Just read it (it’s only 9 pages) and support adoption.
spt
> On Dec 09, 2015, at 18:08, Sandra Murphy wrote:
>
> As noted in the minutes, the authors of
> draft-tbruijnzeels-sidr-validation-local-cache-02 request that the working
> group adopt this work as a wg work item.
oup of
> the IETF.
>
>Title : BGPsec Algorithms, Key Formats, & Signature Formats
> Author : Sean Turner
> Filename: draft-ietf-sidr-bgpsec-algs-14.txt
> Pages : 7
> Date: 2015-11-10
>
> Abs
Here’s a file that shows the differences between the two procedures (I backed
out the capitalization changes). text1 is in 6487 (left) and text2 is in
validation-reconsidered (right).
spt
Title: Diff: text1.txt - text2.txt
text1.txt text2.txt
s.
> This draft is a work item of the Secure Inter-Domain Routing Working Group of
> the IETF.
>
>Title : BGPsec Algorithms, Key Formats, & Signature Formats
> Author : Sean Turner
> Filename: draft-ietf-sidr-bgpsec-al
On Nov 04, 2015, at 20:14, t.petch <ie...@btconnect.com> wrote:
>
> - Original Message -----
> From: "Sean Turner" <s...@sn3rd.com>
> To: "sidr wg list" <sidr@ietf.org>
> Sent: Tuesday, November 03, 2015 2:07 AM
>
>> Incorporat
ting Working Group of
> the IETF.
>
>Title : A Profile for BGPsec Router Certificates,
> Certificate Revocation Lists, and Certification Requests
>Authors : Mark Reynolds
> Sean Turner
> Steph
tion Requests
>Authors : Mark Reynolds
> Sean Turner
> Stephen Kent
> Filename: draft-ietf-sidr-bgpsec-pki-profiles-14.txt
> Pages : 14
> Date: 2015-11-03
>
> Abstra
aft 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
>
Ah so I guess this one is informational so it could proceed without the waiting
for all the refs, but I do think we can ask the RFC editor to hold it for at
least the normative refs. When progressing a block of drafts, there’s always a
bunch of tradeoffs to deal with: 1) Will the IESG be upset
We’ll need to figure out what to do about the I-D.sidr-as-migration reference
it’s in the “IESG Dead” state.
I guess s3.2 is going to match whatever updates are made to bgpsec-protocol-14.
spt
On Oct 07, 2015, at 11:32, Chris Morrow wrote:
>
> Howdy WG folks,
>
On Aug 11, 2015, at 12:12, Richard Hansen wrote:
> Unfortunately no, with the disclaimer that I haven't really thought
> about it in depth. Because of the challenge of accomplishing topic #3,
> I would like start with the much simpler topic #1. Note that I'm not
> opposed to
it
to you to decide whether that’s enough of a safety margin.
I think Richard gives his opinion in point 8 of this msg:
https://mailarchive.ietf.org/arch/msg/sidr/SLhN-BAOzQmxn-7GmfWxIc2VrrQ
spt
-G
On Thu, Aug 6, 2015 at 8:52 PM, Sean Turner turn...@ieca.com wrote:
On May 22, 2015, at 10:55
Saw you’re earlier msg, but figured I’d just reply to this one.
On Aug 07, 2015, at 12:07, Richard Hansen rhan...@bbn.com wrote:
On 2015-08-07 06:35, Randy Bush wrote:
This change would require certificates to be re-issued (or possibly
keys to be rolled) all the way down from Trust Anchors.
This one looks good - let’s ship it!
spt
On Jul 25, 2015, at 04:47, Geoff Huston g...@apnic.net wrote:
With many thanks to Richard Hansen for his editing of this draft, I believe
that
this draft addresses both the underlying tech issue that was unable to be
addressed
in an erratum, and
On May 22, 2015, at 10:55, Richard Hansen rhan...@bbn.com wrote:
Hi all,
A while back Sean Turner raised the idea of switching to SHA-256 for the
Subject Key Identifier while discussing rfc6487bis (see
http://article.gmane.org/gmane.ietf.sidr/6878). I see a couple of
reasons to do
.
Title : BGPsec Algorithms, Key Formats, Signature Formats
Author : Sean Turner
Filename: draft-ietf-sidr-bgpsec-algs-11.txt
Pages : 7
Date: 2015-08-06
Abstract:
This document specifies the algorithms
of
the IETF.
Title : BGPsec Algorithms, Key Formats, Signature Formats
Author : Sean Turner
Filename: draft-ietf-sidr-bgpsec-algs-10.txt
Pages : 7
Date: 2015-07-20
Abstract:
This document specifies
of
the IETF.
Title : Router Keying for BGPsec
Authors : Sean Turner
Keyur Patel
Randy Bush
Filename: draft-ietf-sidr-rtr-keying-09.txt
Pages : 11
Date: 2015-07
Not seeing any objections I’ll go ahead and spin a new version over the weekend.
spt
On Jun 02, 2015, at 13:32, David Mandelberg da...@mandelberg.org wrote:
Hi,
There's some text in draft-ietf-sidr-bgpsec-pki-profiles-10 sections 3.1 and
3.1.3 that I found confusing. For reference,
On Apr 23, 2015, at 21:50, Richard Hansen rhan...@bbn.com wrote:
On 2015-04-21 18:49, Sean Turner wrote:
so I'd probably just leave it.
Are you saying that the errata process is too heavyweight for a minor
editorial typo like this? If so, is there a more appropriate way to
report
On Apr 21, 2015, at 13:23, Richard Hansen rhan...@bbn.com wrote:
On 2015-04-21 02:24, Geoff Huston wrote:
I am trying very hard to understand why or how such a change affects
interoperability of running
code that is based on this specification. So far I’ve been unable to think
of an
On Mar 09, 2015, at 21:07, Richard Hansen rhan...@bbn.com wrote:
Hi all,
I have submitted a bis of RFC6487 as a -00 individual submission, and
will be presenting it in Dallas.
It's a minor change from RFC6487. Changes incorporated:
* all 3 verified errata
Faithfully includes the
: BGP Algorithms, Key Formats, Signature Formats
Author : Sean Turner
Filename: draft-ietf-sidr-bgpsec-algs-09.txt
Pages : 7
Date: 2015-01-21
Abstract:
This document specifies the algorithms, algorithms' parameters
: 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-10.txt
: Router Keying for BGPsec
Authors : Sean Turner
Keyur Patel
Randy Bush
Filename: draft-ietf-sidr-rtr-keying-08.txt
Pages : 11
Date: 2015-01-21
Abstract:
BGPsec-speaking routers
Sean Turner
Steve Kent
Filename: draft-ietf-sidr-bgpsec-pki-profiles-09.txt
Pages : 13
Date: 2014-11-10
Abstract:
This document defines a standard profile for X.509 certificates for
the purposes
On Oct 08, 2014, at 02:48, Randy Bush ra...@psg.com wrote:
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
On Oct 08, 2014, at 09:50, Andreas Reuter andreas.rou...@googlemail.com wrote:
Hi,
I came across a (possible) oversight in RFC 6487, Section 4.4 about
the issuer field:
An issuer name MUST contain one instance of the CommonName attribute
and MAY contain one instance of the
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
I’ve read this draft and support it progressing. One minor comment:
It would be nice if there was a short summary of the differences between this
version and RFC 6490. Maybe a new section 1.2 titled differences between this
version and RFC 6490:
This document obsoletes RFC 6490 by adding
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
On Jul 02, 2014, at 11:16, Sean Turner turn...@ieca.com wrote:
On Jul 02, 2014, at 10:00, Stephen Kent k...@bbn.com wrote:
Rob,
At Mon, 30 Jun 2014 11:27:03 -0400, Stephen Kent wrote:
I did suggest we might use other cert request mechanisms. EST is the
obvious, current, standards-based
All,
I put my working copies of draft-ietf-sidr-bgpsec-pki-profiles and
draft-ietf-sidr-bgpsec-algs up on github:
https://github.com/seanturner/draft-ietf-sidr-bgpsec-pki-profiles
https://github.com/seanturner/draft-ietf-sidr-bgpsec-algs
spt
___
sidr
On Jul 07, 2014, at 19:42, Sandra Murphy sa...@tislabs.com wrote:
On Jul 7, 2014, at 7:00 PM, Geoff Huston g...@apnic.net wrote:
the header of draft-ietf-sidr-bgpsec-algs-08 says:
Updates: 6485 (if approved)
so I'm still confused about the two 6485 update drafts.
Ah. So
WRT integrating the two specs … whatever is easier.
spt
On Jul 07, 2014, at 13:06, Matthew Lepinski mlepinski.i...@gmail.com wrote:
Oh, one other thing:
If anyone on this list thinks that instead of referencing as-migration, that
we are better off merging as-migration into
On Jul 02, 2014, at 10:00, Stephen Kent k...@bbn.com wrote:
Rob,
At Mon, 30 Jun 2014 11:27:03 -0400, Stephen Kent wrote:
I did suggest we might use other cert request mechanisms. EST is the
obvious, current, standards-based option for this, if folks want to
consider alternatives to
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 : BGP Algorithms, Key Formats, Signature Formats
Author : Sean Turner
And then I just noticed the section #ing is not sequential :( Stay tuned for
another version.
spt
On Jul 02, 2014, at 11:36, Sean Turner turn...@ieca.com wrote:
A minor update to move some references that were in the wrong place as well
as to correctly identify where the OID goes
.
Title : Router Keying for BGPsec
Authors : Sean Turner
Keyur Patel
Randy Bush
Filename: draft-ietf-sidr-rtr-keying-07.txt
Pages : 11
Date: 2014-05-23
Abstract
On May 13, 2014, at 12:23, Randy Bush ra...@psg.com wrote:
Though I’m not sure that there is a huge distinction between disabling
BGPSec and taking the router offline since disabling BGPSec would trigger
neighbor session resets for capability renegotiation unless we’ve
specified otherwise in
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 : Router Keying for BGPsec
Authors : Sean Turner
Keyur Patel
On Apr 04, 2014, at 15:47, Geoff Huston g...@apnic.net wrote:
The authors of RFC 6487 can speak for themselves, but I think their
intent was to avoid requests for vanity names (CN=Joe's Pizza
instead of CN=4DF2D88957372FF9FDA05C70F2D9E8BA334CFF89), which could
be construed as eroding claims
On May 12, 2014, at 16:03, Randy Bush ra...@psg.com wrote:
Would it make sense to have the name that goes in the router
certificate then be something like “ROUTER-#-32_bit_BGP_Identifier”
where the # gets incremented everytime there’s a new key? For those
that love hard coded lengths this
private keys or not, but I’m not sure if there are
additional considerations that need to be discussed.
Thanks,
Wes
On 4/29/14, 10:14 AM, Sean Turner turn...@ieca.com wrote:
Hi,
This version includes a new section 4 that addresses key management
(i.e., keep a timer to make sure
: Sean Turner
Keyur Patel
Randy Bush
Filename: draft-ietf-sidr-rtr-keying-05.txt
Pages : 10
Date: 2014-04-29
Abstract:
BGPsec-speaking routers are provisioned with private keys to sign
On Feb 24, 2014, at 11:41, Stephen Kent k...@bbn.com wrote:
Rob,
Good catch.
Obscure little conflict that only an implementor would notice: there's
a three-way conflict between the current rtr-keying draft, the current
bgpsec-pki-profile draft, and the base RPKI certificate profile RFC.
New version should be posted soon addressing this and some other reference
updaets.
spt
On Mar 11, 2014, at 11:56, Christopher Morrow morrowc.li...@gmail.com wrote:
On Tue, Mar 11, 2014 at 10:34 AM, Stephen Kent k...@bbn.com wrote:
Chris,
It was pointed out in passing (hallway/table
I think this one is ready for wglc ;)
nits that can be fixed whenever:
s6:
r/and [RFC6487] a apply to certificate and CRLs
/and [RFC6487] apply to certificates and CRLs
s8: Maybe consider just renaming s8 to “Changes since RFC 6485” and striking:
[Remove before publication.
Dear IESG,
Routing Working Group of
the IETF.
Title : Router Keying for BGPsec
Author(s) : Sean Turner
Keyur Patel
Randy Bush
Filename: draft-ietf-sidr-rtr-keying-02.txt
Pages : 9
.
Title : A Profile for BGPSEC Router Certificates, Certificate
Revocation Lists, and Certification Requests
Author(s) : Mark Reynolds
Sean Turner
Steve Kent
Filename: draft-ietf-sidr-bgpsec-pki-profiles-05
Working Group of
the IETF.
Title : BGP Algorithms, Key Formats, Signature Formats
Author(s) : Sean Turner
Filename: draft-ietf-sidr-bgpsec-algs-04.txt
Pages : 7
Date: 2013-03-26
Abstract:
This document
+1
spt
On 3/11/13 9:56 AM, Carlos M. Martinez wrote:
I support WG adoption of this draft.
~Carlos
On 3/11/13 9:54 AM, Andy Newton wrote:
On 3/11/13 9:48 AM, Matthew Lepinski mlepinski.i...@gmail.com wrote:
This seems like quite a reasonable document, and I do not anticipate
that it would
Action: draft-ietf-sidr-rtr-keying-01.txt
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 : Router Keying for BGPsec
Author(s) : Sean
1 - 100 of 152 matches
Mail list logo