At the Internet Engineering Task Force (IETF) 85 conference, there was a Birds of a Feather (BoF) meeting on Web PKI operations. The plan will be to start an IETF working group on Web PKI operations, with a mandate to document how the Web PKI currently works.
So, why do we need to do this? The Web PKI has been around since about 1995. The IETF has been documenting PKI for about the same time period. That’s enough time to consider this all to be history. Unfortunately, it is not.
The Web PKI is probably the largest and most used PKI in the world. Many certification authorities (CA) contribute their roots to the Web PKI and these roots are distributed by many browsers and operating systems. The CA industry issues certificates to secure servers, whose trust is then provided by validating that the root certificate is trusted by the software doing the validation.
The issue is that the Web PKI deployment did not follow the IETF standards. Just to be clear, most of the Web PKI does match the standards, but along the way a few items got sidetracked. I won’t go into the reasons why. I’m sure there are a lot of them. However, now with so much history behind us, we may run into the issue of “breaking the web” if we try to fix anything.
So, what’s the big deal? Why worry about this now? Well, why not?
What we have seen over the past are issues that come up that should work, but they don’t. An instance from 2011 was when Comodo and DigiNotar issued fraudulent certificates. If you follow the standards, a simple revocation action should have taken place and the problem fixed. Not the case.
Revocation does not really work with the Web PKI. Many browsers do not have certificate status-checking turned on by default. Those that do have it turned on react to revocation in different ways. Some browsers allow the user to proceed to the website even though it knows that the certificate has been revoked.
The solution for Comodo and DigiNotar was to make changes to the browsers or operating systems. The bad certificates or bad issuing CA certificates had to be disclosed within the software and the trust decision would be made without the revocation information.
Another issue is the implementation of domain name constraints (nameConstraints). The RFC 5280 states that this extension must be marked as critical. If the client application does not understand a critical extension, then it should fail the connection — or break the Web.
As such, the name constraints extension is not used, as many browsers and operating systems do not know what to do with this extension. If we just make the extension non-critical, then the client software that understands it will comply and the software that does not will ignore it and the Web will not be broken.
So, the goal of the working group is to document the Web PKI and look for the problems. As the problem list grows, they will be analyzed. In the future, the group’s mandate may be changed to find solutions to the problems or the problems may be left for another working group to address.