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 **
In developing standards it is sometimes useful to keep track of
progress in implementation. In this light it may be interesting to
note that the most recent experimental branch of the GNU TLS library,
which runs on most Unix platforms as well as on Windows and provides
support for TLS 1.0, TLS 1.1 and SSL 3.0 and authentication using
both X.509 certificates and OpenPGP keys and certificates, now also
includes support for RFC 3820 proxy certificates (as well as TLS 1.2):
http://www.gnu.org/software/gnutls/
Alan
Alan Sill, Ph.D
TIGRE Senior Scientist, High Performance Computing Center
Adjunct Professor of Physics
TTU
====================================================================
: Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 :
: e-mail: Alan.Sill(a)ttu.edu ph. 806-742-4350 fax 806-742-4358 :
====================================================================
It's already the night before the week of, and we haven't formed an
actual draft agenda yet! Well.
Let's try something a bit different this time. The following is up on
the CAOPS-WG wiki, feel free to add ideas, your name next to things to
do :-), etc.
http://forge.gridforum.org/sf/wiki/do/viewPage/projects.caops-wg/wiki/HomeP…
CAOPS-WG (Document Session)
Thursday 11:00 am - 12:30 pm (Windflower Room)
* Status of existing documents (5' Darcy)
* OCSP document ??
* CA Auditing ??
* RA Aditing (15' Matthew Viljoen)
* Certificate Contents ??
* Any other bright ideas ??
Let's form the agenda on the wiki and through discussion on the mailing
list, otherwise this is going to be a short session. I think it's set
up so that any one who's a member of the CAOPS-WG group can edit the
wiki. Let's see.
Darcy
