"scott.stark(a)jboss.org" wrote : "anil.saldhana(a)jboss.com" wrote : 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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980163#3980163
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980163
"scott.stark(a)jboss.org" wrote : "jason.greene(a)jboss.com" wrote :
| | 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.
"scott.stark(a)jboss.org" wrote :
| \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-su...
If work starts in either of these areas I can try and get some time to work on this if needed.
-Jason
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980162#3980162
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980162
"jason.greene(a)jboss.com" wrote :
| 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.
"jason.greene(a)jboss.com" wrote :
| 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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980154#3980154
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980154
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
3. 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
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980129#3980129
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980129