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._______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
