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/

Saturday, December 5, 2015

13 Hardcore EJBCA PKI options explained

This blog post is based on my 'Hardcore PKI' presentation at PrimeKey Tech Days 2015. The EJBCA functions described can help you integrate PKI more efficiently for specific use cases.

What is hardcore PKI?

Technologies such as ASN.1 and X.509, RSA and ECC Standards and APIs are extremely complex for most users and developers, and the important process of fitting them all together in standards (to enable interoperable systems) is very hard. However, implementors of PKI systems don't have to care about these hardcore technologies due to a few helpful tools:
  • ASN.1 parsing is done using the library BouncyCastle
  • Digital signatures with RSA and ECC is also done either using BouncyCastle in software, or it is done in Hardware Security Modules.
  • Standardization is done by organizations such as IEFT and Oasis.
When people think about PKI they often think about hardcore technologies, but because of these handy tools, the technologies themselves are not what is hardcore about PKI.

The Devil is in the Detail

Hardcore PKI, in my opinion, is that everybody needs and uses PKI, but always in slightly different ways. This demands from the PKI to have the ability to support a lot of different architectures (which EJBCA does) and from you to be able to configure and fine tune your PKI according to your precise needs. The devil is in the details!
The many possibilities of configuring several details is really the hardcore part in PKI.

Thirteen EJBCA options explained

Here are thirteen examples of hardcore details that can truly make your PKI better integrated. But unless you are looking for one or more of these specific features,  these options may appear somewhat incomprehensible.
One reason for EJBCA to provide all these functions is to support policy enforcement all the way from Complete Enforcement by the CA, to All Enforcement in the RA (where the CA trusts the RA blindly).
On to the details! Most of the options are also described in the EJBCA User Guide.

Permissions
EJBCA Certificate Profile override and certificate storage options
EJBCA Certificate Profile options: override and certificate storage
  • Allow validity override – Normally validity is determined by the certificate profiles, but with this option the validity period can be taken from the request sent by the client/RA.
  • Allow extension override – Normally certificate extensions are determined by the certificate profiles, but with this option the extensions can be taken from the request sent by the client/RA.
  • Allow DN override – Normally the DN is pre-registered and determined by the end entity record, but with this option the DN can be taken from the request sent by the client/RA.
  • Use Certificate storage – An interesting option where you can choose to not store issued certificates in the CA database. This fits specific use cases where revocation never needs to happen and you want to issue large amounts of certificates without the burden of administrating a growing CA database. A kind of fire and forget CA.

Other data
EJBCA Certificate Profile CN postfix and single active certifiate options
EJBCA Certificate Profile options: CN postfix and single active certificate
  • Use CN postfix – tells the CA to add some text after the CN in the issued certificate. Can be used to get user friendly names (like 'Tomas – Encryption' and 'Tomas – Signing') in browser certificate dialogues.
  • Use DN and altName subset – use this if you want to register more information about end entities, than is visible in the issued certificate.
  • Approvals – enforces dual control (or four eyes principle) for certain functions such as revocation and key recovery.
  • Single Active Certificate Constraint – automatically revokes an end entity's old certificate when a new certificate is retrieved. This ensures that a user or device can only use one certificate at a certain point in time.

Directives
EJBCA Certificate Profile enforce public key and DN options
EJBCA Certificate Profile options: enforce public key and DN
  • Enforce unique public keys – makes two end entities unable to use the same public key.
  • Enforce unique DN – makes two end entities unable to share the same subject DN.
  • Enforce unique Subject DN SerialNumber - makes two end entities unable to share the same SerialNumber component in the Subject DN. The SerialNumber in the DN is typically used for device serial numbers, thus ensuring that one device is only registered as a single end entity.
  • Use User Storage – when disabled, end entities are not stored in the database when issuing certificates through an RA capable protocol. Saves space in the database, but removes some functionality.
  • Use Certificate Storage – when disabled, certificates are not stored in the database when issued. This option enables issuing of billions of certificates without using any storage space, but on the other hand disables several of the commonly required PKI functions such as revocation.

The Key Take Aways

All of the obscure functions described above are used in real life, for various use cases. Some very domain specific, some more generic. The key take away, is that these functions provide short-cuts for use cases where you thought you would have to do work-arounds, or be limited by the capabilities of a specific product. With the functions described (and several others) you can integrate PKI in your use case in the most efficient way, only having your imagination setting the boundaries.

EJBCA Enterprise

In EJBCA Enterprise we strive for maximum flexibility, only having a single platform to manage all needs of PKI. This means EJBCA has to be available for all platforms, and be ready to implement many protocols and multiple APIs, while enabling you to use your PKI from many locations. In order to do this we need to support many different PKI architectures (as was explained here).

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.