users@glassfish.java.net

Re: GF v3 - Multiple CRL's

From: Kumar.Jayanti <Vbkumar.Jayanti_at_Sun.COM>
Date: Thu, 28 Oct 2010 10:27:05 +0530

On 22/10/10 12:04 AM, glassfish_at_javadesktop.org wrote:
> Kumar or anyone,
>
> I want to process multiple CRL's. In Apache (on Linux) this is done by concatenating the CRL files into a single CRL file (a long with symbolic links to each individual CRL)
can you point me to the documentation on this. Are you concatenating the
contents of individual PEM encoded CRL files into a single one ?. The
resulting file will not be a valid CRL file IMHO. The RFC 2549 does not
define a CRLList.

> When I tried this (on windows dev env) no certs presented work. Exceptions were thrown.
>
> My question is this ... What is the proper approach to using multiple CRL's within GF v3
A single CRL file can contain information about multiple revoked
certificates and this is what GF can support.

http://www.faqs.org/rfcs/rfc2459.html

The X.509 v2 CRL syntax is as follows. For signature calculation,
the data that is to be signed is ASN.1 DER encoded. ASN.1 DER
encoding is a tag, length, value encoding system for each element.

CertificateList ::= SEQUENCE {
         tbsCertList TBSCertList,
         signatureAlgorithm AlgorithmIdentifier,
         signatureValue BIT STRING }

    TBSCertList ::= SEQUENCE {
         version Version OPTIONAL,
                                      -- if present, shall be v2
         signature AlgorithmIdentifier,
         issuer Name,
         thisUpdate Time,
         nextUpdate Time OPTIONAL,
         revokedCertificates SEQUENCE OF SEQUENCE {
              userCertificate CertificateSerialNumber,
              revocationDate Time,
              crlEntryExtensions Extensions OPTIONAL
                                            -- if present, shall be v2
                                   } OPTIONAL,
         crlExtensions [0] EXPLICIT Extensions OPTIONAL
                                            -- if present, shall be v2
                                   }

As you can see the issuer is common for all the revoked certs.

If you want more flexible revocation checking it is best to enable OCSP
or Dynamic revocation checking. As you may be aware a static CRL file is
not very good anyway (The main limitation of CRL is the fact that
updates must be frequently downloaded to keep the list current. OCSP
overcomes this limitation by checking certificate status in real time.)

regards,
kumar
> Any help would be greatly appreciated. (I'll let you write the white paper ;) )
>
> Thanks,
> Eric
> [Message sent by forum member 'eliscinsky']
>
> http://forums.java.net/jive/thread.jspa?messageID=485889
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>