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