Hi Mike, all, Mike Helm wrote:

Thanks for making such an excellent document; I have many small comments & few fairly important ones perhaps.

http://www.lbl.gov/~mike/draft-ggf-certificate-profile-v0_14-mwh.doc

Thanks for the comments! I'll merge the changes and look through the comments to see if I (or anyone else) can improve the text.

I am not sure about those footnotes, is your intention to work on them & incorporate them into the text body, delete them completely, or leave them as-is?

The previous versions has all the explanatory and background text (which is is now in the footnotes in v0.14) interspersed throughout the main text. That was considered confusing, having normative text and annotated ideas in teh same text flow. So the idea was to put all the explanations in footnotes, but in a prominent (same sized) font so that this information and the rationale for the normative text is preserved. So the idea now is to keep the footnotes also in the final version, and add our experience in there.

It seems clear that one of the constraints operating on us is the need to chase various string matching & manipulating habits and features of the grid middleware. I think this should be stated in the first section, so the reader can get this idea as soon as possible.

I don't really get the first paragraph of section 1 either. Is that really true & do we need to say it?

Agreed to both, and the generic first paragraph can indeed just be removed. Will to that in the next version. Thanks a lot! DavidG. -- David Groep ** National Institute for Nuclear and High Energy Physics, PDP/Grid group ** ** Room: H1.56 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL **

Mike Helm wrote:

Thanks for making such an excellent document; I have many small comments & few fairly important ones perhaps.

http://www.lbl.gov/~mike/draft-ggf-certificate-profile-v0_14-mwh.doc

The new document v0.15 is now in GridForge and the extended changelog is below. https://forge.gridforum.org/sf/go/doc13741 (PDF version) https://forge.gridforum.org/sf/go/doc13742 (DOC version) Thanks for the improvements, and waiting for more comments and experience! Regards, DavidG. -------- Grid Certificate Profile document – change log for version 0.15 2006.11.01 DG Comment from mail: do we need the first paragraph of section 1? The first paragraph has been silently dropped. Comment H1: “A couple fun things missing: name constraints, pathlen” I feel that by including such potentially fun elements in the main body of the text, we will have to add many more extensions and attributes whose use up to now has been infrequent. Instead, I propose we add to the general introduction the following text (now in v0.15): “If a particular extension or attribute is not discussed in this document, this should not be construed as to mean the extension or attribute is either useful or harmless; it means that at the time of writing it was not in widespread use, and was therefore not needed for interoperability. It may or may not be harmless and may of may not cause interoperability problems. It is recommended that specific interoperability testing is performed prior to including any such extensions or attributes.” and then leave these extensions out unless Scott has provide us with some experience that we can include here (which would of course be very welcome!). I did add the text on pathLenConstraint in basicConstraints section, though. Comment H2: “It occurs to me that the motivator for a lot of this is the need to support string renderings for the basis of grid middleware and other consumers. This should be emphasized as goal elsewhere probably in section 1 for instance.” Added this paragraph to section 1: “Specific attention has been given to the representation of the subject and issuer distinguished names as strings, since in much of the grid software it is this string rendering, and not the actual sequence of relative distinguished names, which is used for identification and subsequent authorization purposes. This imposes specific additional constraints on such names, and on the set of attributes which can be used in these names, to ensure wide interoperability of the certificates.” and removed the explanation sentence at the point of comment H2. Comment H3: a commonName SHOULD be included: “What’s the basis for this should?” This is a duplicate from section 2.3.5, where it is a should to allow recognition of the CA in the typical browser list (which uses the CN as the display name). I removed this entire sentence here, as it’s superfluous. Also dropped the reference to the examples section, as it was used inconsistently. Comment H4: basicConstraints pathlength: “Need pathlength recommendation. It used to be necessary to set pathlen=0 in the entire chain, to prevent problems with proxy certs. I don’t know if this has been addressed fully by the proxy cert IETF draft or by the scope of implementations which may support older forms of proxy certs.” Since there are still old-style Globus proxies out there, and software that parses them, I thing we should add the requirement here that pathLenConstraint MUST be absent or set to 0. I did the same for end-entity certs, comments welcome on that! Comment H5: inclusion of cRLSign in the keyUsage should be a MUST due to software limitations described in footnote 8. There is also the case of a CA that will never issue CRLs – some SLCS CAs provide the example for that. In that case the CA will not sign a CRL and this bit need not be set. I’ve added some text in the footnote for this. Comment in footnote 10 on certificatePolicies.userNotice.explicitText I’ve checked with the complainers again, and I was mistaken: the piece of software I referred to (VOMS-Admin version 1.x) cannot handle CPS comments and reason codes, and takes them to either be part of something else entirely, or just messes up the database. This is being addressed in the software, AFAIK. Remove the caution text in the comment. Comment H6 on the dash-wildcard design flaw I dropped the “This might be considered” sentence, but I think we should keep the text in to alert people to this issue. There is indeed not that much one can do about it, as using dashed in hostnames is normal common practice when you have large series host with identical roles… Hopefully this flaw will get fixed, as some point in the future. Comments H7 and H8: on the extensions and the MUST/SHOULD/RECOMMENDED wording Most of the extensions we want indeed by policy. I’ve rewritten the entire paragraph to better reflect this, making some of these RECOMMENDED and some even MAY with some qualifier. I think RECOMMENDED is the proper way of putting it, since we still want some guidance for new people and not have them omit these useful extensions. For certs that need an email address, the subjectAltName SHOULD be used with rfc822Name, since we earlier said that emailAddress SHOULD NOT be part of the subject DN. It now reads: For use of an end-entity certificate certificate with grid software, at least either of the extendedKeyUsage or nsCertType extensions MUST be present, where the use of the extendedKeyUsage extension is preferred. Including basicConstraints is RECOMMENDED. For end-entity certificates issued to networked entities (servers or services), the use of the subjectAltName extensions with a dNSName attribute is RECOMMENDED. For end-entity certificates that include an rfc822 email address, the subjectAltName extension SHOULD be used, and the email address included in the rfc822Name attribute. It is RECOMMENDED that an end-entity certificate includes also the extensions keyUsage, certificatePolicies, and cRLDistributionPoints. There is no a priori requirement by grid software for any other extension in end entity certificates. Comment H9: on nonRepudiation The current text is already kind-of discouraging. If there is a CA operating in a way, and in a jurisdiction that support nonRepudiation, its use is probably justifiable, and it does not harm out operations. I propose to leave the text as-is – it’s pretty scary already for new CAs. Comment H10: on keyCertSign and cRLSign in EE certs Yes we are stating the obvious, and it’s a duplication of RFC3280, but with these two we have the entire set of values complete. So for completeness sake I would leave them here – but have no really strong objection to dropping them either… Comment H11: on CRL download URL and HTTP answers It’s similar guandance text that ended up in the footnotes everywhere else. So I moved it to a footnote here as well, and retained a single line in the text body: It is RECOMMENDED that the reply returned at the http URL is cacheable . And put the rest in footnote 39. And of course we still need the activity … Comment H12/H14: subjectKeyIdentifier and certificatePolicies MUST?? not be critical I’ve seen no harm come from a sKI, but does all software actually parse it? I’m not sure that by making it critical we will not break things. But otherwise we can limit ourselved to say that this extension is harmless. Any other reason why we would want it in an EE cert? Changed to SHOULD NOT since we do not know in both cases Comment H13: certificatePolicy additional attributes I got confused here with some someware bugs for a different extension (CDP). Removed this text entirely. Comment H15: critical subjectAltName It need not be critical since we already banned empty subject DNs, but it’s confusing text so I removed it entirely. Now there is no guidance on critical or not, and people can just look at RFC3280 and decide the proper way. Comment H16: on co-setting of organization and noticeNumbersin certPolicies This was taken from implementation guidance in OpenSSL. So it is or was likely an OpenSSL implementation limitation. But since we do no longer need specific guidance on explicitText, this entire paragraph can be dropped without harm to the document – which is what I did in v0.15. Other comments incorporated Added Jens’s text on the importance of a critical keyUsage in CA certs. -- David Groep ** National Institute for Nuclear and High Energy Physics, PDP/Grid group ** ** Room: H1.56 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL **