Hi Sandy,

On Oct 23, 2012, at 5:36 PM, Murphy, Sandra wrote:

On nday, October 22, 2012 9:29 AM, Roque said



> Significant work on this document should be dependent on the advance of the 
> key provisioning
>specifications (there is still not WG document yet on this point) and some 
>initial experience.

There is the draft 
draft-ietf-sidr-rtr-keying<http://tools.ietf.org/wg/sidr/draft-ietf-sidr-rtr-keying/>
 which says it is about provisioning routers with the private keys they need.  
Do you mean something other than that?


That draft mentions formats for the keys/certificates in two scenarios but not 
which enrollment protocol would be use. One option mentioned in our draft is to 
adopt EST (http://tools.ietf.org/html/draft-ietf-pkix-est-03) as an option that 
already has running code. Another activity that the key rollover draft depends 
on is the RTR protocol extensions.

Regards,
Roque


--Sandy, speaking as regular ol' wg member

________________________________
From: sidr-boun...@ietf.org<mailto:sidr-boun...@ietf.org> 
[sidr-boun...@ietf.org] on behalf of Roque Gagliano (rogaglia) 
[rogag...@cisco.com]
Sent: Monday, October 22, 2012 9:29 AM
To: sidr@ietf.org<mailto:sidr@ietf.org>
Subject: [sidr] Fwd: New Version Notification for 
draft-ietf-sidr-bgpsec-rollover-01.txt

Dear WG,

We created a new version of the BGPSEC key roll-over draft that basically 
incorporate all corrections/comments from Steve (on: 
http://www.ietf.org/mail-archive/web/sidr/current/msg04770.html) and comments 
from Sriram here: 
http://www.ietf.org/mail-archive/web/sidr/current/msg05170.html and considering 
his views 
here:http://www.ietf.org/mail-archive/web/sidr/current/msg04863.html). Thank 
you both for the detail reviews.

There are two "admin" changes that I want to do on a future version:
- change the title:"BGPSEC router key rollover as an alternative to beaconing" 
had the initial intend to propose an alternative to "beaconing" but the current 
stage of the draft a title change is needed. An option could be:"BGPSEC 
certificate key rollover and its effects to replay attacks protection"
  - change document type to BCP. Just like RFC 6489

We do think the changes are significant enough at this time to request a slot 
in Atlanta as they basically addressed editorial pieces.

We believe that the draft at its current stage gives a generic overview on the 
rollover process and its use to limit the windows of exposure to replay 
attacks. Significant work on this document should be dependent on the advance 
of the key provisioning specifications (there is still not WG document yet on 
this point) and some initial experience.

Regards,
Roque


Begin forwarded message:

From: <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>>
Date: October 22, 2012 3:04:39 PM GMT+02:00
To: <rogag...@cisco.com<mailto:rogag...@cisco.com>>
Cc: <keyup...@cisco.com<mailto:keyup...@cisco.com>>, 
<b...@cisco.com<mailto:b...@cisco.com>>
Subject: New Version Notification for draft-ietf-sidr-bgpsec-rollover-01.txt


A new version of I-D, draft-ietf-sidr-bgpsec-rollover-01.txt
has been successfully submitted by Roque Gagliano and posted to the
IETF repository.

Filename: draft-ietf-sidr-bgpsec-rollover
Revision: 01
Title: BGPSEC router key rollover as an alternative to beaconing
Creation date: 2012-10-22
WG ID: sidr
Number of pages: 14
URL:             
http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-rollover-01.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-rollover
Htmlized:        http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-01
Diff:            
http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-rollover-01

Abstract:
  BGPSEC will need to address the impact from regular and emergency
  rollover processes for the BGPSEC End-Entity (EE) certificates that
  will be performed by Certificate Authorities (CAs) participating at
  the Resource Public Key Infrastructure (RPKI).  This document
  provides general recommendations for that process and specifies how
  this process is used to control BGPSEC's window of exposure to replay
  attacks.




The IETF Secretariat




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

Reply via email to