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