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