What do we need in terms of x509 cert processing for ws secu

[starksm64]

As part of a user issue, I ended up needing to drill into the OtherName value of the SubjectAltName field of an x509 cert. There does not appear to be public apis for doing this as the DER classes are implementation details under the sun.* package namespace. I'm sure I can get equivalents from bouncy castle, but I want to know what is the scope of the x509 cert processing routines we should be providing as part of the jbosssx spis.

Can we gather those requirements here and translate those into a http://jira.jboss.com/jira/browse/SECURITY issue.

[anil.saldhana]

I do not think all the constituents of a X509 certificate map to standard JDK classes. An example are the Attribute Certificates that can be issued by the CA as part of a x509 certificate.

[jason.greene]

We need 2 things:

1. Ability to generate a v3 cert, bouncy castle does support this. Right now I tell people to use openssl.

2. Support for subject key identifier code follows (Although, ideally all v3 attributes would be supported)

 public static byte[] getSubjectKeyIdentifier(X509Certificate cert)
 {
 // Maybee we should make one ourselves if it isn't there?
 byte[] encoded = cert.getExtensionValue("2.5.29.14");
 if (encoded == null)
 return null;

 // We need to skip 4 bytes [(OCTET STRING) (LENGTH)[(OCTET STRING) (LENGTH) (Actual data)]]
 int trunc = encoded.length - 4;

 byte[] identifier = new byte[trunc];
 System.arraycopy(encoded, 4, identifier, 0, trunc);

 return identifier;
 }

Let me know how you would like this represented as JIRA issues.

-Jason

[starksm64]

1. Ability to generate a v3 cert, bouncy castle does support this. Right now I tell people to use openssl.

We should just look at whether bouncy castle/ejbca can be leveraged to get a sufficient cert generation capability into our codebase.

2. Support for subject key identifier code follows (Although, ideally all v3 attributes would be supported)

 public static byte[] getSubjectKeyIdentifier(X509Certificate cert)
 {
 // Maybee we should make one ourselves if it isn't there?
 byte[] encoded = cert.getExtensionValue("2.5.29.14");
 if (encoded == null)
 return null;

 // We need to skip 4 bytes [(OCTET STRING) (LENGTH)[(OCTET STRING) (LENGTH) (Actual data)]]
 int trunc = encoded.length - 4;

 byte[] identifier = new byte[trunc];
 System.arraycopy(encoded, 4, identifier, 0, trunc);

 return identifier;
 }

Access to any raw attribute seems to exist. What is not generally available is a mechanism to control how to decode a given attribute. I would assume this is going to require ASN/DER classes (should exist in bc or even opends), along with a OID to format handler registry. The latter is core to ldap and so maybe we can leverage the opends schema handling pieces as a way to externalize the cert attribute handling as well.

[starksm64]

I do not think all the constituents of a X509 certificate map to standard JDK classes. An example are the Attribute Certificates that can be issued by the CA as part of a x509 certificate.

Where is this used? I'm not keen on pushing too much to pki management layer. Issuing certs for roles seems like an unnecessary indirection.

[jason.greene]

1. Ability to generate a v3 cert, bouncy castle does support this. Right now I tell people to use openssl.

We should just look at whether bouncy castle/ejbca can be leveraged to get a sufficient cert generation capability into our codebase.

Agreed, I know we have some advanced long term goals, but I think just getting a basic tool in to begin with is important. Even if self-signing is all thats supported thats something.

\Access to any raw attribute seems to exist. What is not generally available is a mechanism to control how to decode a given attribute. I would assume this is going to require ASN/DER classes (should exist in bc or even opends), along with a OID to format handler registry. The latter is core to ldap and so maybe we can leverage the opends schema handling pieces as a way to externalize the cert attribute handling as well.

Yes bc does have ASN/DER decoding:
http://www.bouncycastle.org/docs/docs1.5/org/bouncycastle/asn1/package-summary.html

If work starts in either of these areas I can try and get some time to work on this if needed.

-Jason

[anil.saldhana]

I do not think all the constituents of a X509 certificate map to standard JDK classes. An example are the Attribute Certificates that can be issued by the CA as part of a x509 certificate.

Where is this used? I'm not keen on pushing too much to pki management layer. Issuing certs for roles seems like an unnecessary indirection.

No user requests have come in this area. Mainly used in smart cards(not sure of other uses). Like you said, unnecessary indirection.

[jason.greene]

In addition bc also has utility classes that decode just about every X509 attribtue that exists.

For example:

http://www.bouncycastle.org/docs/docs1.5/org/bouncycastle/asn1/x509/SubjectKeyIdentifier.html
http://www.bouncycastle.org/docs/docs1.5/org/bouncycastle/asn1/x509/AttributeCertificate.html

-Jason

[starksm64]

Ok, so we need a basic ca tool set. Its been a while since I looked at ejbca (http://sourceforge.net/projects/ejbca/) so its worth looking at how retargetable it would be for this effort.

[starksm64]

No user requests have come in this area. Mainly used in smart cards(not sure of other uses). Like you said, unnecessary indirection.

I'm not opposed to this driving features, like a new keystore format to allow for these types of certs, as you know I love the idea of smart cards replacing the password hell that exists today.

[anil.saldhana]

I'm not opposed to this driving features, like a new keystore format to allow for these types of certs, as you know I love the idea of smart cards replacing the password hell that exists today.

Not sufficient. It is still single factor. There is a real need for two or multi-factor authentication.

SRP (Scott's Robust Password) system also does not make the cut. ;)

Any legal issues (patents, licensing) with bouncy castle api-impl?

[starksm64]

SRP can use an external source for the random number to create two factor authentication. At least one customer has been doing this for years.

The only bc issue is around the IDEA algorithms. We should just drop those from the dist.

[anil.saldhana]

Since PKI etc have been broached on this thread, I also want to provide a link to the following lgpl oss project that users may find useful:
http://www.strongkey.org