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

[Tim Bruijnzeels <[e-mail]>]

Hi Steve,

Without going into every detail.

I understand this is not what the current text says. I provided an alternative description to illustrate how I would propose to re-write text. The current text takes a bottom-up view of the process w.r.t. verifying the presence of resources looking back up the path for a given certificate or object. I believe things are much more clear taking a top-down view.

I hope to find time over the next weeks to do this work and would welcome your feedback on new text when it is done.

Tim



> On 17 Dec 2015, at 17:27, Stephen Kent <[e-mail]> wrote:
> 
> 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. 
>  
> 
>