[igtf-general] Re: [caops-wg] Certificate Profile document, update v0.5

[David Groep]

Hi Jens,

Jensen, J (Jens) wrote:
> David, I have now finally had time to go through the document
> and made only a few changes.  And fixed a few bugs, like commonName
> cannot use IA5String as encoding.  I used Word's change tracker.
> 
> http://www.grid-support.ac.uk/files/eugridpma-certprofile-20060814-0-6-jens.doc

Thanks for the update. I've merged all changed in the new version 0.7,
on the web at
   http://www.eugridpma.org/temporary/
in both formats.

> What would be the consequences of saying in 4.1 "RDNs MUST be
> in the Right Order".  Will we lose SWITCH and Purdue?

I've added a lot of new text in this section, to explain that it
SHOULD NOT be used but MAY be ok for intermediate CAs to have the
'reverse' ordering (i.e. issuing no more than 2 trusted subordinates),
but is MUST be in the correct order for end-entity certificates.

This accommodates the SWITCH EE issuing CAs, that have reversed the
ordering last year (although it took SwissSign some time to implement
these changes).

Other options are not supportable by Globus, as the wild card matching
is done at the end of the string only. So, just like SwissSign did for
SWITCH, I think the Purdue CA will have to re-order the components as well
to get the signing_policy file to work.

> Would it be worth expanding section 5 into a general annotated
> openssl.cnf?  If new CAs feel this would be useful, I will be
> happy to provide something (if so, please reply to me).

I seems like #5 is getting larger and larger, but I'm not sure
we want the OpenSSL config to be in this document, though. The
software is quite volatile, with options appearing and disappearing
all the time, so maybe we should move some of existing stuff that is just
too openssl specific out of this doc, and on to a Wiki.

> The document has also gradually started to describe how software
> deals with certificates - browsers, OpenLDAP, etc.  This could
> be expanded.

Indeed. But there is something to be said as well for getting
the basic guidance out for new CAs on a relatively short time scale.
OpenLDAP got included there since UNICORE (and also other services used
in DEISA) depend on it & browsers since they are needed to register to a VO
in many grids.
If we can get the issues with at least the current software needed for grid
operations in there, we should do it (GT, UNICORE, BouncyCastle, OpenSSL,
Sun's JCE, OpenLDAP, VOMS (-Admin) & VOMRS, ...)

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