Operations » Editor » Public Comments » Public Comments Archive

• I find the ragged right layout awkward to read (or even a bit slap-dash) compared to the justified footnotes, but that is probably a personal preference.
• rfc 822 is mentioned a lot. It was obsoleted by rfc2822, which in turn was obsoleted by RFC 522
• Extensions tables. I believe there is some lack of clarity in these (e.g. in 2.4) for the following reasons:
  1. The top section (Required) has values on separate lines, they should be merged like the other sections, or at least the separating line removed
  if it is important for them to be on separate lines.
  2. There isn't always a good match between the table category and the text below. I am assuming that "Required" => MUST, "Advised to use" => SHOULD,
  "Optional" => "MAY" and "Not to be used" => "MUST NOT", but this isn't always the case. In particular some of the "Not to be used" is "SHOULD NOT".
  (e.g. 2.4.3 extendedKeyUsage)
• "a priori" -> use italics for latin
• When we talk about extensions being critical or not, should we use italics for "critical"?

• "this should not be construed as to mean the extension or attribute is either useful or harmless"
  I'd change "to mean" to "meaning".
  Also each time I read it my brain tells me that it should say "useless" rather than "useful" - maybe it just sounds wrong juxtaposing
  a positive with a negative like that.

• The information on message digests appears under "Serial Number", maybe it should have its own subsection or be included under "General Provisions". In Section 3, MDs and SNs are described under this latter section.
• 2.3 SETs are mentioned - I can't see a definition of this term before this point. I can see from the appendix that is part of the structure of an ASN.1 SEQUENCE, but maybe something is needed before this point.
• Footnote 1: "for example in case only the lifetime is extended" -> "for example in the case that the lifetime is extended" [meaning changes subtly from that of an unexpected occurrence to a potentially expected one]
• In this same footnote IE7 is mentioned a few times - if we are re-issuing the document, should we not show we have tried with later versions of IE?
• Footnote 2: "Note that modern hashes, such as SHA-256, are supported in recent versions of the majority of software, such as OpenSSL in use, so SHA-1 is no longer the only available value as of time of writing." -> Sentence is clumsy, maybe move comma from after "in use" to before. Basically there are too many commas so it is hard to see what is parenthesised and what isn't.
• 2.3.1 "the CA the CN" -> "the CA. The CN"
• 2.3.3 "serialNumber {2.5.4.5}" - there is no description of what the numbers in curly braces represent; the other components don't have this designation in this section.
• 2.3.4 "depricated" -> "deprecated"
• 2.3.4 Might it be better just to say emailAddress MUST NOT be used for CA certificates
• AuthorityInfoAccess -> authorityInfoAccess (for consistency)
• 2.4.3 "It MUST NOT be marked critical" -> "If present, it MUST NOT be marked critical"
• Footnote 9 "life time" -> "lifetime"
• Footnote 9 - no definition/description of what an "indirect CRL" is, likewise for OCSP - maybe a link is needed.
• "There is also no direct way to create such an end-entity certificate in the many CA products" -> "... in many CA products"
• Footnote 14 "If adding explicit text to the certificate, such as was possible using the nsComment extension, is desired, the new attribute ..." ->
  "If adding explicit text to the certificate is desired, as was possible using the nsComment extension, then the appropriate attribute ..."
• 2.4.6 "The certificatePolicies extension may be set" -> "... MAY be set"
• 2.4.7 "The cRLDistributionPoints extension need not be in a self-signed root CA certificate" - I suggest changing "need not be" to use terms like "MAY" or "SHOULD"
• 2.4.8 "A subjectKeyIdentifier extension MUST be included in CA certificates to aid in validation path construction and
  an authorityKeyIdentifier MUST be included in all CA certificates, unless the certificate is self-signed."
  The problem here is that it isn't obvious what the scope is of the final "unless the certificate is self-signed" - is it whole sentence, or only the bit
  after the "and".
• Footnote 19: "should" -> "SHOULD"?
• 3.1 "by the same issuer" - it isn't clear from this what "same" means. Consider re-signed/extended certificates, re-keyed certificates, an offline and
  an online CA signing in the same namespace. There are many possibilities. Does it mean "by the same issuer (i.e. with the same DN)"

[truncated - I have more comments on section 3 which I'll add later]

JK