Here’s a file that shows the differences between the two procedures (I backed out the capitalization changes). text1 is in 6487 (left) and text2 is in validation-reconsidered (right).
sptTitle: Diff: text1.txt - text2.txt
| text1.txt | text2.txt | |||
|---|---|---|---|---|
| Validation of signed resource data using a target resource | Validation of signed resource data using a signing key that is | |||
| certificate consists of verifying that the digital signature of the | certified in a resource certificate, coupled with a specific set of | |||
| signed resource data is valid, using the public key of the target | number resources, consists of verifying that the digital signature of | |||
| resource certificate, and also validating the resource certificate in | the signed resource data is valid, using the public key that is | |||
| the context of the RPKI, using the path validation process. This | certified by the resource certificate, and also validating the | |||
| path validation process verifies, among other things, that a | resource certificate in the context of the RPKI, using the path | |||
| validation process. | ||||
| This path validation process verifies, among other things, that a | ||||
| prospective certification path (a sequence of n certificates) | prospective certification path (a sequence of n certificates) | |||
| satisfies the following conditions: | satisfies the following conditions: | |||
| 1. for all 'x' in {1, ..., n-1}, the subject of certificate 'x' | 1. for all 'x' in {1, ..., n-1}, the subject of certificate 'x' | |||
| is the issuer of certificate ('x' + 1); | is the issuer of certificate ('x' + 1); | |||
| 2. certificate '1' is issued by a trust anchor; | 2. certificate '1' is issued by a trust anchor; | |||
| 3. certificate 'n' is the certificate to be validated; and | 3. certificate 'n' is the certificate to be validated; and | |||
| 4. for all 'x' in {1, ..., n}, certificate 'x' is valid. | 4. for all 'x' in {1, ..., n}, certificate 'x' is valid for the | |||
| specific set of resources. | ||||
| Certificate validation entails verifying that all of the following | RPKI validation for a specific set of resources entails verifying | |||
| conditions hold, in addition to the certification path validation | that all of the following conditions hold, in addition to the | |||
| criteria specified in Section 6 of [RFC5280]: | certification path validation criteria specified in Section 6 of | |||
| [RFC5280]: | ||||
| 1. The certificate can be verified using the issuer's public key | 1. The certificate can be verified using the issuer's public key | |||
| and the signature algorithm | and the signature algorithm | |||
| 2. The current time lies within the certificate's Validity From | 2. The current time lies within the certificate's Validity From | |||
| and To values. | and To values. | |||
| 3. The certificate contains all fields that MUST be present, as | 3. The certificate contains all fields that MUST be present, as | |||
| defined by this specification, and contains values for | specified by [RFC6487], and contains values for selected | |||
| selected fields that are defined as allowable values by this | fields that are defined as allowable values by this | |||
| specification. | specification. | |||
| 4. No field, or field value, that this specification defines as | 4. No field, or field value, that the [RFC6487] specification | |||
| MUST NOT be present is used in the certificate. | defines as MUST NOT be present is used in the certificate. | |||
| 5. The issuer has not revoked the certificate. A revoked | 5. The issuer has not revoked the certificate. A revoked | |||
| certificate is identified by the certificate's serial number | certificate is identified by the certificate's serial number | |||
| being listed on the issuer's current CRL, as identified by the | being listed on the issuer's current CRL, as identified by the | |||
| CRLDP of the certificate, the CRL is itself valid, and the | CRLDP of the certificate, the CRL is itself valid, and the | |||
| public key used to verify the signature on the CRL is the same | public key used to verify the signature on the CRL is the same | |||
| public key used to verify the certificate itself. | public key used to verify the certificate itself. | |||
| 6. The resource extension data is "encompassed" by the resource | 6. The resource extension data contained in this certificate | |||
| extension data contained in a valid certificate where this | "encompasses" the entirety of the resources in the specific | |||
| issuer is the subject (the previous certificate in the context | resource set ("encompass" in this context is defined in | |||
| of the ordered sequence defined by the certification path). | Section 7.1 of [RFC6487]). | |||
| 7. The certification path originates with a certificate issued by | 7. The certification path originates with a certificate issued by | |||
| a trust anchor, and there exists a signing chain across the | a trust anchor, and there exists a signing chain across the | |||
| certification path where the subject of Certificate 'x' in the | certification path where the subject of Certificate 'x' in the | |||
| certification path matches the issuer in Certificate 'x + 1' | certification path matches the issuer in Certificate 'x + 1' | |||
| in the certification path, and the public key in Certificate | in the certification path, and the public key in Certificate | |||
| 'x' can verify the signature value in Certificate 'x+1'. | 'x' can verify the signature value in Certificate 'x+1'. | |||
| End of changes. 6 change blocks. | ||||
| 18 lines changed or deleted | 23 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||
> On Nov 04, 2015, at 23:23, Christopher Morrow <[email protected]> > wrote: > > hurray! ambiguity in questions was raised by an interested party... > > I'd rather do this Friday at the end of the meeting with a short > presentation/conversation. > > -chris > > On Tue, Nov 3, 2015 at 8:21 PM, Christopher Morrow > <[email protected]> wrote: >> During the meeting today (tues 11/3/2015) one of the authors of: >> draft-ietf-sidr-rpki-validation-reconsidered >> >> noted that after the last set of updates and over the history of the >> document (2+yrs) there's been no real support nor direction from the >> working-group. Additionally, all co-authors noted that the lack of >> support and direction meant that abandoning the draft seemed like the >> best current direction. >> >> The primary author: Geoff Huston ([email protected]) is willing to toss >> the XML over the fence to another author/editor if there is interest, >> or to let the draft expire/die if no one is willing to take up the >> pencil. >> >> Over the next three weeks let's discuss the direction/end-goal and >> determine if 'abandon' or 'new author' is the best course of action >> here. >> >> -chris >> sidr-co-chair > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
