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 <[email protected]> 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. > > > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
