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

Stephen Kent <> Fri, 11 March 2011 00:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF8B93A6ADF; Thu, 10 Mar 2011 16:23:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1s9TeRjlMyur; Thu, 10 Mar 2011 16:23:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0253E3A69B6; Thu, 10 Mar 2011 16:23:49 -0800 (PST)
Received: from ([]:35762 helo=[]) by with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <>) id 1PxqAE-000G8F-6F; Thu, 10 Mar 2011 19:25:07 -0500
Mime-Version: 1.0
Message-Id: <p06240804c99f16612cae@[]>
In-Reply-To: <>
References: <>
Date: Thu, 10 Mar 2011 19:21:22 -0500
To: Sam Hartman <>
From: Stephen Kent <>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Mar 2011 00:23:50 -0000


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.