Hi all, Paul Millar raised an issue about DNs. The schema has two attributes, IssuerCA and TrustedCA, with type DN_t, defined as: "Distinguished Name as defined by RFC 4514 (http://www.rfc-editor.org/rfc/rfc4514.txt). X.509 uses a X.500 namespace, represented as several Relative Domain-Names (RDNs) concatenated by forward-slashes. The final RDN is usually a single common name (CN), although multiple CNs are allowed." What I expect is the usual globus/openssl-style format like /C=UK/O=eScienceCA/OU=Authority/CN=UK e-Science CA 2B and that is indeed what's being published in EGI. The text of the definition above agrees with that. However, RFC 4514 is in fact the definition of LDAP DNs, which of course look like GLUE2DomainID=UKI-SOUTHGRID-BHAM-HEP,GLUE2GroupID=grid,o=glue i.e. comma-delimited and in the reverse order. The reference to RFC 4514 looks like a mistake to me - any thoughts? Stephen -- Scanned by iCritical.
Hi all,
Paul Millar raised an issue about DNs. The schema has two attributes, IssuerCA and TrustedCA, with type DN_t, defined as:
"Distinguished Name as defined by RFC 4514 (http://www.rfc-editor.org/rfc/rfc4514.txt). X.509 uses a X.500 namespace, represented as several Relative Domain-Names (RDNs) concatenated by forward-slashes. The final RDN is usually a single common name (CN), although multiple CNs are allowed."
What I expect is the usual globus/openssl-style format like
/C=UK/O=eScienceCA/OU=Authority/CN=UK e-Science CA 2B
and that is indeed what's being published in EGI. The text of the definition above agrees with that. However, RFC 4514 is in fact the definition of LDAP DNs, which of course look like
GLUE2DomainID=UKI-SOUTHGRID-BHAM-HEP,GLUE2GroupID=grid,o=glue
i.e. comma-delimited and in the reverse order. The reference to RFC 4514 looks like a mistake to me - any thoughts?
A mistake indeed. What would be the correct RFC?
Hi all, I submitted a request to some people doing security development, and it turs out that the forward slash notation is only openssl notation. I am googling here and there but the forward slash notation does not seems to exist in any RFC. I really wonder why openssl guys went that way, then... I asked for a openssl reference document. Maybe we can find more pointers there. Well, this in kinda embarassing now, me myself I never went through the RFC to actually check it was as defined on page 71 of GFD147 (*blush*) Cheers, Florido On 2013-01-31 11:13, Maarten Litmaath wrote:
Hi all,
Paul Millar raised an issue about DNs. The schema has two attributes, IssuerCA and TrustedCA, with type DN_t, defined as:
"Distinguished Name as defined by RFC 4514 (http://www.rfc-editor.org/rfc/rfc4514.txt). X.509 uses a X.500 namespace, represented as several Relative Domain-Names (RDNs) concatenated by forward-slashes. The final RDN is usually a single common name (CN), although multiple CNs are allowed."
What I expect is the usual globus/openssl-style format like
/C=UK/O=eScienceCA/OU=Authority/CN=UK e-Science CA 2B
and that is indeed what's being published in EGI. The text of the definition above agrees with that. However, RFC 4514 is in fact the definition of LDAP DNs, which of course look like
GLUE2DomainID=UKI-SOUTHGRID-BHAM-HEP,GLUE2GroupID=grid,o=glue
i.e. comma-delimited and in the reverse order. The reference to RFC 4514 looks like a mistake to me - any thoughts?
A mistake indeed. What would be the correct RFC? _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
-- Florido Paganelli Lund University - Particle Physics ARC Middleware EMI Project
Maarten Litmaath [mailto:Maarten.Litmaath@cern.ch] said:
A mistake indeed. What would be the correct RFC?
I don't think there is one, it's just a de-facto standard. E.g. see this page from NIKHEF: http://wiki.nikhef.nl/grid/How_to_handle_OpenSSL_and_not_get_hurt_background... Stephen -- Scanned by iCritical.
A security expert told me:
RFC 4514 (previously RFC 2253) defines the only standard string representation for DNs that I'm aware of. Globus adopted an old OpenSSL DN string format which maybe could be called a de-facto standard at this point, but even OpenSSL supports it only for the sake of backward compatibility:
It would appear there is no RFC. We have a choice to make on whether to change GLUE 2 to be compliant with an RFC, or keep things the way they are to be compatible with an old de-facto standard. Both option have impacts of different sorts. JP On Jan 30, 2013, at 6:20 PM, stephen.burke@stfc.ac.uk wrote:
Hi all,
Paul Millar raised an issue about DNs. The schema has two attributes, IssuerCA and TrustedCA, with type DN_t, defined as:
"Distinguished Name as defined by RFC 4514 (http://www.rfc-editor.org/rfc/rfc4514.txt). X.509 uses a X.500 namespace, represented as several Relative Domain-Names (RDNs) concatenated by forward-slashes. The final RDN is usually a single common name (CN), although multiple CNs are allowed."
What I expect is the usual globus/openssl-style format like
/C=UK/O=eScienceCA/OU=Authority/CN=UK e-Science CA 2B
and that is indeed what's being published in EGI. The text of the definition above agrees with that. However, RFC 4514 is in fact the definition of LDAP DNs, which of course look like
GLUE2DomainID=UKI-SOUTHGRID-BHAM-HEP,GLUE2GroupID=grid,o=glue
i.e. comma-delimited and in the reverse order. The reference to RFC 4514 looks like a mistake to me - any thoughts?
Stephen
-- Scanned by iCritical. _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
JP Navarro [mailto:navarro@mcs.anl.gov] said:
It would appear there is no RFC. We have a choice to make on whether to change GLUE 2 to be compliant with an RFC, or keep things the way they are to be compatible with an old de-facto standard. Both option have impacts of different sorts.
With our current middleware I think it doesn't make sense to use anything other than the openssl format in GLUE, it would mean having format converters in both directions which would be highly error-prone, there are lots of subtleties. You could argue that the entire middleware should change, but I think that would be about as likely as the UK changing to driving on the right! Stephen -- Scanned by iCritical.
Hi all, On 2013-01-31 17:55, stephen.burke@stfc.ac.uk wrote:
JP Navarro [mailto:navarro@mcs.anl.gov] said:
It would appear there is no RFC. We have a choice to make on whether to change GLUE 2 to be compliant with an RFC, or keep things the way they are to be compatible with an old de-facto standard. Both option have impacts of different sorts.
With our current middleware I think it doesn't make sense to use anything other than the openssl format in GLUE, it would mean having format converters in both directions which would be highly error-prone, there are lots of subtleties. You could argue that the entire middleware should change, but I think that would be about as likely as the UK changing to driving on the right!
Stephen
I think the same as Stephen. And to be practical, these fields are only used by middlewares to check against certificates DN written in the same format. I think for an extension we can imagine something smarter, but for the moment we should leave it like that. It's just then difficult to formally define the content of that field now.... also because of the reverse order that ldap dn impose :P Cheers, -- Florido Paganelli Lund University - Particle Physics ARC Middleware EMI Project
Hi all, On 01/31/2013 05:55 PM, stephen.burke@stfc.ac.uk wrote:
JP Navarro [mailto:navarro@mcs.anl.gov] said:
It would appear there is no RFC. We have a choice to make on whether to change GLUE 2 to be compliant with an RFC, or keep things the way they are to be compatible with an old de-facto standard. Both option have impacts of different sorts.
With our current middleware I think it doesn't make sense to use anything other than the openssl format in GLUE, it would mean having format converters in both directions which would be highly error-prone, there are lots of subtleties. You could argue that the entire middleware should change, but I think that would be about as likely as the UK changing to driving on the right!
Actually, I disagree. GLUE-2 is a standard, or is meant to be one. If it says "use this format" then that format must be defined in precise language, or we point to where it is defined. Yet here we have a problem. The OpenSSL/Globus format simple isn't defined. There's some incomplete, partial definitions out there. It has ambiguous, with the potential for different software resolving these ambiguities in different ways. The format isn't even constant, but has evolved over the lifetime of the OpenSSL library. ... and you want to base a standard on this? OK, so you do. Since there's no document, we would need to write down precisely what we mean by OpenSSL-DNs, for example as Appendix C in the document. Next we would try to insist that all software adopts our definition of a (ASCII? UTF-8?) DN representation. My bet is on the software ignoring Appendix C in favour of what the OpenSSL library happens to do (this release of the library, anyway), what Globus libraries do, what CANL does, what ... ... yup, so this also doesn't work. So, what can we do? Adopt a standardised format, say, one published as an RFC. Yes, this means that publishing DNs will be a bit of pain, but probably not *that* much of a pain, since libraries exist for representing DNs in standard formats. (That's why standards are good! ;-) That we've been doing it wrong for a long time doesn't mean it becomes right; and GLUE 2 is an excellent opportunity to fix such mistakes. As usual, just my 2c worth, Paul.
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On
Behalf Of Paul Millar said: ... and you want to base a standard on this?
Apparently we already have - essentially all the middleware uses it, including dcache as far as I remember. I don't see much point in GLUE doing something different when all it's doing is publishing strings, if everything that actually *uses* DNs for authn and authz uses the openssl format.
Adopt a standardised format, say, one published as an RFC.
An RFC for LDAP, not X509! Stephen -- Scanned by iCritical.
Hi Stephen, On 02/08/2013 06:05 PM, stephen.burke@stfc.ac.uk wrote:
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On
Behalf Of Paul Millar said: ... and you want to base a standard on this?
Apparently we already have - essentially all the middleware uses it, including dcache as far as I remember.
Up to a point; there are file formats that use OpenSSL-format for representing DNs, perhaps most notably the gridmap and signing_policy files. Software, like dCache, that supports these files must support OpenSSL-format (or, more often, use libraries that do). So the statement "all the middleware uses it" is probably correct, insofar as all middleware supports file formats (like signing_policy files) that use it. Internally, it very much depends. Support for any particular file format isn't necessarily a strong indicator that it supports that particular encoding internally. Within dCache, we're in the process of moving away from Globus-specific representations in favour of standards-based ones. Therefore it is spurious to conclude that, since all software supports particular file formats, they all use OpenSSL-format internally.
I don't see much point in GLUE doing something different when all it's doing is publishing strings, if everything that actually *uses* DNs for authn and authz uses the openssl format.
First off, and I can't emphasis this enough, it's not a standard! How does one represent a RDN value with a '/' in it? How are non-ASCII names handled (Chinese CNs, anyone)? How are RDNs with multiple AVAs handled? ... etc ... How can one write a validator for GLUE2 when so much is left unspecified. How does this foster interoperability? Second, this argument is that of vendor lock-in. For a variety of reasons, WLCG grid software currently suffers from a vendor lock-in with Globus code, which uses OpenSSL-format. Rather than use a vendor-neutral format, you advocate using a non-standard format. Yes, it's always easier to follow the path of vendor lock-in; that's why it works. Remaining neutral often involves putting in some extra effort; however, it pays off in the long run.
Adopt a standardised format, say, one published as an RFC.
An RFC for LDAP, not X509!
Note that I didn't say we keep the same RFC, rather that it must be a published standard. [aside, LDAP and X509 both use ASN.1 for encoding and have the same concept of "a DistingushedName", since they both derive from X500 service model. Using an LDAP RFC isn't *so* crazy.] I would recommend we take advice from security experts about which standard/RFC we should use when defining the representation. Cheers, Paul.
Given that standards in support of interoperability is our mission and that it takes time for infrastructures to migrate from old (de-factor) DN representations to newer standards based ones, I would recommend an approach that gives GLUE2 users and infrastructures time to migrate by discussing and choosing a new standards based representation for DNs would adopt, introducing a new and separate set of optional GLUE2 attibributes that can be used to publish standards based representations, and discussing a GLUE2 publishing policy/profile that facilitates evolution away from non-standards toward standards. That's my recommendation. JP On Feb 11, 2013, at 5:08 AM, Paul Millar <paul.millar@desy.de> wrote:
Hi Stephen,
On 02/08/2013 06:05 PM, stephen.burke@stfc.ac.uk wrote:
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On
Behalf Of Paul Millar said: ... and you want to base a standard on this?
Apparently we already have - essentially all the middleware uses it, including dcache as far as I remember.
Up to a point; there are file formats that use OpenSSL-format for representing DNs, perhaps most notably the gridmap and signing_policy files. Software, like dCache, that supports these files must support OpenSSL-format (or, more often, use libraries that do).
So the statement "all the middleware uses it" is probably correct, insofar as all middleware supports file formats (like signing_policy files) that use it.
Internally, it very much depends. Support for any particular file format isn't necessarily a strong indicator that it supports that particular encoding internally. Within dCache, we're in the process of moving away from Globus-specific representations in favour of standards-based ones.
Therefore it is spurious to conclude that, since all software supports particular file formats, they all use OpenSSL-format internally.
I don't see much point in GLUE doing something different when all it's doing is publishing strings, if everything that actually *uses* DNs for authn and authz uses the openssl format.
First off, and I can't emphasis this enough, it's not a standard!
How does one represent a RDN value with a '/' in it? How are non-ASCII names handled (Chinese CNs, anyone)? How are RDNs with multiple AVAs handled? ... etc ...
How can one write a validator for GLUE2 when so much is left unspecified. How does this foster interoperability?
Second, this argument is that of vendor lock-in.
For a variety of reasons, WLCG grid software currently suffers from a vendor lock-in with Globus code, which uses OpenSSL-format. Rather than use a vendor-neutral format, you advocate using a non-standard format.
Yes, it's always easier to follow the path of vendor lock-in; that's why it works. Remaining neutral often involves putting in some extra effort; however, it pays off in the long run.
Adopt a standardised format, say, one published as an RFC.
An RFC for LDAP, not X509!
Note that I didn't say we keep the same RFC, rather that it must be a published standard.
[aside, LDAP and X509 both use ASN.1 for encoding and have the same concept of "a DistingushedName", since they both derive from X500 service model. Using an LDAP RFC isn't *so* crazy.]
I would recommend we take advice from security experts about which standard/RFC we should use when defining the representation.
Cheers,
Paul.
_______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
participants (5)
-
Florido Paganelli -
JP Navarro -
Maarten Litmaath -
Paul Millar -
stephen.burke＠stfc.ac.uk