Hi Russ! Inline ...
> -----Original Message----- > From: Russ Housley <[email protected]> > Sent: Wednesday, May 19, 2021 11:27 AM > To: Roman Danyliw <[email protected]> > Cc: IESG <[email protected]>; [email protected]; > [email protected]; Ops Area WG <[email protected]>; George Michaelson > <[email protected]> > Subject: Re: Roman Danyliw's Discuss on draft-ietf-opsawg-finding-geofeeds- > 10: (with DISCUSS and COMMENT) > > 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. Works for me. Thanks for precisely stating the CMS field names which would not have been recognizable from my above short hand notation. > > > > > > ---------------------------------------------------------------------- > > 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. Agreed. > > ** 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? With the precision you provided in the response to the DISCUSS, I would have rephrased my original comment to: NEW ... the RPKI certificate covering the inetnum: object's address range is included in the IP Address Delegation certificate extension [RFC3779] field. > > object's address range is included in the [RFC5652] CMS SignedData > > certificates field > > ** Section 4. Per the format of the signature appended to the geofeed file: > > # RPKI Signature: 192.0.2.0/24 > > # > MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKo > Z > > # > IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7h > Zu > > ... > > # > 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? I figured. I'm thinking it just needs a sentence to say that. > > ** 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. There was a CMS structure subtlety that I didn't understand. The CA cert made no reference to v6, but the end-point one did. Regards, Roman > Russ > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
