Subject: [sidr] Certificate policy -- new draft (version 14)

From: Karen Seo <[email-masked]>
Date: Fri, 15 Oct 2010 12:28:32 -0400

Folks,

We just submitted a new version of the RPKI Certificate Policy. In 
addition to a few typo/format corrections, we have included all the 
changes for which there was consensus among those who provided review 
feedback. We believe the document has thus completed WG Last Call and 
respectfully request that it proceed to the next stage of review.

Thank you,
Karen

---

From: Geoff Huston <[email-masked]>
Date: Mon, 18 Oct 2010 11:47:59 +1100

On 16/10/2010, at 3:28 AM, Karen Seo wrote:

> Folks,
> 
> We just submitted a new version of the RPKI Certificate Policy. In addition to a few typo/format corrections, we have included all the changes for which there was consensus among those who provided review feedback. We believe the document has thus completed WG Last Call and respectfully request that it proceed to the next stage of review.

Respectfully, I have to disagree that this document is ready. Its a long document and for me each re-reading reveals more nits, unfortunately.

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.

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.

Also, please correct the back ref in section 1.4.2 i.e. s/1.5.1/1.4.1/

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.

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?

regards,

   Geoff

---

From: Stephen Kent <[email-masked]>
Date: Tue, 19 Oct 2010 15:27:35 -0400

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
>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.

>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

---

From: Geoff Huston <[email-masked]>
Date: Wed, 20 Oct 2010 06:45:48 +1100

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 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:
> 
> 
>   certificates also are permitted under this policy. Use of the certificates and

Yes,this proposed wording works for me.

> I hope you find the text above to be appropriate for section 1.  How about the following text for 1.4:
> 
>   system described in 2.4. Such transitive uses are permitted under this policy.
> 
> 

again, thanks, I agree with this proposed edit.

>> This version added the text in section 4.8.1:    When previously distributed INRs are removed from a certificate,
> 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:
> 

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