Hi David and the CAOps group, I'd like to suggest that we think collectively about the considerations that have led us to put forward the very useful and by now quite mature CAOPs document GFD.125 as a "COmmunity Practice" document and not as a proposed recommendation. I understand that historically, there was some thought that this profile might not represent a collection of items that ought to be standardized, but I think that experience has shown most of its content to be important, if not essential. With this in mind, I'd like to raise the issue of whether this quite mature document, or another one quite close to it in intent, might be worth putting forward into the stream as a proposed recommendation. To go from a proposed to a full recommendation would take the passage of some time and demonstration of multiple implementations; I am willing to consider the multiple adoptions of GFD.125 by CAs throughout the world as implementations for this purpose. There may be other points of view, but now is the time to discuss them, I think, and so would like to ask for your input. Thanks, Alan
I can't remember what was agreed in Salt Lake City regarding comments for GFD.125. That said: The emailAddress vs Email issue has just lit up again on a UK mailing list. Do we have the opportunity for, and should we consider, strengthening the SHOULD NOT use emailaddress in subject names to a MUST NOT? It's still "deprecated but permitted" in the replacement of RFC3280 by RFC5280. Mike On Monday 31 January 2011 08:01:05 Alan Sill wrote:
Hi David and the CAOps group,
I'd like to suggest that we think collectively about the considerations that have led us to put forward the very useful and by now quite mature CAOPs document GFD.125 as a "COmmunity Practice" document and not as a proposed recommendation. I understand that historically, there was some thought that this profile might not represent a collection of items that ought to be standardized, but I think that experience has shown most of its content to be important, if not essential.
With this in mind, I'd like to raise the issue of whether this quite mature document, or another one quite close to it in intent, might be worth putting forward into the stream as a proposed recommendation. To go from a proposed to a full recommendation would take the passage of some time and demonstration of multiple implementations; I am willing to consider the multiple adoptions of GFD.125 by CAs throughout the world as implementations for this purpose.
There may be other points of view, but now is the time to discuss them, I think, and so would like to ask for your input.
Thanks, Alan -- caops-wg mailing list caops-wg@ogf.org http://www.ogf.org/mailman/listinfo/caops-wg
Hi Mike,
I think the consensus was that there should not be substantial changes
to the document because it would then need to start a long review
process again. OTOH, I would think a few minor changes should be OK,
provided we add a little changelog at the end. (From SHOULD to MUST is
not a big step...?)
I guess what you're really asking is could the UK CA please take email
out of hosts - which of course we have had for a long time only
because doggedly stick to the policy of not changing EE DNs, so we're
stuck with what was OK in 2001. Once I find a mail to optionally
remove it in rekey - or of course optionally keep it in rekey - I'll
let you know. In fact I have a student working on the bulk host stuff
at the moment and he's a pretty smart egg so he should be able to get
round to this shortly.
0.02.
-j
On 5 August 2011 15:16, Mike Jones
I can't remember what was agreed in Salt Lake City regarding comments for GFD.125.
That said: The emailAddress vs Email issue has just lit up again on a UK mailing list.
Do we have the opportunity for, and should we consider, strengthening the SHOULD NOT use emailaddress in subject names to a MUST NOT?
It's still "deprecated but permitted" in the replacement of RFC3280 by RFC5280.
Mike
On Monday 31 January 2011 08:01:05 Alan Sill wrote:
Hi David and the CAOps group,
I'd like to suggest that we think collectively about the considerations
that have led us to put forward the very useful and by now quite mature
CAOPs document GFD.125 as a "COmmunity Practice" document and not as a
proposed recommendation. I understand that historically, there was some
thought that this profile might not represent a collection of items that
ought to be standardized, but I think that experience has shown most of
its content to be important, if not essential.
With this in mind, I'd like to raise the issue of whether this quite mature
document, or another one quite close to it in intent, might be worth
putting forward into the stream as a proposed recommendation. To go from
a proposed to a full recommendation would take the passage of some time
and demonstration of multiple implementations; I am willing to consider
the multiple adoptions of GFD.125 by CAs throughout the world as
implementations for this purpose.
There may be other points of view, but now is the time to discuss them, I
think, and so would like to ask for your input.
Thanks,
Alan
--
caops-wg mailing list
caops-wg@ogf.org
-- caops-wg mailing list caops-wg@ogf.org http://www.ogf.org/mailman/listinfo/caops-wg
Hi Mike Jens, On 2011-08-05 16:40, Jens Jensen wrote:
I think the consensus was that there should not be substantial changes to the document because it would then need to start a long review process again.
That's what I remember as well ...
OTOH, I would think a few minor changes should be OK, provided we add a little changelog at the end. (From SHOULD to MUST is not a big step...?)
Apart from the fact that this attribute is most harmful for EECs (and not for issuer DNs), I think that in general a "SHOULD" -> "MUST" change *is* a significant change, given the way RFC2119 interprets these. And, yes, emailAddress is very, very annoying in subject DNs, but there /are/ ways around it (listing each user twice in all lists that are string-representation based), and as such a MUST may not be warranted. Also: there is a derived implication of changing to "MUST". Since for the IGTF the Authentication Profiles reference this requirement, it imples that all accredited have to comply within 6 months (as per the accreditation guidelines for the EUGridPMA at least). This puts a very strict requirement on the CAs where there is no current operational show-stopper. Should that be the side-effect or result of transitioning GFD.125 from GFD.I to P-REC? I would save this change for a next iteration ... Cheers, DavidG.
I guess what you're really asking is could the UK CA please take email out of hosts - which of course we have had for a long time only because doggedly stick to the policy of not changing EE DNs, so we're stuck with what was OK in 2001. Once I find a mail to optionally remove it in rekey - or of course optionally keep it in rekey - I'll let you know. In fact I have a student working on the bulk host stuff at the moment and he's a pretty smart egg so he should be able to get round to this shortly.
0.02. -j
On 5 August 2011 15:16, Mike Jones
wrote: I can't remember what was agreed in Salt Lake City regarding comments for GFD.125.
That said: The emailAddress vs Email issue has just lit up again on a UK mailing list.
Do we have the opportunity for, and should we consider, strengthening the SHOULD NOT use emailaddress in subject names to a MUST NOT?
It's still "deprecated but permitted" in the replacement of RFC3280 by RFC5280.
Mike
On Monday 31 January 2011 08:01:05 Alan Sill wrote:
Hi David and the CAOps group,
I'd like to suggest that we think collectively about the considerations
that have led us to put forward the very useful and by now quite mature
CAOPs document GFD.125 as a "COmmunity Practice" document and not as a
proposed recommendation. I understand that historically, there was some
thought that this profile might not represent a collection of items that
ought to be standardized, but I think that experience has shown most of
its content to be important, if not essential.
With this in mind, I'd like to raise the issue of whether this quite mature
document, or another one quite close to it in intent, might be worth
putting forward into the stream as a proposed recommendation. To go from
a proposed to a full recommendation would take the passage of some time
and demonstration of multiple implementations; I am willing to consider
the multiple adoptions of GFD.125 by CAs throughout the world as
implementations for this purpose.
There may be other points of view, but now is the time to discuss them, I
think, and so would like to ask for your input.
Thanks,
Alan
--
caops-wg mailing list
caops-wg@ogf.org
-- caops-wg mailing list caops-wg@ogf.org http://www.ogf.org/mailman/listinfo/caops-wg
-- caops-wg mailing list caops-wg@ogf.org http://www.ogf.org/mailman/listinfo/caops-wg
-- David Groep ** Nikhef, Dutch National Institute for Sub-atomic Physics,PDP/Grid group ** ** Room: H1.50 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL **
participants (4)
-
Alan Sill
-
David Groep
-
Jens Jensen
-
Mike Jones