Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-finding-geofeeds-10: (with DISCUSS and COMMENT)
Thanks Roman. Two follow-up comments in line. Russ > On May 19, 2021, at 5:59 PM, Roman Danyliw wrote: > > Hi Russ! > > Inline ... > >> -Original Message- >> From: Russ Housley >> Sent: Wednesday, May 19, 2021 11:27 AM >> To: Roman Danyliw >> Cc: IESG ; draft-ietf-opsawg-finding-geofe...@ietf.org; >> opsawg-cha...@ietf.org; Ops Area WG ; George Michaelson >> >> 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 ” 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 ma
Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-finding-geofeeds-10: (with DISCUSS and COMMENT)
Hi Russ! Inline ... > -Original Message- > From: Russ Housley > Sent: Wednesday, May 19, 2021 11:27 AM > To: Roman Danyliw > Cc: IESG ; draft-ietf-opsawg-finding-geofe...@ietf.org; > opsawg-cha...@ietf.org; Ops Area WG ; George Michaelson > > 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 ” 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 [RFC
Re: [OPSAWG] 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 ” 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
