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
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
