More people in OSG are using the voms-proxy-init with -rfc flag and the problem
is reported more often, so I raise the priority to critical.

Can you do a grid-cert-info -all -cert <proxyfilename> and send in the output?

Here you go:

[timur@fnisd1 dCache-hg]$ voms-proxy-init -vomses /home/timur/.edg/vomses
--confile $HOME/.edg/vomses -voms fermilab --hours=240 -rfc
Cannot find file or dir:
/home/condor/execute/dir_14135/userdir/glite/etc/vomses
Enter GRID pass phrase:
Your identity: /DC=org/DC=doegrids/OU=People/CN=Timur Perelmutov 683749
Cannot find file or dir:
/home/condor/execute/dir_14135/userdir/glite/etc/vomses
Creating temporary proxy .............................. Done
Contacting  fg5x1.fnal.gov:15001
[/DC=org/DC=doegrids/OU=Services/CN=http/voms.fnal.gov] "fermilab" Done
Creating proxy ......................................... Done
Your proxy is valid until Sat Nov 21 09:07:28 2009
[timur@fnisd1 dCache-hg]$ grid-cert-info -all -file /home/timur/k5-ca-proxy.pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 35486 (0x8a9e)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: DC=org, DC=doegrids, OU=People, CN=Timur Perelmutov 683749
        Validity
            Not Before: Nov 11 15:02:28 2009 GMT
            Not After : Nov 21 15:07:28 2009 GMT
        Subject: DC=org, DC=doegrids, OU=People, CN=Timur Perelmutov 683749,
CN=858639941
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (512 bit)
                Modulus (512 bit):
                    00:ba:50:b4:8c:97:99:eb:a8:c8:35:9a:7b:cd:c7:
                    5d:c9:f4:4a:24:f7:94:6a:e3:97:9a:2a:22:45:2c:
                    7b:54:98:84:e9:89:08:84:06:c8:8c:16:7d:7a:38:
                    98:50:39:52:9c:ca:d0:ec:c4:0b:84:c4:97:52:04:
                    ad:be:5b:72:95
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            1.3.6.1.4.1.8005.100.100.5:
                0..h0..d0..`0..H...0o.m0f.d0b1.0..
..&...,d....org1.0..
..U....People1 0...U....Timur Perelmutov 683749......e0c.a0_1.0..
..&...,d....org1.0..
..........:.0"..20091111150728Z..20091112030728Z0..0...voms.fnal.gov0
+.....Edd.1..0...
..fermilab://voms.fnal.gov:150010y.#/fermilab/Role=NULL/Capability=NULL.(/fermilab/test/Role=NULL/Capability=NULL.(/fermilab/grid/Role=NULL/Capability=NULL0..z0..
+.....Edd...0.0.0...U.8....0...U.#..0......w....A...u.p.4o=N0..6.
+.....Edd
.....0i1.0..0...0.............0
..&...,d....org1.0..
100910192438Z0_1.0..1 0...U....Certificate Authorities1.0...U...
..&...,d....org1.0..
..........0..oegrids1.0...U....Services1.0...U....http/voms.fnal.gov0.."0
T.j........H.i..T.l....B/.............6.e.jZ.[.TymG......BK..........,..Z.2!.@2.......1!...]..n...Q......h..0.Kqqq........0..0...`.H...B........0...U.........*.H..L.....0.0
..........Pg(.G[Z...&5.UZ+t.....w....5....#...f...,.ig^3..r0s.s......
...[.2\...$.....7.0DND.. .ue....[....Q.....Z.......m....}....%...5.~?.....wP
..B.....!|..[...;...I....n(.
..........\".D....T....b..{......UK.....$....@D...k..g....S..1..R....'.....B.....\qYdP.o...R...&x....<5hr..?c..E......}w......._.8..n}Zb..+?IR?6W....F..q..[.....}..Jw.\F.7%._..E....i....UB.(..[....}.9....5.Z.......:.e..&...!..=...mz......g55,.~Z.
%.1.E'ye/...)l..xd.
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Data Encipherment
            1.3.6.1.4.1.8005.100.100.6:
                03
            1.3.6.1.5.5.7.1.14: critical
                0.0
..+.......
    Signature Algorithm: md5WithRSAEncryption
        55:e7:f9:64:25:7d:08:a7:ad:30:bd:ad:c7:9a:5d:b7:55:63:
        1b:e7:7e:89:c1:54:d1:41:7f:33:3c:17:d9:61:ff:70:b3:e1:
        ed:17:6b:cc:4f:36:0c:94:df:bf:cc:50:f0:d5:5f:b5:09:4a:
        a7:93:6f:69:21:54:e6:fa:08:0b:ab:dd:54:56:34:f2:56:be:
        5d:53:25:96:ed:e3:f1:d2:ea:62:80:37:76:2c:4a:d2:4d:53:
        3d:90:47:b5:e4:c4:c8:28:28:a3:c4:ef:45:d3:17:d7:2b:53:
        33:51:83:15:27:de:eb:10:05:e3:1b:da:63:db:59:63:c8:70:
        9c:a0:0f:e4:32:06:25:82:6f:9c:c2:3a:87:9b:29:a6:ae:fe:
        06:ed:99:eb:e0:ed:db:39:07:50:6b:99:9a:05:f9:bc:8b:5c:
        d3:ba:c3:8e:be:5d:2d:c2:11:40:52:12:ca:83:56:ac:bc:d0:
        9a:c0:c7:c0:11:25:4d:61:f9:f4:20:66:1b:99:35:9b:c3:fe:
        5d:c0:8f:84:a0:da:a3:03:29:a9:02:88:55:c7:4e:73:db:7d:
        22:89:36:18:5e:26:1d:f8:34:77:ab:01:b5:17:a7:d0:01:20:
        cd:af:06:b6:81:57:c1:5e:0b:ca:70:89:a0:6f:87:90:30:40:
        0b:01:54:7c
[timur@fnisd1 dCache-hg]$ voms-proxy-info -all
WARNING: Unable to verify signature! Server certificate possibly not installed.
Error: Cannot find certificate of AC issuer for vo fermilab
subject   : /DC=org/DC=doegrids/OU=People/CN=Timur Perelmutov
683749/CN=858639941
issuer    : /DC=org/DC=doegrids/OU=People/CN=Timur Perelmutov 683749
identity  : /DC=org/DC=doegrids/OU=People/CN=Timur Perelmutov 683749
type      : unknown
strength  : 512 bits
path      : /home/timur/k5-ca-proxy.pem
timeleft  : 239:56:47
=== VO fermilab extension information ===
VO        : fermilab
subject   : /DC=org/DC=doegrids/OU=People/CN=Timur Perelmutov
683749/CN=858639941
issuer    : /DC=org/DC=doegrids/OU=Services/CN=http/voms.fnal.gov
attribute : /fermilab/Role=NULL/Capability=NULL
attribute : /fermilab/test/Role=NULL/Capability=NULL
attribute : /fermilab/grid/Role=NULL/Capability=NULL
timeleft  : 11:56:47
[timur@fnisd1 dCache-hg]$

Looks like this is a check that any key usage bit asserted in a certificate
must be asserted in the issuing certificate also. This check is not exclusive
to RFC compliant proxy certificates, so the validation code for rfc and non-rfc
should not be different.

Can you please check the following:

* Does the proxy issuer have the same key usage bits set? " Digital Signature,
Key Encipherment, Data Encipherment"

* If -rfc is not used, are the same key usage bits set as with -rfc flag?

Thanks,
Rachana

How do I check if the proxy issuer have the same key usage bits set?  As I
understand the issuer of my cert is doegrids.org and the issuer of my proxy is
my cert, signed by the voms server. Could you send me the lists of commands you
want me to run? Do you want grid-cert-info for DOE Grids CA cert? Voms CA Cert?

Issuer of this proxy is:

 Issuer: DC=org, DC=doegrids, OU=People, CN=Timur Perelmutov 683749


So "grid-cert-info -file <path to your certificate file> -all" should show the
relevant information.

Rachana

Here is the info for the issuing cert, bellow it the info for voms cert created
without -rfc flag:
[timur@fnisd1 dCache-hg]$ grid-cert-info -file /home/timur/.globus/usercert.pem
-all
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 35486 (0x8a9e)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: DC=org, DC=DOEGrids, OU=Certificate Authorities, CN=DOEGrids CA
1
        Validity
            Not Before: Sep  9 19:43:12 2009 GMT
            Not After : Sep  9 19:43:12 2010 GMT
        Subject: DC=org, DC=doegrids, OU=People, CN=Timur Perelmutov 683749
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:c0:a9:8c:b1:24:60:6f:f6:81:c7:ac:50:32:82:
                    86:53:b0:b8:aa:14:3c:00:37:90:5d:6d:be:4c:da:
                    65:f6:de:67:8c:c9:59:91:8e:85:89:1f:b5:ce:f4:
                    9c:aa:f2:22:4a:ed:40:51:4b:7f:d8:f9:c6:ee:2c:
                    2a:75:31:f7:5e:db:38:07:31:f9:bc:2f:c0:1b:79:
                    47:8e:67:cc:2b:cc:e3:73:f4:2c:5d:e7:33:8f:2d:
                    8b:b0:bd:97:ad:48:2d:8b:51:41:0e:17:c0:d7:68:
                    5b:14:8a:f9:a2:9b:e1:48:36:0f:06:30:25:8f:fb:
                    f1:e8:38:d4:4c:1f:bf:66:a4:8a:05:fd:2d:17:58:
                    28:45:3a:1d:eb:47:71:10:e7:82:95:18:41:2c:f4:
                    a8:65:47:a0:33:a4:8a:6d:83:55:ea:a4:37:1d:93:
                    41:68:53:51:74:de:1a:23:dd:bf:5b:af:23:29:d3:
                    23:da:df:a1:8a:74:3f:35:41:ce:00:aa:47:f1:5c:
                    77:b8:06:66:53:94:fe:9a:f9:4a:54:ef:d1:ed:95:
                    78:df:c9:49:49:5a:9f:c7:47:10:0c:ff:7e:4f:0d:
                    8f:11:87:e0:33:e1:90:90:99:70:56:0b:d6:6d:94:
                    7c:33:09:b2:cf:a8:a0:87:67:25:56:ac:af:40:23:
                    8d:6b
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            Netscape Cert Type:
                SSL Client, S/MIME
            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Certificate Policies:
                Policy: 1.2.840.113612.3.7.1.3.1
                Policy: 1.2.840.113612.5.2.2.1
                Policy: 1.2.840.113612.5.2.3.2.1.1

            X509v3 CRL Distribution Points:
                URI:http://crl.doegrids.org/1c3f2ca8/1c3f2ca8.crl

            X509v3 Subject Alternative Name:
                email:timur@fnal.gov
            X509v3 Authority Key Identifier:
               
keyid:CA:19:1D:12:8E:6E:A4:38:5D:42:D4:31:0E:08:DB:D9:8D:17:0D:5D

    Signature Algorithm: sha1WithRSAEncryption
        00:70:da:93:79:07:7d:84:3d:45:a0:97:2c:28:c1:47:d8:78:
        e6:96:c8:8b:8a:9d:17:23:93:32:e8:c1:8d:59:72:77:35:5f:
        a0:e3:a6:5b:9c:b0:62:4d:3c:9f:b8:83:e6:c2:3f:39:8e:c9:
        75:e9:87:35:a2:7a:cd:7e:3c:3b:31:7b:2d:f4:f7:c1:30:2c:
        c1:33:77:1d:bb:03:37:cd:da:86:07:7c:2f:f6:ae:f2:27:fc:
        9e:6d:9f:7e:0a:7e:e0:b5:45:b7:e8:eb:22:10:34:e9:81:03:
        4c:54:6b:f7:93:2d:ab:3e:c2:96:98:51:c8:d7:a0:a6:b5:aa:
        9d:6c:f9:a8:02:c8:3a:9e:6a:94:5c:5c:f2:fc:24:78:03:c8:
        96:41:18:33:6f:55:db:43:84:d2:98:41:6b:03:de:50:b9:68:
        e2:ab:d4:9b:f5:c5:f5:f7:df:76:68:f5:6b:17:b0:d6:a5:9c:
        ce:af:cb:91:54:a9:ab:8b:01:64:8d:ef:e5:df:0d:97:e1:3c:
        4a:15:69:aa:af:07:fb:45:d7:ad:ea:92:85:ae:f5:43:2b:fe:
        c1:d4:e9:69:2d:96:30:d4:94:f7:1c:ff:69:a2:36:93:d1:86:
        b7:fa:e1:fa:46:cf:b0:60:65:3b:af:da:31:b5:79:8e:e4:6c:
        7e:ec:f7:6e
[timur@fnisd1 dCache-hg]$ 

Here is the info for voms cert without -rfc:
[timur@fnisd1 dCache-hg]$ grid-cert-info -all -file /home/timur/k5-ca-proxy.pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 35486 (0x8a9e)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: DC=org, DC=doegrids, OU=People, CN=Timur Perelmutov 683749
        Validity
            Not Before: Nov 11 22:24:48 2009 GMT
            Not After : Nov 21 22:29:48 2009 GMT
        Subject: DC=org, DC=doegrids, OU=People, CN=Timur Perelmutov 683749,
CN=proxy
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (512 bit)
                Modulus (512 bit):
                    00:d9:c4:75:e9:0b:31:e7:03:8d:fe:dd:a5:b8:03:
                    3a:17:21:d8:1c:e2:fb:d7:2b:1b:66:e4:f8:15:27:
                    81:9b:6e:39:7f:b4:4f:c7:72:40:d1:f9:25:4d:16:
                    75:46:d0:28:80:e8:e1:f2:bc:ed:53:06:38:4d:b8:
                    a6:37:fd:9d:65
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            1.3.6.1.4.1.8005.100.100.5:
                0..h0..d0..`0..H...0o.m0f.d0b1.0..
..&...,d....org1.0..
..U....People1 0...U....Timur Perelmutov 683749......e0c.a0_1.0..
..&...,d....org1.0..
..........:.0"..20091111222948Z..20091112102948Z0..0...voms.fnal.gov0
+.....Edd.1..0...
..fermilab://voms.fnal.gov:150010y.#/fermilab/Role=NULL/Capability=NULL.(/fermilab/test/Role=NULL/Capability=NULL.(/fermilab/grid/Role=NULL/Capability=NULL0..z0..
+.....Edd...0.0.0...U.8....0...U.#..0......w....A...u.p.4o=N0..6.
+.....Edd
.....0i1.0..0...0.............0
..&...,d....org1.0..
100910192438Z0_1.0..1 0...U....Certificate Authorities1.0...U...
..&...,d....org1.0..
..........0..oegrids1.0...U....Services1.0...U....http/voms.fnal.gov0.."0
T.j........H.i..T.l....B/.............6.e.jZ.[.TymG......BK..........,..Z.2!.@2.......1!...]..n...Q......h..0.Kqqq........0..0...`.H...B........0...U.........*.H..L.....0.0
..........Pg(.G[Z...&5.UZ+t.....w....5....#...f...,.ig^3..r0s.s......
...[.2\...$.....7.0DND.. .ue....[....Q.....Z.......m....}....%...5.~?.....wP
..B.....!|..[...;...I....n(.
..........,....._......G.m.%..S.#)Z...q...'...Re....;..
...Lum....b..)..!.J..f:l8....s.3P.x=.cCKi.)Tk.........<G.....X...?..k-...k....y.._./...V..t.y.5..UI.
..Y..(.fl...'.A.o..e.....X..%.o...|.*.:*....K..<p...(......Yg..f..Q.Z.elC.XB......M..*]Uz).
....g.2..!....O?.
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Data Encipherment
            1.3.6.1.4.1.8005.100.100.6:
                03
    Signature Algorithm: md5WithRSAEncryption
        b8:70:96:9e:89:ae:66:43:74:01:9f:8e:93:1b:b3:e9:04:3e:
        61:18:2e:16:ad:8e:eb:c9:9f:80:91:2d:3c:c6:d4:91:aa:6c:
        6f:0d:46:a4:4e:da:a5:d8:8a:53:e4:05:50:d9:37:7c:6a:95:
        a7:89:78:78:55:0d:a7:b6:00:43:b7:8c:99:96:95:33:76:7b:
        ae:27:10:6f:d4:42:83:17:76:10:42:29:93:08:11:97:da:ad:
        bf:0a:cb:fe:a4:81:9f:5e:9b:2c:84:d1:20:8a:5b:72:70:4b:
        86:8c:f9:b7:c8:f7:89:83:fd:32:7d:21:86:f9:5c:5e:ee:dd:
        2d:42:e7:d7:37:b9:a2:b4:73:59:90:7f:54:09:45:d4:22:4f:
        d0:19:e0:73:f7:46:13:3a:a8:a1:f8:28:53:b7:c3:e9:c5:9c:
        e9:61:4d:a0:8c:ee:ad:e2:83:0b:78:2f:f3:06:14:41:67:d2:
        27:24:77:85:43:5b:c3:f6:4d:67:47:f1:77:d7:7d:c9:67:2a:
        9d:0d:fe:ed:8f:a2:72:33:5e:49:19:4a:6f:67:7f:f2:95:01:
        4f:86:7b:19:2b:78:ca:16:a3:1a:31:70:21:50:b6:e1:ac:99:
        f8:d8:17:20:c0:be:3a:a0:d9:8d:39:29:07:b6:02:a2:66:a4:
        13:a4:c2:13
[timur@fnisd1 dCache-hg]$

With -rfc the key usage bits are different from your certificate, whereas
without rfc flag they match. Specifically, with -rfc, Data Encipherment bit is
added to the proxy, but it is not present in the issuing certificate.

Looking at section 6.2 in http://www.ietf.org/rfc/rfc3820.txt, it tells me that
the key usage can only be decreased in proxy chains, so a new bit cannot be
introduced.

"An EEC or PC can limit what a new PC can be used for by turning off
   bits in the Key Usage and Extended Key Usage extensions.  Once a key
   usage or extended key usage has been removed, the path validation
   algorithm ensures that it cannot be added back in a subsequent PC.
   In other words, key usage can only be decreased in PC chains."

So it looks me like CoG proxy validation is working as it should.

I don't know why there should be a difference on this based on whether it is
RFC compliant proxy or not. Can you clarify from the VOMs team?

Thank you for looking into this issue. I will propagate this information to the
VOMs team. I will update this ticket with their reply.

I've reported this to glite:
https://savannah.cern.ch/bugs/?58814

I can do the test with a newer version of VOMS. What exactly should I do to see
if the newer version has the problem? I didn't quite understand how to
interpret the output?

Thanks,
-alain

In the output of grid-cert-info, you should look at the key usage: "X509v3 Key
Usage: critical". This will be followed by some bits, example "Digital
Signature, Key Encipherment, Data Encipherment".

What we need to see if that bits set in a particular certificate are all
present in its issuing certificate. So if a certificate has Digital Signature
and Key Encipherment, then its issuer should atleast have those two bits.

Rachana

Actually, regardless of whether or not you use --rfc, the Key Usage extension
will be:

       X509v3 Key Usage: critical
            Digital Signature, Key Encipherment, Data Encipherment

as you can see from comments #3 and #7, so this could hardly be the case of the
authentication failure.  

Furthermore, the argument that a proxy's Key Usage must be a subset of the
EEC's Key usage does not hold.  The way I read it, reference to the RFC only
applies to chains of Proxy Certificates, meaning that a Proxy Certificate may
only restrict, not expand, another Proxy Certificate.  Since the VOMS proxy is
the first Proxy certificate, this rule does not apply.

Besides, even under the most restrictive interpretation that would not be a
reason for a verification failure.  All the RFC has to say about how to handle
the case where two Key Usage do not match, is this:

   *  If a certificate is a proxy certificate with a policy other than
      id-ppl-independent, the effective key usage and extended key usage
      functionality of the proxy certificate is the intersection of the
      functionality of those extensions in the proxy certificate and the
      effective key usage functionality of the proxy issuer.

(section 4.2) which says nothing about failing validation.

Please note that it is commonplace among EEC to have Key Usage extensions that
are not present in their issuer certificates, and indeed RFC 5280 has no
requirements about consistency between a certificate Key Usage and its issuer's
one.

In conclusion, I would say that if the cause of the validation failure is
really the presence of the "Data Encipherment" bit, then this is a bug in the
cog validation code, not in voms.

Comments inline.

(In reply to comment #12)
> Actually, regardless of whether or not you use --rfc, the Key Usage extension
> will be:
> 
>        X509v3 Key Usage: critical
>             Digital Signature, Key Encipherment, Data Encipherment
> 
> as you can see from comments #3 and #7, so this could hardly be the case of the
> authentication failure.  

Presumably there is slightly different validation logic for the two different
types of proxies and hence that is causing the difference.

> Furthermore, the argument that a proxy's Key Usage must be a subset of the
> EEC's Key usage does not hold.  The way I read it, reference to the RFC only
> applies to chains of Proxy Certificates, meaning that a Proxy Certificate may
> only restrict, not expand, another Proxy Certificate.  Since the VOMS proxy is
> the first Proxy certificate, this rule does not apply.

I disagree with this statement. A "proxy issuer" (using RFC 3820 language) is
the issuer of a proxy, be that a EEC or a PC. Hence this is no difference
between a proxy issued by a proxy or a proxy issued by a EEC in terms of the
logic in this situation.


> Besides, even under the most restrictive interpretation that would not be a
> reason for a verification failure.  All the RFC has to say about how to handle
> the case where two Key Usage do not match, is this:
> 
>    *  If a certificate is a proxy certificate with a policy other than
>       id-ppl-independent, the effective key usage and extended key usage
>       functionality of the proxy certificate is the intersection of the
>       functionality of those extensions in the proxy certificate and the
>       effective key usage functionality of the proxy issuer.
> 
> (section 4.2) which says nothing about failing validation.

I agree there these is no requirement for validation failure. The RFC leaves
open the possibility to silently ignore the usage bits set in the proxy not set
in the proxy issuer.

> Please note that it is commonplace among EEC to have Key Usage extensions that
> are not present in their issuer certificates, and indeed RFC 5280 has no
> requirements about consistency between a certificate Key Usage and its issuer's
> one.

There is a big difference logically between a CA issuing a EEC and a EEC
issuing a Proxy Certificate. A CA is entrusted to create new identities. A EEC
is constrained by the identity and rights given to it by the CA.

> In conclusion, I would say that if the cause of the validation failure is
> really the presence of the "Data Encipherment" bit, then this is a bug in the
> cog validation code, not in voms.

Under the philosophy of being conservative in what one sends and flexible in
what one receives, I would say VOMS should not be setting the bit and the COG
code should be more flexible in receiving it, and both should be corrected.

Removed the check that imposes the key usage. Fix committed to
globus_4_0_branch and trunk. Will be part of CoG JGlobus 1.8 release.