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

From: Stephen Kent <[email-masked]>
Date: Fri, 15 Apr 2011 14:45:46 -0400

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.

---

From: John C Klensin <[email-masked]>
Date: Sun, 17 Apr 2011 09:27:32 -0400

Steve,
Two things:

(1) Given the variable amount of time it takes to get RFCs
issued/ published after IESG signoff, are you and the WG sure
that you want to tie the phases of the phase-in procedure to RFC
publication?

(2) There is an incomplete sentence at the end of (2): "This
allows CAs to issue certificates under" (more context below).

   john

--On Friday, April 15, 2011 14:45 -0400 Stephen Kent
<[email-masked]> wrote:

> 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
> 
> capable of processing certificates under the new format.
>...

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Apr 2011 12:02:40 -0400

Steve, thanks for your note.
I realize the certificate resource profile document has been approved,
but I'd still like to understand what is happening here.

I'm having trouble reconciling the new text  you've added to the
document with draft-ietf-sidr-signed-object.

        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

However, when I look at section 2.1.4 in the signed-object document ,
the signer can only include one certificate.
How does that work during phase 2 when some of the RPs support the new
format and some only support the old format?
Your text above suggests that RPs grab the certificates from the RPKI
repository, but it seems at least for end entity certificates they are
included in the signed object.
What happens for end entity certificates during this form of upgrade?