At 6:07 PM -0400 5/3/11, Sam Hartman wrote:
Stephen == Stephen Kent k...@bbn.com writes:
I guess the only question I'd have remaining is whether ROAs or
other signed objects are intended to be used in other protocols
besides simply living in the SIDR repository?
Stephen == Stephen Kent k...@bbn.com writes:
Stephen The BGPSEC protocol being defined does not pass around ROAs
Stephen or other RPKI repository objects. It defines two new,
Stephen signed objects that are passed in UPDATE messages, and are
Stephen not stored in the repository.
At 7:48 AM -0400 5/4/11, Sam Hartman wrote:
Stephen == Stephen Kent k...@bbn.com writes:
Stephen The BGPSEC protocol being defined does not pass around ROAs
Stephen or other RPKI repository objects. It defines two new,
Stephen signed objects that are passed in UPDATE messages, and
Stephen == Stephen Kent k...@bbn.com writes:
Stephen At 7:48 AM -0400 5/4/11, Sam Hartman wrote:
Stephen == Stephen Kent k...@bbn.com writes:
Stephen The BGPSEC protocol being defined does not pass around ROAs
Stephen or other RPKI repository objects. It defines two new,
At 10:32 AM -0400 5/4/11, Sam Hartman wrote:
...
Let me see if I can summarize where we are:
You've describe an upgrade strategey for the origin validation in the
current set of docs. It depends on the ability to store multiple certs,
ROAs and other objects in the repository.
requirements
Steve, I'd like to thank you for working through these issues with me.
I think the new texxt you added before approval is very helpful. You
indicated you could add an additional sentence pointing out that
multiple signed objects would need to be used in order to deal with
phase 2 for end-entity
At 12:02 PM -0400 4/25/11, Sam Hartman wrote:
...
However, when I look at section 2.1.4 in the signed-object document ,
the signer can only include one certificate.
How does that work during phase 2 when some of the RPs support the new
format and some only support the old format?
Your text
At 9:27 AM -0400 4/17/11, John C Klensin wrote:
Steve,
Two things:
(1) Given the variable amount of time it takes to get RFCs
issued/ published after IESG signoff, are you and the WG sure
that you want to tie the phases of the phase-in procedure to RFC
publication?
It probably would help if
Let me make sure I'm understanding what you're saying. I can have
multiple ROAs for the same set of prefixes in the repository and valid
at the same time: one signed by a new certificate and one signed by a
previous certificate? If so, I think I now begin to understand why the
SIDR working
At 11:05 AM -0400 5/3/11, Sam Hartman wrote:
Let me make sure I'm understanding what you're saying. I can have
multiple ROAs for the same set of prefixes in the repository and valid
at the same time: one signed by a new certificate and one signed by a
previous certificate? If so, I think I now
Stephen == Stephen Kent k...@bbn.com writes:
I guess the only question I'd have remaining is whether ROAs or
other signed objects are intended to be used in other protocols
besides simply living in the SIDR repository?
Stephen The RPKI repository is designed to support
Steve, thanks for your note.
I realize the certificate resource profile document has been approved,
but I'd still like to understand what is happening here.
I'm having trouble reconciling the new text you've added to the
document with draft-ietf-sidr-signed-object.
2- During phase 2
Steve,
Two things:
(1) Given the variable amount of time it takes to get RFCs
issued/ published after IESG signoff, are you and the WG sure
that you want to tie the phases of the phase-in procedure to RFC
publication?
(2) There is an incomplete sentence at the end of (2): This
allows CAs to
Sam,
In response to your comments on the res-certs draft, re the
restrictive nature of the relying party checks in certs, we have
prepare the following text that will be included as a new section in
the document.
Steve
-
Operational Considerations
This profile requires that relying
Jeff
Steve noted a desire to limit the liability of entities acting as CAs in
the RPKI. I agree that goal is desirable, and restrictions on what
certificates issued by those CAs can contain help to do that (provided
the CAs actually comply). However, requiring compliant RPs to treat all
On Thu, 2011-03-10 at 11:31 -0800, Paul Hoffman wrote:
for changes that need to change the system's semantics, you
change the certificates in a way that relying parties that don't
understand the change won't accept the certificate.
Sure. The way to do that is to issue a certificate with a
16 matches
Mail list logo
