[caops-wg] Grid Certificate Profile version 0.20

[David Groep]

Dear all,

Following the discussion today at OGF19 on the Grid Certificate Profile
document, and with the valuable comments from Mike Jones addressed inasfar
we had not done that already during the meeting, a new version of
the GCP is now available on gridforge:

   https://forge.gridforum.org/sf/go/doc13741 (PDF version)
   https://forge.gridforum.org/sf/go/doc13742 (MS Word version)


The biggest change is probably in the abstract. The original abstract was
very unclear, so I've rewritten it quite a bit to hopefully better convey
the message. The new version reads:

"
Interoperability for X.509 identity certificates between issuers of those 
certificates and the software that interprets the certificates has become 
increasingly important with the growth of the global grid community. As the 
number of participants in grids that rely on a X.509 certificates grows, it is 
increasingly more difficult to predict which software will be used by the 
parties relying on the certificate, and how this software will interpret 
specific name forms, extensions and attributes. To ensure the certificate is 
interpreted by the relying party in the way the issuer intended it, better 
specifications and in some cases explicit restrictions on the use of name forms 
and certificate extensions is needed in order to ensure continued 
interoperability. This document provides guidance for the content of issuer and 
end-entity X.509 certificates for use with grid software.
"

For the rest, it is mostly minor changes as we discussed live today.

Please have a final look at this document, so that the Chairs can push this
document to WG final call RealSoonNow(TM).

	Thanks for all the comments!
	DavidG.



Original comments from Mike:
-------------------------------------------------------

Globally:
1, Suggest changing URL to URI throughout (and using scheme=http/https if
    necessary).
2, Suggest adding the OID as a subtitle to the relevant section


Abstract
--------

1a, The abstract confused me slightly (I had to read it a few times to try and 
get the intended meaning).

Suggest a content change from "As the number of participants in the grid that 
use certificates grows, the relationship between the issuers and relying parties 
becomes weaker.", to "As the number of participants in a grid that use 
certificates grow, the ability of a Certificate Authority to maintain an adequet 
trust relation with its relying parties becomes more difficult." -- and perhaps 
add -- "Therefore the assertions may need to become looser to reflect weaknesses 
in larger scale environments."

1b,  Otherwise can I suggest: "in the grid" -> "in a grid", "certificate grows," 
-> "certificates grow"

2, Of the relying parties refered to, are these the services who rely upon the 
CA to identify EECs, the users and servers to whome certificates are issued or 
both: do they both get weaker?

2, Typo: "come cases" -> "some cases"


1. Scope of this document
-------------------------

1, Suggest you delete ", unless explicitly stated otherwise in this document" -- 
I think it's unecessary.


2.2 Serial Number
-----------------

1, Suggest you qualify the statememt "The serial number of each CA certificate 
SHOULD be unique" to explicitely say that a CA's S/N is to be unique for each 
instance of a certificate created to represent the CA. e.g. "The serial number 
of each CA certificate SHOULD be unique among all certificates representing that CA.

2, In the footnote: suggest you change "the import of" to "the process of 
importing" -- the import of sounds like "the importance of".

3, In the footnote: change "certificate in Microsoft E" to certificate into 
Microsoft E"

2.3 Issuer and Subject names
----------------------------

1, Typo: "supported by the all of the current software", delete the first "the".

2, "all known grid-middleware" is subjective. And I don't think UNICORE uses the 
DN for identity purposes rather the whole X.509 certificate (I may be wrong).

3, Footnote2.  Why is FreeRadius mentioned?  It seems out of place to mention 
one software and not list the others.

2.3.1 serialNumber
------------------

1, Do you want to explicitely forbid serialNumber rather that recommend not 
using it?

2, Footnote3. discussion -> discussions


2.3.2 emailAddress
------------------

1, emailAddress has been deprecated not obsoleted.


2.2.3 userID of uid
-------------------
uid is also described in oid 2.5.4.45 (uniqueIdentifier) which openssl regards 
as UID:

from crypto/objects/objects.h
#define SN_uniqueIdentifier             "UID"
#define LN_uniqueIdentifier             "uniqueIdentifier"
#define NID_uniqueIdentifier            102
#define OBJ_uniqueIdentifier            OBJ_X509,45L

and from crypto/objects/obj_mac.h
0x55,0x04,0x2D,                          /* [544] OBJ_uniqueIdentifier */


2.4.5 cRLDistributionPoints
---------------------------

Need a CRL distribution point be included in an EEC whose CA falls within the 
catagory of the SLCS profile?

footnote13, https downloads do not have to pass any verification. Therefore 
bootstrap problems need not occur.

2.4.6 Authority and Subject Key Identifier
------------------------------------------

1, change "the authorityKeyIdentifier and subjectKeyIdentifier MUST be the same" 
to "the subjectKeyIdentifier and authorityKeyIdentifier's subjectKeyIdentifier 
MUST be the same".


3.2 Subject distinguished names
-------------------------------

1, change "Other RDN attribute types" to "RDN attribute types other"


3.2.2 PrintableString encoding recommendations
----------------------------------------------

footnote 17 kind of conrtadicet footnote 19.


3.2.6 userID or uid
-------------------

"i.e." should contian 2.5.4.45 as well


3.2.7 domainComponent...
---------------------

1, Why need DC ever be encoded as IA5string when DNS only allows [a-z0-9_.-]?

2, should the last word be RECOMENDED rather than encouraged?


3.3.13 authorityInformationAccess
---------------------------------

1, change authoirtyInfoAccess to authorityInformationAccess as per heading.


4.3 Maximum key lengths
-----------------------

Does the action for 2007 in this section need to be done now?


----------------------------------------------------------

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