On 20/10/2010, at 6:27 AM, Stephen Kent wrote: > 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. > >
Yes,this proposed wording works for me. > >> 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. > > again, thanks, I agree with this proposed edit. >> 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.) I can live with this. I'm still unsure how this "new" SIA value is to be supplied to the Issuer, given that it is not in the "current" request from the subject (i.e. the most recent request that caused the about-to-be-revoked-and reissued-with-a-smaller-INR-set certificate to be issued), but that is perhaps out of scope for the CP, hence my conclusion that I can live with this. regards, Geoff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
