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.
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Jeffrey Hutzelman
- [secdir] Secdir review of draft-ietf-sidr-res-cer… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Paul Hoffman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Paul Hoffman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Rob Austein
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Martin Rex
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… John C Klensin
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Stephen Kent
- Re: [secdir] Secdir review of draft-ietf-sidr-res… Sam Hartman