Monday, June 26, 2017

Introducing the EJBCA RA, Part 1: Introduction

Where we are now

One the primary complaints we here at PrimeKey get about EJBCA is about the design of our interface, or rather the lack of thereof. We've come a long way from being a tiny open source project to being one of the primary PKI software vendors globally, so while we maintain our dedication to delivering a powerful and secure product, it's time for us to give our users a bit of a break.

The Public Web 



A major feature EJBCA has always been lacking is a dedicated RA. The Public Web, while basically functional, is merely a rudimental interface for performing RA functions, one which only works locally, needs to be used in conjunction with the CA web, and is not in a state that can be considered deployable to the end user.

Many of you reading this have in all likelihood designed your own personal RA using CMP, SCEP or our WebService interface, which brings us to our next topic. Most CA installations are understandably hesitant to expose their CAs to the wild in order to interact with an RA, but instead protect it using a firewall. Currently we provide the standalone ExternalRA, an asynchronous proxy meant to reside outside the firewall, restricted to only being polled by the RA.


What is in store

Those of you familiar with EJBCA Enterprise will hopefully be a bit familiar with the EJBCA's RA Web. We released it back in EJBCA 6.6.0, and with the refinements being done in EJBCA 6.8.0 and beyond.

The EJBCA RA in EJBCA 6.7.0
The RA is the herald of the end of the Public Web and of ExternalRA. By the end of this year we will be discontinuing these two modules and removing them. So what does this mean to you? Well, quite a bit, and all of it good. The RA is in fact designed to completely supersede the Public Web, while providing quite a bit more functionality and improved design, aside from being a whole lot prettier.

Not only that, but by using the Peers protocol introduced in EJBCA 6.3.0, one instance of EJBCA can be set up in the DMZ as a proxy to another acting as CA within the confines of the firewall, responding to synchronous polling from the CA and communicating over TLS instead through database polling.

That's it for now, but follow us for an additional couple of blog posts. Part 2 will take a close look at the EJBCA RA and how to transition to it from using the Public Web, while Part 3 will talk about setting up an RA Proxy, as well as discuss some future ideas for the RA.

Cheers!
Mike Agrenius Kushner,
Product Owner EJBCA

Friday, June 9, 2017

A Sneak Peak into EJBCA 6.8.0: Roles, Rule and RA

So we're finally coming into the last sprints of the current release, testing and fixing bugs as we go. We're expecting the final drop of EJBCA 6.8.0 in the end of June, but in the meanwhile I'd like to talk about and demonstrate some of the new features we've implemented.

Improvements to Roles and Rules

So I know firsthand that one of the more complex and confusing aspects of administrating EJBCA are the roles and rules system. While we're not quite so brave as to redesign the rules system entirely, we've taken several steps to simplify rules administration, and make the capabilities of each role clearer. 

Simplified Rule Administration

You're probably all familiar with the current look and feel of the rules page:

In 6.8.0 we've made some simple improvements which we very much hope will improve usability. From now on, the same page will look like this:



I would like to draw your attention to several features:

  • We've removed the Unused-state and the Recursive-cbeckbox and replaced them both with the Inherit-state. It simply means to inherit whatever rights were set further up the tree (in the above example, setting Allow to /ca_functionality will give access to /ca_functionality/activate_ca and all other subsequent rules, unless they've been specifically set to Deny
  • In order to simplify overview, we made a conscious choice to go from drop-downs to radio buttons, as well as differentiating between leaf rules and branches by color. 
  • Rules are automatically normalized, which means that when saved the rule-set will automatically be minimized to its smallest possible size. Rules which are invalid or redundant are automatically culled. 

Rule Summary

If you check out the top right, a new meny option has been added to the navigation menu:
Clicking on it will bring up a summary of the active rule set for the role (after normalization, see above).

Role Namespaces

We've recognized that there may be many disjunct groups of users administrating EJBCA, all of which may not need to know of each other. In order to minimize confusion in naming Roles, we've added the concept of namespaces.
Belonging to a role in blank namespace (to which the Super Administrator Role belongs) gives access to all namespaces, while all other roles will only see the namespaces to which they themselves belong. In other words, an administrator belonging to WidgetCorp's namespace will only see the WidgetCorp roles. In addition to that, if the administrator only belongs to a single namespace, then the whole column will be hidden and they will never be aware of any other roles at all. 

Roles in the RA

We hope that you've all been following the exciting new development that came in version 6.6 last year, our very own proxyable RA! In EJBCA 6.8.0 we've also extended roles and rules administration to the RA, allowing end users on a proxied RA to manage their own users and rights without needing to access the CA.

CMP Proxy and Windows AutoEnroll Proxy

We're slowly migrating away from the legacy ExternalRA, as well as the CMP and SCEP Proxies. The reasoning behind and advantages to this will be explained in future blog posts, but for now I'd like to let you know about two new features we've introduced in 6.8.0. If an installation of EJBCA has been set up as an RA for a CA installation, it can now proxy both CMP messages and the Windows AutoEnroll feature we introduced in EJBCA 6.7. No special configuration is needed: simply send the messages to the RA as usual, and if it has contact with a CA it will automatically pass the messages on. 

Approval Profiles

Lastly, we decided to build a bit upon the concept of Approval Profiles that was introduced in EJBCA 6.6. In previous versions, only a single approval profile could be to cover for all actions for a CA or Certificate Profile.
CA settings

Certificate Profile settings
In EJBCA 6.8 we've somewhat more intuitively made it possible to set a profile per action, meaning that you don't need to have the same approval workflow for adding end entities as for revocations. 
CA settings

Certificate Profile Settings

Now, that's all for now. We're expecting EJBCA 6.8.0 to pass QA and be released by the end of next week, which will be announced through all the usual channels. On behalf of all of us at PrimeKey Solutions I'd like to wish you all an excellent summer, and check back here during the coming weeks for a series of blog posts about our new RA!

Cheers!
Mike Agrenius Kushner
Product Owner EJBCA

Thursday, June 1, 2017

From PrimeKey Tech Days 2016: Certificate Transparency

Ryan Hurst, Product Manager at Google, talks about Certificate Transparency. What are lessons learned and shape of things to come.




Wednesday, May 24, 2017

From PrimeKey Tech Days 2016: How to be ready for tomorrow’s quantum attacks Vladimir Soukharev

By Vladimir Soukharev, Ph.D. Cryptographer at InfoSec Global Group


Wednesday, April 19, 2017

DNS CAA to be Mandatory from September 2017

The Vote

Back in March, the CA/Browser Forum (CABForum) held a vote for Ballot 187 - Make CAA Checking Mandatory. The vote passed with a resounding 19 out of 21 CAs voting 'yes' (one 'no' and one 'abstain') and all three participating browsers in favor [1]. The practical result of this is that starting September 8th of 2017 it will become mandatory for CAs to consult CAA records before issuing certificates. [2]

The Current State of the PKI Ecosystem  

A commonly lifted obstacle in PKI infrastructure is the issue of the Web of Trust. Through the years we've seen on several occasions how that trust can be violated, i.e when a CA goes rogue, becomes compromised, or fails to follow its own regulations. This was illustrated back in 2011 by the infamous breaches of the Comodo and DigiNotar certificate authorities where both CAs issued wildcard certificates for several high profile domains, or just this year when Google Chrome downgraded certificates issued by Symantec due them to issuing test certificates to Google domains without Google's knowledge. [3]

Several combined efforts have been made to solve the inherent vulnerabilities to this system. So far, no single solution is all encompassing, and even the overlap of every solution proposed doesn't create a foolproof system. Certificate Transparency [4] is one such effort, and has been been supported by EJBCA Enterprise since EJBCA 6.0.4, released in early 2014. [5]

So what is DNS CAA?

DNS Certificate Authority Authorization is defined in RFC 6488 [6] and defines a requirement for CAs to make a pre-issuance check, according to the certificate policy set, with a record stored at the DNS of the affected domain. Any CA without authorization from the DNS will be warned not to issue a certificate. 

Essentially, it allows the end client to restrict which CA's they consider trustworthy, and since the vote at CABForum, this implies any CA not enforcing CAA. While this does not guard against CAs going rogue (by ignoring CAA), it allows domain owners to restrict issuance to CAs whose security and policies they trust, and to exclude less trustworthy (but still CAA enforcing) CAs from the web of trust. 

How does this affect EJBCA?

Here at PrimeKey we more than welcome any efforts to improve the state of the PKI ecosystem, so naturally we were delighted to see the results of the vote at CABForum. While CAA hasn't been a priority for us until now (due to little demand), we've moved up our roadmap. Thus we've slated CAA for EJBCA 6.9.0, which will be released to by August 4th 2017, a month before CAA becomes mandatory. CAA will be an Enterprise feature only

On behalf of the EJBCA Development Team, 
Mike Agrenius Kushner,
Product Owner EJBCA

[1] https://cabforum.org/pipermail/public/2017-March/009988.html
[2] https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-mandatory/
[3] https://arstechnica.com/security/2017/03/google-takes-symantec-to-the-woodshed-for-mis-issuing-30000-https-certs/
[4] https://www.certificate-transparency.org/
[5] http://blog.ejbca.org/2014/06/certificate-transparency-with-ejbca.html
[6] https://tools.ietf.org/html/rfc6844

Wednesday, May 18, 2016

What does eIDAS compliance mean for a PKI?

The new eIDAS regulation that has been adopted in the EU (by 1 July 2016) comes with a new set of standard documents from ETSI, specifying particular requirements on PKI. The two new eIDAS standards relevant for PKI are:
  • EN 319 411 - Policy and security requirements for Trust Service Providers issuing certificates
  • EN 319 412 - Certificate Profiles
The standards are maintained by the standardization body ETSI and can be downloaded from the ETSI download area.

What new requirements do these standards come with? Looking closely there are only two new things needed to be able to claim "eIDAS compliance":
  • A new DN attribute organizationIdentifier
  • New fields in the QCStatement certificate extension
Let's dig a little deeper into these two requirements.

OrganizationIdentifier

OrganizationIdentifier is a DN attribute with OID 2.5.4.97 specified in X.520. This is an attribute that has, to my knowledge, never been in common use in certificates before. Its usage in the eIDAS context is described in the following sections of EN 319 412:
  • EN 319 412-1 section 5.1.1 and 5.1.4
  • EN 319 412-2 section 4.2.3.1 and 4.2.4
  • EN 319 412-3 section 4.2.1
OrganizationIdentifier is supported in EJBCA Enterprise PKI from version 6.5.2.

QCStatement

There is already a QCStatement extension in use since long. With the new standards comes a few additions.

The new items in the QCStatement extension are:
  • QcType, claiming that the certificate is a EU qualified certificate of a particular type
  • PdsLocation, location of PKI Disclosure Statements (PDS)
The QCStatement is described in:
  • EN 319 411-2 section 6.6.1
  • EN 319 412-1 section 5.1.1 and 5.1.2
  • EN 319 412-2 section 5.1 and 5.2
  • EN 319 412-4 section 4.2
  • EN 319 412-5, full technical description
With the convenient ability to define custom extensions in the EJBCA GUI (since EJBCA 6.4.0) the new QCStatement extension can be easily added to any certificate profile.

EJBCA Enterprise

We strive to support all relevant open PKI standards and it is important to keep EJBCA Enterprise up to date with new and emerging standards. Since EJBCA 6.5.2 eIDAS compliance should be easily achieved on the level of PKI.

More information  

Basic information on EJBCA Enterprise PKI and PKI Appliance developed by PrimeKey.
EJBCA is a registered trademark of PrimeKey Solutions AB in the EU, the United States, Japan and certain other countries.

Wednesday, April 13, 2016

USB 3.1 Certificate Authentication with EJBCA

A USB standard for authentication of devices has been released a little while ago [1] as part of USB 3.1.

In short, the standard specifies the use of:
  • X509v3, DER encoding certificates 
  • ECDSA using the NIST P256 (a.k.a. secp256r1) curve, uncompressed point format 
  • SHA256 
SubjectDN fields should be:
  • CN: USB:<vendor ID>:<product ID>
  • O: organization name attribute shall contain the human-readable name of the organization that owns the private key 
  • DN Serial Number: lowercase hex-encoded value of the binary data (e.g. wafer number, lot number, production lot, etc.) necessary for uniqueness. 
In addition, there is one new certificate extension:

Custom certificate extension USB-IF ACD (OID 2.23.145.1.2): Seems to contain static data in an OCTET STRING, which can be added via EJBCA Admin GUI.

Conclusion: EJBCA should be able to issue such certificates.

[1] "USB Authentication Specification Rev. 1.0, March 25, 2016" http://www.usb.org/developers/docs/