Re: [sidr] Opsdir last call review of draft-ietf-sidrops-rtr-keying-02

[Sean Turner]

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 it fell in the latter bucket and there was at least 
one person who felt that the router and operator driven methods weren’t the way 
to go in the future (hence why there is s8 the "advanced deployment scenarios” 
section).  So the WG said go ST and because this draft has exhausted me we just 
changed it to ST.  I will note that the SECDIR and RTGDIR both had this same 
comment it seems like we’re back to BCP.  I think there was another message 
somewhere about changing this to BCP so I will do that in -03 unless I hear 
otherwise.

spt

> On Dec 26, 2018, at 08:29, Christopher Morrow  wrote:
> 
> BCP seems like a fine answer here, I'm not remembering why we would have 
> swapped to ST from BCP.
> 
> On Wed, Dec 26, 2018 at 11:12 AM Warren Kumari  wrote:
> [ + Sandy, Alvaro ]
> 
> On Wed, Dec 26, 2018 at 9:51 AM Scott Bradner  wrote:
> that use of a MUST is commendable but its not exactly an interoperability 
> issue 
> 
> to me “must” works in this case (and the other cases in this document)
> 
> but, that said, 2119 has been misused for kinda a long time so its not a new 
> sin
> 
> 
> This document has a long history -- it was originally a product of the SIDR 
> Working Group (as draft-ietf-sidr-rtr-keying), and only moved over to SIDROPS 
> recently, when SIDR closed down (https://datatracker.ietf.org/wg/sidr/about/).
> 
> The document was originally a BCP 
> (https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/09/), but was 
> changed to Standards Track in -10 
> (https://www.ietf.org/archive/id/draft-ietf-sidr-rtr-keying-10.txt).
> 
> 
> I have gone back through the agenda and minutes for IETF 92 
> (https://datatracker.ietf.org/doc/agenda-92-sidr/), IETF 93 
> (https://datatracker.ietf.org/doc/agenda-93-sidr/) and IETF 94 
> (https://datatracker.ietf.org/doc/agenda-94-sidr/). 
> I also went back and watched the video recordings from IETF 94: 
> https://youtu.be/fElkBi4UMEA?t=2397 and wasn't able to find any discussion of 
> why the change was made, but I *was* able to find some changes made between 
> -09 and -10 which seem to be the outcome of those discussions. 
> 
> Authors / SIDROPS [0] & SIDR / chairs -  can y'all remember why the track 
> change was made? 
> 
> Whatever the case, the IETF LC was done as Standards Track (a higher level), 
> and so it could always be "downgraded" to BCP / informational during IESG 
> Eval.
> I personally think it "feels" like BCP, but I don't have full history / 
> inherited the document and don't want to be arbitrarily making changes.
> 
> 
> W
> [0]: SIDROPS and SIDR participant overlap is almost 100%.
> 
> 
>  
> Scott
> 
> > On Dec 26, 2018, at 9:25 AM, Randy Bush  wrote:
> > 
> > mornin’ scott,
> > 
> >> it is hard to see why it should be standards track or why it should 
> >> be using RFC 2119 type terminology.
> > 
> > these are two separate issues.  
> > 
> > alvaro and the chairs can adjudicate what flavor of ice cream it should
> > be.  it my memory says it was a wg decision.  i really do not care.
> > 
> > as to 2119 language, i kinda feel it should remain.  it is used
> > sparingly. but is crucial when used.  e.g.
> > 
> >  all private keys MUST be protected when at rest in a secure
> >  fashion.
> > 
> > i suspect we would want to keep that strongly prescriptive; but it is
> > not a hill on which i am interested in dying.
> > 
> > randy
> 
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad idea in 
> the first place.
> This is like putting rabid weasels in your pants, and later expressing regret 
> at having chosen those particular rabid weasels and that pair of pants.
>---maf
> ___
> 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] I-D Action: draft-ietf-sidr-rtr-keying-16.txt

[Sean Turner]

> 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 that and chat up any changes/etc between now and 'meeting time' ?
> 
> Ideally we can turn around after the meeting breaks and WGLC this document in 
> SIDROPS, unless changes are requested (of course!) :)
> 
> This sounds like a grand plan! 
> 
> I have"draft-ietf-sidrops-bgpsec-rollover-04 - BGPsec Router Certificate 
> Rollover - RFC Ed Queue : MISSREF for 281 days" sitting in my document queue. 
> It's been awaitin' on draft-ietf-sidr-rtr-keying for almost 10 months, and 
> it's making my twitchy :-)

I should be able to get this up by the end of the week.

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

Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-16.txt

[Sean Turner]

This version I believes addresses the two outstanding issues Sandy raised 
during her review.

spt

> On Aug 30, 2018, at 14:28, 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 WG of the IETF.
> 
>Title   : Router Keying for BGPsec
>Authors : Randy Bush
>      Sean Turner
>  Keyur Patel
>   Filename: draft-ietf-sidr-rtr-keying-16.txt
>   Pages   : 18
>   Date: 2018-08-30
> 
> Abstract:
>   BGPsec-speaking routers are provisioned with private keys in order to
>   sign BGPsec announcements.  The corresponding public keys are
>   published in the global Resource Public Key Infrastructure, enabling
>   verification of BGPsec messages.  This document describes two methods
>   of generating the public-private key-pairs: router-driven and
>   operator-driven.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-16
> https://datatracker.ietf.org/doc/html/draft-ietf-sidr-rtr-keying-16
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-16
> 
> 
> 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

Re: [sidr] comments needed (Re: I-D Action: draft-ietf-sidr-rtr-keying-14.txt)

[Sean Turner]

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.
> 
> The mail archive does not seem to show attachments.  For me. I see do see 
> attachments on other messages.
> 
> It would be nice to know if anyone has seen attachments on my messages in the 
> last few weeks.
> 
> At any rate, for the mail archive, the comments are copied below the 
> signature.
> 
> —Sandy
> 
> 
> Points that might get lost in the long detailed list that follows:
> 
> 1.  RFC4271 (and RFC6286) and RFC8209 use the term “BGP Identifier”.  The 
> main text says RouterID and the Appendix B says “serial number”.  I believe 
> both are talking about what RFC8209 calls the “BGP Identifier”.  Most of the 
> tech sites say router ID or router-id or routerid or RID or some such.  But I 
> think consistency with the referenced text would be good.

#Sean: Changed throughout the draft to BGP Identifier and added a reference to 
4271.

> 2.  I was initially confused by the text in various places that talks about 
> the operator adding the AS and RouterID (sic) and sends to the CA.  I thought 
> that meant the operator adds those to the CSR, which would be hard since the 
> CSR is signed.  This occurs a couple of places.  I suggest a sentence early 
> on that says the router certificate includes the AS and router identifier but 
> the CSR does not include such fields, so the operator must include the AS and 
> routerID when it sends the CSR to the CA.

#Sean: The setup section explains that the Operator either needs to configure 
the AS and to configure/extract the BGP Identifier.  These values are included 
in the cert req; I guess the way I said they are added was confusing?  I guess 
in s5.1/s5.2 as opposed to saying the operator adds it should just say:

   The PKCS#10 includes the chosen AS number and
   BGP Identifier that the RPKI CA will certify.

> 3.  “corresponds” - there are several places that say the certificate must be 
> validated to prove that the public key corresponds with the private key.  The 
> main body does not say how that correspondence is validated.  The appendix 
> suggests that the operator could validate the signature on the CSR with the 
> returned router cert in order to validate the key.  (a) When the operator 
> generated the public/private key pair, why not just do a comparison to the 
> generated public key, presuming it was retained?  (b) When the operator 
> passed the CSR generated by the router to the CA, why not validate the public 
> key before sending it to the CA?  The public key in the returned router 
> certificate could subsequently be validated by a comparison, presuming the 
> public key was retained.  (c) When the router is supposed to validate the 
> public key of the router cert it receives, and the operator generated the 
> public/private key pair, it does not have a copy of the CSR to validate the 
> correspondence.  Took me a bit to realize the router could sign just any old 
> bit of bytes and then validate the signature with the received router cert.  
> Right?

#Keyur: Ack on A and B. Sean and Randy Can u validate if that makes sense? On C 
we should call this results in incorrect signing of “old bit of bytes”. 
Assuming there is a key rollover period this should be okay as old keys could 
be active? 

#Randy: yes, if the router has both the private and alleged pubic keys, it 
could sign a nonce and then verify it.  but if you worry that the operertor is 
lying to the router, she would be smart enough to give the router a 
public/private pair which matches but is not the same as she negotited with the 
CA.  the router would have to make some sort of check with the CA, i.e. the 
router would need the CA's public key or up-chain.

#Sean: So corresponds means that the public key in the certificate and private 
key are actually a key pair, i.e., the public key can be used to validate a 
signature generated with the private.  In this draft we only do the check on 
the returned certificate because the CA does the check on the certificate 
submitted for certification; that bit is called POP or proof-of-possession.   
Now you can do this by verifying any old signed bag-o-bits or the PKCS#10 and 
if the RPKI package you used to generate the key pair supports it special 
functions that do the verification.  The check in s6 is done when the operator 
does it to check that the CA didn’t screw up and send it the wrong cert; the 
check in s7 covers both the router and operator generated cases because in the 
former the router needs to the check because it made the request and in the 
later the operator may have screwed up and sent the router the wrong cert.  The 
check is repeated in s8 and AppA because we’ll those sections are variations on 
a theme.  So, I was 

Re: [sidr] [Editorial Errata Reported] RFC6487 (5191)

[Sean Turner]

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 for RFC6487,
> "A Profile for X.509 PKIX Resource Certificates".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5191
> 
> --
> Type: Editorial
> Reported by: Nikolai Malykh 
> 
> Section: 8
> 
> Original Text
> -
> (The issuing CA may wish to be able to extract the database
> key or subscriber ID from the commonName.  Since only the
> issuing CA would need to be able to parse the commonName,
> the database key and the source of entropy (e.g., a UUID)
> could be separated in any way that the CA wants, as long as
> it conforms to the rules for PrintableString.  The separator
> 
> 
> 
> 
> Huston, et al.   Standards Track   [Page 21]
> 
> RFC 6487  Resource Certificate Profile February 2012
> 
> 
> could be a space character, parenthesis, hyphen, slash,
> question mark, etc.
> 
> 
> Corrected Text
> --
> (The issuing CA may wish to be able to extract the database
> key or subscriber ID from the commonName.  Since only the
> issuing CA would need to be able to parse the commonName,
> the database key and the source of entropy (e.g., a UUID)
> could be separated in any way that the CA wants, as long as
> it conforms to the rules for PrintableString.  The separator
> 
> 
> 
> 
> Huston, et al.   Standards Track   [Page 21]
> 
> RFC 6487  Resource Certificate Profile February 2012
> 
> 
> could be a space character, parenthesis, hyphen, slash,
> question mark, etc).
> 
> 
> Notes
> -
> The closing parenthesis is missing.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
> 
> --
> RFC6487 (draft-ietf-sidr-res-certs-22)
> --
> Title   : A Profile for X.509 PKIX Resource Certificates
> Publication Date: February 2012
> Author(s)   : G. Huston, G. Michaelson, R. Loomans
> Category: PROPOSED STANDARD
> Source  : Secure Inter-Domain Routing
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> 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 mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC: draft-ietf-sidr-rtr-keying - finishes - 10/16/2017 - Oct 16, 2017

[Sean Turner]

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] sure I changed “perhaps” to "e.g.” ;)

1) 

  In the router-driven method, the router generates its own public/
  private key-pair.

[ob] End the sentence here

[ob]  The paragraph below contains too much detail for the introduction

[spt] The introduction just kind of kept growing.  And, I think somebody asked 
for concrete references somewhere along the way.  The references are   
elsewhere in the document so maybe we can drop the super technical bits from 
the intro If we’re going to change this sentence to make it that short I’ll 
likely that the e.g., bit out of the previous paragraph.

2) update references

[spt] Yep - and done

3) s3 Intro

[ob] Maybe more than one sentences make it clearer. Not easy to
[ob] understand.

[spt] it is kind of a mouthful, how about:

  A number of options exist for the operator management
  station to exchange PKI-related information with routers
  and with the RPKI including:

  - Use application/pkcs10 media type [RFC5967]  to
extract certificate requests and application/pkcs7-mime
[RFC5751] to return the issued certificate

  - Use FTP or HTTP per [RFC2585], or

  - Use the Enrollment over Secure Transport (EST) protocol
per [RFC7030].

4) router burden in s4, s6 (now s7), and s7, etc

   To start, the operator uses the communication channel to
   install the appropriate RPKI Trust Anchor' Certificate (TA Cert)
   in the router. This will later enable the router to validate the
   router certificate returned in the PKCS#7.

[ob] Section 8.1 specifies that the operator is responsible to assure
[ob] that the router has valid keys. Therefore, it is not clear why this
[ob] above paragraph necessary.
[ob] Maybe the above paragraph could be a feature of the “Advanced
[ob] Deployment [ob] Scenarios” in section 7

…

[ob] This is again back to trust. The operator should verify the
[ob] certificate, not the router.The operator MUST verify the
[ob] certificate prior publishing it. This is outside of the scope of the
[ob] router.

[spt] I agree with your point that it’s up to the operator to ensure the 
router’s keys are valid.  But, operators are humans and they make mistakes.

[spt] While s8.1 does include text stating that the operator is responsible to 
ensure valid keys are used, it’s in s8.1 much later in the document.  We placed 
this here to avoid a back pointer.

[spt] WRT burdening the router with verifying the private key corresponds to 
the returned public key: You’re right it’s the operator’s job, but operator’s 
make mistakes.  If the router also checks that the private key corresponds to 
the returned public key, it’s goodness all around.

6) Comments on restructuring s5-7.

[spt] Some of this I think might make sense, but not all of it ;)

7) s5

[spt] In the choose your own adventure of s5, I’d prefer to the leave the AS 
inclusion text in sub-sections.  Sure it’s repeated twice, but then each 
section is self-contained.

[spt] The 2nd para in s5.1 is there to address some comment we got long ago.  
I’d like to leave the text, but add “NOTE:” in the front of it so people get 
that something has to happen for the RPKI to authenitcate the router.

8) new s7

[spt] I’m not sure why we’d move the paragraph that talks about checking the 
sig on the PKCS#8 and Certificate to s5.2.1.  The certificate isn’t yet in the 
picture yet so to me it seems to fit best where it is.

9) s7 (now s8)

[spt] We can’t move it to an informative appendix because s7 was a grand 
compromise between Max and the authors.  He assertion is that the manual 
process is weak security and it really ought to be more automated.

[spt] WRT “More PKI-capable router” there’s no really a reference.  It’s really 
just that the router supports some of the things listed in the remainder of the 
paragraph.  But, the basic idea is that the operator won’t be messing with the 
CLI.

[ob] How is this with RouterID 0 for shared keys within an AS? Could this
[ob] cause conflicts? Same for multiple keys for same router with
[ob] RouterID?

[spt] I’m trying to figure out whether this comment just applies to the 
advanced scenarios or more generally?

[spt] Here’s how I see it: Operator has two routers each with IEEE 802.1 AR 
certificates.  They communicate the subject names (and maybe the public keys) 
from the AR certificates to the CA.  The CA then accepts requests from these 
two routers and no others.  If the operator tells the CA to give them the same 
AS number it does if not it doesn’t.  Makes sense?

10) s8 (now s9)

[spt] I’m okay with the re-write of the intro, but I kind of want to keep the 
part about it being the operator’s responsibility to maintain the key for their 
entire 

Re: [sidr] Review of draft-ietf-sidr-bgpsec-pki-profiles-21

[Sean Turner]

> 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,
> 
> s/Rouer/Router

Thanks! If the RFC editor misses this I’ll make sure that it gets fixed up in 
AUTH48.

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

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-17.txt

[Sean Turner]

This version addresses the IESG comments we got from Alexey (drive home the 
point that these algs are different than the rest of the RPKI) and Stephen (add 
examples).  As you may have seen, Oliver did a lot of work on the examples so 
he’s now listed as an author.

I’m hoping this is the last step prior to approval, but I’ll leave that in 
Alvaro/Chris/Sandy’s hands.

spt

> On Mar 6, 2017, at 11:34, 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   : BGPsec Algorithms, Key Formats, & Signature Formats
>    Authors : Sean Turner
>  Oliver Borchert
>   Filename: draft-ietf-sidr-bgpsec-algs-17.txt
>   Pages   : 15
>   Date: 2017-03-06
> 
> Abstract:
>   This document specifies the algorithms, algorithm parameters,
>   asymmetric key formats, asymmetric key size and signature format used
>   in BGPsec (Border Gateway Protocol Security).  This document updates
>   the Profile for Algorithms and Key Sizes for Use in the Resource
>   Public Key Infrastructure (RFC 7935).
> 
>   This document also includes  example BGPsec Update messages as well
>   as the private keys used to generate the messages and the
>   certificates necessary to validate those signatures.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-17
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-17
> 
> 
> 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] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs

[Sean Turner]

 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 existing example.
> 
> Again, for better reading I attached the example as text/pdf in case the 
> formatting within the email gets
> Messed up.
> 
> Oliver
> 
> exampleexampleexample
> Topology:
> 
> AS(64496)AS(65536)AS(65537)
> 
> Prefix Announcements: AS(64496), 192.0.2.0/24, 2001:db8::/32
> 
> For this example, the ECDSA algorithm was provided with a static k to 
> make the result deterministic. 
> The k used for all signature operations was taken from RFC 6979, 
> chapter A.2.5 ?Signatures With SHA-256, message 'sample'?.
> 
>  k = A6E3C57DD01ABE90086538398355DD4C3B17AA873382B0F24D6129493D8AAD60
> 
> Keys of AS64496:
> 
> ski: AB4D910F55CAE71A215EF3CAFE3ACC45B5EEC154
> 
> private key:
>  x = D8AA4DFBE2478F86E88A7451BF075565709C575AC1C136D081C540254CA440B9
> 
> public key: 
>  Ux = 7391BABB92A0CB3BE10E59B19EBFFB214E04A91E0CBA1B139A7D38D90F77E55A
>  Uy = A05B8E695678E0FA16904B55D9D4F5C0DFC58895EE50BC4F75D205A25BD36FF5
> 
> Router Key Certificate example using OpenSSL 1.0.1e-fips 11 Feb 2013
> 
> Certificate:
>Data:
>Version: 3 (0x2)
>Serial Number: 38655612 (0x24dd67c)
>Signature Algorithm: ecdsa-with-SHA256
>Issuer: CN=ROUTER-FBF0
>Validity
>Not Before: Jan  1 05:00:00 2017 GMT
>Not After : Jul  1 05:00:00 2018 GMT
>Subject: CN=ROUTER-FBF0
>Subject Public Key Info:
>Public Key Algorithm: id-ecPublicKey
>Public-Key: (256 bit)
>pub: 
>04:73:91:ba:bb:92:a0:cb:3b:e1:0e:59:b1:9e:bf:
>fb:21:4e:04:a9:1e:0c:ba:1b:13:9a:7d:38:d9:0f:
>77:e5:5a:a0:5b:8e:69:56:78:e0:fa:16:90:4b:55:
>d9:d4:f5:c0:df:c5:88:95:ee:50:bc:4f:75:d2:05:
>a2:5b:d3:6f:f5
>ASN1 OID: prime256v1
>X509v3 extensions:
>X509v3 Key Usage: 
>Digital Signature
>X509v3 Subject Key Identifier: 
>AB:4D:91:0F:55:CA:E7:1A:21:5E:F3:CA:FE:3A:CC:45:B5:EE:C1:54
>X509v3 Extended Key Usage: 
>1.3.6.1.5.5.7.3.30
>sbgp-autonomousSysNum: critical
>Autonomous System Numbers:
>  64496
>Routing Domain Identifiers:
>  inherit
> 
>Signature Algorithm: ecdsa-with-SHA256
> 30:44:02:20:07:b7:b4:6a:5f:a4:f1:cc:68:36:39:03:a4:83:
> ec:7c:80:02:d2:f6:08:9d:46:b2:ec:2a:7b:e6:92:b3:6f:b1:
> 02:20:00:91:05:4a:a1:f5:b0:18:9d:27:24:e8:b4:22:fd:d1:
> 1c:f0:3d:b1:38:24:5d:64:29:35:28:8d:ee:0c:38:29
> -BEGIN CERTIFICATE-
> MIIBiDCCAS+gAwIBAgIEAk3WfDAKBggqhkjOPQQDAjAaMRgwFgYDVQQDDA9ST1VU
> RVItMDAwMEZCRjAwHhcNMTcwMTAxMDUwMDAwWhcNMTgwNzAxMDUwMDAwWjAaMRgw
> FgYDVQQDDA9ST1VURVItMDAwMEZCRjAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNC
> AARzkbq7kqDLO+EOWbGev/shTgSpHgy6GxOafTjZD3flWqBbjmlWeOD6FpBLVdnU
> 9cDfxYiV7lC8T3XSBaJb02/1o2MwYTALBgNVHQ8EBAMCB4AwHQYDVR0OBBYEFKtN
> kQ9VyucaIV7zyv46zEW17sFUMBMGA1UdJQQMMAoGCCsGAQUFBwMeMB4GCCsGAQUF
> BwEIAQH/BA8wDaAHMAUCAwD78KECBQAwCgYIKoZIzj0EAwIDRwAwRAIgB7e0al+k
> 8cxoNjkDpIPsfIAC0vYInUay7Cp75pKzb7ECIACRBUqh9bAYnSck6LQi/dEc8D2x
> OCRdZCk1KI3uDDgp
> -END CERTIFICATE-
> 
> 
> 
> Keys of AS(65636):
> ==
> ski: 47F23BF1AB2F8A9D26864EBBD8DF2711C74406EC
> 
> private key:
>  x = 6CB2E931B112F24554BCDCAAFD9553A9519A9AF33C023B60846A21FC95583172
> 
> public key: 
>  Ux = 28FC5FE9AFCF5F4CAB3F5F85CB212FC1E9D0E0DBEAEE425BD2F0D3175AA0E989
>  Uy = EA9B603E38F35FB329DF495641F2BA040F1C3AC6138307F257CBA6B8B588F41F
> 
> Router Key Certificate example using OpenSSL 1.0.1e-fips 11 Feb 2013
> 
> Certificate:
>Data:
>Version: 3 (0x2)
>Serial Number: 3168189942 (0xbcd6bdf6)
>Signature Algorithm: ecdsa-with-SHA256
>Issuer: CN=ROUTER-
>Validity
>Not Before: Jan  1 05:00:00 2017 GMT
>Not After : Jul  1 05:00:00 2018 GMT
>Subject: CN=ROUTER-
>Subject Public Key Info:
>Public Key Algorithm: id-ecPublicKey
>Public-Key: (256 bit)
>pub: 
>04:28:fc:5f:e9:af:cf:5f:4c:ab:3f:5f:85:cb:21:
>2f:c1:e9:d0:e0:db:ea:ee:42:5b:d2:f0:d3:17:5a:
>a0:e9:89:ea:9b:60:3e:38:f3:5f:b3:29:df:49:56:
>41:f2:ba:04:0f:1c:3a:c6:13:83:07:f2:57:cb:a6:
>b8:b5:88:f4:1f
>ASN1 OID: prime256v1
>X509v3 extensions:
>

Re: [sidr] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs

[Sean Turner]

> 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
>> example. This seems feasible to me.
> 
>>> of course that leaves open what lifetime to recommend.  we're not
>>> gonna do oscp, but rather withdraw from the rpki.  so to keep from
>>> making too much bgp noise, let me toss out O(year) to start the
>>> discussion.
> 
> i can live with a year.  i will be interested if others comment.
> 
> i have a vague memory of talking about this before.  one needs to deploy
> the replacement key in advance, as it can take some time to propagate to
> the far corners of the internet.  and one probably does not want to
> reannounce all one's routes at once.
> 
> a small i-d may be in order.

The CPS really dictates the validity period.  Can you check what your RIPE 
issued RPKI certificates have as a validity date?

You’re right that you need to get the replacement cert early to make sure you 
don’t end up being without a certificate.  RFC 6484 recommends 1 week prior to 
the expiration of the old cert.  I think the CPS also allows some addition time 
to account for this problem.

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

Re: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

[Sean Turner]

> 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.
> Stephen and Sean agreed that would be a better place and it is happening:
> https://www.ietf.org/mail-archive/web/sidr/current/msg08288.html 

Oliver has just posted the v4 examples:
https://mailarchive.ietf.org/arch/msg/sidr/eJdWwuwTHT6DVS-MPbMQh8z6iH8
Probably worth adding an explicit pointer to the examples once we get them 
agreed by the WG.

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

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

[Sean Turner]

I believe this version addresses Stephen’s discuss points as well as the other 
comments I’ve picked up along the way (minus fighting with nroffedit to add 
references).

spt

> On Jan 4, 2017, at 19:58, 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-20.txt
>   Pages   : 12
>   Date: 2017-01-04
> 
> 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-20
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-20
> 
> 
> 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

Re: [sidr] Review of draft-ietf-sidr-bgpsec-pki-profiles-19

[Sean Turner]

> 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, Yaron Sheffer <yar...@gmx.com>
>>>  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
>>> something other than a serial number, which is explicitly NOT unique,
>>> and the CA is left to decide how to make it unique in the face of
>>> potentially repeating BGP IDs. If this is not a real issue (e.g.
>>> because duplicate IDs are rare and never within a RIR), please say
>>> so.
>>> 
>> As Rob pointed out this paragraph is talking about the serial number naming 
>> attribute.  Maybe something like:
>> 
>> r/only two attributes/only two naming attributes
>> and
>> r/common name and serial number/common name (i.e., X520CommonName) and 
>> serial number (i.e., X520SerialNumber) 
>> 
>> People ought to them be able to track down the definitions.
>> 
> I'm good with these changes. However, according to Randy's response to my 
> review, the text later on is subtly incorrect (or at least misleading). 
> Router IDs are not globally unique, but the combination of AS Number and 
> Router ID is in fact globally unique.

This bit is now OBE based on Stephen’s discuss.

>>> * 3.2: earlier we said that Basic Constraints must not be included in
>>> the EE cert. Now we are saying that only a particular boolean flag
>>> must not be honored when processing the Cert Request. What happens if
>>> Basic Constraints is included in the Cert Request but with other
>>> flags?
>>> 
>> The CA is ultimately the one who decides what gets issued.  A good CA would 
>> know to only issue properly formatted BGPsec certificates either by ignoring 
>> the improperly requested “feature" or rejecting it outright.  Since these 
>> CAs really aren’t open CAs then the CA ought not get caught off-guard with 
>> requests.
> I'm not sure I understand. Why not give a consistent advice to EEs and CAs, 
> e.g., reject any request that includes any Basic Constraints.

So there’s really no good way to put this but it’s primarily because the common 
PKCS#10/PKCS#7 dance doesn’t support errors; it’s either success or silence.  
It’s better to assume they’ve dorked their request and to give ‘em a proper 
certificate.  Remember these CAs are pretty clued into what’s going on here 
this isn’t the webPKI.

>>> * 3.3: ID.sidr-rfc6485bis -> RFC 7935
>>> 
>> drat I missed one.
>> 
>> 
>>> * 6: in the paragraph that discusses hash functions, please spell out
>>> the names of the two key identifiers, because I cannot determine what
>>> they are from the document.
>>> 
>> Ack they’re the key identifiers in the cert: Subject Key Identifier and 
>> Issuer Key Identifier 
>> 
>> r/two key identifier extensions./two key identifier extensions (i.e., 
>> Subject Key Identifier and Issuer Key Identifier)
>> 
> Yes.
>> 
>> spt
>> 
> 

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

Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT)

[Sean Turner]

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:
>>   Common name encoding options that are supported are
>>   printableString and UTF8String.  For BGPsec Router Certificates, it
>>   is RECOMMENDED that the common name attribute contain the literal
>>   string "ROUTER-" followed by the 32-bit AS Number [RFC3779] encoded
>>   as eight hexadecimal digits and that the serial number attribute
>>   contain the 32-bit BGP Identifier [RFC4271] (i.e., the router ID)
>>   encoded as eight hexadecimal digits.  If there is more than one AS
>>   number, the choice of which to include in the common name is at the
>>   discretion of the Issuer. 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.
> 

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

Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT)

[Sean Turner]

> 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 Manifests and ROAs because the public key found in the
>>> BGPsec Router Certificate is used only to verify the signature on
>>> the BGPsec certificate request (only CAs process these) and the
>>> signature on a BGPsec Update Message [ID.sidr-bgpsec-protocol]
>>> (only BGPsec routers process these)." Do you mean that there's no
>>> way that an entity can confuse a Manifest, ROA, CSR or BGPsec 
>>> update so there's no issue with which public keys are used to
>>> verify the signatures on those data structures?
>> 
>> Ga … so that’s a little tortured; it’s a continuation of the
>> whole “these certs don’t really affect the rest of the RPKI".  How
>> about:
>> 
>> BGPsec Router Certificates are used only to verify the signature on
>> the BGPsec certificate request (only CAs process these) and the
>> signature on a BGPsec Update Message [ID.sidr-bgpsec-protocol] (only
>> BGPsec routers process these); BGPsec Router Certificates are not
>> used to process Manifests and ROAs or verify signatures on
>> Certificates or CRLs.
> 
> Yep, better.

Incorporated in my editor’s copy.

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

Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT)

[Sean Turner]

> --
> 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 Manifests and ROAs because the public key
> found in the BGPsec Router Certificate is used only to
> verify the signature on the BGPsec certificate request
> (only CAs process these) and the signature on a BGPsec
> Update Message [ID.sidr-bgpsec-protocol] (only BGPsec
> routers process these)." Do you mean that there's no way
> that an entity can confuse a Manifest, ROA, CSR or BGPsec
> update so there's no issue with which public keys are used
> to verify the signatures on those data structures?

Ga … so that’s a little tortured; it’s a continuation of the whole “these 
certs don’t really affect the rest of the RPKI".  How about:

BGPsec Router Certificates are used only to verify the signature on the BGPsec 
certificate request (only CAs process these) and the signature on a BGPsec 
Update Message [ID.sidr-bgpsec-protocol] (only BGPsec routers process these); 
BGPsec Router Certificates are not used to process Manifests and ROAs or verify 
signatures on Certificates or CRLs.

> - section 3: As noted in my comments on the BGPsec
> protocol, it'd be better to call out the SKI here if you
> don't add the direct ref to 6487 to the BGPsec protocol
> draft.

Wait, I thought I wasn’t supposed to duplicate any of the crazy stuff from 6487 
:)

spt

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

Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT)

[Sean Turner]

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 unique? I don't see what'd
> break in BGPsec if that rule is omitted, but maybe I'm
> missing something. 

This might OBE based on the hack/burn of this section, but are you talking 
about the last sentence?

>>> On 04/01/17 20:04, Rob Austein wrote:
>> ...
 This draft is a profile of RFC 6487, which is itself a profile of RFC
 5280.  All of the above is pretty much verbatim from RFC 6487.
>>> 
>>> Hmm. I wonder if that's the best plan, especially if there's
>>> no interop justification for some of it.
>> 
>> The theory, such as it is, goes:
>> 
>> * RPKI is a tightly constrained profile of X.509v3, with almost
>>  everything either required or forbidden, to reduce the number of
>>  grey areas.
>> 
>> * The BGPSEC profile is a minimal set of changes and extensions to the
>>  RPKI profile: same overall goal, slightly different constraints.

Yep that’s it: constraining the constrained.

>>> I note that 6487 says "In the RPKI, the subject name is determined
>>> by the issuer, not proposed by the subject" but that seems a bit
>>> weird for routers, where I would guess there'll be more diversity in
>>> terms of key/CSR generation code.
>> 
>> Well, strictly speaking the subject name is always selected by the
>> issuer in X.509, but I know what you mean.
>> 
>> RFC 6487 is weird about this because various parties were extremely
>> concerned to avoid anything that could be construed as certification
>> of real-world identity, ie, they did not want to find themselves in
>> the mainstream PKI business.  So RPKI uses meaningless names and has
>> the ability to enforce that, hence the text you note in RFC 6487.
> 
> I'd say any concerns that the web PKI CAs might have had ought
> now be ameliorated (or OBE, give letsencrypt), so not trodding
> on mainstream CA business is probably not as much as concern
> as was the case at the start of the RPKI work.
> 
>> 
>> RFC 6487 6.1.1 does in fact allow the subject to include a subject
>> name in the PKCS #10 request, but the text is loaded with weasel
>> words.  Speaking as someone who has implemented all of this, I find
>> the RFC 6487 constraints on subject name in PKCS #10 requests a bit
>> excessive, but that's not the document currently under discussion.
> 
> Well, except that this draft does re-iterate some of those now
> clearly weird MUSTs.
> 
>> 
>>> (Correct me if I'm wrong but I'm not sure if it's possible to
>>> conform to these requirements with e.g. openssl, or is it?)
>> 
>> The OpenSSL command line tool would probably fight hard against either
>> omitting the subject field from the PKCS #10 request or allowing it to
>> be NULL.  The former (field absent) is not even syntactically legal
>> X.509.  The latter (present but NULL) is legal but kind of unusual:
>> RFC 5280 4.1.2.6 allows it in certificates if a critical, non-empty
>> subjectAltName extension is present, RFC 2986 is silent on the subject
>> and is only informational in any case.
>> 
>> I'm pretty sure that the OpenSSL library would allow the
>> present-but-NULL form, but haven't tested it (recently? ever? don't
>> recall...).
>> 
>> In practice, I don't think any of the RKI CA implementations reject
>> PKCS #10 requests for having a non-NULL subject, they just ignore it.
>> 
>> All of this is still a problem with RFC 6487, which we should have
>> caught five years ago.  Oops.  Not sure what the best approach is when
>> trying to sub-profile a profile with a known wart like this.

The only thing I want to what Rob has mentioned is that this constraint to use 
common name and serial number has been around since mid-2011.  In contrast to 
many other groups I’ve worked with there was no desire to support everything 
and the kitchen sink only to find out later that there were a whole lot of 
implementation pitfalls to be had with T61String, BMPString, or how IDNA2008 vs 
IDNA2003 might affect comparisons.  I remember trying to get people to provide 
input to tell me that more was needed, I gave up at some point because all I 
got in response was crickets.  Now that might have been for a lot of reasons, 
but I/we certainly asked.

> Fair point.
> 
> So assuming there isn't a chorus of WG participants asking to
> remove the weird constraints then I'd say the right thing must
> be to not re-iterate any weirdness from 6487 but to only inherit
> that by reference. That way, if/when we modify 6487, we won't
> have to do the same with this, and maybe also hit problems
> with these constraints being enforced by code in two places.
> 
> I think the only such text I saw (that re-iterates 6487) was
> in 3.1.1 but there might I guess be more.

That text has basically been unchanged since the -01 of the individual draft 

Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-pki-profiles-19: (with COMMENT)

[Sean Turner]

> 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 different 2119
>>> approaches among the various bgpsec draft could be confusing to the
>>> reader.
>> 
>> 
>> Where’s that in draft-ietf-sidr-bgpsec-protocol?
>> 
>> Regardless, I’m not sure that restoration will work in this draft because 
>> there are repeated MUST requirements from other RFC and my AD told me to not 
>> capitalize them :)
> 
> Oops, sorry, I meant to say draft-ietf-sidr-bgpsec-ops.
> 
> Maybe I misunderstand what you mean; are the non-capitalized requirements 
> from other drafts intended as normative for _this_ draft? If not, then the 
> treatment of non-capitalized 2119 words as normal English seems to help.
> 

It’s more like: "As defined in RFC mubleqsuat, client must do this.”  The 
thinking goes (and I agree) that we should repeat requirements if we’re just 
quoting them.

spt

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

Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-pki-profiles-19: (with COMMENT)

[Sean Turner]

> 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 and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/
> 
> 
> 
> --
> COMMENT:
> --
> 
> A few strictly editorial comments:
> 
> - IDNits complains about some undefined references.

== Missing Reference: 'ID.sidr-rfc6485bis' is mentioned on line 334, but
 not defined

Yep that gets fixed when I change it to: RFC 7935

  ** Obsolete undefined reference: RFC 6485 (Obsoleted by RFC 7935)

I haven’t a clue where this reference is and why this warning is there.

  == Missing Reference: 'RFC6818' is mentioned on line 416, but not defined

And this also seems to be a fail on nroffedit.  It’s in the list but not 
populated in the informative references. 6818 is in the rfc-ref.txt from which 
the references are pulled.  grrr

 Have I recently mentioned how much I sometimes %$#@#$ hate the tools we 
need to use to make these drafts. 

I’m going to claim I failed here, beg forgiveness, and hope that we’ll let the 
RFC editor help us out later in the process.

> - Abstract: Why is the phrase "(to routers within an Autonomous System)"
> in parentheses?

sigh - no idea - parentheses removed

> -2: draft-ietf-sidr-bgpsec-protocol explicitly excludes non-capitalized
> versions of 2119 words. This draft does not. It seems different 2119
> approaches among the various bgpsec draft could be confusing to the
> reader.

Where’s that in draft-ietf-sidr-bgpsec-protocol?

Regardless, I’m not sure that restoration will work in this draft because there 
are repeated MUST requirements from other RFC and my AD told me to not 
capitalize them :)

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

Re: [sidr] Alexey Melnikov's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

[Sean Turner]

> 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 engineer actually implementing requested the change to the
> current syntax for ease of generating/parsing.
> 
> randy

I believe this is that thread that resulted in the final organization:

https://mailarchive.ietf.org/arch/msg/sidr/8B_e4CNxQCUKeZ_AUzsdnn2f5MU

spt

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

Re: [sidr] Review of draft-ietf-sidr-bgpsec-pki-profiles-19

[Sean Turner]

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
> something other than a serial number, which is explicitly NOT unique,
> and the CA is left to decide how to make it unique in the face of
> potentially repeating BGP IDs. If this is not a real issue (e.g.
> because duplicate IDs are rare and never within a RIR), please say
> so.

As Rob pointed out this paragraph is talking about the serial number naming 
attribute.  Maybe something like:

r/only two attributes/only two naming attributes
and
r/common name and serial number/common name (i.e., X520CommonName) and serial 
number (i.e., X520SerialNumber) 

People ought to them be able to track down the definitions.

> * 3.2: earlier we said that Basic Constraints must not be included in
> the EE cert. Now we are saying that only a particular boolean flag
> must not be honored when processing the Cert Request. What happens if
> Basic Constraints is included in the Cert Request but with other
> flags?

The CA is ultimately the one who decides what gets issued.  A good CA would 
know to only issue properly formatted BGPsec certificates either by ignoring 
the improperly requested “feature" or rejecting it outright.  Since these CAs 
really aren’t open CAs then the CA ought not get caught off-guard with requests.

> * 3.3: ID.sidr-rfc6485bis -> RFC 7935

drat I missed one.

> * 6: in the paragraph that discusses hash functions, please spell out
> the names of the two key identifiers, because I cannot determine what
> they are from the document.

Ack they’re the key identifiers in the cert: Subject Key Identifier and Issuer 
Key Identifier 

r/two key identifier extensions./two key identifier extensions (i.e., Subject 
Key Identifier and Issuer Key Identifier)

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

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

[Sean Turner]

This version incorporates the comments received to date (Alvaro’s AD review and 
GENART).  Figured it was better to address these before the IESG begins their 
reviews.

spt

> On Dec 30, 2016, at 14:52, 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-19.txt
>   Pages   : 13
>   Date: 2016-12-30
> 
> 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-19
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-19
> 
> 
> 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] Review of draft-ietf-sidr-bgpsec-pki-profiles-18

[Sean Turner]

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 with Nits
> 
> I am the assigned Gen-ART reviewer for this draft.  The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed by
> the IESG for the IETF Chair.  Please treat these comments just like
> any other last call comments.
> 
> Document: draft-ietf-sidr-bgpsec-pki-profiles-18
> Reviewer: Dale R. Worley
> Review Date: 12 Dec 2016
> IETF LC End Date: 19 Dec 2016
> IESG Telechat date: unknown
> 
> Summary:
> 
> This draft is basically ready for publication, but has nits that
> should be fixed before publication.
> 
> Some of these items appear to be technical, but I suspect that the
> intended meanings are clear to people well-versed in PKI and are known
> to work.  However, they are unclear to a naive reader.
> 
> 2.  Describing Resources in Certificates
> 
>   The RIR, in turn, issues a CA certificate to an Internet Service
>   Providers (ISP). 
> 
> s/Providers/Provider/
>   
>   The CA also
>   generate.  The CA also generates Certificate Revocation Lists
> (CRLs).
> 
> The first "The CA also generate." is extraneous.

Alvaro caught these too in his AD review so I’ve got them in the editor's copy 
I’m working with.

> 3.1  BGPsec Router Certificate Fields
> 
>   A BGPsec Router Certificate is a valid X.509 public key
> certificate,
>   consistent with the PKIX profile [RFC5280], containing the fields
>   listed in this section.  This profile is also based on [RFC6487]
> and
>   only the differences between this profile and the profile in
>   [RFC6487] are specified below.
> 
> I suspect this paragraph is going to cause implementers some trouble.
> What, exactly, are the constraints on the BGPsec Router Certificate?
> 
> It looks like the certificate must conform to:
> 
> - X.509
> 
> - RFC 5280
> 
> - RFC 6487 as modified by "below"
> 
> and I see that RFC 6487 requires that certificates conform to RFC
> 5280.  So it seems that the first two items are directly required by
> this document and transitively required by RFC 6487.
> 
> I suggest changing the first two items to be required only by
> transitivity, only mentioning X.509 and RFC 5280 as explanatory:
> 
>   A BGPsec Router Certificate is consistent with the profile in
>   [RFC6487] as modified by the specifications in this section.  As
>   such, it must be a valid X.509 public key certificate and
>   consistent with the PKIX profile [RFC5280].
> 
> Also, "below" is vague.  I suspect you mean "The differences between
> this profile and the profile in [RFC6487] are specified in this
> section.”

It’s basically profile of a profile of a profile plus some stuff.  I’m happy to 
adopt your suggestion modulo s/must be/is.

> 3.1.1.1.  Subject 
> 
>   However, each
>   certificate issued by an individual CA MUST contain a Subject name
>   that is unique within that context.
> 
> What is "that context"?  Do you mean:
> 
>   However, the certificates issued by an individual CA MUST contain
>   unique Subject names.
> 
> However that has difficulties when it comes time for the CA to issue
> new certificates with later validity times.
> 
> Why there is a constraint based on "issued by an individual CA" is not
> clear, given that there is no constraint regarding which CA issues
> certificates to which routers.  Merely aggregating the work of
> multiple CAs into one CA could require changing the subject names in
> the next revision of issued certificates, whereas splitting the
> work of one CA into multiple CAs would loosen this requirement.  In
> addition, the definition of "an individual CA" is not clear.  Is there
> really an operational requirement for this uniqueness constraint?
> 
> More to the point, is the combination of common name (i.e. AS number)
> and serial number (router ID) required to be globally unique or not?
> That seems to be the only question that can be operationally
> significant.
> 
> I suspect that someone well-versed in PKI knows these answers, but for
> the naive, what is required and why seems confusing.

I think this is just a case of a missing “CA” in front of the word “context” so 
tweaking it to: “…. that is unique to that CA context”.  The certs only need to 
be unique on a per CA basis the subject name does not need to be unique across 
the whole of the RPKI.  The combination of issuer+subject+serial # plus all the 
parent certs provides the uniqueness.

> 3.2.  BGPsec Router Certificate Request Profile
> 
>o The SubjectPublicKeyInfo and PublicKey fields are specified in
>  [ID.sidr-bgpsec-algs].
> 
> There is no "PublicKey field" discussed in ID.sidr-bgpsec-algs.  Is
> "subjectPublicKey" intended?  If so, "subjectPublicKey" seems to be a
> sub-field of SubjectPublicKeyInfo (per 

Re: [sidr] Stephen Farrell's No Objection on draft-ietf-sidr-bgpsec-algs-16: (with COMMENT)

[Sean Turner]

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 the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/
> 
> --
> COMMENT:
> --
> 
> - As Randy commented, if the goal is to smallerise the
> packets, it'd have been nice to use eddsa here but I assume
> that wasn't practical due to the timing and the number of
> RPKI elements that'd need to be defined for that? Is that
> right? Did the WG consider using 25519 instead of p256?  If
> not, is it worth asking, just in case everyone loves the
> idea more than this?

We weren’t trying to optimize for the smallest possible packets just smaller 
than RSA because at the time we were deciding on the algorithm suite, which was 
circa ’11, 25519 (or really any other EC-based algorithm) wasn’t far enough 
along the standardization path.  And, you’re right there was a grunch of 
timing/elements that needed to be come together to make any other EC-based 
algorithm realistic.

Since we’re now cc'ing the WG on IESG ballot positions it kind of feels like it 
just got asked ;)  Personally, I think it’s fine the way it is and for what 
it’s worth there are now interoperable implementations (see below).

> - Documents like this are better with test vectors included
> or referenced. Couldn't you add those or some pointers to
> those?

Would they be better in this draft or in the protocol draft (on the 20170115 
IESG telechat)?  Either way I reached out to Oliver Borchers @ NIST who did 
some interop testing between QuaggaSRx and BIRD [0].  Hoping that doing some 
packet captures with a simple example (BGPsec packets, private key+certs) 
wouldn’t be too hard to pull off; it’ll double the size of this draft that’s 
for sure.

Cheers,

spt

[0] https://tinyurl.com/hdsux2d
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Benoit Claise's No Objection on draft-ietf-sidr-bgpsec-algs-16: (with COMMENT)

[Sean Turner]

On Dec 12, 2016, at 16:54, Benoit Claise <bcla...@cisco.com> wrote:
> 
> Benoit Claise 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 the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/
> 
> 
> 
> --
> COMMENT:
> --
> 
> As noted by Jouni in his OPS DIR review, and acknowledged by Sean Turner
>> o Section 7 IANA Considerations says on line 192:
>> "Infrastructure (RPKI) group.  The one-octet BGPsec Algorithm Suite”
>>^
>> However, in the following table and text it says nothing about
>> values 0x10-0xff. Are these unassigned or reserved? This is a bit
>> confusing since the table lists values up to 0xF (one-nibble).
> 
> Sigh - that should be:
> 
> +++-+-+
> | 0x2-0xEF   | Unassigned | Unassigned  | This draft  |
> +++-+-+
> | 0xFF   | Reserved   | Reserved| This draft  |
> +++-+——+

Yep this is in my list of things to do.  I also let IANA to double check that I 
did it before they create the registry :)

spt

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

Re: [sidr] Alexey Melnikov's No Objection on draft-ietf-sidr-bgpsec-algs-16: (with COMMENT)

[Sean Turner]

> 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:
>>> 
>>> Maybe I missed it, but I don't think the document is clear on why new
>>> algorithms are needed. Is this specified in one of referenced documents?
>> 
>> I think you’re asking why different algorithms are needed to those specified 
>> for the rest of the RPKI?  If that’s the case, it’s key/sig size to keep the 
>> protocol smaller than if we used RSA/RSA-PSS and that’s covered in RFC 5480. 
>>  
> 
> Thank you, Sean. Maybe the document should have a sentence on this.

Ack - maybe in the last para of s1 we put something like this:

BGPsec uses a different algorithm as compared to the rest of the RPKI to 
minimize the size of the protocol exchanged between routers [RFC5480].

I’m not wed to this wording though so wordsmithing from the WG is welcome.

spt

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

Re: [sidr] Alexey Melnikov's No Objection on draft-ietf-sidr-bgpsec-algs-16: (with COMMENT)

[Sean Turner]

> 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 the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Maybe I missed it, but I don't think the document is clear on why new
> algorithms are needed. Is this specified in one of referenced documents?

I think you’re asking why different algorithms are needed to those specified 
for the rest of the RPKI?  If that’s the case, it’s key/sig size to keep the 
protocol smaller than if we used RSA/RSA-PSS and that’s covered in RFC 5480.  
If you’re asking about why would somebody want to define different algorithms 
for BGPsec then it's discovered weaknesses, vanity :), etc.

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

Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-pki-profiles-18

[Sean Turner]

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,
> 
> Thanks for the careful review.
> 
> I agree with your suggested edits cited in C2, C3, C4, C6, C7, C8, C9, and 
> C10.
> 
> C1: yep, this sentence is broken in a few ways. How about:
> "A router holding the private key is authorized to send
>route advertisements (to its peers) identifying the router's ASN as the 
> source of the advertisements.
> 
> C5: The allusion to future updates is in anticipation of adopting the relaxed 
> validation procedure that SIDR is about to forward to you. Still, the wording 
> is poor" how about: "…is identical to the validation procedure described in 
> Section 7 of [RFC6487] (and any RFC that updates this procedure), as modified 
> below."
> 
> C11: yes, my name should be removed from the Acknowledgements section.
> 
> I'll rely on Sean to make these changes, if he concurs.
> 
> Steve
> From: Alvaro Retana (aretana) 
> Sent: Sunday, December 4, 2016 7:58:20 AM
> To: draft-ietf-sidr-bgpsec-pki-profi...@ietf.org
> Cc: sidr-cha...@ietf.org; Chris Morrow; sidr@ietf.org
> Subject: AD Review of draft-ietf-sidr-bgpsec-pki-profiles-18
>  
> Dear authors:
>  
> Hi!  I just finished reading this document.
>  
> I have some comments (please see below) I would like you to address, but I 
> wouldn’t characterize any of them as major, so I’m starting the IETF Last 
> Call and placing this document in the next available IESG Telechat.
>  
> Thanks!
>  
> Alvaro.
>  
>  
> Comments:
>  
> C1. From the Introduction: “A router holding the private key is authorized to 
> send route advertisements (to its peers) that contain one or more of the 
> specified AS number as the last item in the AS PATH attribute.”  First of 
> all, if BGPSec is used, then the AS_PATH attribute is not.  Second, what does 
> “one or more of the specified AS number as the last item” mean?  There is 
> only one “last item”…but I’m guessing you might be referring to pre-pending.
>  
> C2. “Border Gateway Protocol Security protocol (BGPsec)”  I haven’t seen 
> BGPsec expanded anywhere else like that.  In fact, ID.sidr-bgpsec-protocol 
> just used BGPsec (no expansion).
>  
> C3. s/ID.sidr-rfc6485bis/rfc7935
>  
> C4. In Section 3.1.3.2. (Extended Key Usage): “As specified in [RFC6487] this 
> extension MUST be marked as non-critical.”  Because the behavior was 
> specified in RFC6487, then the “MUST” shouldn’t be Normative here; s/MUST/must
>  
> C5. Section 3.3. (BGPsec Router Certificate Validation) says that the 
> “validation procedure…is identical to the validation procedure described in 
> Section 7 of [RFC6487] (and any RFC that updates this procedure), but using 
> the constraints applied come from this specification.”  It Is strange to me 
> that the phrase inside the parenthesis is included here since there isn’t an 
> update to the procedure – is there a specific reason why you need to call 
> future (unknown) updates out at this point?   BTW, s/using the constraints 
> applied come from this specification/using the constraints from this 
> specification
>  
> C6. References.
> - RFC6818 can be made Informative.
> - RFC6486 and ID.sidr-bgpsec-protocol should be Normative.
>  
> C7. s/to an Internet Service Providers (ISP)/ to an Internet Service Provider 
> (ISP)
>  
> C8. s/The CA also generate./  (orphan phrase)
>  
> C9. s/The [RFC6480]/[RFC6480]
>  
> C10. s/3.1.1.1./3.1.1.
>  
> C11. “…the efforts of Steve Kent…were instrumental in preparing this work”  
> Steve is an author.

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

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-16.txt

[Sean Turner]

This version addresses AD review comments.  Most were related to the wording in 
the IANA considerations section.

spt

> On Nov 14, 2016, at 07:21, 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   : BGPsec Algorithms, Key Formats, & Signature Formats
>    Author  : Sean Turner
>   Filename: draft-ietf-sidr-bgpsec-algs-16.txt
>   Pages   : 7
>   Date: 2016-11-13
> 
> Abstract:
>   This document specifies the algorithms, algorithm parameters,
>   asymmetric key formats, asymmetric key size and signature format used
>   in BGPsec (Border Gateway Protocol Security).  This document updates
>   the Profile for Algorithms and Key Sizes for Use in the Resource
>   Public Key Infrastructure (RFC 7935).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-16
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-16
> 
> 
> 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] WGLC - draft-ietf-sidr-rpki-validation-reconsidered - ends 10/25/2016

[Sean Turner]

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  wrote:
> 
> Hi Sean, Tom, Russ, and all,
> 
> Sorry for bringing this up late. Technically past 25 October, and yes I would 
> like to see this go through as you might expect from an author...
> 
> That said, can someone with good ASN.1-fu please have look at the changes 
> w.r.t. ASN.1 structure and OIDs? I tried to include all your comments 
> properly - but I would feel safer if one of you could confirm.
> 
> Thanks
> Tim
> 
> 
>> On 26 Oct 2016, at 05:13, Sriram, Kotikalapudi (Fed) 
>>  wrote:
>> 
>> I read the draft once again. I support publication.
>> 
>> Found a minor typo in the last paragraph on p.15 (can be dealt with during 
>> RFC editor review process):
>> s/the loss of on IP address prefix from the VRS-IP/the loss of one IP 
>> address prefix from the VRS-IP/
>> 
>> Sriram
>> 
>> 
>> From: sidr  on behalf of Chris Morrow 
>> 
>> Sent: Tuesday, October 11, 2016 10:08 AM
>> To: sidr@ietf.org; sidr-cha...@ietf.org; sidr-...@ietf.org
>> Subject: [sidr] WGLC - draft-ietf-sidr-rpki-validation-reconsidered - ends   
>>10/25/2016
>> 
>> Howdy WG folks!
>> The authors of:
>> draft-ietf-sidr-rpki-validation-reconsidered
>> 
>> believe they have addressed all inflight concerns/comments, the
>> request is to WGLC this, consider it's place in the world and if
>> appropriate pass this document along to the IESG for publication.
>> 
>> The abstract for this draft is:
>> "This document proposes an update to the certificate validation
>>  procedure specified in RFC 6487 that reduces aspects of operational
>>  fragility in the management of certificates in the RPKI, while
>>  retaining essential security features."
>> 
>> Let's have a read through, consider and reply with your thoughts please,
>> this WGLC is set to expire: 10/25/2016 - October 25, 2016.
>> 
>> thanks for reading/replying/thinking!
>> -chris
>> co-chair-persona
>> 
>> ___
>> 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] WGLC - draft-ietf-sidr-delta-protocol - 10/25/2016

[Sean Turner]

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 launch [0].

spt

[0] https://www.youtube.com/watch?v=zVf-rehP4b8

> On Oct 20, 2016, at 10:19, Christopher Morrow  wrote:
> 
> Howdy!
> 5 more days until this call expires, please read and comment... or at least 
> say:
>   "Hey! I did read this it is [awesome|horrible|acceptable|dumpsterfire]"
> 
> thanks!
> -chris
> (feel free to cut/paste/edit the quote if it'll save you time)
> 
> On Tue, Oct 11, 2016 at 10:15 AM, Chris Morrow  wrote:
> 
> Howdy WG Folks!
> Let's chat (email) about the subject document:
>   draft-ietf-sidr-delta-protocol
> 
> The authors believe they have dealt with all open items and are
> interested in moving this document forward to IESG for
> publication. Let's have a read/write/arithmetic time with the draft
> and send comments/questions/suggestions/etc to the list for the
> authors to handle or, possibly just: "yea! move this document along!"
> if you believe it's ready for the next step in it's lifecycle.
> 
> The WGLC should end 10/25/2016 - October 25th 2016.
> 
> The abstract for this document is:
>   "In the Resource Public Key Infrastructure (RPKI), certificate
>authorities publish certificates, including end entity certificates,
>Certificate Revocation Lists (CRL), and RPKI signed objects to
>repositories.  Relying Parties (RP) retrieve the published
>information from those repositories.  This document specifies a delta
>protocol which provides relying parties with a mechanism to query a
>repository for incremental updates, thus enabling the RP to keep its
>state in sync with the repository."
> 
> thanks!
> -chris
> co-chair-persona
> 
> ___
> 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 mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Proposal for next steps - chartering sidrops?

[Sean Turner]

> 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 is created by CA and maintained by repository managers.
>> 
>> IMHO, network operators are not the only RPKI role that the community is 
>> going to solicit input from.  CA operators, repository operators, RP service 
>> providers all bear significance as with SIDR Operations, in identifying 
>> issues and sharing experiences. 
> Yeah there are a bunch of actors who are operators of elements other
> than networks.
> 
> RIRs and CAs spring immediately to mind.
>> Although network operators could also be CA operators, repository operators, 
>> RP service providers, yet RIRs, CA and repository backend service providers, 
>> and third party RP don’t fall into the category of  ‘network operators’.  
>> 
>> I would suggest the “The goals of the sidr-ops working group” be adjusted 
>> slightly, with CA operators, repository operators, RP service providers 
>> involved.
> yeah I think the tent should be inclusive.

I agree with Di+Joel so +1.

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

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

[Sean Turner]

tax is imported from [RFC6268] --

   END


> - Original Message -
> From: "Sean Turner" <s...@sn3rd.com>
> To: "Rob Austein" <s...@hactrn.net>; "Tim Bruijnzeels" <t...@ripe.net>;
> "Russ Housley" <hous...@vigilsec.com>
> Cc: "IETF SIDR" <sidr@ietf.org>
> Sent: Tuesday, August 02, 2016 12:28 AM
> 
>> On Jul 21, 2016, at 06:36, Tim Bruijnzeels <t...@ripe.net> wrote:
>> 
>> 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 <hous...@vigilsec.com> wrote:
>>> 
>>> 
>>> On Jul 19, 2016, at 9:14 AM, Rob Austein <s...@hactrn.net> 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-number
> s-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-number
> s-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
> 
> To make sure I’m following along, to address the "Updates: 3779, 6484,
> 6487 (if approved)" changes would the follow changes work:
> 
> 0) RFC6484-related changes
> 
> If we’re going with two OIDs (one for the original “strict" validation
> and one for new “relaxed” validation), then I’m hoping that we can just
> define a new OID in s1.2 of RFC 6484 and be done with it (i.e., I hope
> we don’t also have to update s4.1.1, s4.5.1, and s4.7.1 where RFC 3779
> is mentioned).  Here’s some text for a new section:
> 
> #.#  Updates to RFC 6484
> 
> This section replaces s1.2 of [RFC6484] with the following:
> 
> The name of this document is "Certificate Policy (CP) for the Resource
> PKI (RPKI)”.
> 
> This policy has been assigned the following two OIDs:
> 
>   id-cp-ipAddr-asNumber OBJECT IDENTIFIER ::= { iso(1)
> identified-organization(3) dod(6) internet(1)
> security(5) mechanisms(5) pkix(7) cp(14) 2 }
> 
>   id-cp-ipAddr-asNumber-v2 OBJECT IDENTIFIER ::= { iso(1)
> identified-organization(3) dod(6) internet(1)
> security(5) mechanisms(5) pkix(7) cp(14) TBD }
> 
> id-cp-ipAddr-asNumber and the extensions defined in [RFC3779] indicate
> that the original certification path validation rules are to be used.
> id-cp-ipAddr-asNumber-v2 and the extensions defined in [this document]
> indicate that the validation reconsidered certification path validation
> rules defined in [this document] are to be used.
> 
> 
> 1) IANA registrations
> 
> We need to register some OIDs with IANA.  Here’s an IANA considerations
> section (assumes we’re registering a new CP OID - [] references will be
> to whatever section # it ends up being):
> 
> 6. IANA Considerations
> 
> IANA is to register the following five OIDs:
> 
> - id-cp-ipAddr-asNumber-v2 from [insert Section and #] in the SMI
> Security for PK

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] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-06.txt

[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 Router Certificate I-D because it's not an RFC, 
>> just yet. It's currently in IESG Processing. The current document therefore 
>> has a request and some suggestion to the authors to change the document (in 
>> which case the section can be deleted in the next (hopefully final) version 
>> of this document.
>> 
>> I don't mind either way. Maybe the chairs have an idea about what the best 
>> process is. But in either case we would like to ask the BGPSec Router 
>> Certificate authors to review the included text.
> 
> Tim,
> 
> Just so I’m following along:
> 
> - This draft replaces the text in RFC 6487 s7.2 so should 
> rpki-validation-reconsidered draft include the “Updates: 6487 (if approved)” 
> header?  My understanding is that the proposal is that all RPKI validators 
> follow these new steps so that would make sense process wise.

I would like to propose that sidr-rpki-validation-reconsidered include an 
updates header, i.e., “Updates: 6487 (if approved)”, be included on the 1st 
page of the draft in the appropriate location.

Of the options presented in the change below for sidr-bgpsec-pki-profiles, I’d 
like to rely on the change proposed above and not make the OLD/NEW changes I 
proposed below, i.e., I am suggesting making no changes to the introductory 
text in s3.3 of sidr-bgpsec-pki-profiles to refer to 
sidr-rpki-validation-reconsidered because it’s an unnecessary change.

Steve’s suggested some other edits a a result of this thread and 
rpki-validation-reconsidered, so if the chairs direct me I can upload a new 
version of sidr-bgpsec-pki-profiles.  Since AD review hasn’t really happened 
yet, maybe we can treat these as late, but timely WGLC comments?

spt

> - bgpsec-pki-profiles s3.3 currently refers to RFC 6487 s7 for validation 
> procedures and technically if rpki-validation-reconsidered updates RFC 6487 
> when bgpsec-pki-profiles refers to RFC 6487 it includes those references so I 
> wouldn’t necessarily have to add a explicit reference to 
> rpki-validation-reconsidered … but people will forget this and miss the 
> update and I know Wes hates chasing references ;)  So, to drive this point 
> home we could do the following tweak in addition to adding your suggested 
> bullet and separate-certificate per ASN suggestion:
> 
> OLD:
> 
>  The validation procedure used for BGPsec Router Certificates is
>  identical to the validation procedure described in Section 7 of
>  [RFC6487], but using the constraints applied come from this
>  specification.
> 
> NEW:
> 
>  The validation procedure used for BGPsec Router Certificates is
>  identical to the validation procedure described in Section 7 of
>  [ID.sidr-rpki-validation-reconsidered], but using the constraints
>  applied come from this specification.
> 
> Note I’d probably also add ID.idr-rpki-validation-reconsidered to the 
> required reading list in the terminology section :/
> 
> spt

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

Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-06.txt

[Sean Turner]

> 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 therefore 
> has a request and some suggestion to the authors to change the document (in 
> which case the section can be deleted in the next (hopefully final) version 
> of this document.
> 
> I don't mind either way. Maybe the chairs have an idea about what the best 
> process is. But in either case we would like to ask the BGPSec Router 
> Certificate authors to review the included text.

Tim,

Just so I’m following along:

- This draft replaces the text in RFC 6487 s7.2 so should 
rpki-validation-reconsidered draft include the “Updates: 6487 (if approved)” 
header?  My understanding is that the proposal is that all RPKI validators 
follow these new steps so that would make sense process wise.

- bgpsec-pki-profiles s3.3 currently refers to RFC 6487 s7 for validation 
procedures and technically if rpki-validation-reconsidered updates RFC 6487 
when bgpsec-pki-profiles refers to RFC 6487 it includes those references so I 
wouldn’t necessarily have to add a explicit reference to 
rpki-validation-reconsidered … but people will forget this and miss the update 
and I know Wes hates chasing references ;)  So, to drive this point home we 
could do the following tweak in addition to adding your suggested bullet and 
separate-certificate per ASN suggestion:

OLD:

  The validation procedure used for BGPsec Router Certificates is
  identical to the validation procedure described in Section 7 of
  [RFC6487], but using the constraints applied come from this
  specification.

NEW:

  The validation procedure used for BGPsec Router Certificates is
  identical to the validation procedure described in Section 7 of
  [ID.sidr-rpki-validation-reconsidered], but using the constraints
  applied come from this specification.

Note I’d probably also add ID.idr-rpki-validation-reconsidered to the required 
reading list in the terminology section :/

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

Re: [sidr] wglc for draft-ietf-sidr-rpki-oob-setup-04

[Sean Turner]

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  wrote:
> 
> The authors believe that draft-ietf-sidr-rpki-oob-setup-04 ("An Out-Of-Band 
> Setup Protocol For RPKI Production Services”) is mature and ready for a 
> working group last call.
> 
> This message starts a two week wglc for draft-ietf-sidr-rpki-oob-setup-04, 
> which will end 16 Jun 2016.
> 
> Please review the draft and send comments and your opinion of whether it is 
> worthy of publication to the list.  Remember that support for publication is 
> needed, and comments can improve quality, so lack of comments is not 
> sufficient.
> 
> You can reach the document at 
> https://tools.ietf.org/html/draft-ietf-sidr-rpki-oob-setup-04 and 
> https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-oob-setup/.
> 
> —Sandy, speaking as one of the wg co-chairs
> ___
> 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] I-D Action: draft-ietf-sidr-bgpsec-overview-08.txt

[Sean Turner]

We added 3 paragraphs at the end of s3.2 to address Wes’ WGLC comment.

There’s also editorial tweaks as suggested by Wes and Steve K (off-list) as 
well as additional editorial tweaks the author team found.

We believe this version addresses the known WGLC issues.  Obviously, we’ll have 
to see if Wes agrees :)

spt

> On Jun 23, 2016, at 13:07, 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   : 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 document provides an overview of a security extension to the
>   Border Gateway Protocol (BGP) referred to as BGPsec.  BGPsec improves
>   security for BGP routing.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-overview/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-overview-08
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-overview-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/
> 
> ___
> 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] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016)

[Sean Turner]

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 
> lifetime of the draft.
> 
> But still.
> 
> Please.  Pretty please.  Pretty please with sugar on top.  Pretty please with 
> a cherry on top.
> 
> Could we get some feedback that this document is ready for publication?
> 
> —Sandy, speaking as one of the wg co-chairs
> 
> 
> On Jun 8, 2016, at 10:19 PM, Sandra Murphy  wrote:
> 
>> No responses at all.
>> 
>> Come on folks.  It’s a short document, like Chris says.
>> 
>> You should be able to read and comment without much trouble.
>> 
>> —Sandy, speaking as one of the wg co-chairs
>> 
>> On Jun 1, 2016, at 2:52 PM, Chris Morrow  wrote:
>> 
>>> 
>>> Howdy WG folks,
>>> Please take this note as the start of the 2wk WGLC period for:
>>> 
>>> 
>>> Abstract:
>>> "Deployment of the BGPsec architecture and protocols has many
>>> operational considerations.  This document attempts to collect and
>>> present the most critical and universal.  It is expected to evolve as
>>> BGPsec is formalized and initially deployed."
>>> 
>>> This is a relatively short document, 8 pages, full of wonder and
>>> excitement! I hope that the wg members have read it (it's been through
>>> 8+ revisions) and that they will re-read it quickly, provide comments
>>> as appropriate and ideas on preparedness for publication or not.
>>> 
>>> 
>>> Thanks for you time and attention to this matter,
>>> 
>>> -Chris
>>> co-chair-persona
>>> 
>>> ___
>>> 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 mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-11.txt

[Sean Turner]

This is just a resurrection draft:
https://www.ietf.org/rfcdiff?url1=draft-ietf-sidr-rtr-keying-10=draft-ietf-sidr-rtr-keying-11

spt

> On Jun 15, 2016, at 09:58, 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   : Router Keying for BGPsec
>Authors : Randy Bush
>      Sean Turner
>  Keyur Patel
>   Filename: draft-ietf-sidr-rtr-keying-11.txt
>   Pages   : 13
>   Date: 2016-06-15
> 
> Abstract:
>   BGPsec-speaking routers are provisioned with private keys in order to
>   sign BGPsec announcements.  The corresponding public keys are
>   published in the global Resource Public Key Infrastructure, enabling
>   verification of BGPsec messages.  This document describes two methods
>   of generating the public-private key-pairs: router-driven and
>   operator-driven.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-11
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-11
> 
> 
> 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] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-17.txt

[Sean Turner]

Updated with a new 3.4 section as per Sandy’s direction.

spt

> On Jun 01, 2016, at 15:11, 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-17.txt
>   Pages   : 13
>   Date: 2016-06-01
> 
> 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-17
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-17
> 
> 
> 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] WGLC on draft-ietf-sidr-bgpsec-algs-11 (ENDS 30-Oct-2015)

[Sean Turner]

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

> On Apr 21, 2016, at 11:26, Sandra Murphy  wrote:
> 
> This wglc ended a very long time ago.
> 
> The chairs believe that the wg consensus supports publication of this draft.
> 
> The draft was waiting for the draft-ietf-sidr-rfc6485bis draft, which it 
> updates.
> 
> Unfortunately, this draft uses the same language in the Additional 
> Requirements section that draft-ietf-sidr-rfc6485bis used.  Now that the wg 
> has reached consensus on new text for that section, the draft authors are 
> directed to change the Additional Requirements section to the language used 
> in draft-ietf-sidr-rfc6485bis.
> 
> The draft authors are also reminded of the agreement to revise text in the 
> IANA registry section (see message 
> https://mailarchive.ietf.org/arch/msg/sidr/ArfOCMbpG0X9JGDFH2d6StBSBLs).
> 
> When a new version is posted, the wg chairs can request publication.
> 
> —Sandy, speaking as one of the wg co-chairs
> 
> On Oct 16, 2015, at 6:47 PM, Sandra Murphy  wrote:
> 
>> The chairs and the authors believe that draft-ietf-sidr-bgpsec-algs-11 is 
>> mature and has stabilized.
>> 
>> This message starts a WGLC for  draft-ietf-sidr-bgpsec-algs-11, which will 
>> end 30-October-2015.
>> 
>> Please review the draft and send comments to the list, and say whether you 
>> believe it is ready for publication.
>> 
>> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs
>> 
>> BGPsec Algorithms, Key Formats, & Signature Formats
>> 
>> Abstract
>> 
>>  This document specifies the algorithms, algorithms' parameters,
>>  asymmetric key formats, asymmetric key size and signature format used
>>  in BGPsec (Border Gateway Protocol Security).  This document updates
>>  the Profile for Algorithms and Key Sizes for use in the Resource
>>  Public Key Infrastructure (draft-ietf-sidr-rfc6485bis).
>> 
>> —Sandy, speaking as one of the wg co-chairs
>> 
>> 
>> 
> 
> ___
> 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] wglc for draft-ietf-sidr-bgpsec-15

[Sean Turner]

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 
> https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-15.
> 
> Please respond with your opinion of the draft’s readiness for publication.
> 
> Remember that positive replies are needed, so please do provide comments to 
> the list.
> 
> —Sandy, speaking as one of the wg co-chairs
> ___
> 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] wglc for draft-ietf-sidr-rfc6485bis-05

[Sean Turner]

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, Sandra Murphy  wrote:
> 
> A nagging reminder.  There has been no comment, pro or con.
> 
> It’s a short draft.  Please do review and say whether you want the draft to 
> progress or not.
> 
> If you want to see the differences in this latest version, one way is to look 
> at the tools page for the draft:
> 
> draft page: https://tools.ietf.org/html/draft-ietf-sidr-rfc6485bis-05
> side-by-side diff:  
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-sidr-rfc6485bis-05.txt
> 
> —Sandy, speaking as one of the wg co-chair
> 
> On Mar 9, 2016, at 6:28 AM, Sandra Murphy  wrote:
> 
>> As discussed in December, a new version for draft-ietf-sidr-rfc6485bis was 
>> required to deal with an IESG comment on the Security Considerations section.
>> 
>> The authors have submitted a new version and ask for a working group last 
>> call.
>> 
>> This starts the wglc which will end on 23 Mar 2016.  Please review the draft 
>> for its readiness for publication and provide comments to the list.
>> 
>> Positive support is needed in order to judge consensus for publication, so 
>> please do comment on the list.
>> 
>> The draft is available at:  
>> https://tools.ietf.org/html/draft-ietf-sidr-rfc6485bis-05.
>> 
>> —Sandy, speaking as one of the wg co-chairs
>> ___
>> 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 mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] comments on draft-ietf-sidr-bgpsec-pki-profiles

[Sean Turner]

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 value.

Now we have a couple of options:

a) say nothing and rely on the CA doing the right thing

b) prohibit/require SIA/EKU (respectively) be present in the PKCS#10

c) For:

* SIA - allow SIA in the PKCS #10 and rely on the CA to discards it and issue a 
properly formed certificate.

* EKU - allow EKU but not require EKU in the PKCS #10; if present, the EKU must 
have the correct OID.

I’m partial to option c because it seems like the pragmatic approach.

Thoughts?

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

Re: [sidr] Modifiation request: draft-ietf-sidr-bgpsec-protocol-14

[Sean Turner]

Right - so after re-reading this I see it now.

spt

> On Feb 24, 2016, at 11:19, Borchert, Oliver <oliver.borch...@nist.gov> wrote:
> 
> Sean,
> 
> The change relates to the "Sequence of Octets to be Signed" (SOS), not the 
> signature blocks on the wire. 
> For validation and signing, one needs to generate a separate SOS per 
> algorithm / signature block 
> which is the same as it always was - nothing changed here.
> The resulting signature (while signing) will be added to the appropriate 
> signature block,
> and algorithm transfers are 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 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?
>> 
>> spt
>> 
>>> On Feb 10, 2016, at 15:05, Borchert, Oliver <oliver.borch...@nist.gov> 
>>> wrote:
>>> 
>>> Hello Matt,
>>> 
>>> after reading version 14 of the BGPSec protocol draft and after discussing 
>>> the
>>> update between us, Michael Baer (BIRD implementer) and I (Quagga 
>>> Implementer)
>>> want to propose some  changes for generation of the “Sequence of Octets to 
>>> be
>>> Signed” (SOS) in the draft on pg. 15. This change would modify the order of
>>> information within the SOS as well as the order of attributes within the
>>> “Secure_Path” Segment listed on pg. 8. 
>>> 
>>> For your convenience I attached this email as pdf document as well.
>>> 
>>> NONE of the changes has any impact on the information that is put on the 
>>> wire
>>> in regards to adding or removing data. The only on the wire change is the
>>> ordering of the attributes within the Secure_Path Segment.
>>> 
>>> As we are all aware, the most expensive operation within the BGPSEC 
>>> protocol is
>>> the crypto operation, especially the Path verification.
>>> With the proposed modification of the SOS, implementers will be able to 
>>> utilize
>>> more efficient and higher performing software mechanisms to validate the
>>> complete chain of signatures in an update. The current form makes this more
>>> difficult.
>>> 
>>> Our request does remove some data from the previous SOS structure, changes 
>>> the
>>> order of the remaining attributes within the SOS and includes the 
>>> re-ordering
>>> of one data segment on the wire, which will facilitate the SOS generation.
>>> 
>>> 
>>> 1) Request for re-ordering the Secure_Path segment
>>> The first request deals with modifying the order of the Secure_Path segment.
>>> This modification will become more obvious later on when we explain our 
>>> request
>>> for changes in the structure of “Sequence of Octets to be Signed” (SOS) on
>>> pg. 15. 
>>> This is also the only change that has an affect on the data on the “wire” 
>>> but
>>> again only regarding the order itself, NOT the content.
>>> 
>>> The current format as it is shown on pg. 8 is as follows:
>>> 
>>> +---+
>>> | AS Number  (4 octets) |
>>> +---+
>>> | pCount (1 octet)  |
>>> +---+
>>> | Flags  (1 octet)  |
>>> +---+
>>> 
>>> We request to move the “AS Number” field to the end of the signature 
>>> segment.
>>> This results in the following structure:
>>> 
>>> +---+
>>> | pCount (1 octet)  |
>>> +---+
>>> | Flags  (1 octet)  |
>>> +---+
>>> | AS Number  (4 octets) |
>>> +---+
>>> 
>>> The reason for this minor change becomes more clear when we explain our 
>>> request
>>> for modifying the SOS structure. But as a little preview for where we want 
>>> to
>>> go with this, consider the following:
>>> 
>>> Having a set of Secure_Path segments, the last f

Re: [sidr] Modifiation request: draft-ietf-sidr-bgpsec-protocol-14

[Sean Turner]

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?

spt

> On Feb 10, 2016, at 15:05, Borchert, Oliver  wrote:
> 
> Hello Matt,
> 
> after reading version 14 of the BGPSec protocol draft and after discussing the
> update between us, Michael Baer (BIRD implementer) and I (Quagga Implementer)
> want to propose some  changes for generation of the “Sequence of Octets to be
> Signed” (SOS) in the draft on pg. 15. This change would modify the order of
> information within the SOS as well as the order of attributes within the
> “Secure_Path” Segment listed on pg. 8. 
> 
> For your convenience I attached this email as pdf document as well.
>  
> NONE of the changes has any impact on the information that is put on the wire
> in regards to adding or removing data. The only on the wire change is the
> ordering of the attributes within the Secure_Path Segment.
>  
> As we are all aware, the most expensive operation within the BGPSEC protocol 
> is
> the crypto operation, especially the Path verification.
> With the proposed modification of the SOS, implementers will be able to 
> utilize
> more efficient and higher performing software mechanisms to validate the
> complete chain of signatures in an update. The current form makes this more
> difficult.
>  
> Our request does remove some data from the previous SOS structure, changes the
> order of the remaining attributes within the SOS and includes the re-ordering
> of one data segment on the wire, which will facilitate the SOS generation.
>  
>  
> 1) Request for re-ordering the Secure_Path segment
> The first request deals with modifying the order of the Secure_Path segment.
> This modification will become more obvious later on when we explain our 
> request
> for changes in the structure of “Sequence of Octets to be Signed” (SOS) on
> pg. 15. 
> This is also the only change that has an affect on the data on the “wire” but
> again only regarding the order itself, NOT the content.
>  
> The current format as it is shown on pg. 8 is as follows:
>  
> +---+
> | AS Number  (4 octets) |
> +---+
> | pCount (1 octet)  |
> +---+
> | Flags  (1 octet)  |
> +---+
>  
> We request to move the “AS Number” field to the end of the signature segment.
> This results in the following structure:
>  
> +---+
> | pCount (1 octet)  |
> +---+
> | Flags  (1 octet)  |
> +---+
> | AS Number  (4 octets) |
> +---+
>  
> The reason for this minor change becomes more clear when we explain our 
> request
> for modifying the SOS structure. But as a little preview for where we want to
> go with this, consider the following:
>  
> Having a set of Secure_Path segments, the last field of the following segment
> equals the “Target AS” needed in the SOS structure. But this becomes more
> obvious later on.
>  
>  
> 2) Modifying the SOS structure”
>  
> The current structure as it is presented on pg. 15 of draft-14 is as follows:
>  
> +---+
> | Target AS Number  |
> +---+
> | AS Number |
> +---+
> | pCount|
> +---+
> | Flags |
> +---+
> | Previous Secure_Path  |
> +---+
> | Previous Signature_Block  |
> +---+
> | AFI   |
> +---+
> | SAFI  |
> +---+
> | NLRI  |
> +---+
>  
> This structure is very inefficient for signature validation because for each
> signature validation the structure needs to be newly regenerated.
>  
> One major change in version-14 compared to the preceding drafts is the
> inclusion of all previous signatures to the SOS structure. In the previous
> draft only the directly preceding signature was part of the SOS. Version-14
> introduces an additional overhead of approximately 91-93 bytes (69-71 for
> signature + 20 SKI + 2 signature length) or ~92 extra bytes per Signature.
>  
> This means that verifying a 10 hop path, the following additional overhead for
> signatures must be added to each SOS in comparison to draft 13:
>  
> (assumed 92 bytes on average per signature)
>  
> SOS overhead 10 signatures: +828 bytes
> SOS overhead  9 signatures: +736 bytes
> SOS overhead  8 signatures: +644 bytes
> 

Re: [sidr] wg adoption call for draft-tbruijnzeels-sidr-validation-local-cache-02

[Sean Turner]

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.
> 
> A working group adoption poll starts now and will end 14 days from now on 23 
> December.
> 
> Please respond on the list to say whether you support adoption of this work 
> as a working group work item AND whether you will participate in the 
> discussion.
> 
> Remember that working group consensus to adopt the work needs responses, not 
> just absence of objection, so speak up.
> 
> --Sandy, speaking as one of the wg co-chairs
> ___
> 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] I-D Action: draft-ietf-sidr-bgpsec-algs-14.txt

[Sean Turner]

Just fixes two spelling mistakes.

spt

> On Nov 10, 2015, at 17:36, 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   : BGPsec Algorithms, Key Formats, & Signature Formats
>    Author  : Sean Turner
>   Filename: draft-ietf-sidr-bgpsec-algs-14.txt
>   Pages   : 7
>   Date: 2015-11-10
> 
> Abstract:
>   This document specifies the algorithms, algorithm parameters,
>   asymmetric key formats, asymmetric key size and signature format used
>   in BGPsec (Border Gateway Protocol Security).  This document updates
>   the Profile for Algorithms and Key Sizes for use in the Resource
>   Public Key Infrastructure (ID.sidr-rfc6485bis).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-14
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-14
> 
> 
> 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

Re: [sidr] Validation reconsidered draft status

[Sean Turner]

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  
  
 Validation of signed resource data using a target resourceValidation of signed resource data using a signing key that is
 certificate consists of verifying that the digital signature of thecertified in a resource certificate, coupled with a specific set of
 signed resource data is valid, using the public key of the targetnumber resources, consists of verifying that the digital signature of
 resource certificate, and also validating the resource certificate inthe signed resource data is valid, using the public key that is
 the context of the RPKI, using the path validation process.  Thiscertified by the resource certificate, and also validating the
 path validation process verifies, among other things, that aresource certificate in the context of the RPKI, using the path
  validation process.

  This path validation process verifies, among other things, that a
 prospective certification path (a sequence of n certificates)prospective certification path (a sequence of n certificates)
 satisfies the following conditions:satisfies the following conditions:
   
1.  for all 'x' in {1, ..., n-1}, the subject of certificate 'x'   1.  for all 'x' in {1, ..., n-1}, the subject of certificate 'x'
is the issuer of certificate ('x' + 1);   is the issuer of certificate ('x' + 1);
   
2.  certificate '1' is issued by a trust anchor;   2.  certificate '1' is issued by a trust anchor;
   
3.  certificate 'n' is the certificate to be validated; and   3.  certificate 'n' is the certificate to be validated; and
   
  
4.  for all 'x' in {1, ..., n}, certificate 'x' is valid.   4.  for all 'x' in {1, ..., n}, certificate 'x' is valid for the
 specific set of resources.
   
  
 Certificate validation entails verifying that all of the followingRPKI validation for a specific set of resources entails verifying
 conditions hold, in addition to the certification path validationthat all of the following conditions hold, in addition to the
 criteria specified in Section 6 of [RFC5280]:certification path validation criteria specified in Section 6 of
  [RFC5280]:
   
1.  The certificate can be verified using the issuer's public key   1.  The certificate can be verified using the issuer's public key
and the signature algorithm   and the signature algorithm
   
2.  The current time lies within the certificate's Validity From   2.  The current time lies within the certificate's Validity From
and To values.   and To values.
   
3.  The certificate contains all fields that MUST be present, as   3.  The certificate contains all fields that MUST be present, as
  
defined by this specification, and contains values for   specified by [RFC6487], and contains values for selected
selected fields that are defined as allowable values by this   fields that are defined as allowable values by this
specification.   specification.
   
  
4.  No field, or field value, that this specification defines as   4.  No field, or field value, that the [RFC6487] specification
MUST NOT be present is used in the certificate.   defines as MUST NOT be present is used in the certificate.
   
5.  The issuer has not revoked the certificate.  A revoked   5.  The issuer has not revoked the certificate.  A revoked
certificate is identified by the certificate's serial number   certificate is identified by the certificate's serial number
being listed on the issuer's current CRL, as identified by the   being listed on the issuer's current CRL, as identified by the
CRLDP of the certificate, the CRL is itself valid, and the   CRLDP of the certificate, the CRL is itself valid, and the
public key used to verify the signature on the CRL is the same   public key used to verify the signature on the CRL is the same
public key used to verify the certificate itself.   public key used to verify the certificate itself.
   
  
6.  The resource extension data is "encompassed" by the resource   6.  The resource extension data contained in this certificate
 

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-13.txt

[Sean Turner]

This version addresses editorial tweaks I got from Steve.  Most are 
concentrated in s2 where I tried to make it clearer that the algs to 
sign/verify cert requests and sign/verify BGPsec update messages are defined in 
the doc and the algs to make certs/CRLs are in 6485bis.

And like the pki-profiles draft this one updates another Standards track 
draft/rfc so this really ought to be intended for Standards track as well.

spt

> On Nov 06, 2015, at 07:31, 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   : BGPsec Algorithms, Key Formats, & Signature Formats
>    Author  : Sean Turner
>   Filename: draft-ietf-sidr-bgpsec-algs-13.txt
>   Pages   : 7
>   Date: 2015-11-05
> 
> Abstract:
>   This document specifies the algorithms, algorithm parameters,
>   asymmetric key formats, asymmetric key size and signature format used
>   in BGPsec (Border Gateway Protocol Security).  This document updates
>   the Profile for Algorithms and Key Sizes for use in the Resource
>   Public Key Infrastructure (ID.sidr-rfc6485bis).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-13
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-13
> 
> 
> 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

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-12.txt

[Sean Turner]

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
> 
>> Incorporates comments received during WGLC.
>> 
>> Willing to be shouted down on the tweaks in the IANA considerations
> section, but I am hoping that we can move progress this version of the
> document towards our AD.
> 
> Sean
> 
> More a gentle nudge than a shout.
> 
> draft-leiba-cotton-iana-5226bis-11 introduces the idea of a registry
> being within a group and this I-D makes no mention of the latter.  Is
> the intent to have a new BGPsec Group, slotting in between Battery
> Technologies and BFD, or is it part of the existing RPKI Group?  I
> suggest making that explicit in the IANA Considerations.

Oh good idea. I think we should put the BGPsec registry in the RPKI group so 
how about :

  The Internet Assigned Numbers Authority (IANA) is requested
  to define the "BGPsec Algorithm Suite Registry" described below
  in the Resource Public Key Infrastructure (RPKI) group.  

> And to make the IANA Considerations complete of themselves, since they
> get extracted onto a web site, should there be a reference to the
> constraints imposed on the algorithms in section two i.e. the two
> algorithms to be registered must be as specified in rfc6485bis?  An
> rfc6485ter would then have to have IANA Considerations to update that
> part but I expect we would remember to do that.

So there’s no registry for the algorithms used to sign RPKI objects.  Folks 
that start out in IANA registries will need to follow some bread crumbs from 
ROAs, Manifests, and Ghostbusters to 6487 to 6485bis.  BGPsec will be no 
different in this regard.  Again, this assume readers start in the IANA 
registries, which I hope is not where they’re starting ;)

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

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

[Sean Turner]

tl;dr: new versions since -13 to address editorial comments - changed from BCP 
to standards track

Sandy noted that a some point this draft switched the BCP.  For the life of me, 
I can’t remember the rationale for that changed especially since this draft is 
updating a standards track RFC.  I changed the intended track to the more 
defensible standards track.

spt

> On Nov 05, 2015, at 08:15, 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
>  Stephen Kent
>   Filename: draft-ietf-sidr-bgpsec-pki-profiles-15.txt
>   Pages   : 13
>   Date: 2015-11-04
> 
> 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-15
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-15
> 
> 
> 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] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-14.txt

[Sean Turner]

WG chair review turned up that for some reason an earlier version got switched 
to BCP.  I’ve got no record of why and since we’re updating 6485bis that’s 
standards track - I switched it back.

spt

> On Nov 04, 2015, at 15:54, 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
>  Stephen Kent
>   Filename: draft-ietf-sidr-bgpsec-pki-profiles-14.txt
>   Pages   : 14
>   Date: 2015-11-03
> 
> 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-14
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-14
> 
> 
> 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

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

[Sean Turner]

This version incorporates comments received during WGLC.

I think this one can be safely handed to our AD.

spt

> On Nov 03, 2015, at 08:04, 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
>  Stephen Kent
>   Filename: draft-ietf-sidr-bgpsec-pki-profiles-13.txt
>   Pages   : 14
>   Date: 2015-11-02
> 
> 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-13
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-13
> 
> 
> 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] WGLC: draft-ietf-sidr-bgpsec-overview ENDING: 10/21/2015)

[Sean Turner]

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 by having to read a 
couple of hundred pages, 2) What’s the right order of the drafts to hit the 
IESG agenda, 3) Will we need to change something in the overview draft, etc.  
I’ve come to think that when the WG thinks a draft is done we should push it 
upstream and let them deal with it in the order that it comes.  We can let the 
IESG place discusses that hold the draft before it gets to the RFC editor based 
on whatever criteria they feel is appropriate, or the RFC editor can hold it 
because of their processes - basically we should get things off our plate ASAP 
so that we can focus on other things.  Obviously YMMV.

spt

On Oct 13, 2015, at 09:39, Samuel Weiler  wrote:

> The doc cites a bunch of i-d's.  Under previous practice, that would have 
> left it languishing in the RFC Editor queue waiting for the others.  If that 
> were the practice now, I would suggest we hold it and release all of the docs 
> as a group, which would permit later changes to this doc if needed.  I think 
> current practice does allow citing i-d's (though version numbers need to be 
> specified), but I'm wondering if we wouldn't be better off waiting.  This is 
> the first BGPsec doc many will read - I would prefer to have it be correct 
> and complete even if we make changes in the other docs along the way.
> 
> Other than that, no issues with the doc - it's in good shape.
> 
> Minor nits sent separately to the editors.
> 
> -- Sam Weiler
> 
> ___
> 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] WGLC: draft-ietf-sidr-bgpsec-overview ENDING: 10/21/2015)

[Sean Turner]

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,
> Please consider this your warning/notice that the WGLC has been started for:
> 
>  draft-ietf-sidr-bgpsec-overview
> 
> Abstract:
>  "This document provides an overview of a security extension to the
>   Border Gateway Protocol (BGP) referred to as BGPsec.  BGPsec improves
>   security for BGP routing."
> 
> Please give this a read, send comments if there are any, and let us
> know if this is prepared for publication request.
> 
> Thanks!
> 
> -chris
> co-chair
> 
> ___
> 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] preventing SKI collisions

[Sean Turner]

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 tackling #3, but the amount of work involved means that I'd
> like to get topic #1, and possibly topic #2, out of the way first.
> 

Okay so I think we’re in agreement here that we don’t work on #3 now, but I’m 
also thinking that we should leave #1 and #2 alone for now.   If we think a 
SHA-1 hash for the RPKI’s KIs are good enough now, then it sounds like it's 
also good enough for BGPsec.  It seems really odd that we do something 
different in BGPsec than what is done in the rest of the RPKI.  So, I’m 
proposing that:

1. We make no change to the SKI generation mechanism.

2. To make sure folks don’t continue to go down this rathole I think we should 
add the following to the security considerations, which is copied from RFC 7093:

  While hash algorithms provide preimage resistance, second-preimage
  resistance, and collision resistance, none of these properties are
  needed for key identifiers.

3. We tackle the KI algorithm change we/if we re-open the RPKI PKI profile.

spt

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

Re: [sidr] preventing SKI collisions

[Sean Turner]

(I see there’s been some more mail on this thread so hopefully I won’t 
contradict myself later :/ )

No fear about harming SHA256 deployment!  We’re already using it for the 
hash+sigs of the Manifest, ROAs, RPKI-certs (both for RPKI and BGPsec).

On Aug 06, 2015, at 20:33, George Michaelson g...@algebras.org wrote:

 Can you give me some indication at what level of operation a SHA1 over the 
 public key risks colliding? 0.001? 0.1?
 
 I don't want to impede progress if SHA256 is sensible, but I have a feeling 
 this is a risk almost at the noise floor. Since its per-CA, the CA is 
 presumed to have to hand a complete set of all the active keys its signed 
 over, and presumably could say: damn. collide -not that it has much choice 
 about what to do, to get over this.
 
 Its possible we're just hunting more 0.000s down the road.

This made me chuckle, because in some sense that’s what we always do while 
cryptographers are chopping’/slayin’ zeros ;)

 There are 1m discrete prefixes in the current routing system, and less than 
 256,000 actors in this specific (non-BGP router key, not path key) space of 
 allocations and assignments (we're only just walking into 4 byte ASN 
 territory so the real number of actors is very possibly far smaller, but its 
 more than the total count of ASN since many prefix holders in Asia don't have 
 ASN and sign ROA over somebody else's ASN, but clearly, its bounded by the 
 prefix count. So I feel ok saying it lies between 64k and 1m)
 
 There is a minimum break-out of 5-way near the top, lets assume they equi 
 position (they don't) and say between 16k and 256k per top CA, thats me 
 asking you if a SHA1 hash over the keys, in 256,000 sign-overs, is likely to 
 collide. Anyone else has far fewer. Most CA has less than 1 and very 
 probably less than 1000 things to sign over. Even the APNIC flat world has 
 less than 256k things to sign over.
 
 I know; I could spin up the dice (again)
 
 I did this for about 60,000 when I first tested things before we had a 
 design. I did not even collide in the crude OpenSSL hash name model, let 
 alone the SKI hash.
 
 Pragmatism is not good. I'm fine with a respin to put this to SHA256 but 
 might we not just want to say ...plus a -1 -2 -3 generational qualifier 
 should a collision occur and avoid any risk?

Starting with my usual caveat: I’m not a cryptographer

When talking about collisions, a hash algorithms are usually considered to be 
about as strong as half the output length so for SHA-1 it’s 2^(160/2).  But, 
there’s been some attacks which RFC 6194 says got down to 2^69 but assuming 
wikipedia is right it’s down in the 2^63 range.  I guess I’d have to leave 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, 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 this:
 
   *  If/when additional weaknesses are found in SHA-1, 3rd party
  cryptographic libraries that implement SHA-1 may become hard to
  find.
 
   *  If/when a serious weakness is found in SHA-1, someone might be
  able to exploit the weakness to attack some aspect of RPKI/BGPsec.
 
  Thinking about the latter, I believe there is a not-entirely-implausible
  attack that might justify a change:
 
   1. An attacker uses a weakness in SHA-1 to generate a large number of
  BGPsec router certificates for an AS, where each certificate has a
  different key but the same SKI.
 
   2. The attacker uses one of those certificates to generate a
  signature segment in the BGPsec_Path attribute, and sends the
  BGPsec Update message to a peer.
 
   3. The peer starts the process of validating the signature segment
  generated by the attacker.  Due to the numerous keys with the same
  SKI, the peer is forced to test each of the attacker's keys one by
  one until a match is found.  This could take a considerable amount
  of time.
 
   4. While it is validating the signature, the peer processes all
  Update messages as if they were unsigned because there is not
  enough CPU available at the moment.  The attacker has succeeded in
  (temporarily) disabling BGPsec.
 
  One way to block the above attack is to use a stronger hash function
  (e.g., SHA-256) for the SKI.  Unfortunately, because the SKI extension
  doesn't have an algorithm identifier field, there's no way to switch
  without a flag day.
 
  We could make a proactive change now while deployment is low, but it
  would still be unpleasant.
 
  An alternative idea suggested by Matt Lepinski

Re: [sidr] preventing SKI collisions

[Sean Turner]

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. When the
 parent CA re-issues a certificate for the child CA with a new style
 SKI, then the child will have to re-issue its products with a new AKI.
 
 This is not impossible, but not trivial either. Especially if a
 delegated model is used.
 
 have we done a dnssec-v1?  we should be able to change hashes without a
 flag day.  if not, we need to think.
 
 We cannot change the SKI algorithm without a flag day.  Fortunately, if
 we prohibit CAs from publishing router certs with colliding SKIs within
 an AS (as proposed in my original email), we won't ever need to.

I think there’s probably three-related topics:

1) avoiding collisions in BGPsec,

2) chaining the way SKIs are generated for BGPsec certificates/messages, and

3) changing the way we make KIs for the entire RPKI.

I think what Richard and I are going back and forth about is #1, but others 
(including myself) seemed to be discussing #3 and I’m sure I was thinking about 
#2.  I agree with Randy that if we can’t change the algorithm used to generate 
KIs without a flag-day, then I think we need to think (more on this at the end).

 The following is an enumeration of some important points about the SKI
 that hopefully makes it easy to understand why my proposed change should
 be sufficient (credit for the idea goes to Matt Lepinski; I only came up
 with the specific wording):
 
  1.  The SKI length is currently fixed at 160 bits:
 
* RFC6487 (and rfc6487bis) says 160-bit SHA1
* the rpki-rtr protocol has a fixed-length 160-bit SKI field
* the BGPsec protocol has a fixed-length 160-bit SKI field

Excellent - three of the example methods for defining a key identifier in RFC 
7093 are 160-bit outputs:

  The keyIdentifier is composed of the leftmost 160-bits of the
  SHA-* hash of the value of the BIT STRING subjectPublicKey
  (excluding the tag, length, and number of unused bits).

Where * is 256, 384, and 512.

I think this helps out somewhat on topics #2 and #3 because we’d not have to 
change a bunch of other drafts to make the SKIs fit.

  2.  The SKI does not contain an algorithm identifier OID, so there is
  no way to communicate to RPs that a different algorithm was used
  to produce the SKI.

There’s also the fourth option from RFC 7093, which is:

   The keyIdentifier is composed of the hash of the DER encoding of
   the SubjectPublicKeyInfo value

The SPKI does include the algorithm ID.

  3.  SKI collisions must be prevented to keep an attacker from
  temporarily disabling BGPsec.  If collisions were not prevented,
  I believe the attacker could launch the following attack:
 
a. generate tons of certificates with different keys but the
   same SKI
b. publish the certificates
c. send a syntactically correct BGPsec update message where:
 * the BGPsec_Path entries are made up (including invalid
   signatures)
 * the most recent entry uses the colliding SKI and the
   attacker's AS number but a bad signature
d. sit back and enjoy a period of time where routers use the
   invalid route while validation is pending
 
  The above attack works because routers will likely use the update
  message as if it was valid until the cryptographic operations
  determine otherwise (see bgpsec-protocols section 5 paragraph 2).
  Because of the numerous colliding SKIs, it will take routers a
  long time to exhaustively check every matching certificate before
  it reaches the conclusion that the signature was not produced
  by any of the matching certificates.
 
  4.  The only mechanism we have in place to prevent SKI collisions is
  the SKI algorithm itself.
 
  5.  Because of points #3 and #4 above, RPs must validate the SKI in a
  router certificate.  If RPs blindly trusted CAs to correctly
  produce the correct SKI value, then it would be trivial for an
  attacker to produce thousands of certificates with colliding SKI
  values (e.g., just fill in the SKI with all zeros).
 
  6.  Because of points #2 and #5 above, we can't change the SKI
  algorithm without a flag day.
 
  7.  Because of points #3, #4, and #6 above, BGPsec's security is tied
  to the security of the unchangeable SKI algorithm.
 
  8.  SHA-1 is believed to be sufficient at the moment for preventing
  SKI collisions, even with malicious actors.
 
  9.  Someone might eventually discover a way to easily produce SHA-1
  collisions.  If so, SHA-1 would no longer be sufficient for
  preventing SKI collisions with malicious actors.
 
  10. If we added a separate mechanism to prevent SKI 

Re: [sidr] I-D Action: draft-ietf-sidr-rfc6485bis-03.txt

[Sean Turner]

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 also addressed the other outstanding errata reported for 
 RFC 6485, 
 as well as correcting minor nits that escaped the eagle eyes of various 
 reviewers of
 the RFC and previous versions of this draft, and hopefully I’ve avoided adding
 more nits in my final markup!
 
 Chairs (well, specifically Sandy, as she has been working with me on getting 
 this
 document ready), I’m not sure of the current WG status of this document, wrt 
 last
 calls, etc, but I believe its about as cooked as it is ever going to be!
 
 regards,
 
   Geoff
 
 
 
 
 On 24 Jul 2015, at 3:32 pm, 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   : The Profile for Algorithms and Key Sizes for use in 
 the Resource Public Key Infrastructure
   Authors : Geoff Huston
 George Michaelson
  Filename: draft-ietf-sidr-rfc6485bis-03.txt
  Pages   : 9
  Date: 2015-07-24
 
 Abstract:
  This document specifies the algorithms, algorithms' parameters,
  asymmetric key formats, asymmetric key size, and signature format for
  the Resource Public Key Infrastructure (RPKI) subscribers that
  generate digital signatures on certificates, Certificate Revocation
  Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and
  certification requests as well as for the relying parties (RPs) that
  verify these digital signatures.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/
 
 There's also a htmlized version available at:
 https://tools.ietf.org/html/draft-ietf-sidr-rfc6485bis-03
 
 A diff from the previous version is available at:
 https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rfc6485bis-03
 
 
 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

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

Re: [sidr] preventing SKI collisions

[Sean Turner]

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 this:
 
  *  If/when additional weaknesses are found in SHA-1, 3rd party
 cryptographic libraries that implement SHA-1 may become hard to
 find.
 
  *  If/when a serious weakness is found in SHA-1, someone might be
 able to exploit the weakness to attack some aspect of RPKI/BGPsec.
 
 Thinking about the latter, I believe there is a not-entirely-implausible
 attack that might justify a change:
 
  1. An attacker uses a weakness in SHA-1 to generate a large number of
 BGPsec router certificates for an AS, where each certificate has a
 different key but the same SKI.
 
  2. The attacker uses one of those certificates to generate a
 signature segment in the BGPsec_Path attribute, and sends the
 BGPsec Update message to a peer.
 
  3. The peer starts the process of validating the signature segment
 generated by the attacker.  Due to the numerous keys with the same
 SKI, the peer is forced to test each of the attacker's keys one by
 one until a match is found.  This could take a considerable amount
 of time.
 
  4. While it is validating the signature, the peer processes all
 Update messages as if they were unsigned because there is not
 enough CPU available at the moment.  The attacker has succeeded in
 (temporarily) disabling BGPsec.
 
 One way to block the above attack is to use a stronger hash function
 (e.g., SHA-256) for the SKI.  Unfortunately, because the SKI extension
 doesn't have an algorithm identifier field, there's no way to switch
 without a flag day.
 
 We could make a proactive change now while deployment is low, but it
 would still be unpleasant.
 
 An alternative idea suggested by Matt Lepinski is to prohibit router
 certificate SKI collisions within an AS if the keys differ.  In other
 words, if there are two valid BGPsec router certs in the same AS with
 different keys but the same SKI, then RPs MUST mark them both as
 invalid.  Thanks to the RFC3779 checks, it would not be possible for
 someone in a different AS to invalidate your certs even if a weakness in
 SHA-1 was discovered.
 
 So I propose we add something like the following to the end of Section 3
 in draft-ietf-sidr-bgpsec-pki-profiles:
 
o To prevent denial-of-service attacks against RPs, Subject Key
  Identifier collisions within an AS are not permitted.  Any
  BGPsec Router Certificate that:
*  references the same AS number in the Autonomous System
   Identifier Delegation extension,
*  has a different key, and
*  has the same value in the Subject Key Identifier extension
  as another otherwise valid certificate MUST NOT be considered
  valid.
 
 We may also want to add something to rfc6487bis to invalidate a
 certificate if its SKI matches an ancestor (and the key differs), though
 I can't think of a way to take advantage of such a collision at the moment.
 
 Thoughts?
 
 Thanks,
 Richard

I’m all for switching to using a better hash algorithm to avoid collisions, but 
why can’t we just do it anytime we want?  The SKI/AKI fields are only ever 
generated by a CA so the RPs don’t need to know the algorithm used.

What I am/was suggesting we do is make the following change in Section 4.8.2/3 
to RFC 6487:

OLD:

  The Key Identifier used for resource certificates is the 160-bit
  SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the
  Subject Public Key, as described in Section 4.2.1.1/2 of [RFC5280].

NEW:

  The Key Identifier used for resource certificates is the 160-bit
  SHA-256 hash of the value of the DER-encoded ASN.1 bit string of the
  Subject Public Key, as described in Section 2 of [RFC7093].

As far as you tweaks to the bgpsec-pki-profile draft, if we can do these checks 
without calculating the AKI/SKI values I’m all for this [0], but I guess I’m 
curious why collisions outside the AS would be allowed? Shouldn’t it be:

  To prevent denial-of-service attacks against RPs, Subject Key
  Identifier collisions are not permitted.  Any BGPsec Router
  Certificate that:
   *  references the same AS number in the Autonomous System
  Identifier Delegation extension,
   *  has a different key, and
   *  has the same value in the Subject Key Identifier extension
  as another otherwise valid certificate MUST NOT be
  considered valid.

spt

[0] Full disclosure: I co-authored RFC 7093 Additional Methods for Generating 
Key Identifiers Values”.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-11.txt

[Sean Turner]

I took the liberty of updating the reference to 6485bis.

spt

On Aug 06, 2015, at 20:02, 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   : 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, algorithms' parameters,
   asymmetric key formats, asymmetric key size and signature format used
   in BGPsec (Border Gateway Protocol Security).  This document updates
   the Profile for Algorithms and Key Sizes for use in the Resource
   Public Key Infrastructure (draft-ietf-sidr-rfc6485bis).
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/
 
 There's also a htmlized version available at:
 https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-11
 
 A diff from the previous version is available at:
 https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-11
 
 
 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

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-10.txt

[Sean Turner]

Change is r/BGPSEC/BGPsec to align with overview draft and dates.

spt

On Jul 20, 2015, at 13:52, 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   : 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 the algorithms, algorithms' parameters,
   asymmetric key formats, asymmetric key size and signature format used
   in BGPsec (Border Gateway Protocol Security).  This document updates
   the Profile for Algorithms and Key Sizes for use in the Resource
   Public Key Infrastructure (RFC 6485).
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/
 
 There's also a htmlized version available at:
 https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-10
 
 A diff from the previous version is available at:
 https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-10
 
 
 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

Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-09.txt

[Sean Turner]

This is a simple keep alive update (i.e., I just updated the dates).

spt

On Jul 20, 2015, at 13:45, 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   : Router Keying for BGPsec
Authors : Sean Turner
  Keyur Patel
  Randy Bush
   Filename: draft-ietf-sidr-rtr-keying-09.txt
   Pages   : 11
   Date: 2015-07-20
 
 Abstract:
   BGPsec-speaking routers are provisioned with private keys to sign BGP
   messages; the corresponding public keys are published in the global
   RPKI (Resource Public Key Infrastructure) thereby enabling
   verification of BGPsec messages.  This document describes two ways of
   provisioning the public-private key-pairs: router-driven and
   operator-driven.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/
 
 There's also a htmlized version available at:
 https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-09
 
 A diff from the previous version is available at:
 https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-09
 
 
 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] extensions in RFC6487 but not draft-ietf-sidr-bgpsec-pki-profiles-10

[Sean Turner]

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,
 
 https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-10#section-3.1:
 
   This profile is also based on [RFC6487] and
   only the differences between this profile and the profile in
   [RFC6487] are listed.
 
 https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-10#section-3.1.3:
 
   The following X.509 V3 extensions MUST be present (or MUST be absent,
   if so stated) in a conforming BGPSEC Router Certificate, except where
   explicitly noted otherwise.  No other extensions are allowed in a
   conforming BGPSEC Router Certificate.
 
 I checked with the authors, and the intent was that the following refers to 
 all extensions in RFC6487 and the updates to extensions in 
 draft-ietf-sidr-bgpsec-pki-profiles-10. However, I initially read the text in 
 3.1.3 as forbidding all extensions not mentioned in 
 draft-ietf-sidr-bgpsec-pki-profiles-10, including some useful ones like the 
 SKI.
 
 I think it might be clearer to simply remove the entire first paragraph of 
 section 3.1.3. RFC 6487 section 4.8 contains similar[0] text, and section 3.1 
 of the draft makes it clear that RFC 6487 section 4.8 applies.
 
 [0] But not the same. That issue should probably be handled by 
 draft-rhansen-sidr-rfc6487bis though.
 
 -- 
 David Eric Mandelberg / dseomn
 http://david.mandelberg.org/
 
 ___
 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] [Editorial Errata Reported] RFC6485 (4340)

[Sean Turner]

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 an editorial typo so that it will be fixed in a bis if/when one
 is ever produced?
 
 Thanks,
 Richard

Sorry definitely wasn't clear there - errata is the right way to handle this.  
I jumped to how I’d mark it if I were AD :)  There’s three ways: approved, 
rejected, and HDFU (hold for document update).  I was opting for HFDU.

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

Re: [sidr] [Editorial Errata Reported] RFC6485 (4340)

[Sean Turner]

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 example
 that makes sense.
 
 I also fail to see how this affects interoperability, which is why I
 submitted it as an editorial errata instead of a technical errata.  This
 change is about as significant as
 http://www.rfc-editor.org/errata_search.php?eid=3162, except maybe
 less so because people sometimes cite section numbers while nobody will
 ever cite this particular line.
 
 If the change was technical and substantial, I would have submitted a
 bis or update draft.
 
 Could Richard kindly enlighten me as to why this is an important change?
 
 Someone unfamiliar with the SIDR working group might be confused by
 mention of SIDR.  (Just like someone stumbling across a typo might be
 distracted a bit.)
 
 This is just a readability fix, nothing more.  I think the more
 important question is:  Is the suggested change correct?

The document to which the words refers to is called:
An Infrastructure to Support Secure Internet Routing
and the short title in the header of the draft is:
RPKI Architecture
but I don’t think folks are going to be confused because they’re going to 
follow the [RFC6480] to the normative references and then do a lookup or just 
do a straight lookup on RFC 6480 so I’d probably just leave it.

spt

 -Richard
 
 
 thanks,
 
   Geoff
 
 
 
 
 On 20 Apr 2015, at 7:36 pm, RFC Errata System rfc-edi...@rfc-editor.org 
 wrote:
 
 The following errata report has been submitted for RFC6485,
 The Profile for Algorithms and Key Sizes for Use in the Resource Public 
 Key Infrastructure (RPKI).
 
 --
 You may review the report below and at:
 http://www.rfc-editor.org/errata_search.php?rfc=6485eid=4340
 
 --
 Type: Editorial
 Reported by: Richard Hansen rhan...@bbn.com
 
 Section: 1
 
 Original Text
 -
  the SIDR Architecture
  [RFC6480],
 
 
 Corrected Text
 --
  the RPKI Architecture
  [RFC6480],
 
 
 Notes
 -
 Neither SIDR nor Secure Inter-Domain Routing is mentioned in RFC6480.  
 RFC6480 is about the design of the RPKI, so RPKI Architecture seems like 
 a more appropriate fit.
 
 Instructions:
 -
 This erratum is currently posted as Reported. If necessary, please
 use Reply All to discuss whether it should be verified or
 rejected. When a decision is reached, the verifying party (IESG)
 can log in to change the status and edit the report, if necessary. 
 
 --
 RFC6485 (draft-ietf-sidr-rpki-algs-05)
 --
 Title   : The Profile for Algorithms and Key Sizes for Use in 
 the Resource Public Key Infrastructure (RPKI)
 Publication Date: February 2012
 Author(s)   : G. Huston
 Category: PROPOSED STANDARD
 Source  : Secure Inter-Domain Routing
 Area: Routing
 Stream  : IETF
 Verifying Party : IESG
 
 
 ___
 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 mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] New Version Notification for draft-rhansen-sidr-rfc6487bis-00.txt

[Sean Turner]

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 errata I submitted ;)

  * RFC 7318 (update)
  * two changes that were submitted as errata but rejected for being
technical changes:
http://www.rfc-editor.org/errata_search.php?rfc=6487rec_status=9
 
 Comments welcome.

I’ll caveat this by saying I am definitely not hard over on this, but I thought 
I’d bring it up: Should we switch to a SHA-256-based key identifier?

s4.8.3 includes the following text:

  The Key Identifier used for resource certificates is the 160-bit
  SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the
  issuer's public key, as described in Section 4.2.1.1 of [RFC5280].

Well now there’s RFC 7093 (http://datatracker.ietf.org/doc/rfc7093/) and we 
could point there and generate an identifier based on SHA-256.  Full 
disclosure: this would introduce a downref to the document; the RFC was 
published through the ISE.

spt

 Thanks,
 Richard
 
 
  Forwarded Message 
 Subject: New Version Notification for draft-rhansen-sidr-rfc6487bis-00.txt
 Date: Mon, 09 Mar 2015 15:56:48 -0700
 From: internet-dra...@ietf.org
 To: Richard Hansen rhan...@bbn.com, Andrew Newton a...@arin.net,
 Robert Loomans robert.loom...@suncorp.com.au, Geoff Huston
 g...@apnic.net, George Michaelson g...@apnic.net
 
 
 A new version of I-D, draft-rhansen-sidr-rfc6487bis-00.txt
 has been successfully submitted by Richard Hansen and posted to the
 IETF repository.
 
 Name: draft-rhansen-sidr-rfc6487bis
 Revision: 00
 Title:A Profile for X.509 PKIX Resource Certificates
 Document date:2015-03-09
 Group:Individual Submission
 Pages:32
 URL:
 http://www.ietf.org/internet-drafts/draft-rhansen-sidr-rfc6487bis-00.txt
 Status:
 https://datatracker.ietf.org/doc/draft-rhansen-sidr-rfc6487bis/
 Htmlized:   http://tools.ietf.org/html/draft-rhansen-sidr-rfc6487bis-00
 
 
 Abstract:
   This document defines a standard profile for X.509 certificates for
   the purpose of supporting validation of assertions of right-of-use
   of Internet Number Resources (INRs).  The certificates issued under
   this profile are used to convey the issuer's authorization of the
   subject to be regarded as the current holder of a right-of-use of
   the INRs that are described in the certificate.  This document
   contains the normative specification of Certificate and Certificate
   Revocation List (CRL) syntax in the Resource Public Key
   Infrastructure (RPKI).  This document also specifies profiles for the
   format of certificate requests and specifies the Relying Party RPKI
   certificate path validation procedure.
 
   This document obsoletes RFC 6487.
 
 
 
 
 
 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.
 
 The IETF Secretariat
 
 
 
 ___
 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] I-D Action: draft-ietf-sidr-bgpsec-algs-09.txt

[Sean Turner]

This is just a keep alive version.

spt

On Jan 21, 2015, at 18:29, 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   : 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,
   asymmetric key formats, asymmetric key size and signature format used
   in BGPSEC (Border Gateway Protocol Security).  This document updates
   the Profile for Algorithms and Key Sizes for use in the Resource
   Public Key Infrastructure (RFC 6485).
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-09
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-09
 
 
 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

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

[Sean Turner]

This is just a keep alive version.

spt

On Jan 21, 2015, at 18:29, 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-10.txt
   Pages   : 12
   Date: 2015-01-21
 
 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) or ASes.  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(es).  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-10
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-10
 
 
 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

Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-08.txt

[Sean Turner]

Just a keep alive version.

spt

On Jan 21, 2015, at 18:42, 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   : 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 are provisioned with private keys to sign BGP
   messages; the corresponding public keys are published in the global
   RPKI (Resource Public Key Infrastructure) thereby enabling
   verification of BGPsec messages.  This document describes two ways of
   provisioning the public-private key-pairs: router-driven and
   operator-driven.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-08
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-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

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

[Sean Turner]

I went ahead and submitted the -09 version I referred to earlier:

http://www.ietf.org/mail-archive/web/sidr/current/msg06825.html

As far I know, there are no outstanding issues.

spt

On Nov 10, 2014, at 08: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 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-09.txt
   Pages   : 13
   Date: 2014-11-10
 
 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-09
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-09
 
 
 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

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

[Sean Turner]

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 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?
 
 i think i understand it and it makes sense.  though i would tersify it
 to
 
   Rrouters can support multiple ASs with
   separate keys pairs, one for each AS
 
 :)
 
 randy

I let this one sit for a while and hearing no objections I went ahead and made 
the changes in the version on github:
https://github.com/seanturner/draft-ietf-sidr-bgpsec-pki-profiles/blob/master/draft-ietf-sidr-bgpsec-pki-profiles-09.txt

I’ll submit it to the IETF once the submission window reopens.

To the best of my knowledge this resolves the last remaining technical issue.

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

Re: [sidr] RFC 6487 possible oversight

[Sean Turner]

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 serialNumber attribute.  If both
   attributes are present, it is RECOMMENDED that they appear as a set.
   The CommonName attribute MUST be encoded using the ASN.1 type
   PrintableString [X.680].
 
 This wording does not define the encoding of the serialNumber
 attribute.
 
 While mailing with Rob he told me that the serialNumber came later
 into the spec, and most likely the definition has been just forgotten.
 Can someone from the authors clarify?

I think it’s right as is.

RFC 5280 has the definition for serial number:

-- Naming attributes of type X520SerialNumber

id-at-serialNumber  AttributeType ::= { id-at 5 }

X520SerialNumber ::=PrintableString (SIZE (1..ub-serial-number))

So there’s no need to say it’s printable string because it always is printable 
string.  When you specify a common name you need say which of the permitted 
encodings you want because there’s a choice of 5 string types:

-- Naming attributes of type X520CommonName

id-at-commonNameAttributeType ::= { id-at 3 }

-- Naming attributes of type X520CommonName:
--   X520CommonName ::= DirectoryName (SIZE (1..ub-common-name))
--
-- Expanded to avoid parameterized type:

X520CommonName ::= CHOICE {
  teletexString TeletexString   (SIZE (1..ub-common-name)),
  printableString   PrintableString (SIZE (1..ub-common-name)),
  universalString   UniversalString (SIZE (1..ub-common-name)),
  utf8StringUTF8String  (SIZE (1..ub-common-name)),
  bmpString BMPString   (SIZE (1..ub-common-name)) }

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

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

[Sean Turner]

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

Re: [sidr] WGLC on draft-ietf-sidr-rfc6490-bis-01.txt

[Sean Turner]

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 support for multiple URIs in a TAL. 

Then again maybe just that sentence in the intro would do the trick.

spt

On Sep 26, 2014, at 10:17, Sandra Murphy sandra.mur...@parsons.com wrote:

 The authors of Resource Certificate PKI (RPKI) Trust Anchor Locator, 
 draft-ietf-sidr-rfc6490-bis-01.txt believe the draft is ready for a WGLC.
 
 This starts a two week working group last call, to end on 10 Oct 2014.
 
 The draft is available at 
 http://tools.ietf.org/html/draft-ietf-sidr-rfc6490-bis-01.
 
 Please do comment on the list, indicating whether you believe this draft is 
 ready for publication.  Note that silence is sufficient.  There must be 
 support from the wg indicating consensus for publication.
 
 --Sandy, speaking as one of the wg co-chairs.
 ___
 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] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-08.txt

[Sean Turner]

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

Re: [sidr] EST (was Re: about the thread Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487)

[Sean Turner]

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 option for this, if folks want to
 consider alternatives to PKCS#10. Since it was authored by a Cisco
 guy, there is some chance it might become available in their
 routers. I would suggest this path only for router certs, not for
 the RPKI certs. That might make it unpalatable, as a CA operated by
 an ISP would have to deal with two cert request formats: PKCS#1- for
 child CA certs (if the ISP is not a stub in the RPKI tree) and EST
 for router certs.
 Is there any real benefit to EST, given that we already have to
 support PKCS #10 and given that PKCS #10 implementations are almost
 certainly easier to find than EST implementations?
 As I noted, I am aware of only a Cisco implementation, but we could check 
 with
 Max Pritikin to see if he is aware of others.
 Absent some serious advantage that I'm not seeing, this doesn't seem
 particularly attractive.
 
 I'm just pointing out options.
 Understood.
 
 
 Dan’s got an implementation on github:
 
 https://github.com/danharkins/est
 
 spt

Here’s the link for Cisco's:

https://github.com/cisco/libest

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

[sidr] drafts on github

[Sean Turner]

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 mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.txt

[Sean Turner]

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 your original question was:
 
 
 Whats the relationship between this draft and draft-ietf-sidr-rfc6485bis?
 
 So you want to know if bgpsec-algs is updating the original RFC6485 or 
 updating rfc6485bis?

draft-ietf-sidr-bgpsec-algs adds support for EC public keys  signature formats 
to RFC 6485 for BGPsec.  If 6485bis is going to be updated to include these 
changes then draft-ietf-sidr-bgpsec-algs can go away but I didn’t think that 
was the plan.  Assuming EC algs aren’t incorporated in 6485bis then 
draft-ietf-sidr-bgpsec-algs needs to update RFC 6485 or any document that 
obsoletes it.  I’m happy to change the updates header info to “Updates: 
draft-ietf-sidr-rfc6485bis (once approved) though if that makes things crystal 
clear.

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

Re: [sidr] New version draft-ietf-sidr-bgpsec-protocol

[Sean Turner]

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 bgpsec-protocol, this would be a 
 great time to speak up.
 
  (That is, it is not too late to pull the solution from as-migration directly 
 into bgpsec-protocol, but if we are going to go down that road, we should do 
 it as soon as possible!)
 
 
 On Mon, Jul 7, 2014 at 1:03 PM, Matthew Lepinski mlepinski.i...@gmail.com 
 wrote:
 Wes,
 
 I agree that inserting a reference in bgpsec-protocol (and bgpsec-overview) 
 and then publishing as-migration as part of the bgpsec document set (along 
 with the router certificate profile, the algorithm document, etc) is a good 
 way forward. 
 
 I need to do a careful review of the latest version of as-migration (I really 
 haven't looked at the -01). I will get to that before we meet in Toronto. 
 
 Also, I am open to suggestions with regards to where to insert a reference to 
 as-migration -- but I will try to suggestion for how to link the two 
 documents in time for Toronto.
 
 - Matt Lepinski
 
 
 On Mon, Jul 7, 2014 at 12:40 PM, George, Wes wesley.geo...@twcable.com 
 wrote:
 
 From: Matthew Lepinski mlepinski.i...@gmail.com
 Date: Friday, July 4, 2014 at 6:16 PM
 To: sidr@ietf.org sidr@ietf.org
 Subject: [sidr] New version draft-ietf-sidr-bgpsec-protocol
 
 I submitted a new version of the bgpsec protocol document. This revision 
 includes a fair number of editorial changes but does not include any 
 normative changes.
 
 Now that the BGPSEC requirements document is essentially done, I look forward 
 to discussing the protocol document again in Toronto. In particular, between 
 now and the Toronto meeting I will write up (and send to the list) a brief 
 comparison between the requirements in the final version of the reqs draft 
 and what we deliver in the protocol document. 
 
 The only open issue in the protocol document that I am aware of is the 
 following:
 
 [snip]
 
 Matt - 
 
 One additional change I think is necessary is to add a reference to 
 ietf-sidr-as-migration. This is effectively an extension of the BGPSec 
 protocol that is contained in a separate document. If the BGPSec doc was 
 already done, I'd most likely be using the metadata of as-migration to update 
 RFC so that the link would exist from the BGPSec protocol doc in addition 
 to the normative reference to -protocol from as–migration, but in the current 
 form where it's trivial to update the -protocol draft, I think that should 
 instead be accomplished by a forward reference, and then the two documents 
 will simply be part of the group of interdependent docs that get released for 
 BGPSec (assuming of course that -as–migration passes LC).
 
 That said, my quick scan of –protocol didn't reveal an obvious place to 
 insert that reference, so if you or others have ideas of where it should go, 
 I'm happy to contribute a few lines of wrapper text. 
 
 Thanks,
  
 Wes
 
 Anything below this line has been added by my company’s mail server, I have 
 no control over it.
 ---
 
 
 This E-mail and any of its attachments may contain Time Warner Cable 
 proprietary information, which is privileged, confidential, or subject to 
 copyright belonging to Time Warner Cable. This E-mail is intended solely for 
 the use of the individual or entity to which it is addressed. If you are not 
 the intended recipient of this E-mail, you are hereby notified that any 
 dissemination, distribution, copying, or action taken in relation to the 
 contents of and attachments to this E-mail is strictly prohibited and may be 
 unlawful. If you have received this E-mail in error, please notify the sender 
 immediately and permanently delete the original and any copy of this E-mail 
 and any printout.
 
 
 ___
 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] EST (was Re: about the thread Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487)

[Sean Turner]

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 PKCS#10. Since it was authored by a Cisco
 guy, there is some chance it might become available in their
 routers. I would suggest this path only for router certs, not for
 the RPKI certs. That might make it unpalatable, as a CA operated by
 an ISP would have to deal with two cert request formats: PKCS#1- for
 child CA certs (if the ISP is not a stub in the RPKI tree) and EST
 for router certs.
 Is there any real benefit to EST, given that we already have to
 support PKCS #10 and given that PKCS #10 implementations are almost
 certainly easier to find than EST implementations?
 As I noted, I am aware of only a Cisco implementation, but we could check with
 Max Pritikin to see if he is aware of others.
 Absent some serious advantage that I'm not seeing, this doesn't seem
 particularly attractive.
 
 I'm just pointing out options.
 Understood.
 

Dan’s got an implementation on github:

https://github.com/danharkins/est

spt

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

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-07.txt

[Sean Turner]

A minor update to move some references that were in the wrong place as well as 
to correctly identify where the OID goes that indicates the algorithm used in 
the CRMF (thanks Sandy for pointing these out).  Oh and I updated the dates.

spt

On Jul 02, 2014, at 11:34, 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   : BGP Algorithms, Key Formats,  Signature Formats
Author  : Sean Turner
   Filename: draft-ietf-sidr-bgpsec-algs-07.txt
   Pages   : 7
   Date: 2014-07-02
 
 Abstract:
   This document specifies the algorithms, algorithms' parameters,
   asymmetric key formats, asymmetric key size and signature format used
   in BGPSEC (Border Gateway Protocol Security).  This document updates
   the Profile for Algorithms and Key Sizes for use in the Resource
   Public Key Infrastructure (RFC 6485).
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-07
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-07
 
 
 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] I-D Action: draft-ietf-sidr-bgpsec-algs-07.txt

[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 that indicates the algorithm used 
 in the CRMF (thanks Sandy for pointing these out).  Oh and I updated the 
 dates.
 
 spt
 
 On Jul 02, 2014, at 11:34, 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   : BGP Algorithms, Key Formats,  Signature Formats
   Author  : Sean Turner
  Filename: draft-ietf-sidr-bgpsec-algs-07.txt
  Pages   : 7
  Date: 2014-07-02
 
 Abstract:
  This document specifies the algorithms, algorithms' parameters,
  asymmetric key formats, asymmetric key size and signature format used
  in BGPSEC (Border Gateway Protocol Security).  This document updates
  the Profile for Algorithms and Key Sizes for use in the Resource
  Public Key Infrastructure (RFC 6485).
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-07
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-07
 
 
 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] I-D Action: draft-ietf-sidr-rtr-keying-07.txt

[Sean Turner]

Addresses some editorial issues I got off-list.

spt

On May 23, 2014, at 17:48, 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   : 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:
   BGPsec-speaking routers are provisioned with private keys to sign BGP
   messages; the corresponding public keys are published in the global
   RPKI (Resource Public Key Infrastructure) thereby enabling
   verification of BGPsec messages.  This document describes two ways of
   provisioning the public-private key-pairs: router-driven and
   operator-driven.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-07
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-07
 
 
 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] I-D Action: draft-ietf-sidr-rtr-keying-05.txt

[Sean Turner]

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 the protocol docs (doesn’t look like it in my quick
 skim), and most likely force an entirely ungraceful set of updates as the
 neighbors re-send their announcements with AS_PATH instead of BGPSEC_PATH.
 
 likely significantly shorter than whatever time it takes to revoke, get
 new cert, install, and then go through the bgp reset.  though you will
 eventually do that anyway.
 
 randy

I’m going to throw in a new version and ask for WGLC.

spt

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

Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-06.txt

[Sean Turner]

SIDR Chairs,

This version address all known outstanding comments.  At this point, I’d like 
to request a WGLC but realize that this draft probably needs to progress with 
the other BGPsec drafts.

spt

On May 20, 2014, at 10:05, 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   : Router Keying for BGPsec
Authors : Sean Turner
  Keyur Patel
  Randy Bush
   Filename: draft-ietf-sidr-rtr-keying-06.txt
   Pages   : 11
   Date: 2014-05-20
 
 Abstract:
   BGPsec-speaking routers are provisioned with private keys to sign BGP
   messages; the corresponding public keys are published in the global
   RPKI (Resource Public Key Infrastructure) thereby enabling
   verification of BGPsec messages.  This document describes two ways of
   provisioning the public-private key-pairs: router-driven and
   operator-driven.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-06
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-06
 
 
 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

Re: [sidr] Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487

[Sean Turner]

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 that the RPKI attests only to things
 like addresses and autonomous system numbers.
 
 As I recall the discussion at the time was based around a desire to
 avoid any implication that the CA was attesting as to the identity of the
 subject. i.e. the CA was explicitly not saying that the holder of the public
 key was the individual described int subject field (section 4.5 of RFC6487).
 
 There was also some convenience in using a subject name that was linked
 to the subject's public key, in so far as when the subject rolled keys
 then the subject would request a new certificate and the issuer would
 use a different subject name (section 4.5 once more).
 
 Geoff

Ah this last part I had glossed over.  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 might be an issue if 
the # grows, but is that the only drawback?

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

Re: [sidr] Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487

[Sean Turner]

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 might be an issue if the # grows,
 but is that the only drawback?
 
 if you have to go down that path, and i am unsure of it, then use a
 fixed length router# and wrap.

I could live with that make it like 000 an wrap 999.  If you have to rekey that 
often ….

 and keep in mind that bgp_id is unique only within an AS.

yep that’s true.

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

Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-05.txt

[Sean Turner]

Wes,

Randy and I bashed some text around; would this work:

When it is decided that an active router key is to be revoked, the
process of requesting the CA to revoke, the process of the CA
actually revoking the router’s certificate, and then the process of
rekeying/renewing the router’s certificate, (possibly distributing a
new key and certificate to the router), and distributing the status
takes time during which the operator must decide how they wish
to maintain continuity of operations, with or without the compromised
private key, or whether they wish to to bring the router offline to
address the compromise.  

Keeping the router operational and BGPsec-speaking is the ideal goal,
but if operational practices do not allow this then reconfiguring the
router to disabling BGPsec is likely preferred to bringing the router
offline.

Routers which support more than one private key, where one is
operational and the other(s) are soon-to-be-opertional, facilitate
revocation events because the operator can configure the router to make
a soon-to-be-operational key operational, request revocation of the
compromised key, and then make a new soon-to-be-operational key, all
hopefully without needing to take offline or reboot the router.  For
routers which support only one operational key, the operators should
create or install the new private key, and then request revocation of
the compromised private key.

spt

On Apr 30, 2014, at 16:26, George, Wes wesley.geo...@twcable.com wrote:

 This update address my comments on the document, and I think it’s in good
 shape now. The new section 4 is really good. The one thing I might
 recommend adding for completeness is a few additional words around
 revocation process at the end of section 4, specifically if there is any
 difference or recommendation in process for make before break (provision
 new key, then revoke old) or when that may not be a good idea compared
 with the risk of outage caused by revoking and then rekeying. It may be as
 simple as saying something similar to the above about whether a router
 supports multiple 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 your cert doesn’t expire).  There’s also
 some editorial/readability corrections.  Please review as the authors
 think this version pretty much wraps up what we wanted to say.
 
 spt
 
 On Apr 29, 2014, at 10:10, 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   : Router Keying for BGPsec
   Authors : 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 BGP
  messages; the corresponding public keys are published in the global
  RPKI (Resource Public Key Infrastructure) thereby enabling
  verification of BGPsec messages.  This document describes two ways of
  provisioning the public-private key-pairs: router-driven and
  operator-driven.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-05
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-05
 
 
 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
 
 
 This E-mail and any of its attachments may contain Time Warner Cable 
 proprietary information, which is privileged, confidential, or subject to 
 copyright belonging to Time Warner Cable. This E-mail is intended solely for 
 the use of the individual or entity to which it is addressed. If you are not 
 the intended recipient of this E-mail, you are hereby notified that any 
 dissemination, distribution, copying, or action taken in relation to the 
 contents of and attachments to this E-mail is strictly prohibited and may be 
 unlawful

Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-05.txt

[Sean Turner]

Hi,

This version includes a new section 4 that addresses key management (i.e., keep 
a timer to make sure your cert doesn’t expire).  There’s also some 
editorial/readability corrections.  Please review as the authors think this 
version pretty much wraps up what we wanted to say.

spt

On Apr 29, 2014, at 10:10, 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   : Router Keying for BGPsec
Authors : 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 BGP
   messages; the corresponding public keys are published in the global
   RPKI (Resource Public Key Infrastructure) thereby enabling
   verification of BGPsec messages.  This document describes two ways of
   provisioning the public-private key-pairs: router-driven and
   operator-driven.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-05
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-05
 
 
 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

Re: [sidr] Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487

[Sean Turner]

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.
 
 The problem is with router-ids and the subject field in the PKCS #10
 request.
 
 - draft-ietf-sidr-bgpsec-pki-profiles-06 3.1.1.1 (talking about
   certificates, not certificate requests) says router certificate
   names SHOULD be /commonName=ROUTER-/serialNumber=,
   where  is the ASN and  is the router-id, as 32-bits
   hex in both cases.  OK, fine.
 
   As far as I can tell, this is the only way in which the router-id is
   encoded anywhere in the certificate.
 yep.
 - draft-ietf-sidr-bgpsec-pki-profiles-06 3.2 says that the certificate
   request profile matches RFC 6487 with a few specific differences,
   none of which have anything to do with subject names.
 yep.
 - draft-ietf-sidr-rtr-keying-04 3.1 says that when a router is
   generating keys, it includes the router-id in the PKCS #10.
 this seems to be the place where there is an error, given you observation re 
 6487, 6.1.1.
   Given that the only place we have to encode the router-id is in the
   subject name (as opposed to, say, a newly-defined X.509v3
   extension), this text would seem to imply that the PKCS #10 includes
   a non-empty Subject field.
 - RFC 6487 6.1.1 says that the Subject field of the PKCS #10 MUST be
   absent or empty except when requesting reissuance of an existing key
   and even then only if the CA's CPS allows reusing subject names.
 
 I see no way to reconcile all of this without changing something.
 a router cert is issued by an ISP to one if its routers. it's not clear to
 me that a PKCS #10 request is strictly required for this, as it is a local 
 process
 within an AS. But, if one does use PKCS #10 then a CA operating within an
 AS context can probably determine the ID of the router making the request.
 I suggest this mismatch ought to be addressed in the rtr keying I-D.

Finally getting back around to this.

Two points I think need to be made:

1. Can you omit the subject name from a PKCS#10?

I don’t think so. The syntax for PKCS#10 is [1]:

CertificationRequestInfo ::= SEQUENCE {
version   INTEGER { v1(0) } (v1,...),
subject   Name,
subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
attributes[0] Attributes{{ CRIAttributes }}
   }

Note there’s no “OPTIONAL” after Name.  It could be pretty easily argued that 
completely omitting the field would result in a non-interoperable certificate 
request; that is a certificate request that CAs might choke on because at a 
minimum they’re expecting a NULL subject name.  Based on this I think the text 
in RFC 6487 might need to be tweaked based on not being able to omit subject 
from PKCS#10:

OLD:

  Subject
  This field MAY be omitted.  If present, the value of this field
  SHOULD be empty (i.e., NULL), in which case the CA MUST
  generate a subject name that is unique in the context of
  certificates issued by this CA.

NEW:

  Subject
  This field is mandatory and MUST be included; however,
  the value of this field
  SHOULD be empty (i.e., NULL), in which case the CA MUST
  generate a subject name that is unique in the context of
  certificates issued by this CA.

2. Is rtr-keying correct in stating the following in s3.1 because the text 
there is about initial provisioning not rekey/renewal and it contradicts the 
2nd sentence about subject in RFC 6847?

s3.1 rtr-keying:

   … to generate the PKCS#10 request that includes the router number and
   public key ...

s6.1 RFC 6487:

 This field is allowed to be
 non-empty only for a re-key/reissuance request, and only if the
 CA has adopted a policy (in its Certificate Practice Statement
 (CPS)) that permits reuse of names in these circumstances.

I’m wondering how the router is going to know what value to use.  I suspect its 
only going to know what value to use after it has been told the value :)  Not 
including a router # in the request is probably okay if the request comes 
through the CLI session the operator is using to talk to the router because it 
can capture the request and tag it in someway to know what name ought to go 
in the subject field of the issued certificate.  But, say the CLI session isn’t 
used and the router uses its network connectivity to communicate with the CA.  
If there’s no name in the request, how will the CA know what name to include in 
the issued certificate?  Seems to me like for that scenario, we’d actually want 
the subject name present in the PKCS#10.  Thoughts?

spt

[1] http://datatracker.ietf.org/doc/rfc2986/
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] BGPSEC Algorithms document missing a clear reference?

[Sean Turner]

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 conversation) that in:
   draft-ietf-sidr-bgpsec-algs-05 (at least 05)
 
 there's this text in section 2:
 
 NOTE: The exception to the above hashing algorithm is the use of
 
SHA-1 [SHS] when CAs generate authority and subject key
identifiers [ID.bgpsec-pki-profiles].
 
 The reference to bgpsec-pki-profiles, is PROBABLY really:
draft-sidr-bgpsec-pki-profiles
http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol
 
 not sure why the angle bracket reference to the bgpsec protocol appears
 above,
 
 angle brackets because of old-skool email-client/URL interpolation habits :(
 wrong reference because ... #fail. The right one:
  http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles
 
 apologies for the confusion.
 
 after the intended reference. But, as you note below,
 draft-sidr-bgpsec-pki-profiles
 does not refer to SKI's.It says that it inherits all of the RPKI cert
 profile
 (RFC 6487) except as noted in Section 3 of the I-D. RFC 6487 mandates
 inclusion
 of the SKI and AKI extensions, and specifies use of SHA-1 to compute SKI and
 AKI values.
 So, the text above should be changed to refer RFC 6487. (There is no need to
 go back to
 5280, since 6487 cites it and narrows the SKI/AKI generation options from
 that RFC.)
 
 awesome! the OP was correct in pointing out the missing linkages, sweet :)
 
 ___
 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 mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] comments: draft-ietf-sidr-rfc6485bis-00.txt

[Sean Turner]

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, This is a slight technical change to RFC6485, and the
   advice to the WG from a Routing AD was that this is outside the
   limited scope of an erratum.

and the final ].

In recent history, the IESG liked to have a section in update drafts that 
remains after publication listing the changes.

spt

On Mar 07, 2014, at 15: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 Working Group of 
 the IETF.
 
Title   : The Profile for Algorithms and Key Sizes for use in 
 the Resource Public Key Infrastructure
Authors : Geoff Huston
  George Michaelson
   Filename: draft-ietf-sidr-rfc6485bis-00.txt
   Pages   : 7
   Date: 2014-03-07
 
 Abstract:
   This document specifies the algorithms, algorithms' parameters,
   asymmetric key formats, asymmetric key size and signature format for
   the Resource Public Key Infrastructure subscribers that generate
   digital signatures on certificates, Certificate Revocation Lists, and
   signed objects as well as for the Relying Parties (RPs) that verify
   these digital signatures.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-sidr-rfc6485bis-00
 
 
 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

Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-02.txt

[Sean Turner]

Better late than never?

I believe this version addresses Wes' comments (if he can remember them :)

spt

On 9/12/13 7:08 PM, 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   : Router Keying for BGPsec
Author(s)   : Sean Turner
   Keyur Patel
   Randy Bush
Filename: draft-ietf-sidr-rtr-keying-02.txt
Pages   : 9
Date: 2013-09-12

Abstract:
BGPsec-speaking routers must be provisioned with private keys and the
corresponding public key must be published in the global RPKI
(Resource Public Key Infrastructure).  This document describes two
ways of provisioning public/private keys, router-driven and operator-
driven.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-02


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] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-05.txt

[Sean Turner]

This is just a keep alive version.  Date changes only.

spt

On 4/17/13 9:31 PM, 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
Author(s)   : Mark Reynolds
   Sean Turner
   Steve Kent
Filename: draft-ietf-sidr-bgpsec-pki-profiles-05.txt
Pages   : 11
Date: 2013-04-17

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-05

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


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] I-D Action: draft-ietf-sidr-bgpsec-algs-04.txt

[Sean Turner]

This is a keep-alive version.  I changed the issue and expiry dates and 
the draft number.


spt

On 3/26/13 4:47 PM, 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   : 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 specifies the algorithms, algorithms' parameters,
asymmetric key formats, asymmetric key size and signature format used
in BGPSEC (Border Gateway Protocol Security).  This document updates
the Profile for Algorithms and Key Sizes for use in the Resource
Public Key Infrastructure (RFC 6485).


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

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

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


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] draft-newton-sidr-policy-qualifiers-01

[Sean Turner]

+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 take a lot of working group cycles to process this
document. I would, therefore, support adoption of this document by the
working group.


Thank you Matt. And since you beat me to getting a message to the list
regarding the adoption of this draft, I would like to ask the working
group to adopt this draft as a work item.

-andy

___
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 mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-01.txt

[Sean Turner]

 protocols such as FTP and HTTP.

And the answer might be maybe.  In the router-generated case, what's 
being returned in the public key certificate, which is well going to be 
made public so it's not necessary to secure it.  Then, again if there's 
a protected channel open continuing to use it is okay.  Not sure how to 
explain that but I can give it a shot.



Direct/indirect makes sense, but the process for indirect transfer is a little 
light on details - what steps must be taken to ensure that the keys are not 
compromised in this transfer, either from the router or to the RPKI CA? Even a 
reference to section 5 might be enough to cover this.


Ah for this section, the only key transferred is public and it's in the 
PKCS#10, which is the only thing that gets transferred.  But, you asking 
this question makes me think I should make it clearer about what's being 
transfer and why anybody'd care.



Also, I don't follow your last sentence ...linkage between private key and a 
router... - why is that important?


The idea is that you want to be able to know the router's got the 
private key associated with the public key.  Another way to say this is 
POP - and I agree this could be made clearer.  Something like:


 Note that even if the operator can not get the private key off the
 router this still provides a linkage between a private key and a
 router.  That is the server can do a proof of possession (POP),
  as required by [RFC6484].


3.2 installed over the ssh session... - are we talking simple copy and paste 
of a huge string of text representing the key, or is it actually SCP/SFTP of a file that 
is then read into the router's config via additional commands?
If you're talking copy/paste, it's probably worth warning that for keys over a 
certain size, this method is error-prone. I've seen a lot of mangled config 
because someone exceeded a paste buffer when trying to copy/paste a config, 
especially over a 9600 bps console at the other end of 90ms of latency.


An excellent point, but I'm sure hope it's commands and not ctrl-c/v.


5. when you talk about offload methods, you should probably specify the 
required/recommended security precautions associated with handling the key so 
that it isn't intercepted across the transfer method used (e.g. use SNMPv3 with 
encryption, use sFTP/SCP, CLI with SSH, etc, as well as any considerations 
around chain of possession and level of trust as the keys are stored and 
transferred between old and new box. There are a lot of risk factors if a tech 
is transferring it to his (possibly compromised) laptop when compared with 
transferring to parts of the infrastructure (a config repository server, for 
example) that are properly hardened.
Also need to discuss sneakernet transfer, where I dump the key to a local 
storage device so that the tech can plug it into the new RP/RE and upload it 
that way. This is sometimes important if the box is having issues and as a 
result has limited connectivity to offload the keys. Any considerations to 
ensure proper security in a transfer like that?


All good points and that means I need to get out a new version ;)


Thanks,

Wes George




-Original Message-
From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
internet-dra...@ietf.org
Sent: Saturday, February 23, 2013 10:41 AM
To: i-d-annou...@ietf.org
Cc: sidr@ietf.org
Subject: [sidr] I-D 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 Turner
   Keyur Patel
   Randy Bush
   Filename: draft-ietf-sidr-rtr-keying-01.txt
   Pages   : 9
   Date: 2013-02-23

Abstract:
BGPsec-speaking routers must be provisioned with private keys and the
corresponding public key must be published in the global RPKI
(Resource Public Key Infrastructure).  This document describes two
ways of provisioning public/private keys, router-driven and operator-
driven.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-01


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


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use