Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Thu, May 20, 2021 at 09:13:52AM -0700, Randy Bush wrote:
> Russ wrote:
> > Responding to Part 1 of your DISCUSS and a few of your comments.  My
> > co-authors will address the other parts, including the NITS.
> 
> turning attention to this now.  i was in the RIPE meetings getting this
> through their sausage machine.

mmm, sausage, tasty.

> > OLD:
> > 
> >    1.  Obtain the signer's certificate from an RPKI Repository.  The
> >        certificate SubjectKeyIdentifier extension [RFC5280] MUST match
> >        the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier
> >        [RFC5286].  If the key identifiers do not match, then validation
> >        MUST fail.
> > 
> > NEW:
> > 
> >    1.  Obtain the signer's certificate from the CMS SignedData CertificateSet
> >         [RFC5652].  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.
> 
> done

+1

> > [snip]
> > 
> >> 
> >> Section 3
> >> 
> >>   The URL's use of the web PKI can not provide authentication of IP
> >>   address space ownership.  It is only used to authenticate a pointer
> >>   to the geofeed file, [...]
> >> 
> >> I'm a little confused by the use of the phrase "authenticate a pointer
> >> to the geofeed file".  My understanding is that the "pointer to the
> >> geofeed file" is the URL itself, i.e., it is a pointer from the RPSL
> >> stanza to the geofeed file, and that dereferencing the URL retrieves the
> >> geofeed file itself (i.e., not a pointer).  In particular, the URL (and
> >> any Web PKI usage therein) does not do anything to authenticate the RPLS
> >> stanza in which the URL appears.  IIUC, it would be okay to just drop
> >> that bit and say "It is only used to authenticate the domain name in the
> >> URL, and provide confidentiality and integrity for the geofeed file in
> >> transit".  Am I missing something?
> > 
> > I think it would be more accurate to say that the WebPKI provides
> > authentication and integrity of the geofeed file that is fetched.  However,
> > as I said in response to Roman's ballot comments, the ultimate integrity
> > check is the signature that is validated with the RPKI certificate.
> 
> the current text is close to this.  please indicate any tweaks that
> would improve it
> 
>    The URL's use of the web PKI can not provide authentication of IP
>    address space ownership.  It is only used to authenticate a pointer
>    to the geofeed file, authenticate the domain name in the URL, and
>    provide confidentiality and integrity for the geofeed file in
>    transit.  In contrast, the Resource Public Key Infrastructure (RPKI,
>    see [RFC6481]) can be used to authenticate IP space ownership; see
>    optional authentication in Section 4.
[handled in other thread]
> > OLD:
> > 
> >    One needs a format that bundles the relevant RPKI
> >    certificate with the signature and the digest of the geofeed text.
> > 
> > NEW:
> > 
> >    One needs a format that bundles the relevant RPKI
> >    certificate with the signature of the geofeed text.
> 
> easy

+1

> > OLD:
> > 
> >    Borrowing detached signatures from [RFC5485], after file
> >    canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652]
> >    would be used to create a detached DER encoded signature which is
> >    then padded BASE64 encoded (as per [RFC4648]) and line wrapped to 72
> >    or fewer characters.
> > 
> > NEW:
> > 
> >    Borrowing detached signatures from [RFC5485], after file
> >    canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652]
> >    would be used to create a detached DER encoded signature which is
> >    then padded BASE64 encoded (as per [RFC4648]) 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 calculating the message digest on the SignerInfo 
> >    SignedAttributes [RFC8933].  The message digest algorithm identifier
> >    MUST appear in both the SigenedData DigestAlgorithmIdentifiers and
> >    the SignerInfo DigestAlgorithmIdentifier [RFC5652].
> 
> ok

+1
and thanks again to Russ for getting 8933 done

> >>   text.  Trailing space characters MUST NOT appear on a line of text.
> >>   That is, the space or tab characters must not be followed by the
> >>   <CRLF> sequence.  [...]
> >> 
> >> Is the restriction on Unicode characters of category "space separator"
> >> ("space characters") or the two listed characters?  (Why just those two,
> >> and not form feed as well?)
> > 
> > Looking at the ABNF in RFC 8805, It does not look like there should be
> > any trailing whitespace, this was more for consistency with RFC 5485.
> 
> perhaps a clearer phrasing would be
> 
>     Trailing space characters MUST NOT appear on a line of text.  That
>     is, space or tab characters must not immediately preceed a <CRLF>
>     sequence.

Hmm, so I'm supposed to read "space characters" and think "a sequence of
one or more 0x20 bytes"?  I guess I can maybe see that, but do kind of want
an answer on whether we care about other unicode codepoints that are
"whitespace" appearing immediately prior to <CRLF>.  For better or for
worse, things get complicated and messy once we go past 7-bit ASCII.

> > OLD:
> > 
> >    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.
> > 
> > NEW:
> > 
> >    4.  Verify that the IP Address Delegation certificate extension
> >        [RFC3779] covers all of the address ranges of the geofeed file.
> >        If all of the address ranges are not covered, then validation
> >        MUST fail.
> 
> ok

I think "If any ... are not covered" is better.  We need all to be covered,
so if any is not covered then we fail.  (Hi, De Morgan!)

> >> Is "the signing certificate" different from "the RPKI certificate"?
> > 
> > To be consistent with the other numbered paragraphs, it would be
> > better to say "signer's certificate".
> 
> ack
> 
> >> Also, I suggest clarifying what "the resources" are that are covered.
> > 
> > As you suggest above, "all of the address ranges of the geofeed file"
> > is probably a good way to say it.
> 
> ack
> 
> >> Also^2, "the current manifest" would be a great place to put in a
> >> reference to the relevant document(s)
> > 
> > Yes, a reference to RFC 6486 would be good here.
> 
> ack

+3 for these.

Thanks,

Ben