[sidr] revising Section 7.2 of RFC 6487

[Stephen Kent <[e-mail]>]

I've been discussing details of text in the "validation revisited" I-D 
with Tim, now that he has become the primary editor.  I believe a 
description of a new validation  algorithm will be cleaner and easier to 
understand if we replace all of section 7.2 in 6487, rather than trying 
to change just step 6. Most of the text will remain the same, but I've 
tried to simplify the language where appropriate, to correct a technical 
error (in describing validity checking), and add text needed to describe 
the revised alg. I think it makes sense to fix the section while we're 
updating 6487.  Here is my proposed re-write for this section. I've 
marked the changed text as *bold*, and included *red* comments to 
explain the rationale for the suggested changes.

Steve

------

7.2 Resource Certification Path Validation

*The following algorithm is employed to validate CA and EE resources 
certificates. It is modeled on the path validation algorithm from 
[RFC5280], but modified to make use of the IP Address Delegation and AS 
**Identifier Delegation Extensions from [RFC3779]. (this is a shorter, 
simpler intro for the section)*

*There are two inputs to the validation algorithm:*

**

*1.**a trust anchor *

**

*2.****a certificate to be validated*

*(a description of inputs was present in 5280, in 6.1.1, but omitted in 
6487)*



*The algorithm is initialized with two new variables for use in the 
RPKI: Validated Resource Set-IP (VRS-IP) and Validated Resource Set-AS 
(VRS-AS). These sets are used to track the set of resources (IP address 
space and AS Numbers) that are considered valid for each CA certificate. 
The VRS-IP and VRS-AS sets are initially set to the IP Address 
Delegation and **AS Identifier Delegation values, respectively, from the 
trust anchor used to perform validation.*

*(this new text describes the sets needed to track what resources are 
present in all certs along a path. I suggest we use two sets, not one, 
because when we deal with ROAs and router certs they each have only only 
one of these 3779 extensions present.)*


This path validation algorithm verifies, among other things, that 
aprospective certification path (a sequence of n certificates)

satisfies the following conditions:

A.for all 'x' in {1, ..., n-1}, the subject of certificate 'x'

is the issuer of certificate ('x' + 1);

B.certificate '1' is issued by a trust anchor;

C.certificate 'n' is the certificate to be validated; and

D.for all 'x' in {1, ..., n}, certificate 'x' is valid.


*(I changed the enumeration for the bullets above to letters from 
numbers, because we use numbers to enumerate the steps below. 5280 also 
used letters vs. numbers when enumerating different aspects of path 
validation, in some parts of section 6, on which this is based.)*

Certificate validation requires verifying that all of the following

conditions hold, in addition to the certification path validation

criteria specified in Section 6 of [RFC5280].

1.***The signature of certificate x (x>1) is verified using the *

**

*public key of the issuer’s certificate (x-1), using the *

**

*signature algorithm specified for that public key (in *

**

***certificate x-1). **(this is a more precise specification of what
*

*    it means to verify the sig of cert x in the path)*

2.*The current time lies within the interval defined by the *

**

*NotBefore and NotAfter values in the Validity field of *

**

*certificate x. **(this wording matches the names of the fields in a 
cert, whereas the 6487 text uses terms that do not match cert field names.)*

3.*The Version, Issuer, and Subject fields of certificate x *

**

*satisfy the constraints established in Section 4.1-4.7 *

**

*of this specification. ***(this text precisely defines constraints that 
apply to cert fields, vs. extensions. the 6487 text referred  to fields 
in step 3, which does not encompass extensions!)**

4.*Certificate x contains all the extensions that MUST be *

**

*present, as defined in Section 4.8 of this specification. *

**

*The value(s) for each of these extensions MUST be satisfy*

**

*the constraints established for each extension in the*

**

*respective sections.**Any extension not identified in Section 4.8 MUST 
NOT****appear in certificate x. ***(this text describes the constraints 
imposed on extensions, vs. fields, paralleling #3 above)
**

******

5.***Certificate x MUST NOT have been revoked, i.e., it *

**

*MUST NOT appear on a CRL issued by the CA represented by certificate 
x-1 (this is a more concise wording of step 5 in 6487)*

6.*Compute the VRS-IP and VRS-AS set values as indicated below:*

**

**

**

*If the IP Address Delegation extension is present *

**

*in certificate x, compute the intersection of the resources between 
this extension and the current value of the VRS-IP. *

**

**

**

*If the IP Address Delegation extension is absent in certificate x, set 
the VRS-IP to NULL. *

**

**

**

*If the AS Identifier Delegation extension is present *

**

*in certificate x, compute the intersection of the resources between 
this extension and the current value of the VRS-AS *

**

**

**

*If the AS Identifier Delegation extension is absent *

**

*in certificate x, set the VRS-AS to NULL.*

**

**

**

*If x = n (i.e., this is the certificate being validated),*

**

*then:*

**

*1.**If IP Address Delegation extension is present, it is replaced with 
the intersection of the values from that extension and the current value 
of the VRS-IP. *

**

*2.**If an AS Identifier Delegation extension is present, it is replaced 
with the intersection of the values from that extension and the current 
value of the VRS-IP. *

**

*3.***

**

**

**

*If an RP is caching the results of validation, these values*

**

*MAY be stored along with the certificate, to facilitate*

**

*Incremental validation based on cached results.*

**

**

**

*Otherwise, return to step 1 and continue path validation.*

*(this is the description of the new rule for "relaxed" validation 
relative to 3779 extensions. it is more detailed than what Tim proposed, 
in part because I elected to treat IP address and ASNs as separate sets, 
consistent with the use of separate 3779 extensions. Tim has indicated 
that he would like to consider making this step apply only to CA certs, 
in hopes of not having to update the ROA RFC and the impending router 
cert RFC. This step can be modified to do that with a few tweaks.)*

*These rules allow a CA certificate to contain resources *

**

*that are not present in (all of) the certificates along *

**

*the path from the trust anchor to the CA certificate. *

**

*If none of the resources in the CA certificate are present *

**

*in all certificates along the path, no subordinate *

**

*certificates could be valid. However, the certificate is not 
immediately rejected as this may be a transient condition. *

**

*Not immediately rejecting the certificate does not result in a security 
problem because the associated VRS sets accurately reflect the resources 
validly associated with the *

**

*certificate in question.*

**

**

**

*The IP address and/or AS number resources contained in an *

**

*EE certificate being validated MUST always be **encompassed by all 
certificates along the path to the **trust anchor used to verify that 
certificate. The algorithm described above ensures this. *

**

**

*(the last two paragraphs provide an explanation for the revised 
validation alg, and asserts a critical requirement for EE certs) *