Ben:
Responding to Part 1 of your DISCUSS and a few of your comments. My co-authors
will address the other parts, including the NITS.
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Roman and Russ did the heavy lifting already, but I think I have a bit more
> fiddling to do regarding the validation procedures (just getting them
> internally consistent, I think)...
>
> (1)
> Here:
>
> 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.
>
> we say that the signing certificate is included in the SignedData
> certificates field. That makes sense, as SignedData is a SEQUENCE
> including "certificates [0] IMPLICIT CertificateSet OPTIONAL", and
> CertificateSet, as a SET OF CertificateChoices, allows for the literal
> "Certificate" branch of CertificateChoices.
>
> But later on, we say that:
>
> 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.
>
> which entails fetching the certificate from a directory, based on the
> SubjectKeyIdentifier.
>
> Why do we need to obtain the certificate twice in two different ways?
Thanks for catching this error that I introduced yesterday. Here is a
correction.
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.
[snip]
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
[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.
[snip]
> Section 4
>
> address range. One needs a format that bundles the relevant RPKI
> certificate with the signature and the digest of the geofeed text.
>
> If the signature is distributed alongside the file being signed, why is
> it necessary to bundle the digest of the file being signed with the
> signature? This just invites security-relevant implementation bugs
> where the validator just accepts the precomputed digest and does not
> validate that the contents of the geofeed file actually have that
> digest.
This comes from the fact that CMS does carry the message digest in a
signed attribute, but this is probably too much detail at this point in the
discussion.
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.
> (There is, however, value in the CMS SignedData including the digest
> *algorithms* used in signatures. I don't know if that was the intent
> here.)
Yes, CMS carries the digest algorithm identifier. We can be more explicit.
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].
>
> 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.
> 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.
>
> We want RFC 5652 again, here (5286 is IP Fast Reroute: Loop-Free
> Alternates, which is of no relevance to this document).
This typo was corrected in the response to your DISCUSS ballot position.
> 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.
>
> "address range of the geofeed file" is probably under-specified, since
> the file could in theory include multiple disjoint ranges. I assume we
> want to say something like "covers all the addresses and/or address
> ranges in the geofeed file" and make the grammar in the last sentence
> match.
Yes. That is better.
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.
>
> 5. Validation of the signing certificate MUST ensure that it is part
> of the current manifest and that the resources are covered by the
> RPKI certificate.
>
> 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".
> 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.
> 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.
[snip]
> Appendix A
>
> Those are some interesting Subject CNs in the non-root certs, but I
> guess they work...
>
> I only did some cursory spot-checking of the examples, and not a full
> work-up.
The RPKI purposely does not identify the current address block holder.
RFC 6487 says:
An issuer name MUST contain one instance of the CommonName attribute
and MAY contain one instance of the serialNumber attribute. If both
attributes are present, it is RECOMMENDED that they appear as a set.
The CommonName attribute MUST be encoded using the ASN.1 type
PrintableString [X.680]. Issuer names are not intended to be
descriptive of the identity of issuer.
There is similar language for the subject name.
Russ
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
