Bug 575 - Upcoming OpenSSL problem
: Upcoming OpenSSL problem
Status: RESOLVED FIXED
: GSI C
Credentials and Proxies
: 2.0
: All All
: P2 normal
: 3.2
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2003-01-09 15:52 by
Modified: 2014-02-14 17:41 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2003-01-09 15:52:54
This isn't actually a bug just yet, but it will be.  (I kind of like
the idea of submitting a bug report before the bug actually appears).

The NPACI certificate authority, also known as CACL,
issues certificates using a field with an OID (Object ID) of
"0.9.2342.19200300.100.1.1".  The version of OpenSSL currently used
by Globus doesn't recognize this OID, but CACL maps it to the name
"USERID".

For example, the subject name for my certificate is

    /C=US/O=NPACI/OU=SDSC/CN=Keith Thompson/0.9.2342.19200300.100.1.1=kst

but it appears in the grid-mapfile as

    /C=US/O=NPACI/OU=SDSC/CN=Keith Thompson/USERID=kst

(Interestingly enough, grid-cert-info displays this as
"0.9.2342.19200300.100.1.1", but grid-proxy-info displays it as
"USERID".  There must be some gratuitous difference in the way
they work.)

The signing certificate for CACL itself also uses this field.
The subject name is

    /C=US/O=NPACI/OU=SDSC/CN=Certificate Manager/USERID=certman

There's some special-case code in the globus_openssl_module package
(source file globus_openssl.c, function globus_l_openssl_activate)
that handles this:

    OBJ_create("0.9.2342.19200300.100.1.1","USERID","userId");

This was added in globus_openssl_module-0.2, which first appeared in
Globus release 2.2.3; see Globus Bugzilla #435.  I think this code was
also in Globus 2.0 and 2.1.

OpenSSL version 0.9.7 was released on 2002-12-31.  The good news:
it now recognizes the OID "0.9.2342.19200300.100.1.1".  The bad news:
it maps it to "UID", not "USERID".  It turns out that there is some
precedent for using the name "UID" for this OID; CACL's use of "USERID"
should probably be considered a bug in CACL.

If I understand all this stuff correctly, it means that when a future
version of Globus incorporates OpenSSL 0.9.7, the subject name for
my certificate will consistently appear to be

    /C=US/O=NPACI/OU=SDSC/CN=Keith Thompson/UID=kst

This assumes that the special-case code in globus_openssl.c is removed.
If it's left in place, the confusion will be even greater.

There's probably no reason for CACL not to continue to issue
certificates as it does now.  The only required changes I can think
of are:

    1. When Globus incorporates OpenSSL 0.9.7, the special-case code
       in globus_openssl.c should be removed.

    2. All grid-mapfile entries for CACL-issued certificates will
       have to be updated, changing "USERID" to "UID".

    3. The signing policy file for the NPACI CA will have to be
       modified to reflect the new subject name of the signing
       certificate.

In the transition, it probably makes sense to duplicate the grid-mapfile
entries; for example, there's no harm in mapping both 
    /C=US/O=NPACI/OU=SDSC/CN=Keith Thompson/USERID=kst
and
    /C=US/O=NPACI/OU=SDSC/CN=Keith Thompson/UID=kst
to the same Unix user name.  I'm not sure whether a similar solution
exists for the signing-policy file.

The latter two changes will have to be made at all Globus installations
that accept CACL certificates.  When the time comes I can probably
take care of either updating them myself or notifying the right people.
------- Comment #1 From 2003-04-11 12:31:59 -------
In discuss@globus.org, on 2003-04-11, Markus Lorch <mlorch@vt.edu> wrote:

    Another tweak along the same lines is in order if
    DNs have an email address. I just found out yesterday
    that
    /Email=ddd@ddd.dd
    changed in 0.9.7 to
    /emailAddr=ddd@dd.dd

    However both, the issue Keith reported and ours are
    actually due to the missuse of the human readable name
    for machine comparison. However, I guess there is no
    easy way around this due to the abstraction in the
    GSS-API unless we start using gss_compare_name to
    do the name comparisons on the ASN.1 objects (the
    way they are supposed to be done) but then we add complexity
    to the gridmap file as we will have to save the encoded
    version of the DN. Anyhow, there will be some tweaks
    required as Keith said.

I replied:

    Actually, I've found that /Email=... changed to /emailAddress=...
    If you're actually seeing "emailAddr", there's something really
    strange going on.

    The old (pre-CACL) NPACI CA uses this field.

    I'll add this information to bug #575.
------- Comment #2 From 2003-04-11 13:22:33 -------
There are more problems with doing ASN.1 level comparisons of DNs. A fairly
comprehensive treatment can be found at 

http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt

I should say that i have no intention of upgrading to 0.9.7 until they either
stop supporting the 0.9.6 release or some other really compelling reason comes
along.

/Sam
------- Comment #3 From 2003-04-11 16:30:21 -------
And Markus Lorch writes:

    my mistake; it is emailAddress
------- Comment #4 From 2003-07-31 15:03:49 -------
Removed the work around in globus_openssl.c, but will leave the bug open until
there is a release that contains 0.9.7

/Sam
------- Comment #5 From 2003-07-31 15:22:25 -------
Just to be clear, a version of Globus without the workaround in
globus_openssl.c
that uses OpenSSL 0.9.6 will have serious problems with CACL certificates.

If we're sure that there will be no such release (i.e., that the change in
globus_openssl.c is strictly tied to the use of OpenSSL 0.9.7), then we're ok.

(I'm probably stating the obvious.)
------- Comment #6 From 2003-07-31 16:28:07 -------
I've increased the major version for the openssl package (the upgrade required
some code changes), so releasing 0.9.7 with anything based on 0.9.6 is not
really going to be possible.

/Sam
------- Comment #7 From 2004-05-21 19:42:05 -------
Another question about this:

I see that the pre-OGSI portion of Globus 3.2.0 uses OpenSSL 0.9.7d.
This changes the subject names of certain certificates (USERID -->
UID, Email --> emailAddress), including CA signing certificates,
host certificates, and user certificates.  What I'm wondering is how
to support, say, both Globus 2.4.3 and Globus 3.2.0 on a single system.

For the grid-mapfile, it should be fairly straightforward.  Any
entries that use the changed fields can be duplicated; for example:

"/C=US/O=NPACI/OU=SDSC/CN=Keith Thompson/USERID=kst" kst
"/C=US/O=NPACI/OU=SDSC/CN=Keith Thompson/UID=kst" kst

But what about the *.signing_policy files?

For example, the signing_policy file for the SDSC CA 
(b89793e4.signing_policy) looks like this:

========================================================================
access_id_CA   X509    '/C=US/O=NPACI/OU=SDSC/CN=Certificate 
Manager/USERID=certman'
pos_rights     globus  CA:sign
cond_subjects  globus  '/C=US/O=NPACI/*'
========================================================================

That's the version for Globus 2.4.3, which uses OpenSSL 0.9.6l.

If I want to replace Globus 2.4.3 with Globus 3.2.0 (OpenSSL 0.9.7d), 
I can change it to this:

========================================================================
access_id_CA   X509    '/C=US/O=NPACI/OU=SDSC/CN=Certificate 
Manager/UID=certman'
pos_rights     globus  CA:sign
cond_subjects  globus  '/C=US/O=NPACI/*'
========================================================================

But what if I want to use both 2.4.3 and 3.2.0 on the same machine
(which I'll most likely need to do as the TeraGrid transitions away
from 2.4.3).  Is there a way to specify both versions of the DN,
either in the same signing_policy file or in two separate ones?  
If so, what is the syntax?

I realize that I can use $GLOBUS_LOCATION/share/certificates 
rather than /etc/grid-security/certificates, but I'd rather use
/etc/grid-security if possible.  

This is probably related to Globus Bugzilla # 1736.
------- Comment #8 From 2004-05-21 21:50:12 -------
Never mind, I've tracked down the answer.  It was posted on the
discuss@globus.org mailing list in January.

<http://www-unix.globus.org/mail_archive/discuss/2004/01/msg00354.html>
<http://www.grid-support.ac.uk/downloads/pdf/6300_Signing_Policy_02.pdf>

(The '#' suggested in the PDF file is unnecessary; a blank line will
work as well.)

To summarize, here's the previous (2.4.3-compatible) version of
b89793e4.signing_policy:
========================================================================
# SDSC CA Policy

access_id_CA   X509    '/C=US/O=NPACI/OU=SDSC/CN=Certificate 
Manager/USERID=certman'
pos_rights     globus  CA:sign
cond_subjects  globus  '/C=US/O=NPACI/*'
========================================================================

and here's one that works with both Globus 2.4.3 and Globus 3.2.0
(at least the pre-OGSI portion of 3.2.0):
========================================================================
# SDSC CA Policy

access_id_CA   X509    '/C=US/O=NPACI/OU=SDSC/CN=Certificate 
Manager/USERID=certman'
pos_rights     globus  CA:sign
cond_subjects  globus  '/C=US/O=NPACI/*'

access_id_CA   X509    '/C=US/O=NPACI/OU=SDSC/CN=Certificate 
Manager/UID=certman'
pos_rights     globus  CA:sign
cond_subjects  globus  '/C=US/O=NPACI/*'
========================================================================
------- Comment #9 From 2004-05-21 21:52:01 -------
Bugzilla wrapped some of the lines.  Each line starting with "access_id_CA"
should be joined with the line following it.
------- Comment #10 From 2014-02-02 19:50:10 -------
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen live from the domain http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.
------- Comment #11 From 2014-02-14 17:41:41 -------
The previous comment "Comment #10 From Alexa 2014-02-02 19:50:10" is clearly
spam. Somebody should probably check other bugs for similar comments.