Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-finding-geofeeds-10: (with DISCUSS and COMMENT)

[Roman Danyliw <[e-mail]>]

Hi Russ!

Inline ...

> -----Original Message-----
> From: Russ Housley <[e-mail]>
> Sent: Wednesday, May 19, 2021 11:27 AM
> To: Roman Danyliw <[e-mail]>
> Cc: IESG <[e-mail]>; [e-mail];
> [e-mail]; Ops Area WG <[e-mail]>; George Michaelson
> <[e-mail]>
> 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
>