First Last Prev Next    No search results available
Bug 5008 - voms-proxy-init creates non-critical KeyUsage extension which causes Java GSI to raise exception
: voms-proxy-init creates non-critical KeyUsage extension which causes Java GSI...
Status: NEW
: Java WS Security
Authentication
: 4.0.3
: All All
: P3 normal
: ---
Assigned To:
:
:
:
:
  Show dependency tree / graph
 
Reported: 2007-02-14 15:12 by
Modified: 2007-12-03 08:47 (History)

Attachments
Add an attachment (proposed patch, testcase, etc.)


Note

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

Description From 2007-02-14 15:12:35 
This bug describes a difference in how GSI C and Java path validation work,
which is triggered by VOMS. Ultimately I think voms-proxy-init is misbehaving
and will report this to the VOMS developers, but I wanted to record this GT
behavior for the record.

By default, voms-proxy-init (version 1.6.16), create a legacy GT2 style proxy
certificate.

Using 'voms-proxy-init -proxyver 3' one can create a RFC compliant (modulo PCI
oid) proxy certificate, but the Key Usage extension isn't critical.

        X509v3 extensions:
            X509v3 Key Usage:
                Digital Signature, Key Encipherment, Data Encipherment
            1.3.6.1.4.1.3536.1.222: critical
                0.0

Now this doesn't seem to bother C GSI at all. I can use the resulting VOMS
Proxy to gsissh.

But when used to connect to a GT WS-based server it results in the following
error:

CLIENT SIDE:

Error: ; nested exception is: 
        java.io.EOFException



CONTAINER SIDE:

2007-02-14 14:59:29,224 ERROR container.GSIServiceThread
[ServiceThread-3,process:145] Error processing request
Authentication failed
. Caused by 
Defective credential detected
. Caused by 
org.globus.gsi.proxy.ProxyPathValidatorException: KeyUsage extension in Proxy
Certificate is not critical
        at
org.globus.gsi.proxy.ProxyPathValidator.checkProxyConstraints(ProxyPathValidator.java:688)
        at
org.globus.gsi.proxy.ProxyPathValidator.validate(ProxyPathValidator.java:478)
        at
org.globus.gsi.gssapi.GlobusGSSContextImpl$GSSProxyPathValidator.validate(GlobusGSSContextImpl.java:668)
        at
org.globus.gsi.gssapi.GlobusGSSContextImpl.verifyChain(GlobusGSSContextImpl.java:704)
        at
org.globus.gsi.gssapi.GlobusGSSContextImpl.acceptSecContext(GlobusGSSContextImpl.java:303)
        at
org.globus.gsi.gssapi.net.GssSocket.authenticateServer(GssSocket.java:124)
        at
org.globus.gsi.gssapi.net.GssSocket.startHandshake(GssSocket.java:142)
        at
org.globus.gsi.gssapi.net.GssSocket.getOutputStream(GssSocket.java:161)
        at
org.globus.wsrf.container.GSIServiceThread.process(GSIServiceThread.java:102)
        at org.globus.wsrf.container.ServiceThread.run(ServiceThread.java:302)
------- Comment #1 From 2007-02-14 15:18:15 ------- 
Just checked with RFC 3280, regarding the legality of a non-critical keyUsage
extension. It says the following in 4.2.1.3, which doesn't clarify things much.

 This extension [key usage] MUST appear in certificates that contain public
keys
   that are used to validate digital signatures on other public key
   certificates or CRLs.  When this extension appears, it SHOULD be
   marked critical.
------- Comment #2 From 2007-02-15 12:37:32 ------- 
In talking to Valerio Venturi, it appears like some time after 1.6.16, VOMS was
altered to produce a critical X509v3 Key Usage. More details as I get them.
------- Comment #3 From 2007-02-16 11:08:30 ------- 
From Valerio, voms-proxy-init version 1.7.14 generates critical key usage
extensions:

Certificate: (Portions replaced with XXX to preserve privacy and compactness.)
    Data:
        Version: 3 (0x2)
        Serial Number: 4725 (0x1275)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: XXX
        Validity
            Not Before: Feb 14 23:05:57 2007 GMT
            Not After : Feb 15 11:10:57 2007 GMT
        Subject: XXX, CN=542440169
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (512 bit)
                Modulus (512 bit):
XXXX
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
            Digital Signature, Key Encipherment, Data Encipherment
            1.3.6.1.4.1.3536.1.222: critical
                0.0
..+.......
    Signature Algorithm: md5WithRSAEncryption
 XXX
------- Comment #4 From 2007-09-12 10:39:12 ------- 
Given RFC 3820 says "When this extension appears, it SHOULD be marked
critical.", it looks to me like the Java code raising an exception in this
scenario is correct. Von, were you expecting different behavior ?
------- Comment #5 From 2007-09-12 12:06:15 ------- 
Responding to comment 4: I don't disagree. Mainly think the C and Java version
should agree.
------- Comment #6 From 2007-09-12 12:29:32 ------- 
ok, thanks. 

Reassigning to C component.
------- Comment #7 From 2007-12-03 08:47:02 ------- 
Since it's not a MUST requirement in the RFC, I'd think that the non-critical
extension shouldn't be fatal.
First Last Prev Next    No search results available