diff --git a/draft-ietf-opsawg-9092-update.xml b/draft-ietf-opsawg-9092-update.xml index cc27243..1db45e3 100644 --- a/draft-ietf-opsawg-9092-update.xml +++ b/draft-ietf-opsawg-9092-update.xml @@ -8,7 +8,7 @@ - @@ -413,191 +413,195 @@
Authenticating Geofeed Data (Optional) + - The question arises whether a particular geofeed data set is valid, i.e., is - authorized by the "owner" of the IP address space and is - authoritative in some sense. The inetnum: that points to the - geofeed file provides - some assurance. Unfortunately, the RPSL in some repositories is - weakly authenticated at best. An approach where RPSL was signed - per would be good, - except it would have to be deployed by all RPSL registries, and - there is a fair number of them. - - - A single optional authenticator MAY be appended - to a geofeed file. It - is a digest of the main body of the file signed by the private - key of the relevant RPKI certificate for a covering address - range. One needs a format that bundles the relevant RPKI - certificate with the signature of the geofeed text. - - - The canonicalization procedure converts the data from their - internal character representation to the UTF-8 character encoding, and the - <CRLF> sequence MUST be used to denote the - end of a line of text. A blank line is represented solely by - the <CRLF> sequence. For robustness, any non-printable - characters MUST NOT be changed by - canonicalization. Trailing blank lines MUST NOT - appear at the end of the file. That is, the file must not end - with multiple consecutive <CRLF> sequences. Any - end-of-file marker used by an operating system is not considered - to be part of the file content. When present, such end-of-file - markers MUST NOT be processed by the digital - signature algorithm. - - - Should the authenticator be syntactically incorrect per the - above, the authenticator is invalid. + The question arises whether a particular geofeed data set is valid, i.e., is authorized by the + "owner" of the IP address space and is authoritative in some + sense. The inetnum: that points to the geofeed file provides some assurance. Unfortunately, + the RPSL in some repositories is weakly authenticated at best. + An approach where RPSL was signed per + would be good, except it would have to be deployed by all RPSL + registries, and there is a fair number of them. - Borrowing detached signatures from , after file canonicalization, the - Cryptographic Message Syntax (CMS) would be used to create a detached - DER-encoded signature that is then padded BASE64 encoded (as per - ) and line wrapped to 72 or fewer characters. - The same digest algorithm MUST be used for - calculating the message digest on content being signed, which is - the geofeed file, and for calculating the message digest on the - SignerInfo SignedAttributes . The message digest algorithm identifier - MUST appear in both the SignedData - DigestAlgorithmIdentifiers and the SignerInfo - DigestAlgorithmIdentifier . + The remainder of this section specifies an optional + authenticator for the geofeed data set that follows the Signed + Object Template for the Resource Public Key Infrastructure + (RPKI) . - - The address range of the signing certificate MUST cover all - prefixes on the geofeed file it signs. The certificate MUST NOT - include the Autonomous System Identifier Delegation certificate - extension . - - - An address range A "covers" address range B if the range of B is - identical to or a subset of A. "Address range" is used here - because inetnum: objects and RPKI certificates need not align on - Classless Inter-Domain Routing (CIDR) - prefix boundaries, while those of the lines in a geofeed file - do. - - - As the signer specifies the covered RPKI resources relevant to - the signature, the RPKI certificate covering the inetnum: - object's address range is included in the CMS SignedData certificates field. - - - The CA MUST sign only one Geofeed with each generated private - key and MUST generate a new key pair for each new version of the - Geofeed. An associated EE certificate used in this fashion is - termed a "one-time-use" EE certificate (see Section 3 of - ). - - - Identifying the private key associated with the certificate and - getting the department that controls the private key (which - might be trapped in a Hardware Security Module (HSM)) to sign - the CMS blob is left as an exercise for the implementor. On the - other hand, verifying the signature requires no complexity; the - certificate, which can be validated in the public RPKI, has the - needed public key. - The trust anchors for the RIRs are expected to already be - available to the party performing signature validation. - Validation of the CMS signature on the geofeed file - involves: -
  1. - - Obtaining the signer's certificate from the CMS SignedData - CertificateSet . The - certificate SubjectKeyIdentifier extension MUST match - the SubjectKeyIdentifier in the CMS SignerInfo - SignerIdentifier . - If the key identifiers do not match, then validation - MUST fail. - - Validation of the signer's certificate MUST - ensure that it is part of the current manifest and that the resources are covered - by the RPKI certificate. - -
    2. + + A single optional authenticator MAY be appended to a geofeed + file. It is a digest of the main body + of the file signed by the private key of the relevant RPKI + certificate for a covering address range. The following format + bundles the relevant RPKI certificate with a signature over the + geofeed text. + + + The canonicalization procedure converts the data from their + internal character representation to the UTF-8 character encoding, and the <CRLF> + sequence MUST be used to denote the end of each line of text. A + blank line is represented solely by the <CRLF> sequence. + For robustness, any non-printable characters MUST NOT be changed + by canonicalization. Trailing blank lines MUST NOT appear at + the end of the file. That is, the file must not end with + multiple consecutive <CRLF> sequences. Any end-of-file + marker used by an operating system is not considered to be part + of the file content. When present, such end-of-file markers + MUST NOT be covered by the digital signature. + + + + If the authenticator is not in the canonical form described above, + then, the authenticator is invalid. + + + + Borrowing detached signatures from , + after file canonicalization, the Cryptographic Message Syntax + (CMS) is used to create a detached + DER-encoded signature that is then Base64 encoded with padding + (as defined in Section 4 of ) and line + wrapped to 72 or fewer characters. The same digest algorithm + MUST be used for calculating the message digest of the content + being signed, which is the geofeed file, and for calculating the + message digest on the SignerInfo SignedAttributes . The message digest algorithm identifier + MUST appear in both the CMS SignedData + DigestAlgorithmIdentifiers and the SignerInfo + DigestAlgorithmIdentifier . The RPKI + certificate covering the geofeed inetnum: object's address range + is included in the CMS SignedData certificates field . + + + + The address range of the signing certificate MUST cover all + prefixes in the signed geofeed file. The signing certificate + MUST NOT include the Autonomous System Identifier Delegation + certificate extension . + + + + As with many other RPKI signed objects, the IP Address + Delegation certificate extension MUST NOT use the "inherit" + capability defined in Section 2.2.3.5 of . An IP Address Delegation extension using + "inherit" would complicate processing. The implementation would + have to build the certification path from the end-entity to the + trust anchor, then validate the path from the trust anchor to + the end-entity, and then the parameter would have to be + remembered when the validated public key was used to validate a + signature on a CMS object. Having to remember things from + certification path validation for use with CMS object processing + is too hard. And, the certificates do not get that much bigger + by repeating the information. + + + + An address range A "covers" address range B if the range of B is + identical to or a subset of A. "Address range" is used here + because inetnum: objects and RPKI certificates need not align on + Classless Inter-Domain Routing (CIDR) + prefix boundaries, while those of the lines in a geofeed file do + align. + + + + The CA MUST sign only one geofeed with a particular generated + private key and MUST generate a new key pair for each new + version of the geofeed. An associated EE certificate used in + this fashion is termed a "one-time- use" EE certificate (see + Section 3 of ). + + + + Identifying the private key associated with the certificate and + getting the department that controls the private key (which + might be stored in a Hardware Security Module (HSM)) to generate + the CMS signature is left as an exercise for the implementor. + On the other hand, verifying the signature has no similar + complexity; the certificate, which is validated in the public + RPKI, contains the needed public key. The RPKI trust anchors + for the RIRs are expected to already be available to the party + performing signature validation. Validation of the CMS + signature over the geofeed file involves: + +
    1. - Constructing the certification path for the signer's - certificate. All of the needed certificates are expected to - be readily available in the RPKI repository. The - certification path MUST be valid according to - the validation algorithm in and the additional checks specified in - associated with the - IP Address Delegation certificate extension and the Autonomous - System Identifier Delegation certificate extension. If - certification path validation is unsuccessful, then validation - MUST fail. -
      2. - -
    2. - Validating the CMS SignedData as specified in using the public key from - the validated signer's certificate. If the signature - validation is unsuccessful, then validation - MUST fail. -
      3. -
    3. - Verifying that the IP Address Delegation certificate extension - covers all of the - address ranges of the geofeed file. If all of the address - ranges are not covered, then validation MUST - fail. -
      4. + Obtain the signer's certificate from the CMS SignedData + CertificateSet . The certificate + SubjectKeyIdentifier extension MUST + match the SubjectKeyIdentifier in the CMS SignerInfo + SignerIdentifier . If the key + identifiers do not match, then validation MUST fail. + + +
    4. + Validation of the signer's certificate MUST ensure that it is + part of the current manifest and that + all resources are covered by the RPKI certificate. +
      5. + +
    5. + Construct the certification path for the signer's certificate. + All of the needed certificates are expected to be readily + available in the RPKI repository. The certification path MUST + be valid according to the validation algorithm in and the additional checks specified in + associated with the IP Address + Delegation certificate extension and the Autonomous System + Identifier Delegation certificate extension. If certification + path validation is unsuccessful, then validation MUST fail. +
      6. + +
    6. + Validate the CMS SignedData as specified in using the public key from the validated + signer's certificate. If the signature validation is + unsuccessful, then validation MUST fail. +
      7. + +
    7. + Confirm that the eContentType object identifier (OID) is + id-ct-geofeedCSVwithCRLF (1.2.840.113549.1.9.16.1.47). This + OID MUST appear within both the eContentType in the + encapContentInfo object and the ContentType signed attribute + in the signerInfo object (see ). +
      8. + +
    8. + Verify that the IP Address Delegation certificate extension + covers all of the address ranges of + the geofeed file. If all of the address ranges are not + covered, then validation MUST fail. +
    + - All of these steps MUST be successful to consider - the geofeed file signature as valid. + All of the above steps MUST be successful to consider the + geofeed file signature as valid. + - As the signer specifies the covered RPKI resources relevant to the - signature, the RPKI certificate covering the inetnum: object's address - range is included in the CMS SignedData certificates field . + Identifying the private key associated with the certificate and + getting the department with the Hardware Security Module (HSM) + to sign the CMS blob is left as an exercise for the implementor. + On the other hand, verifying the signature requires no + complexity; the certificate, which can be validated in the + public RPKI, has the needed public key. + - An IP Address Delegation extension using "inherit" would - complicate processing. The implementation would have to build - the certification path from the end-entity to the trust anchor, - then validate the path from the trust anchor to the end-entity, - and then the parameter would have to be remembered when the - validated public key was used to validate a signature on a CMS - object. Having to remember things from certification path - validation for use with CMS object processing is too hard. And, - the certificates do not get that much bigger by repeating the - information. - - - Therefore an extension using "inherit" MUST NOT be used. This - is consistent with other RPKI signed objects. - - - Identifying the private key associated with the certificate and - getting the department with the Hardware Security Module (HSM) - to sign the CMS blob is left as an exercise for the implementor. - On the other hand, verifying the signature requires no - complexity; the certificate, which can be validated in the - public RPKI, has the needed public key. - - - The appendix MUST be hidden as a series of "#" comments at the - end of the geofeed file. The following is a cryptographically - incorrect, albeit simple, example. A correct and full example is - in . + The authenticator MUST be hidden as a series of "#" comments at the + end of the geofeed file. The following simple example is + cryptographically incorrect: + - The signature does not cover the signature lines. + A correct and full example is in Appendix A. + - The bracketing "# RPKI Signature:" and "# End Signature:" - MUST be present following the model as shown. - Their IP address range MUST match that of the - inetnum: URL followed to the file. + The CMS signature does not cover the signature lines. + - describes - and provides code for a CMS profile for - a general purpose listing of checksums (a "checklist") for use with - the Resource Public Key Infrastructure (RPKI). It provides usable, - albeit complex, code to sign geofeed files. - - - describes - a CMS profile for a general purpose Resource Tagged Attestation (RTA) - based on the RPKI. While this is expected to become applicable in the - long run, for the purposes of this document, a self-signed root trust - anchor is used. - + The bracketing "# RPKI Signature:" and "# End Signature:" MUST + be present as shown in the example. The RPKI Signature's IP + address range MUST match that of the geofeed URL in the inetnum: + that points to the geofeed file. + +
+
Operational Considerations @@ -832,8 +830,6 @@ - - @@ -849,6 +845,7 @@ + @@ -864,8 +861,6 @@ - - Representation Of IP Routing Policies In The RIPE Database