Re: [sidr] Validation Reconsidered (again/again) question

[Stephen Kent <[e-mail]>]

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.