Subject: Re: [sidr] some comments on draft-ietf-sidr-cps-02

From: Stephen Kent <[email-masked]>
Date: Mon, 07 Oct 2013 11:44:01 -0400

Sandy,

We have updated the CPS to address your comments. Karen will post a 
revised version soon.

Responses to the questions you posed appear below.

Steve
------

Terry asked why 5.7 (key rollover and disaster recovery) was 
"[OMITTED]".Steve suggested a small paragraph.

*5.7 is Key changeover (not disaster recovery) is present and it 
contains appropriate text. As noted below, disaster recovery was 
inadvertently omitted in the CP, and will be added there. It will say 
"The CPS for each CA MUST specify procedures it will followin the event 
of compromise, and its disaster recovery plans."*

David noted that sections 5.7 and 5.8 don't match 6484.Steve said that 
6484 was in error.If I understand correctly, 6484 was supposed to omit 
section 5.7, and the section numbering was supposed
to be maintained from 3647, so 6484's 5.7 should be numbered 5.8.

*Yes, that's correct.*

Q: The CPS is an instantiation of 3647, not a re-instantiation of 6484's 
instantiation of 3647, so it
is OK if the CPS has sections from 3647 that are not present in 
6484.Correct?

*Yes, the CP and CPS are both supposed to be based on 3647, so we need 
to issue an erratum for the CP (6484) to fix the numbering error.
*

I agree with Steve that the change to 6484 should just be an errata 
(section numbering typo, not a substantive change) rather than an update.

*Thanks.*

I found a couple other things, while I was trying to figure that out.

Sections 9.1.2 and 9.1.3 match the section titles of 3647's 9.1.4 and 
9.1.5.I presume the CPS intended to omit 9.1.2 and 9.1.3 from 3647 and 
the sequential numbering in the draft is incorrect.

*Yes, that is correct. We'll fix the numbering. I put OMITTED for 9.1.2 
and 9.1.3 because RPKI CAs make certificates and CRLs available for free.*

I am not clear why sections 5.4.6, 5.4.7, and 5.5, which are present in 
3647 but omitted in 6484, are present here.They are tagged as OMITTED 
and have no text.Why not just leave them out as you did for other 
sections?Not a biggie, but I'm curious.

*I'm in favor of leaving them out here, to better match 6484, but I 
think Karen encountered a formatting problem that made it hard. So we 
may have to leave them in, marked as omitted. *

RFC3647 is mentioned but not referenced.

*Fixed.*

There are some "should" uses that might be supposed to be "SHOULD".   In particular I note that the text
about policy qualifiers ("It should be the same URI") looks like it is supposed to be 2119 language.   And is
that a SHOULD not a MUST?   Out of curiosity: any concerns if a CA publishes a CPS somewhere other than i
the URI of the policy qualifier and the two CPSs are different?   Confusion to the user is the only drawback
I can see.

*Changed to SHOULD for PQ, but kept "should" when used with "commensurate with" and "consistent with" phrases.
Changed should to MUST when  referring to PoP and a few other significant security references.*

I am not sure why the preface's suggestions for editing of the draft text to produce a CPS document includes
deleting the normative references.    The CPS text that would be retained includes references to 6484, 6485 and
6487, and there is use of 2119 language.   Those are all in the normative references section and would be deleted.  

*Changed to say that only 2119 is to be omitted.*

Another of those suggested edits is to delete the Disclaimer of Validity section.   But there is no section
by that name.   It also suggests deleting the section Intellectual Property Statement.   There is no section
of that exact name, but there is a section titled "9.5. Intellectual property rights" but I do not believe
that you mean for the user to delete that section.

*The offending text has been removed.*

2.1 says     

         <Insert SIDR-designated protocol name here> at <insert URL here>. The "SIDR" part is not a
         permanent reference, so likely to produce comment.   "IETF-designated"??  

*Changed "SIDR" to "IETF."*

I noticed that section 4.4.3 was added between -01 and -02.   I figure that's (partly) because it is a MUST in 6484.   
That got me to looking at the MUSTs/SHOULDs of 6484.<note: I did check all the SHOULDs in 6484, but I haven't
checked all the MUSTs.   There are more than 100!>  

*yeah, it's a security doc, so we're pretty judgmental!*  

2.3 says

         you still need to provide this information for relying parties. This  should include the period
         of time within which a certificate will be  published after the CA issues the certificate,
         and the period of time  within which a CA will publish a CRL with an entry for a revoked     
         certificate, after the CA revokes that certificate.>

2.3 of 6484 says the CA "MUST" specify these timeframes in the CPS.

*I changed this to a MUST when I checked all the SHOULDs.*

3.1.2 of 6484 says that the CA SHOULD NOT use meaningful names, which leaves the CA some leeway.   
3.1.2 in the CPS draft says "The name of the subscriber will not be "meaningful" ", which is less flexible.   
OK, so this is a template that the CAs can modify, and that language is helpful to the desired outcome that
the subject names are meaningless.   

*I've changed it to more closely match 6484.*

3.1.3 says

         "Although Subject names in certificates issued by this Organization need not be meaningful,"
which is inconsistent with 3.1.2.   And 3.1.5 says "Because the Subject names are not intended to be meaningful".   
So is it "will not be meaningful" or "need not be meaningful"?

*changed to "SHOULD NOT be meaningful." Could make this an erratum for 6484 if we want.*

  4.7.1 of 6484 says     

         Note that if a certificate is revoked to replace the RFC 3779  extensions, the replacement
         certificate MUST incorporate the same public key rather than a new key.

4.7.1 of the CPS draft add's a "unless" clause:     

         If a certificate is revoked to replace the RFC 3779 extensions, the  replacement certificate
         will incorporate the same public key, not a   new key, unless the subscriber requests a re-key
         at the same time.

Does the "unless" clause make the CPS in violation of 6484?

  *I think we didn't anticipate the possibility of a rekey occurring at the same time as a 3779 extension change,
when we wrote 6484, but we thought about it while revising the CPS. I've removed the clause, ignoring the
possible conflation of two actions in the CPS, to maintain consistency with the CP.*

6.3.2 of 6484 says     

         case, the validity period for certificates MUST be chosen by the  issuing CA and described in its CPS.  

6.3.2 of the CPS draft says     

         The <Name of Organization> CA's key pair will have a validity  interval of <insert number of years>.
         <These key pairs and certificates should have reasonably long validity intervals, e.g., 10   years,
         to minimize the disruption caused by key changeover.>

which sounds like it does not describe the validity period of the certs it issues, but rather
its own cert (which according to 6484 is under the control of the CA's parent)

*To clarify this text I added the following, inside the angle brackets:*

*         Note that the CA's key lifetime is under the control of it's issuer,*

*         so the CPS MUST reflect the key lifetime imposed by the issuer.*

9 of the CPS drafts says     

         <The sections below are optional. Fill them in as appropriate for  your organization.

The CP says that CAs should cover 9.1 to 9.11 and 9.13 to 9.17 although not every CA will choose to do so.
but there's no 9.17 in the outline that follows.   Oversight?   Dear God, Sandy, just how anal can you be?

*Changed the text to say 9.16.*

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Oct 2013 21:20:30 +0100

Hi Stephen,

On 07/10/2013 16:44, Stephen Kent wrote:
> 3.1.2 of 6484 says that the CA SHOULD NOT use meaningful names, which 
> leaves the CA some leeway.3.1.2 in the CPS draft says "The name of the 
> subscriber will not be "meaningful" ", which is less flexible.OK, so 
> this is a template that the CAs can modify, and that language is 
> helpful to the desired outcome that the subject names are meaningless.
I don't think there is any compliance statement here (how are you going 
to test for compliance?). So I think you should use "is not meaningful" 
instead.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 09 Oct 2013 16:39:13 -0400

Alexey,

>> leaves the CA some leeway.3.1.2 in the CPS draft says "The name of 
>> the subscriber will not be "meaningful" ", which is less flexible.OK, 
>> so this is a template that the CAs can modify, and that language is 
> I don't think there is any compliance statement here (how are you 
> going to test for compliance?). So I think you should use "is not 
> meaningful" instead.
>
Good point. It would be easy to find examples that clearly violated this 
direction, but there
could be a lot of "gray" area cases!

Steve