ietf
[Top] [All Lists]

Re: Secdir review of draft-ietf-sidr-res-certs

2011-03-10 18:25:26
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 to make then not very useful for other applications. we also wanted to make it as easy as possible for relying parties to process resource certs. X.509 has a lot of potentially complex "features" and RFC 5280 did not kill off as many as some of would have liked :-). So, profiling certs (and CRLs) for the RPKI makes sense. Allowing unknown, non-critical extensions would undermine this stragey. Much as I liked Jon Postel, and worked with him on the IAB for a decade, his oft cited dictum is bad design advice in the security arena.

I also note that we want to impose these constraints on both CAs and RPs, because we have lots of examples of CAs issuing "bad" certs, accidentally. se want to use RP strictness to help "motivate" CAs to do the right thing :-).

I must admit that I found it a bit amusing that you chose to illustrate the potential for a change that would motivate being less stringent by citing RFC 3779, which you noted didn't have the problem in question :-). (Also note that integers usually are not very much constrained in ASN.1 in general, so the observation you made there seems a bit odd to me.)

Nonetheless, I get your point. My response is that IF we discover a need to change the profile, we could do so, e.g., by changing the cert policy (since the policy is specified in the CP, which references this version of the cert profile. Any change of this sort would have to be phased in over a long time scale. I suggest you look at the algorithm agility I-D for RPKI to see the sort of planning envisioned for that sort of change.

I do agree that there is a typo in the doc, re the validity interval. Sean noted that after the doc was released, and we agreed that it can be fixed after last call.

Steve
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf