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

Stephen Kent <kent@bbn.com> Fri, 15 April 2011 18:45 UTC

Return-Path: <kent@bbn.com>
X-Original-To: secdir@ietfc.amsl.com
Delivered-To: secdir@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C082AE06B0; Fri, 15 Apr 2011 11:45:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.686
X-Spam-Level:
X-Spam-Status: No, score=-102.686 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytiYINcEoz9A; Fri, 15 Apr 2011 11:45:52 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfc.amsl.com (Postfix) with ESMTP id 07E8EE065F; Fri, 15 Apr 2011 11:45:51 -0700 (PDT)
Received: from dhcp89-089-062.bbn.com ([128.89.89.62]:49209) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1QAo1f-00068K-2f; Fri, 15 Apr 2011 14:45:51 -0400
Mime-Version: 1.0
Message-Id: <p06240801c9ce424e70b1@[128.89.89.62]>
In-Reply-To: <tslzkp2elyf.fsf@mit.edu>
References: <tslhbbag9m1.fsf@mit.edu> <4D791B26.8020001@vpnc.org> <tsl4o7ag5fw.fsf@mit.edu> <4D79271E.6080707@vpnc.org> <tslzkp2elyf.fsf@mit.edu>
Date: Fri, 15 Apr 2011 14:45:46 -0400
To: Sam Hartman <hartmans-ietf@mit.edu>
From: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="============_-909229346==_ma============"
Cc: draft-ietf-sidr-res-certs@tools.ietf.org, ietf@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 18:45:53 -0000

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 parties reject certificates or 
CRLs that do not conform to the profile. (Through the remainder of 
this section the term "certificate" is used to refer to both 
certificates and CRLs.)
This includes certificates that contain extensions that are 
prohibited, but which are otherwise valid as per RFC 5280. This means 
that any change in the profile (e.g., extensions, permitted 
attributes or optional fields, or field encodings) for certificates 
used in the RPKI will not be backward compatible. In a general PKI 
context this constraint probably would cause serious problems. In the 
RPKI, several factors minimize the difficulty of effecting changes of 
this sort.

Note that the RPKI is unique in that every relying party (RP) 
requires access to every certificate and every CRL issued by the CAs 
in this system. An important update of the certificates and CRLs used 
in the RPKI must be supported by all CAs and RPs in the system, lest 
views of the RPKI data differ across RPs. Thus incremental changes 
require very careful coordination. It would not be appropriate to 
introduce a new extension, or authorize use of an extant, standard 
extension, for a security-relevant purpose on a piecemeal basis.

One might imagine that the "critical" flag in X.509 certificate and 
CRL extensions could be used to ameliorate this problem. However, 
this solution is not comprehensive, and does not address the problem 
of adding a new, security-critical extension. (This is because such 
an extension needs to be supported universally, by all CAs and RPs.) 
Also, while some standard extensions can be marked either critical or 
non-critical, at the discretion of the issuer, not all have this 
property, i.e., some standard extensions are always non-critical. 
Moreover, there is no notion of criticality for attributes within a 
name or optional fields within a field or an extension. Thus the 
critical flag is not a solution to this problem.

In typical PKI deployments there are few CAs and many RPs. However, 
in the RPKI, essentially every CA in the RPKI is also an RP. Thus the 
set of entities that will need to change in order to issue 
certificates under a new format is the same set of entities that will 
need to change to accept these new certificates. To the extent that 
this is literally true it says that CA/RP coordination for a change 
is tightly linked anyway. In reality there is an important exception 
to this general observation. Small ISPs and holders of 
provider-independent allocations are expected to use managed CA 
services, offered by RIRs/NIRs and by large ISPs. (All RIRs already 
offer managed CA services as part of their initial RPKI deployment.) 
This reduces the number of distinct CA implementations that are 
needed, and makes it easier to effect changes for certificate 
issuance. It seems very likely that these entities also will make use 
of RP software provided by their managed CA service provider, which 
reduces the number of distinct RP software implementations. Also note 
that many small ISPs (and holders of provider-independent 
allocations) employ default routes, and thus need not perform RP 
validation of RPKI data, eliminating these entities as RPs.

Widely available PKI RP software does not cache large numbers of 
certificates and CRLs, an essential strategy for the RPKI. It does 
not process manifest or ROA data structures, essential elements of 
the RPKI repository system. Experience shows that such software deals 
poorly with revocation status data. Thus extant RP software is not 
adequate for the RPKI, although some open source tools (e.g., OpenSSL 
and cryptlib) can be used as building blocks for an RPKI RP 
implementation. Thus it is anticipated that RPs will make use of 
software designed specifically for the RPKI environment, and 
available from a limited number of open sources. Several RIRs and two 
companies are providing such software today. Thus it is feasible to 
coordinate change to this software among the small number of 
developers/maintainers.

If the resource certificate format is changed in the future, e.g., by 
adding a new extension or changing the allowed set of name attributes 
or encoding of these attributes, the following procedure will be 
employed to effect deployment in the RPKI. The model is analogous to 
that described in [draft-ietf-sidr-algorithm-agility-00], but is 
simpler.

A new document will be issued as an update to this RFC.  The CP for 
the RPKI [ID-sidr-cp] will be updated to reference the new 
certificate profile. The new CP will define a new policy OID for 
certificates issued under the new certificate profile. The updated CP 
also will define a timeline for transition to the new certificate 
(CRL) format. This timeline will define 3 phases and associated dates:

	1- At the end of phase 1, all RPKI CAs MUST be capable of 
issuing certificates under the new profile, if requested by a 
subject. Any certificate issued under the new format will contain the 
new policy OID.

	2- During phase 2 CAs MUST issue certificates under the new 
profile, and these certificates MUST co-exist with certificates 
issued under the old format. (CAs will continue to issue certificates 
under the old OID/format as well.) The old and new certificates MUST 
be identical, except for the policy OID and any new extensions, 
encodings, etc. Relying parties MAY make use of the old or the new 
certificate formats when processing signed objects retrieved from the 
RPKI repository system. During this phase, a relying party that 
elects to process both formats will acquire the same values for all 
certificate fields that overlap between the old and new formats. Thus 
if either certificate format is verifiable, the relying party accepts 
the data from that certificate. This allows CAs to issue certificates 
under

	3- At the beginning of phase 3, all relying parties MUST be 
capable of processing certificates under the new format. During this 
phase CAs will issue new certificates ONLY under the new format. 
During this phase, certificates issued under the old OID will be 
replaced with certificates containing the new policy OID. The 
repository system will no longer require matching old and new 
certificates under the different formats.

At the end of phase 3, all certificates under the old OID will have 
been replaced. The resource certificate profile RFC will be replaced 
to remove support for the old certificate format, and the CP will be 
replaced to remove reference to the old policy OID and to the old 
resource certificate profile RFC. The system will have returned to a 
new, steady state.