Roman:
Addressing some of your comments below. I'm leaving others to my co-authors.
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> The validation process for the signature computed in Section 4 seems
> underspecified.
>
> For example, let’s consider the example in Appendix A. Through a whois query
> for 192.0.2.0 one finds a “remarks: Geofeed <https url>” field which
> leads to a geofeed file which had the detached CMS signature blob “# RPKI
> Signature: 192.0.2.0/24” depicted at the end of Appendix A. What reference or
> text guides how to validate that signature in the RPKI (akin to the level of
> detail in Section 3.3 of RFC7909 or RFC6125)?
>
> I’m inferring that the steps would roughly be:
>
> ** Download the end-entity certificate identified by the subjectKeyIdentifier
> field via the pointer/URI in the “subjectInfoAccess” field extracted from the
> CMS signature blob
>
> ** Download the intermediate certificate identified by the
> authorityKeyIdentifier field via the pointer/URI in the “caIssuer” field
> extracted from the CMS signature blob
>
> ** Based on the RIR identified in the whois query, download the RPKI trust
> anchor of the RIR
>
> ** Validate the certificate chain from the RPKI trust anchor down to the
> end-entity certificate. Check that all of the basicConstraints,
> certificatePolicies, etc. are accurate. Check the CRL.
>
> ** Verify that the end-entity certificate contains the IP address of interest
> (192.0.2.0) in the sbgp-ipAddrBlock field
>
> ** Validate the signature using the algorithm identified in the CMS signature
> blog using the end-entity certificate
>
> Is that the process? Is that stated somewhere in the document or available
> via
> reference?
I suggest the following changes in Section 4:
OLD:
Validation of the signing certificate needs to ensure that it is part
of the current manifest and that the resources are covered by the
RPKI certificate.
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 [RFC5652] 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.
NEW:
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 [RFC5652] 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.
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. Obtain the signer's certificate from an RPKI Repository. The certificate
SubjectKeyIdentifier extension [RFC5280] MUST match the
SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier [RFC5652].
If the key identifiers do not match, then validation MUST fail.
2. 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 [RFC5280] and the additional checks
specified in [RFC3779] 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.
3. Validate the CMS SignedData as specified in [RFC5652] using the
public key from the validated signer's certificate. If the signature
validation is unsuccessful, then validation MUST fail.
4. Verify that the IP Address Delegation certificate extension [RFC3779]
covers the address range of the geofeed file. If the address range is
not covered, then validation MUST fail.
If all of these steps MUST be successful to consider the geofeed file
signature as valid.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you to Kyle Rose for the SECDIR review.
>
> ** Section 3. "It is only used to authenticate a pointer to the geofeed file
> and transport integrity of the data."
>
> To separate the notion of the transport security provided with TLS and the
> object security provided by the RPKI signature, it might be cleaner to say:
>
> TLS and the web PKI authenticate the domain name in the URL and provides
> confidentiality and integrity for the geofeed file in transit.
The RPKI signature ought to be sufficient to consider the signature valid. The
WebPKI is providing authentication and integrity of the fetched data, but if any
of the data is modified at any point in the process, the RPKI signature will
catch it.
> ** Section 4. Per “Borrowing detached signatures from [RFC5485] …”, I’m
> having
> trouble following which concept is being borrowed to elevate this to a
> normative reference.
With the changes to address your DISCUSS, this can probably be an informational
reference.
> ** Section 4. Per “the RPKI certificate covering the inetnum: object's
> address
> range is included in the [RFC5652] CMS SignedData certificates field”, can a
> more specific statement be made to say that it would be the sbgp-ipAddrBlock
> field in the certificate?
I think this is already explained in the definition of 'covers'. Am I missing
something?
> ** Section 4. Per the format of the signature appended to the geofeed file:
> # RPKI Signature: 192.0.2.0/24
> # MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
> # IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu
> ...
> # imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa
> # O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk=
> # End Signature: 192.0.2.0/24
>
> -- Are the header “# RPKI Signature: 192.0.2.0/24” and footer “# End
> Signature:
> 192.0.2.0/24” syntactically required? If would seem so, but that’s never
> explicitly stated and can only be inferred via the example. It would be
> helpful to explicitly clarify that.
Yes, they are required. Randy, can you suggest a MUST statement?
> ** Appendix A.
>
> Section 4 says: “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 [RFC5652] CMS SignedData certificates field.” I
> was
> expecting the end-entity certificate to encode “192.0.2.0/24” in the
> sbgp-ipAddrBlock field. The CA certificate has this IP block, but the
> end-entity certificate decodes the sbgp-ipAddBlock field to “IPv4: inherit
> IPv6: inherit”. Is that expected -- to have both an ipv4 and ipv6 annotation
> (since the previous certificate in the chain only mentioned IPv4), and not
> explicitly repeat the IPv4 value?
This will be done when the CA is issuing a subordinate certificate explicitly
for geofeed signing. This is good key hygene to use a given key for only one
purpose.
Russ
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
