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

From: "Murphy, Sandra" <[email-masked]>
Date: Wed, 18 Sep 2013 19:40:38 +0000

Some things came up as I reviewed the comments received during wglc.  Most of these are nits, but a few are substantive.

The most substantial of the things that came up are about 2119 language and the preface's suggestions for eliminating references.

A long message with a lot of detail, sorry.

These have been previously shared with the authors.

--Sandy, speaking as wg co-chair

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

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.

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?

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.

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.

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.

RFC3647 is mentioned but not referenced.

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 in the URI of the policy qualifier and the two CPSs are different?  Confusion to the user is the only drawback I can see.

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.

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.

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"??

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

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.

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 not 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.  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 (not intended to be) meaningful"?

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?

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 the validity period of its own cert (which according to 6484 is under the control of the CA's parent)

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?