Bug 5606 - CAS certificate extension is not a properly DER encoded ASN.1 structure
: CAS certificate extension is not a properly DER enco...
: CAS/SAML utilities
: 4.0.4
: All All
: P1 normal
: 4.2
Assigned To:
  Show dependency treegraph
Reported: 2007-10-11 13:09 by
Modified: 2008-06-17 09:26 (History)



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

Description From 2007-10-11 13:09:18
The RFC 3280 section on Certificate Extensions says:

   Each extension includes an OID and an ASN.1 structure.  When an
   extension appears in a certificate, the OID appears as the field
   extnID and the corresponding ASN.1 encoded structure is the value of
   the octet string extnValue.

However, the SAML assertion contained in the CAS OID
certificate extension is not a DER encoded ASN.1 structure.  It does not
contain the proper DER tag, length, value encoding.  This is demonstrated by
the openssl command output indicating "Error in encoding" at

Since GridShib follows CAS's example, it has a similar issue (Bug 5601).  I
attached an example in Bug 5601 showing how the extension could be encoded as
an ASN.1 UTF8String.

In my opinion, if we are to promote this certificate extension as a standard
method of encoding SAML assertions in X.509 certificates, a proper ASN.1
specification and encoding for the assertion is needed.

One way to migrate to an ASN.1 encoding would be to define a new extension OID
with the proper encoding and support both the old and new extensions during a
transition period, similar to what we have done for migrating to RFC 3820 proxy
------- Comment #1 From 2008-01-11 08:12:53 -------
For hints how to solve this problem, see SAMLX509Extension and its


This class can be traced all the way back to org.globus.gsi.X509Extension.  In
fact, you're welcome to incorporate as much of this as you like into
org.globus.gsi.X509Extension, which would mark the beginning of the
CAS-GridShib integration.
------- Comment #2 From 2008-01-19 20:23:46 -------
The patch implemented in SAMLX509Extension will not work in GT 4.0 since 4.0
depends on jce-jdk13-125.jar, which does not include class 


However, GT 4.1 depends on jce-jdk13-131.jar, so the patch works just fine in

By the way, the latest version of the BC provider (jce-jdk13-138.jar) includes
numerous performance enhancements.  (See the r138 release notes and the source
in CVS.)
------- Comment #3 From 2008-02-29 18:05:39 -------
Tom/Jim, thanks for the bug report and the patch.

Fix has been committed to trunk. Support for OID has
been discontinued and GT 4.2 will support OID with
DER encoded ASN.1 structure. Documentation in 4.2 drafts has been updated in
the change summary section. 

Proxy with embedded assertion post fix:

Leaving the bug open to backport this to 4.0.x where both OIDs will be
------- Comment #4 From 2008-03-03 12:48:21 -------
Backported fix to 4.0 branch and will be released as part of GT 4.0.7. An
option has been added to cas-proxy-init to request the new OID with encoded
assertion and the old assertion remains the default.

Old proxy from branch:

New proxy from branch:

Documentation has been updated.
------- Comment #5 From 2008-03-24 09:33:14 -------
Updated URLs:

Proxy with embedded assertion post fix: (trunk)

Old proxy from branch:

New proxy from branch:
------- Comment #6 From 2008-06-16 18:23:21 -------
(In reply to comment #4)
> Backported fix to 4.0 branch and will be released as part of GT 4.0.7.

Reopening this bug since something's fishy.  The new version of SAMLUtil.java
contains the following method

public static String decodeDERUTF8String(byte[] value) 
    throws IOException {

    ASN1InputStream in = null;
    try {
        in = new ASN1InputStream(value);
        DERUTF8String derString = (DERUTF8String)in.readObject();
        if (derString != null) {
            return derString.getString();
        } else {
            return null;
    } finally {
        if (in != null) {
            try {
            } catch (Exception exp){}

but the API in jce-jdk13-125.jar does not include the following constructor:

org.bouncycastle.asn1.ASN1InputStream(byte[] input);

So how can this possibly work in GT 4.0.7?  See


for a summary.
------- Comment #7 From 2008-06-17 09:26:48 -------
SAMLUtil is only in trunk. Branch commit was made to ws-cas module, since in GT
4.0.x the SAML assertion processing is limited to ws-cas module. Relevant API
changes were made before it was committed to that branch - code compiles and
has been tested.