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