Friday, September 20, 2013

SignServer 3.4.2 released

The PrimeKey SignServer team is happy to announce that SignServer 3.4.2has been released!
This is a maintenance release with in total 13 tickets resolved.

The most noteworthy changes can be seen below. Development continues beyond this version and all requests from the community are scheduled for SignServer 3.4.3 or later releases. More information is available at the project web site and the complete changelog can be viewed in the issue tracker.

Major new features and improvements:
  • Uses PKCS#11 crypto token implementation from the Common Criteria certified CESeCore
  • Support for starting audit log verification from a specified sequence number
  • Option to archive all X-Forwarded-For addresses
  • Option to include the ordering field in time-stamp tokens even if the
  • field has value false
  • Option to not include the signingTime CMS attribute in time-stamp signer
  • Option to cache PKCS#11 key reference to increase performance
  • Includes IssuerSerial in the SigningCertificate attribute in
  • time-stamp signer
Bug fixes:
  • HSM auto activation was not working when signed audit log were used
  • Key generation was not working with slotListIndex
  • ClientCLI over web services was not working unless includemodulesinbuild was specified 
Regards,
The PrimeKey SignServer team

Wednesday, September 18, 2013

Certificate Transparency and PreCertificates, how will that work?

The Certificate Transparency initiative (RFC6962) is an admirable suggestion to improve security of TLS web session for certificates issued by public CAs. It has cool technology with Merkle trees, is admirable short and could have been straight forward was it not for something called PreCertificates. PreCertificates are hard for me to understand, I don't like them. I hope it is because I don't understand them...if so please let me know.

Writing this post is a way to sort things out for myself and I'd be happy to edit this post if explained why I "just don't get it". Of course I am posting this to the CT forum as well...

In the sake of transparency, I'm writing with the view point of an implementer of open source CA software (if you didn't figure that one out from the blog name:-)).

Update 1: I got lots of comments already over at the Certificate Transparency Forum, really good.

Update 2: I created an issue in the Certificate Transparency issue tracker. https://code.google.com/p/certificate-transparency/issues/detail?id=18

Update 3: Of course my views on CT changes as the discussion continues, the post below was my original starting point. Follow the discussion in Update 1 for updates.

Update 4: EJBCA will support Certificate Transparency in EJBCA Enterprise eventually, watch out for news.

On to PreCertificates...

PreCertificates are defined in section "3.1. Log Entries" as (text trimed by me) "The Precertificate is constructed from the certificate to be issued by adding a special critical poison extension to the end-entity TBSCertificate". Then it describes how it can be produced and it is mentioned throughout the spec in many places.
A PreCertificate is a essentially a certificate signed with one of two options:

1. PreCertificates signed by the real CA.
This sounds very dangerous as will break the fundamental X.509 rule of unique issuerDN/serialNumber pairs. The consequences of having two "certificates" with the same issuerDN/serialNumber in the wild can not possibly be estimated, making this practice quite dangerous imho.

2. PreCertificates signed by a separate PreCertificate signing CA, which is a SubCA to the real signing CA. This is a less scary, since it is normal practice that different CAs can issue certificate with the same subjectDN/serialNumber, just not the same issuerDN.

The actual implementation of issuing PreCertificates makes it quite impractical. I would believe that most CA implementations creates the TBSCertificate as part of the actual certificate issuance. The CA will not create the TBSCertificate to have is lying around for a couple of days before using it to issue the real certificate.
Thus, if the CA is to create a PreCertificate to send to the CT log, it might as well issue the real certificate and send it to the log. The time difference should be in the milliseconds for most CAs.
If the CA wants to wait before distributing the real certificate, to make sure it's in the logs before put into production, it can surely do so as well.

The PreCertificate imho suffers from several complicating factors for implementers, both on the CA and the CT log side. The TBSCertificate must have a poison extension inserted, and removed, effectively re-encoding the ASN.1 TBSCertificate several times, all these are points of failure.

The reason for PreCertificates are not clearly explained. Why would you want to use PreCertificates?

Fine combing through the spec gives me some ideas on why, for example to be able to embed the Certificate extension from PreCertificate CT logs in the final certificate (section 3.3). But the the TBSCertificate of the PreCertificate is then no longer the real TBSCertificate? In that case, why is the PreCertificate the TBSCertificate at all, and not just a new data structure with the data the CT log wants?

The PreCertificate complicates the CT spec by orders of magnitude, which is not a good thing. There are so many ifs and buts about PreCertificate the RFC is not even itself consitent about what it is.

Ok, I know the PreCertificate is is optional, but the best standards, who gets fast, wide and robust deployment, are the simpler ones (KISS). Skipping PreCertificates from the CT spec makes it so much simpler.

My suggestion:
- Skip PreCertificates altogether

I see though why people will not accept that just because I say something...so in that case

- Explain the purpose behind PreCertificates well
- Describe what the actual information fro PreCertificate are used
- Be consistent throughout in the RFC

Feel free to contact me at tomas a t primekey dot se.

Thursday, September 5, 2013

What's new in EJBCA 6. Part 2: CMP aliases and GUI configuration

Welcome to the second part of the series about what is new in the upcoming EJBCA 6.
For the first part in the series, read Part 1: Crypto Tokens in GUI.

In part 2 we will take a look at new major features in the EJBCA support for the CMP protocol, RFC4210.
EJBCA has supported RFC4210 all the way since EJBCA 3.4 in 2005.
(for the history inclined, see ECA-99).

CMP is a very complex protocol with literally hundreds of different options. And those are just the options that are specified in the RFC, then there is also the question how to process them in the back-end with different types of authorization, auto enrollment, support for both end clients and RAs etc etc. The support in EJBCA for different types of clients and different CMP options have grown step by step over the years and we even implement the somewhat cryptic NestedMessageContent as "Multiprotection support".

Currently there is a single URL to access the CMP server, and a single configuration, cmp.properties, for CMP. This means that when you configure CMP in EJBCA for a specific client (or RA), this is the client that will be interoperable.
If you want to run two different clients against the server, with two different configurations, this is not possible since there is only one URL and one configuration. You can of course deploy two separate servers in a cluster, each server running different configurations, but this is not very nice and feels more like a hack.

Introducing CMP aliases. With the arrival of EJBCA 6 you will be able to configure as many CMP URLs (CMP aliases) as you want, each one with a different configuration. There is a set of default (secure by default) options that each new alias configuration inherits and that you can override for each individual URL.

As an example, I set up this test environment for testing with cmpforopenssl.
  • Client mode with HMAC password authentication on server-address:8080/ejbca/publicweb/cmp
  • Client mode with client certificate authentication on server-address:8080/ejbca/publicweb/cmp/alias1
  • RA mode with fixed HMAC RA password 'password' on server-address:8080/ejbca/publicweb/cmp/alias2
Needless to say, alias1 and alias2 are just strings and you can use anything you like.

At first shot this was configured in a new configuration file, cmpaliasconf.properties.
cmp.alias1.operationmode=client
cmp.alias2.operationmode=ra
etc.

But heck, some people here were not satisfied with that, so lets configure everything in the Admin GUI instead.
You heard it, in EJBCA 6 you will configure CMP in the Admin GUI, and you can select and add new aliases simply by clicking some buttons.
Of course there will also be a command line interface (CLI) so you can script it or simply use the CLI if your administrator certificate has expired (but you don't let that happen do you?).

The new CMP configuration is stored in the database so there is a single configuration across your cluster, configure on one node, see the effects on all.
There will also be a possibility to read in an old configuration file in the CLI, so upgrades from the old style file configuration is easy.

All currently available CMP features, such as the CMP proxy is of course available just as before.

Needles to say, we think this new feature is awesome. Since I don't know much about other products I can't say it is unique, but it's a leap forward in usability for us.
With CMP being used more and more now (after all these years as an RFC) and replacing the simple SCEP protocol, this will ensure that EJBCA can work with many different CMP clients out there, all at the same time.

Part 3 of "What's new in EJBCA 6" will be about a completely new feature called Internal Key Bindings and OCSP Key Bindings. Anyone longing for an Admin GUI for EJBCA standalone OCSP responder?

Until then...check in with PrimeKey, or follow us on Twitter, for the latest news and events.