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.*
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
