Re: [secdir] Secdir review of draft-ietf-sidr-res-certs

[Stephen Kent <[e-mail]>]

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