vt-crypt: Add additional X.509 helper methods

[GoogleCodeExporter]

- Ability to get all subject names (subject DN + altNames of a specified types)
- Ability to get altNames of specified types
- get the subject key identifier for a certificate
- determine the entity certificate given a collection of certs and a private key

You can find out impl of these methods here:
http://svn.shibboleth.net/view/java-opensaml/trunk/opensaml-security-api/src/mai
n/java/org/opensaml/xml/security/x509/X509Util.java?revision=2850&view=markup

Original issue reported on code.google.com by claj...@gmail.com on 6 Dec 2011 at 3:42

[GoogleCodeExporter]

This is an enhancement request.

Original comment by marvin.addison@gmail.com on 20 Dec 2011 at 3:17

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Started work.

Original comment by marvin.addison@gmail.com on 22 Feb 2012 at 4:33

• Changed state: Started

[GoogleCodeExporter]

A convenient (one-liner) facility already exists for getting subject key 
identifier:

{{{
final KeyIdentifier ki = new ExtensionReader(cert).readSubjectKeyIdentifier();
}}}

All X.509 extension fields may be read using a similar idiom.

Original comment by marvin.addison@gmail.com on 22 Feb 2012 at 6:31

[GoogleCodeExporter]

Committed X509Utils class in r2277 that contains the following methods to 
implement the requested functionality:

* List<GeneralName> getSubjectAltNames(
      final X509Certificate cert, final GeneralNameType ... types)
* List<String> getSubjectNames(
      final X509Certificate cert, final GeneralNameType ... types)
* X509Certificate findEntityCertificate(
      final Collection<X509Certificate> candidates, final PrivateKey key)

Original comment by marvin.addison@gmail.com on 23 Feb 2012 at 3:21

[GoogleCodeExporter]

Those methods look fine.  Two general comments about the ExtensionReader 
mechanism:

First, it's unfortunate that one has to new what is essentially a stateless 
object in order to get a specific type of data from a cert. We have use cases 
where we process 5-10 thousand certs in a single set of work.  That in turn 
results in 5-10 thousand objects created unnecessarily.

Second, the more helper classes there are the less likely a developer will be 
to find the one that has the best method for them to use.  For example, I 
wouldn't have thought to look at ExtensionReader for a helper method to read 
the SKI.  Instead I just assumed it was some mostly-internal class used when 
reading in certs from some encoded format.

Original comment by claj...@gmail.com on 1 Mar 2012 at 3:14

[GoogleCodeExporter]

I appreciate the feedback.

In defense of the design of ExtensionReader, the objective was to create a 
component that could easily read multiple extensions from a certificate, which 
met the needs of use cases we had encountered to date.  It was not optimized 
for handling workloads at the scale you mentioned.  I imagine it would take a 
lot more engineering effort than simply refactoring ExtensionReader to reduce 
object allocation.  In fact, after some code review I simply don't see how to 
avoid creation of temporary byte buffers that hold the encoded fields that are 
parsed into types in the x509.types package.  Those buffers would have by far 
the greatest memory cost in your parsing scenario, well beyond that of a single 
ExtensionReader object reference.

I believe your second point has merit.  In response I created some helper 
methods on X509Utils to expose reading some or all of the extension fields from 
a certificate.  See r2297 and r2298 for details.

Original comment by marvin.addison@gmail.com on 2 Mar 2012 at 2:35

[GoogleCodeExporter]

Original comment by marvin.addison@gmail.com on 5 Mar 2012 at 6:43

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by marvin.addison@gmail.com on 5 Mar 2012 at 6:45