Oleg,
Thanks for the feedback on our doc.
Well, actually there is normative language:
you're right. those instances of MUST will be changed to lowercase,
since the intent is that this doc be informational.
And there are several other places where the normative language is not used,
but implied.
the doc is re-iterating what requirements doc say, so it is appropriate
to use language that conveys what the requirements are, but we do try to
avoid normative language. We'll revise the doc to remove normative
(uppercase) language, but we will continue to convey what is mandated
vs. optional, etc.
This doc outlines the RP functions, summarizes them and then gives reference to
those precise sections or paragraphs, in order to make life easier for
implementers to make sure he/she has addressed all of these requirements.
I have two comments for this paragraph.
First, it might seem appealing to create a document that will give a "reference to
those precise sections or paragraphs", so that the implementer could skip reading
those long RFCs in full. But I do not think it is possible or advisable. Even in your
draft you say:
An RP is required
to verify that a resource certificate adheres to the profile
established by [RFC6487]. This means that all extensions mandated by
[RFC6487] must be present and value of each extension must be within
the range specified by this RFC. Moreover, any extension excluded by
[RFC6487] must be omitted.
or
To determine whether a manifest is valid, the RP is required to
perform manifest-specific checks in addition to those specified in
[RFC6488].
So very often it is more practical to refer to the whole RFCs, because an
implementer has to implement all of it, not just specific paragraphs.
I agree that implementers will have to read the cited RFCs. The goal
here is to provide an overview of the requirements and to enumerate the
RFCs that contain such requirements.
Second, what if, for whatever reason, this document will not list *all* of the
requirements? Will it be OK for the implementer to say "I did everything specified
there", or will (s)he be required to double-check with other RFCs you refer to? Or
even with those you do not refer to?
I'm not sure how to define the applicability of such document.
the utility of the doc is that it provides a concise, high level
description of RP requirements, and pointers to the normative RFCs where
these requirements are fully specified. The BGPsec overview I-D is
informational and provides a concise description of what a router needs
to do to implement BGPsec, but it points to the relevant RFCs that
provide the full specs for BGPsec, router certs, etc.
Any comments and feedbacks are appreciated.
Here are my comments for some specific sections:
3.1. Verifying Resource Certificate and Syntax
Certificates in the RPKI are called resource certificates, and they
are required to conform to the profile [RFC6487]. An RP is required
to verify that a resource certificate adheres to the profile
established by [RFC6487]. This means that all extensions mandated by
[RFC6487] must be present and value of each extension must be within
the range specified by this RFC. Moreover, any extension excluded by
[RFC6487] must be omitted.
I think you should not repeat the text of other RFCs, otherwise you risk of
being incomplete or going out of sync with referenced RFC.
An informational RFC providing an overview always runs this risk, but
that doesn't make it a bad idea.
3.2. Certificate Path Validation
In the RPKI, issuer can only assign and/or allocate public INRs
belong to it, ...
I don't think assignment or allocation of INR happens in RPKI.
good point. the text will be revised to note that the RPKI _represents_
the allocations of INRs.
3.3. CRL Processing
The CRL processing requirements imposed on CAs and RP are described
in [RFC6487]. CRLs in the RPKI are tightly constrained; only the
AuthorityKeyIndetifier and CRLNumber extensions are allowed, and they
MUST be present. No other CRL extensions are allowed, and no
CRLEntry extensions are permitted. RPs are required to verify that
these constraints have been met. Each CRL in the RPI MUST be
verified using the public key from the certificate of the CA that
issued the CRL.
Apart from using normative language mentioned above, you seem to repeat the
text of other RFC.
Is it the only bit of RFC6487 that is applicable to CRL processing in RPKI
validation?
Aren't any CRL validation (not only in RPKI) requires that CRL must be verified
using the public key of it's issuer?
The cited text notes what CRL processing requirements are unique to the
RPKI. ALL PKIs require that a CRL be validated using the public key of
the issuer of the CRL.
4.2.1. Manifest
To determine whether a manifest is valid, the RP is required to
perform manifest-specific checks in addition to those specified in
[RFC6488].
Specific checks for a Manifest are described in section 4 of
[RFC6486]. If any of these checks fails, indicating that the
manifest is invalid, then the manifest will be discarded and treated
as though no manifest were present.
This description is quite incomplete. Perhaps you should merge the content of section
"4.3. How to Make Use of Manifest Data" in here, but even there I do not see a
reference to section 6 (Relying Party Use of Manifests) of RFC6486, which is quite a big
omission.
I agree that this needs more work. Your doc describing what the RIPE RP
code does include examples where you have made choices that are allowed,
but not mandated, by RFCs. This text wants to say what is mandated and
what is allowed. I suspect we may add an implementation guidance section
that will address issues where implementers have options and what
experience has taught us about the pros and cons of different options.
4.2.2. ROA
To validate a ROA, the RP is required perform all the checks
specified in [RFC6488] as well as the additional ROA-specific
validation steps. The IP address delegation extension [RFC3779]
present in the end-entity (EE) certificate (contained within the
ROA), must encompass each of the IP address prefix(es) in the ROA.
More details for ROA validation are specified in section 2 of
[RFC6482].
The second sentence is almost a 1-to-1 copy of Section 4 of 6482. What's the
point of copying it instead of referencing?
the goal of this doc is both to point to all of the RFCs that establish
RP requirements, and to provide an overview of the requirements. In some
cases, the text here will paraphrase the requirements, in other cases it
may merely restate them.
Section 2 of RFC6482 defines the ROA content-type, not the validation.
god catch, we'll fix that.
4.2.3. Ghostbusters
The Ghostbusters Record is optional; a publication point in the RPKI
can have zero or more associated Ghostbuster Records.
This is true for all objects except manifest and CRL.
yes, so what?
If a CA has at
least one Ghostbuster Record, RP is required to verify that this
Ghostbusters Record conforms to the syntax of signed object defined
in [RFC6488].
And this is also true for any signed object.
ibid.
The payload of this signed object is a (severely) profiled vCard. An
RP is required to verify that the payload of Ghostbusters conforms to
format as profiled in [RFC6493].
I'm mentioning it here, but it applies to many places in this document: the
validation section of RFC6493 already references RFC6488. So why duplicate it
here?
Oleg, I think we fundamentally disagree about the utility of a doc like
this. I agree that this initial cut can be improved, but I disagree with
you sentiment that it is not a worthwhile document. I have provided you
and Tim with extensive comments on your RIPE validation description doc,
and these have identified a number of places where the text needed to be
clarified or fixed, i.e., it was technically incorrect. In that light I
think it would be fair to assume that successive versions of this doc
can improve as well, and thus refusing to consider it is premature.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
