-
Notifications
You must be signed in to change notification settings - Fork 5
Trustchain: Review of Web PKI
This document forms part of the outputs from Phase 0 of the Trustchain project.
It contains a review the list of Technical improvements to the Web PKI from the 2016 IETF memo entitled: Problems with the Public Key Infrastructure (PKI) for the World Wide Web.
For each issue highlighted in that memo, and each of the corresponding improvements described, we evaluate the extent to which Trustchain might contribute to the desired outcome if it were applied in the Web PKI context. At the same time, we consider whether an analogous issue exists in the DID/VC context and, if so, whether Trustchain can provide any mitigation.
Although Web PKI is not the natural context against which to judge the pros/cons of Trustchain, given the distinct nature of the two domains, the comparison is inevitable and there are many similarities. In particular, this activity was motivated by:
- the observation that the portion of the existing Web PKI system which is already used in India for issuance of Verifiable Credentials at scale could be easily and cheaply ported onto Trustchain, and
- certain similarities between elements of Trustchain and Certificate Transparency.
Quoting from Section 3 of the memo:
Over the years, many technical improvements have been made to the Web PKI. This section discusses several problems and the technical improvements that have been made to address them. This history sets the stage for suggestions for additional improvements in other sections of this document.
In the following subsections we consider each of the problems hightlighted in the text, and ask whether the Trustchain system itself could provide any of the desired technical improvements.
This issue can be readily addressed by choosing appropriate verification methods (in the terminology of the DID standard).
Based on the following excerpts, it appears that the transference of the existing CA hierarchy onto Trustchain could provide a valuable opportunity to remove cases of weak algorithms or short keys, replacing them with new certificates (DIDs) using strong cryptographic algorithms.
a long-lived trust anchor or intermediate CA certificate can have a huge number of subordinate certificates. So, removing one because it uses a weak cryptographic algorithm or a short public key can have a significant impact.
However, there are still a great number of certificates that use SHA-1 and 1024-bit RSA public keys, and these should be replaced.
Thorny question: Would there be a need to change the public keys in the Trustchain root DID at some point? If so, what would this involve? Another public event? Is this realistic? Could we renew DIDs in the root transaction and continue to use them, or would this break the timestamped trust anchor?
Partial answer: There are two options here. The first is to assign "controller" keys to the root DID, which are intended to be unused except for the purpose of resetting the root, and which entail a particularly strong cryptographic algorithm and a particularly long key (adding no cost initially, as these keys aren't used for verification in the original iteration of the system). If/when the original root DID is to be replaced, these keys can be used to create a new root DID that can still be traced back to the original timestamp. The second option is to repeat the public event, creating a new root of trust, and gradually migrate activity to the new tree, while continuing to use the original one until expiry of all outstanding credentials. Since credentials are likely to be time-bound anyway, the main downside of this approach is that a new "red letter day" must be embedded into the public consciousness. How realistic this is will depend on the length of the period between the consecutive public events and the level of adoption enjoyed by the system.
This issue relates to the checking of revocation lists. In the Web PKI context, web browsers are responsible for performing certificate status checks but they may fail to do this due to the disincentives of added latency and bandwidth costs.
In Trustchain, the client (mobile or desktop) would periodically check for revocation events that affect DIDs in which the user is interested. The issue of additional latency is far less significant in a DID/VC scenario compared to a Web PKI scenario. In the latter, a status check that delays the loading of a web page by a few seconds is prohibitively expensive, whereas users are prepared to wait significantly longer for security checks (e.g. in online credit card payments). Therefore this problem is not particularly relevant in the context of digital ID.
Whether the Trustchain infrastructure could mitigate the problem in the context of Web PKI is not immediately obvious. Latency and bandwidth are cited as factors that make it too expensive, but it's unclear why certificate status checks cannot be performed in parallel, while allowing initial access to a site based on a (apparently) valid certificate. The browser's connection status would initially be amber, intermediate between green & red. Then, if the certificate is discovered to have been revoked (or the status check fails to complete), the user is informed and the connection status changes to red.
Trustchain might offer some help, in particular if the above approach is workable, because it would make the "revocation message board" a single source of information and a very transparent one. As soon as revocations are detected, they could be immediately shared between network nodes (both light and full nodes), assuming there aren't so many revocations as to make the continuous use of bandwidth for this purpose problematic.
S3.2.1. Short-lived Certificates
These are a good idea in any case. (The same may well be true of VCs, depending on the use case.)
The potential for improvements via automation is interesting (from the perspective of Trustchain client software design):
In practice, implementation of short-lived certificates requires automation to assist web server administrators
S3.2.2. CRL Distribution Points
This improvement is about limiting the maximum size of certificate revocation lists, but the measure is apparently inadequate:
Few CAs take advantage of the CRLDP certificate extension to limit the size of CRLs. In fact, there are several CAs that publish extremely large CRLs. Browsers never want to suffer the latency associated with large CRLs, and some ignore the CRLDP extension when it is present. Browsers tend to avoid the use of CRLs altogether.
In Trustchain, DIDs are revoked individually and the client software (via the ION layer) should be continuously scanning for published revocations.
These bitesize lists may provide an improvement similar to, or even better than, that introduced in RFC 5280. See also the subsection below on OCSP Stapling.
S3.2.3. Proprietary Revocation Checks
Some browser vendors provide a proprietary mechanism for revocation checking. These mechanisms obtain revocation status information once per day for the entire Web PKI in a very compact form.
This excerpt raises an interesting point: in Trustchain the infrastructure is openly accessible and the client software is open source so anybody can develop mechanisms for improving the flow of useful information such as DID revocation status. Instead of browser vendors providing proprietary mechanisms, we might see open source developers working together to incrementally develop better client & server side software.
S3.2.4. OCSP Stapling
Browsers can avoid transmission of CRLs altogether by using the Online Certificate Status Protocol (OCSP) RFC 6960 to check the validity of web server certificates.... In addition, RFC 6961 defines the TLS Multiple Certificate Status Request extension, which allows the web server to provide status information about its own certificate and also the status of intermediate certificates in the certification path.
So, in the OCSP model, the browser makes a request to the web server for (revocation) status information regarding its certificate or (in the MCSR extension) regarding the whole chain of certificates in the certification path.
This "whole chain" is precisely the information that a Trustchain node would obtain (and validate) using ION.
By including this extension in the TLS handshake, the browser asks the web server to provide an OCSP response in addition to its certificate. This approach greatly reduces the number of round trips by the browser to check the status of each certificate in the path.
This point about minimising the number of the round trips is worth bearing in mind when we come to develop client software that will request SPV proofs. Instead of requiring a separate request for each DID transaction it would be preferable if the protocol can support a single request for the whole chain.
Light clients would want to periodically check for updates to chains in which they are already interested and store status information for all such entities in some compact format.
All of the CAs in the trust store are equally trusted for the entire domain name space, so any CA can issue for any domain name. In fact, there have been certificates issued by CAs that are surprising to the legitimate owner of a domain. The domain name owner is surprised because they did not request the certificates. They are initially unaware that a CA has issued a certificate that contains their domain name, and once the surprising certificate is discovered, it can be very difficult for the legitimate domain name owner to get it revoked.
The issue mentioned here, of an entity being unaware that a certificate has been issued for their domain, is certainly one which might be mitigated by the inherent transparency of the Trustchain approach. Discovery of a surprising certificate would be almost immediate provided the domain owner is running a node. (See also the subsection Certificate Transparency).
The point about the difficulty of getting the surprising certificate revoked is also interesting. Presumably this is due to the fact that, in this scenerio, two certificates have been issued for the same entity by two different CAs. So the CA that issued the second (surprising) one does not recognise the primacy of the first one. There is no trusted piece of information that would allow the distinction of the surprising certificate from the original one.
Further, browsers and other relying parties cannot distinguish a certificate that the legitimate domain name owner requested from a surprising one.
Verifiable timestamping in Trustchain offers a potentially significant benefit here, because the legitimate certificate is necessarily anterior to the surprising one. By verifying the proof of work, all parties can independently determine which certificate should be deemed legitimate, by following the simple rule that the one with the earliest timestamp (and no corresponding revocation) takes precedence.
This is analogous to the way in which Bitcoin itself solves the double spending problem. Miners establish a strict total order on the set of transactions by batching them into timestamped and linked blocks, creating a chain that becomes ossified by cumulative proof of work. This enables a consensus to be reached across the network regarding the ordering of transactions, with the earliest one deemed legitimate in case of conflict. Exactly the same mechanism can be used to reach a consensus on the order of DIDs, and thereby consistently identify the legitimate one among any number of candidates, without the need to trust any particular third party, even those represented in the Trustchain tree.
In addition to the advantage of verifiable timestamping, the decentralised nature of Trustchain offers another benefit. In the Web PKI hierarchy, the trusted entities are CAs whose institutional identity is unlikely to be recognisable to either the certificate holder or the relying party. By contrast, in the decentralised Trustchain model the links in the chain of trust represent institutions or other legal entities that are familiar and recognisable. For instance, in the digital degree certificate example the credential issuer is a UK university and the intermediate link in the chain is the DfE, which is easily recognisable as a department of the UK government. Any other entity publishing a dDID in which the subject is a UK university will be immediately suspicious. Therefore the legitimate chain of trust is recognisable as such.
Since all of the CAs in the trust store are equally trusted, any CA can issue a certificate for any domain name.
This excerpt further highlights the preceding point. In the CA hierarchy, all of the CAs (in the local trust store) are equally trusted and can issue a certificate to any entity.
In Trustchain, each chain of trust is distinct and the entities making up the chain are clearly visible, making it possible to ascribe different levels of trustworthiness to different chains and at different times, based on various factors including:
- the timestamps associated with each link in the chain
- the number of links in the chain
- the identities of the trusted entities in the chain
- the level of permission (for publishing dDIDs) granted to each entity in the chain
- the geographical relationship between upstream and downstream entities
- the sensitivity of the particular use case.
This more nuanced appraisal of trust relationships is particularly beneficial in the context of digital identity, where the consequences of false positives or negatives in the authentication process vary a great deal between different use cases.
There are known cases where attackers have thwarted the CA protections and issued certificates that were then used to mount attacks against the users of that web site. For this reason, all of the CAs listed in the trust store must be very well protected.
Instead of trusting implicitly any one of a list of CAs in the "trust store" (held locally and curated by browser or OS vendors), in Trustchain the list of trusted entities is published on a universally accessible, append-only message board which is monitored continuously by many network participants.
When a CA issues a certificate to a subordinate CA, the inclusion of widely supported certificate extensions can reduce the set of privileges given to the sub-CA. This aligns with the traditional security practice of least privilege, where only the privileges needed to perform the envisioned tasks are provided.
Similarities here with the notion of permissions in Trustchain (allowing simple attestation versus delegation to extend the chain).
Some major implementations have not fully implemented the mechanisms necessary to reduce sub-CA privileges. For example, RFC 5280 includes the specification of name constraints, and the CA/Browser Forum guidelines [CAB2014] encourage the use of dNSNames in permittedSubtrees within the name Constraints extension. Despite this situation, one major browser does not support name constraints, and as a result, CAs are reluctant to use them.
This excerpt raises an interesting idea: if we could encode name constraints in a DID then the constraints could be enforced cryptographically, rather than merely with guidelines that entities are encouraged to follow. Downstream DIDs would simply be considered invalid if they violate the constraints encoded in the upstream DID.
It may be possible to do this using multisignatures or conditional signatures, with the result being a constrained dDID. (Note: more details on this idea, and the related idea of constrained VC issuance, can be found in the Trustchain technical notes.)
The aim is for the upstream entity to be able to issue a downstream DID to another entity that imposes constraints on the sorts of dDIDs that the downstream entity can itself issue.
In the Web PKI context this is analogous to the root CA issuing a certificate to a subordinate CA which imposes constraints (e.g. name constraints) on the types of certificates that the sub-CA can issue to domain owners.
Here's how it could work. The upstream (e.g. root) entity creates a dDID for the subordinate, such that any lower-level dDIDs created by the subordinate must be signed by both the subordinate and the upstream entity. That is, the verification method in the subordinate's DID is a 2-of-2 multisignature, where both the upstream and subordinate entities must sign for the signature to be valid. (With the Schnorr signature scheme, multisignature verification methods look the same as single signature ones, i.e. a single public key, and a valid multisignature is obtained by summing the individual signatures, provided the messages they signed are identical. However, both parties must use the same nonce when signing, which may be problematic, in which case an alternative conditional digital signature scheme may be needed for this application.)
When the subordinate entity wants to issue a dDID, it collects the information and constructs a candidate DID document but does not attempt to publish it (because, without the upsteam entity's signature, this DID is invalid). To get the upstream entity's signature, the subordinate makes an API call to the upstream entity (using an endpoint provided in their own uDID), passing the candidate DID document.
The call to the upsteam entity's API returns a conditional signature that is valid if and only if the exact same DID document is subsequently signed by the subordinate entity. The point is that the call to the API provides the upstream entity with the opportunity to check that the constraint is not violated. The logic behind the API call takes the candidate DID document, checks the constraint, hashes the document, signs the hash and returns the conditional signature. If the candidate DID violates the constraint, an error is returned by the API.
Assuming the constraints are respected, the subordinate entity now has a partially-signed hash of the candidate dDID document, and only needs to add its own signature to make it a valid dDID that can be published.
Notice that the upstream entity does not need to be directly involved in the construction of the final dDID, except by providing the API endpoint, because the logic for checking the constraint can be encoded and a conditional signature provided automatically that will only be valid if the final version of the dDID exactly matches that which was sent to the API.
Also, the reference software client can include the API logic so the upstream entity need only specify the particular constraints they wish to impose on the subordinate at the time of creating their dDID, and the rest is automatic.
As well as name constraints, this mechanism could be used to impose the Trustchain delegation permissions.
[It could also be used to impose constraints on the nature of the VCs that can be issued by the subject of a dDID (e.g. to restrict the attributes about which the VC makes assertions). After all, a dDID is essentially a VC.]
S3.3.1. Certificate Authority Authorization (CAA)
The Certificate Authority Authorization (CAA) [RFC6844] DNS resource record allows a domain administrator to specify one or more CAs authorized to issue certificates that include that domain name. Then, a trustworthy CA will refuse to issue a certificate for a domain name that has a CAA resource record that does not explicitly name the CA.
To date, only one major CA performs this check, and there is no indication that other CAs are planning to add this check in the near future.
This appears to substantiate the point that constraints must be enforced cryptographically if they are to be effective.
S3.3.5. Certificate Transparency
There are some interesting parallels between CT and Trustchain and the two approaches are compared in this Q&A thread.
There have been several attempts to provide automation for routine tasks that are performed by web server administrators, such as certificate renewal. For example, some commercial tools offer automated certificate renewal and installation.
There is enormous potential for automation of routine tasks in Trustchain because processes can be built into the reference software client, instead of being left to commercial tools. Routine tasks include: dDID renewal, challenge-response on initial enrollment, specifying & enforcing constraints in conditional dDIDs.
S4.1. Determination of the Trusted Certificate Authorities
A very basic question for users of the Web PKI is "Who do you trust?" The system for determining which CAs are added to or removed from the trust store in browsers has been perceived by some as opaque and confusing.
In Trustchain, the entities in the chain are expected to be familiar institutions whose trustworthiness users are in a position to judge. Therefore the related issues of i) whether a particular CA should be trusted and ii) how the list of trusted CAs is maintained, are avoided.
The guidelines provided by the WebTrust program [WEBTRUST] provide a framework for removing a CA from the trust store. However, the implications of removing a CA can be significant. There may be a few very large CAs that are critical to significant portions of Internet infrastructure. Removing one of these trusted CAs can have a significant impact on a large cross section of Internet users resulting in potentially large numbers of websites no longer being trusted.
This issue applies equally to Trustchain. Revocation of the DID of an upstream enitity near or at the root could impact a large number of users and institutions.
S4.2. Governance Structures for the Web PKI
Since the Web PKI is widespread, applications beyond the World Wide Web are making use of the Web PKI. For example, the Web PKI is used to secure the connections between SMTP servers. In these environments, the browser-centric capabilities are unavailable. For example, see Section 3.2.3 on proprietary revocation checks. The current governance structure does not provide a way for these other applications to participate. How do we ensure that these other applications get a voice in this forum?
No mention is made here of using Web PKI for Verifiable Credentials, but as Pramod Varma (member of the project's International Advisory Board) pointed out this practice is already widespread in India. However this excerpt (and the preceding paragraph in the memo) hints at the need for more decentralisation.
There is ongoing work to improve the security of the time synchronization infrastructure, and it will use certificates to authenticate time servers. Since the certificate infrastructure relies on quality time synchronization, this dependency creates a boot strapping issue.
While in the case of Web PKI the the Bitcoin block time may be too coarse, for Trustchain it fixes this issue by providing a universal & verifiable time server.
S6. Recommendations for Improving the Web PKI
Priority recommendations in the memo are for:
- Improved certificate status checking.
Trustchain offers several advantages associated with transparency & accessiblility (of the Bitcoin blockchain), openness (of the software) and automation (implemented in the reference client).
- Automation for certificate enrollment and renewal.
There is a major opportunity here to enhance automation with modular and open source client software.
Additional procedural and policy challenges cited in the memo are to enable:
- Smooth transition between cryptographic algorithms.
The verification method properties in DIDs, together with the simple revocation mechanism, are well suited to address this challenge.
- Eliminate surprising certificates.
There are two major advantages of the Trustchain model here.
The first is verifiable timestamping, which automatically defines a canonical ordering on the set of DIDs. This enables verifiers to distinguish between legitimate DIDs and surprising ones, without needing to trust any third party, by following the simple rule that the one with the earliest timestamp (and no corresponding revocation) takes precedence.
The second advantage is a consequence of the decentralised nature of the trust network, whereby the entities in the chain of trust may represent institutions that are recognisable to, and trusted by, the verifier. They need not, therefore, place their trust in (a chain of) unfamiliar Certificate Authorities.
These two advantages address the problem of discriminating between legitimate and surprising DIDs.
There is another potential advantage that might reduce the extent to which surprising DIDs exist in the first place. This is captured in the idea of constrained dDIDs which impose conditions on subordinate dDID issuers.
- Confidence in CA actions.
Confidence is enhanced by the ability to verify, rather than trust, the actions of a third party. Examples of verifiability in Trustchain are cryptographic verification of timestamps and cryptographic enforcement of privileges (in conditional dDIDs).
- Open and transparent Web PKI governance.
The Trustchain model is a radical departure from the existing PKI governance model. It is not, of course, intended to replace the existing Web PKI system (our purpose in this analysis is merely an academic comparative study), but its decentralised nature places it at the extreme end of the scale in terms of both openness and transparency.
This final section recaps and highlights the most significant potential benefits of Trustchain as a decentralised alternative to the Web PKI for digital identity applications. They are:
- The Trustchain system, software and infrastructure are entirely open access and open source, enabling an ecosystem to develop in which incentives are aligned. For instance, revocation checking is done not by a select group of monitors but by everybody who cares about the status of a certificate, and tools/mechanisms for revocation checking need not be proprietary, they can be developed by anybody. The same is true of tools needed for automation of other routine tasks such as certificate renewal.
- Verifiable timestamping eliminates the issue of time synchronisation. It provides a canonical ordering that can be used to correctly discriminate between an original (valid) certificate versus a "surprising" (invalid) one published subsequently, even if the latter has a legitimate signature.
- The entities in the chain are recognisable to the user, so they can judge both their individual trustworthiness and their congruity in that particular chain of trust.
- With "constrained dDIDs", the chains themselves can be restricted (by the upstream entities) to prevent the issuance of certificates that extend outside of the proper domain of the issuing authority. Moreover, these constraints are imposed cryptographically. This is in stark contrast to the model of equally trusted CAs in which any CA can issue a certificate for any domain name, and the mechanism for imposing restrictions on transgressive CAs is essentially voluntary and often ignored.
- Transparency is enhanced, far beyond that afforded by the Certificate Transparency (CT) approach. Also the proof-of-work mechanism makes the current state and full history of Trustchain certificates not only tamper evident (as in CT) but also strongly tamper resistant.
- Verification always involves checking the entire chain of trust, not just the signature on the leaf node.