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
At 5:58 AM +0100 3/11/11, Martin Rex wrote:
Stephen Kent wrote:
n to act as CAs , and we want to limit their liability.
One way to do this is to restrict the fields and extensions in
resource certs to make then not very useful for other applications.
A CA should never sign extensions that
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like
On 3/10/11 9:37 AM, Sam Hartman wrote:
The document also requires that relying parties reject certificates that
include unknown extensions. The rationale explained in section 8 is that
it is undesirable to have a situation where if an RP implemented more
extensions it would reject certificates
Paul == Paul Hoffman paul.hoff...@vpnc.org writes:
Paul On 3/10/11 9:37 AM, Sam Hartman wrote:
The document also requires that relying parties reject
certificates that include unknown extensions. The rationale
explained in section 8 is that it is undesirable to have a
On 3/10/11 11:07 AM, Sam Hartman wrote:
Paul == Paul Hoffmanpaul.hoff...@vpnc.org writes:
Paul On 3/10/11 9:37 AM, Sam Hartman wrote:
The document also requires that relying parties reject
certificates that include unknown extensions. The rationale
explained in
Speaking as someone who has implemented relying party tools for this,
I support the current restrictive choices in the profile, for a very
simple reason: I can't validate what I don't understand. The current
profile is written to restrict what's allowed today to things we
understand today. As
Paul == Paul Hoffman paul.hoff...@vpnc.org writes:
Paul I don't think either of us is missing something, we just
Paul disagree about what needs to happen if a fix that changes the
Paul semantics of the certs needs to be made to the system as a
Paul whole. For changes that don't
Sam,
The cert profile is intentionally very restrictive, as you noted. A
primary rationale is that we are asking folks who manage address (and
AS#) allocation to act as CAs , and we want to limit their liability.
One way to do this is to restrict the fields and extensions in
resource certs
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
Stephen Kent wrote:
n to act as CAs , and we want to limit their liability.
One way to do this is to restrict the fields and extensions in
resource certs to make then not very useful for other applications.
A CA should never sign extensions that it doesn't understand.
Why has the RP to be
25 matches
Mail list logo
