Geoff,
Thans for the cafreful reading. Here are our proposed changes to
address the issues you raised.
I am sorry I did not raise this before, but I'd like to understand
how this constraint in the second paragraph of the Introduction,
namely
This PKI
is designed exclusively for use in support of validation of claims
related to INR holdings. Use of the certificates and certificate
revocation lists (CRLs) managed under this PKI for any other purpose
is a violation of this CP, and relying parties (RPs) SHOULD reject
certificates presented for such uses.
relates to the processing of manifests in the RPKI repository
infrastructure, where a certificate used in the context of the RPKI
is NOT used for support of validation of claims related to INR
holdings. The constraint above appears to preclude the use of
manifests in the RPKI, and I believe that this is an inappropriate
constraint.
I don't read the text in question as precluding the processing EE
certs used in manifests. Manifests exist to enable RPs to detect a
class of attacks against the repository system. The repository system
exists to enable RPs to acquire the CA and EE certs used validate
"claims related to INR holdings." Thus, transitively, the certs used
with manifests are within scope, as is the processing of these certs.
But, to help avoid confusion, how about the following revised text:
The most important and distinguishing aspect of the PKI for which
this policy was created is that it does not purport to identify an
INR holder via the subject name contained in the certificate issued
to that entity. Rather, each certificate issued under this policy is
intended to enable an entity to assert, in a verifiable fashion,
that it is the current holder of an INR based on the current records
of the entity responsible for the resources in question.
Verification of the assertion is based on two criteria: the ability
of the entity to digitally sign data that is verifiable using the
public key contained in the corresponding certificate, and
validation of that certificate in the context of this PKI.
This PKI is designed exclusively for use in support of validation of claims
related to current INR holdings. This includes any certificates issued in
support of operation of this infrastructure, e.g., for integrity or access
control of the repository system described in 2.4. Such transitive uses of
certificates also are permitted under this policy. Use of the
certificates and
certificate revocation lists (CRLs) managed under this PKI for any other
purpose is a violation of this CP, and relying parties (RPs) SHOULD reject
certificates presented for such uses.
Section 1.4.1 is also perhaps misleading, where is allows for these
certificates to be used to support operation of this infrastructure,
but cites an example of access control, whereas the example of
manifest is the case in point where there is a defined use.
I suggest that the wording in the introduction be altered to allow
for use in support of the operation of this infrastructure so that
sections 1.4.1 and the Introduction agree.
I hope you find the text above to be appropriate for section 1. How
about the following text for 1.4:
The certificates issued under this hierarchy are for authorization
in support of validation of claims of current holdings of INRs.
Additional uses of the certificates, consistent with the basic goal
cited above, also are permitted under this policy. For example, certificates
may be issued in support of integrity and access control for the repository
system described in 2.4. Such transitive uses are permitted under
this policy.
Section 4.7.1 referes to section 5.6 relating to key validity
intervals. But in changing section 5.6, the reference in 4.7.1 is no
longer appropriate. This forward reference should be omitted, as the
advice is no longer provided.
Agreed. We will delete the last paragraph in 4.7.1.
This version added the text in section 4.8.1:
When previously distributed INRs are removed from a certificate,
then the old certificate MUST be revoked and a new certificate MUST
be issued, reflecting the changed INR holdings. (The SIA extension
MAY also be changed during this action, if required.)
I'm not sure of the circumstances where the issuer knows what SIA to
use IF it is going to change. The SIA is normally supplied by the
subject, so in the case of certificate modification by the issuer in
response to a "shrink" in response where is the subject's
certificate request that contains a new SIA?
We made this change in response to a comment by another reviewer. If
the SIA is to change, the new one must be provided by the Subject
that is loosing some INRs, as you suggest. Thus, I would expect the
CA that revokes the cert (due to INR shrinkage) to use the SIA that
appeared in the cert being revoked, unless it is informed otherwise.
We can make that clearer with the following, revised paragraph:
When previously distributed INRs are removed from a certificate,
then the old certificate MUST be revoked and a new certificate MUST
be issued, reflecting the changed INR holdings. (The SIA extension
in the new certificate will be unchanged, unless the affected INR holder
supplies a new SIA value.)
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
