[caops-wg] Certificate Profile document updated (to v0.14)

[David Groep]

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