Tim,
...
I believe the draft is being precise, but in the process has become difficult
to parse. Let me attempt once more to explain the proposal in a different way:
"When doing top-down validation of resource certificates in the RPKI we propose
that rather than rejecting a certificate that has resources not held by the parent
(but is valid on all other respects), we would accept the certificate but keep note
of the actual resources we believe it can be authoritative for. I.e. the
intersection of resources on this certificate and the resources accepted for the
parent. The RP SHOULD however issue a warning in case certain resources are excluded
because of this, so that the responsible CA can fix the situation.
That's a reasonable goal, but it does not match what the revised
algorithm says.
Please note that for ROAs there is a requirement that all ROA prefixes are included
on the EE certificate of the (ROA) signed object CMS. This proposal does not change
this. A ROA that has prefixes that were removed for whatever reason higher in the
path would still become invalid using this algorithm. We would therefore RECOMMEND
that CAs issue 1 ROA for each prefix, and avoid fate sharing. That way only ROAs for
prefixes that were removed will be affected."
The recommendation you cite belongs in an updated ROA spec.
Essentially that really is all there is to it.
I'm afraid it's not that simple. The statement of what you want to
accomplish
does not match the algorithm described in Section 5, and that is my
point, i.e.,
the revised algorithm is not correct.
If this is easier to parse, and the co-chairs conclude that work should
continue, then I am happy to use this line of explanation in a next version of
the document. And no, I have no doubt that it will need more detail than above
in an I-D - but it's the basic principle that I am trying to convey here.
As I noted above, the algorithm description in Section 5 doesn't match what
you say you want to accomplish. Below is my take on what a revised
validation
algorithm should say to implement what you and your co-authors seem to
want to accomplish. You'll note that it is substantially different from
the text
that appears in the current I-D.
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].
There are two inputs to the validation algorithm:
1.a trust anchor
2.a certificate to be validated
The algorithm is initialized with the following new variables:
1.If an IP Address Delegation extension is present in the trust anchor
the address set flag is initialized to TRUE and the address resource
working set is initialized to the value of this extension. If the
extension is absent, the flag is initialized to FALSE and the address
resource working set is initialized to NULL.
2.If an AS Identifier Delegation extension is present in the trust
anchor, the AS number flag is initialized to TRUE and the AS number
resource working set is initialized to the value of this extension. If
the extension is absent, the flag is initialized to FALSE and the AS
number working set is initialized to NULL.
This path validation algorithm verifies, among other things, that a
prospective 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.
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 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).
2.The current time lies within the interval defined by the
NotBefore and NotAfter values in the Validity field of
certificate x.
3.The Version, Issuer, and Subject fields of certificate x
satisfy the constraints established in Section 4.1-4.7
of this specification.
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.
5.Any extension not identified in Section 4.8 MUST NOT
appear in certificate x.
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
6.Compute the address space and the AS number working sets
and flags values for certificate x as follows:
If the IP Address Delegation extension is present
in certificate x, and the address flag is TRUE, then
compute the intersection of the resources between this
extension and the current value of the address
space working set.
If the IP Address Delegation extension is present
in certificate x, and the address flag is FALSE,
the certificate fails validation.
If the IP Address Delegation extension is absent
in certificate x, set the address set flag to FALSE.
If the AS Identifier Delegation extension is present
in certificate x, and the AS number flag is TRUE, then
compute the intersection of the resources between this
extension and the current value of the address
space working set.
If the AS Identifier Delegation extension is present
in certificate x, and the AS number flag is FALSE,
the certificate fails validation.
If the AS Identifier Delegation extension is absent
in certificate x, set the AS number flag to FALSE.
If x = n (i.e., this is the certificate being validated)
then the IP address space and AS number working sets are
treated as the values for the IP Address and AS Identifier Delegation
extensions for this certificate, respectively.
If an RP is caching the results of validation, these values
SHOULD be stored along with the certificate, to facilitate
incremental validation based on cached results.
Otherwise, return to step 1 and continue path validation.
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 rejected the certificate does not result in a security
problem because the associated working resource sets accurately reflect
the resources associated with the
certificate in question.)
The address and/or AS number resources contained in a
valid EE certificate being validated MUST always be
encompassed by all certificates along the path to the
trust anchor (used to verify that EE certificate). Also
note that if any CA certificate along the path has no
address space resources, then any subordinate certificate
MUST NOT contain address space resources. The same constraint applies to
AS number resources.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
