PKIX Working Group D.W.Chadwick (University of Kent) INTERNET-DRAFT Expires: Dec 2007 June 2007 Target category: Standard Track Internet X.509 Public Key Infrastructure Use of WebDAV for Certificate Publishing and Revocation Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79 [RFC 3978]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes the use of the WebDAV protocol for publishing and revoking X.509 public key certificates and specifies two new access methods for the Authority Information Access extension to support this. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. Please send comments on this document to the ietf-pkix@imc.org mailing list or to the author. 1. Introduction There are a number of well known problems with using LDAP to store certificates and certificate revocation lists, for example, most corporate firewalls deny access to the LDAP protocol. This document specifies the use of the WebDAV [RFC 2518] protocol extensions to HTTP [RFC 2616] to store and revoke certificates. The protocol supports the transfer of any type of certificate, public key or attribute, as well as any type of revocation list. WebDAV is widely supported, several open source implementations are available including one for Apache, and there is an active community working with it (see http://www.webdav.org/). The protocol specified in this document is based on the Representational State Transfer {REST} principles [REST], in which the web itself is the state transition machine for a certificate. When a certificate does not exist it has no web page. When a certificate exists, it has a unique web page (the certificate URL) at which it MUST be found. When a certificate is revoked, it has a unique web page (revocation URL) at which the revocation list (of length one) SHOULD be found. Obviously both URL pages MUST NOT exist simultaneously, since a certificate cannot be in both states simultaneously. Whilst a certificate might exist i.e. from its time of first issuing until it validity period finishes, one of the pages SHOULD exist, although some implementations MAY choose to treat a revoked certificate the same as a certificate that has never existed. Optionally the revocation page MAY exist after the validity period of a certificate has expired. This document specifies two certificate extensions, the certificate URL and the revocation URL, which may be stored in certificates in order to determine its state using the WebDAV protocol. Section 2 defines these certificate extensions. Section 3 specifies how the WebDAV protocol can be used to retrieve the current state of a certificate, using these two certificate extensions. 2. Certificate extensions to support the use of WebDAV This document specifies two new access methods for the AuthorityInformationAccess (AIA) extension defined in RFC 3280 [RFC 3280]. The AIA extension is designed to point to services of the issuer of the certificate in question. One of the standard uses of this extension is to point to the OCSP service provided by the issuer. Since the WebDAV service can be used as an alternative to the OCSP service, it seems appropriate to use the AIA extension to point to the WebDAV service. We copy below the ASN.1 of the AIA extension, taken from [RFC 3280] for the convenience of the reader: AuthorityInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF AccessDescription AccessDescription ::= SEQUENCE { accessMethod OBJECT IDENTIFIER, accessLocation GeneralName } The two new accessMethods, webdavCert and webdavRev, are defined as follows: webdavCert OBJECT IDENTIFIER ::= { 1.2.826.0.1.3344810.10.2 } webdavRev OBJECT IDENTIFIER ::= { 1.2.826.0.1.3344810.10.3 } When the AIA accessMethod is webdavCert or webdavRev, then the accessLocation must be a URL pointing to the WebDAV server where the certificate or CRL can be found. The URL must point to the exact location of the certificate or CRL in the server so that relying parties can download the certificate or the CRL. webdavRev MUST NOT be present in a certificate if webdavCert is not present. When a certificate has been issued containing the webdavCert extension, and has not been revoked, it MUST be present at the webdavCert location specified in this extension. When a certificate has been issued and revoked, the certificate MUST NOT be available at the webdavCert location. If the webdavRev extension was present in the certificate prior to its revocation, then a CRL of length 1 containing the serial number of the revoked certificate, MUST be present at the webdavRev location immediately the certificate is revoked. 3. Using the WebDAV protocol WebDAV specifies extensions to the HTTP/1.1 protocol so that web content can be managed remotely. WebDAV provides users with the ability to create, remove and query information about web pages, including their contents and properties, such as their creation dates, expiry dates, authors etc. In the context of X.509, a web page will be a single X.509 certificate (either public key or attribute) or a CRL containing a single entry, and their properties can be any fields of the certificate or CRL. WebDAV also provides the ability to create sets of related web pages, called collections, and to retrieve hierarchical membership listings of them. In the context of X.509, a certificate subject can represent a collection, and his/her certificates can be the collection membership listing. The set of CRLs issued by an issuer can also be a collection membership listing. 3.1 Naming WebDAV resources WebDAV resources are named by URLs, where the hierarchical names are delimited with the "/" character. The name of a collection ends with /. If we model our X.509 certificate store in the same way as an X.500/LDAP directory tree, and name it using the subject DNs to represent collections, this provides us with the ability to retrieve a listing of all the certificates that are owned by a single subject. We use the rules of RFC 4514 [RFC 4514] to convert the DNs into strings, with the exceptions that we replace the comma "," separator between RDNs with the "/" character which is the WebDAV separator, and replace spaces with %20. For example, a collection belonging to the subject whose Distinguished Name is, in RFC 4514 syntax, "c=gb, o=University of Kent, cn=David Chadwick", will be named in a WebDAV repository with the URL: https://server.dns.name/c=gb/o=University%20of%20Kent/cn=David%20Chadwi ck/ A GET request to retrieve all the certificates of David Chadwick would use the URL of the collection, viz: GET /c=GB/o=University%20of%20Kent/cn=David%20Chadwick/ HTTP/1.1 Host: server.dns.name A GET request to retrieve a specific certificate of a subject will use the URL specified in the webdavCert access location. We can similarly model a CRL store as a collection of CRLs under its issuer, using the collection name cn=CRLs/, where each CRL contains a single CRL entry and is named with the serial number of the certificate that it revokes. This provides us with the ability to retrieve a listing of all the CRLs that have been issued by a single issuer, and consequently a listing of all certificates that have been revoked. For example, if David Chadwick is an attribute authority who delegates attribute certificates to people, and subsequently revokes some of them, then a GET request to retrieve all the CRLs issued by David Chadwick would use the URL of the collection, viz: GET /c=GB/o=University%20of%20Kent/cn=David%20Chadwick/cn=CRLs/ HTTP/1.1 Host: server.dns.name A GET request to retrieve a specific CRL of a certificate will use the URL specified in the webdavRev access location of the certificate. 3.2. Using the WebDAV protocol to manage X.509 repositories In order to create a new collection, WebDAV specifies the MKCOL method. The difference between this method and HTTP PUT or POST, is that the latter are allowed to overwrite existing content at the specified URL, whereas MKCOL will fail if there is any existing content at the specified URL. In the context of X.509, this ensures that a certificate issuer cannot unwittingly overwrite existing certificates when creating a new collection for a subject. This is an important concern when there are several certificate issuers for the same subject (either attribute certificate issuers and/or public key certificate issuers). It is important to ensure that no issuer deletes the certificates issued by another issuer. In order to create a certificate or CRL or update an existing certificate in an existing collection, the PUT method is used. It is essential that every certificate and CRL has a unique name within a collection, so that updates can overwrite the same certificate and new certificates and CRLs cannot overwrite existing ones. The onus for creating the unique names is with the issuer. This document defines one algorithm in Section 3.3 for ensuring this uniqueness is maintained. In order to revoke a certificate, the HTTP DELETE command is used by the issuer. This removes the certificate and its properties from the WebDAV server. Simultaneously with this, if the revoked certificate contains the webdavRev access location, the issuer MUST use the HTTP PUT method to create a new CRL containing the serial number of the certificate that has just been revoked. The revocationDate and thisUpdate fields of the CRL MUST be set to the current time, and the nextUpdate field SHOULD be set to sometime after the certificate was due to expire and the date after which the CRL will be removed from the WebDAV store. This ensures that: i) the CRL never needs to be reissued or updated, and ii) relying parties know the minimum duration that the CRL will exist for on the web (should they wish to prove sometime after the certificate has expired that it was revoked prior to expiring). 3.3 Searching for particular certificates or CRLs Document properties are specified in XML as name/value pairs. The WebDAV protocol supports the PROPFIND method, in which the properties of a resource can be retrieved, but it not possible to specify which property value you require. Only the property types can be specified. Consequently, if we perform a PROPFIND for the "Role" property, then the web server will return an XML encoded message containing all the ACs that contained a property named Role along with their values. Clearly this is not a viable solution for searching for particular certificates or CRLs. Work on the WebDAV searching and locating capability (DASL) started in 1998, but the work was never completed and the IETF closed the DASL working group some years later. The latest version of the WebDAV Searching and Locating protocol is very recent [Search] and several implementations are said to exist, but we were unable to find a usable one. Consequently we have left the search feature for future work. 3.4 Deriving Unique Names for Certificates and CRLs Because PKCs and ACs may be updated or re-issued by their issuers, it is important to have unique names (certificate URLs) for each of them. Furthermore, each certificate MUST have its unique certificate URL and optional revocation URL embedded in it so that relying parties can retrieve the contents of either URL to check the current state of the certificate. Whilst the primary contents of a PKC are fixed (i.e. public key and subject names) the contents of an AC are very varied, and can be any attribute, including authorisation policies. We therefore propose a fixed naming scheme for PKCs and CRLs, but two different naming schemes for ACs, depending upon whether the attribute contains a role/privilege, or a policy. The following algorithm MAY be used to create the unique names for certificates and CRLs: - each AC has the file suffix .ace, each PKC has the file suffix .p7c and each CRL has the file suffix .crl - we use the rules described in RFC 4514 [RFC 4514] to create strings from distinguished names, in particular, using the comma "," to separate the RDNs in a DN, a plus sign "+" to separate the attribute value assertions in an RDN, and an equals sign "=" to separate attribute types and values. - the name of a PKC file is created from the issuer DN and certificate serial number concatenated with a plus sign e.g. "c=gb, o=university of kent, cn=CSCA+SN=123445.p7c" - the name of a role AC file is created from the contents of its attribute values plus the serial number of the certificate, concatenated with a plus sign E.g. a role AC with the embedded attribute type PermisRole with attribute value Project Manager, and certificate serial number of 12345 would create the filename "PermisRole=Project Manager+SN=123456.ace". The serial number provides the uniqueness, whilst the attribute type and value provides user friendliness when the issuer wants to browse a WebDAV repository and retrieve an AC for editing. - the name of a policy AC file is created from the unique name of the policy embedded in the policy attribute value, E.g. a policy with the name "AstroGridUsers" would produce the filename "Policy=AstroGridUsers.ace". Note that it is a policy language issue how the policy name is encoded in the policy attribute value. - the name of a CRL file is created from the serial number of the certificate that it revokes. E.g. a CRL that revokes a certificate with serial number 1234 would produce the filename "serialNumber=1234.crl". 4. Security Considerations The frequency and method by which a relying party contacts the issuers WebDAV repository is determined by its risk mitigation strategy and the optional presence of the revocation URL in a certificate. The frequency can vary per application or per user request, and is set by the relying party as appropriate, and not by the issuer, which is putting the responsibility and risk where it belongs, with the relying party. In order to minimise risk, a relying party SHOULD contact the repository when a certificate is first validated, and then periodically during the life of the users session according to its own risk assessment. A security weakness in the WebDAV scheme is that it is vulnerable to denial of service attacks, in that if the WebDAV server is not available, relying parties will not be able to tell if a certificate has been revoked or not. However, other schemes, such as OCSP servers and publishing CRLs, are also equally vulnerable to DOS attacks, and so WebDAV is no different in this respect. CRLs do have one advantage in that an old CRL is better than no CRL, since it does contain some revoked certificates. The equivalent WebDAV procedure is where the relying party periodically downloads collections of all single entry CRLs issued by any issuer. Consequently we do not believe that DOS attacks are any more of a significant security threat to WebDAV than to existing revocation mechanisms. The following procedure is one possible one that relying parties may wish to implement in order to periodically validate a certificate. The relying party issues a HTTP or HTTPS GET command to the certificate URL. The choice between HTTP and HTTPS is discussed later. If the HTTP status code 404 Not Found is returned, the relying party SHOULD assume that the certificate has been revoked, and permanently record this in its internal cache along with the time of the request. If the certificate is returned, a simple bitwise comparison of the initial validated certificate with the subsequently retrieved copy of the certificate is all that is needed by the relying party to ensure that the certificate is still identical to the one originally validated. Certificate signature verification is therefore not needed for revocation status checking. The relying party may optionally cache the certificate and its time of last retrieval. If the certificate has been updated in the repository during the users session, which is likely to be a rare occurrence, then the retrieved certificate will fail the bitwise comparison and will need to be validated again. If the client is unable to contact the certificate URL and receive either a certificate or Not Found response, it SHOULD contact the revocation URL, providing there is one is in the certificate. If the HTTP status code 404 Not Found is returned from the revocation URL, the relying party MAY, according to its risk assessment procedure, assume that the certificate is still valid, and record this in its cache. (Note. In high risk cases, an attacker could be blocking the certificate URL and spoofing the revocation URL). If the CRL is returned instead of Not Found, the signature is validated and the relying party caches the result permanently to ensure the certificate cannot be used again and no further retrieves need be made. Intermediate caching of the CRL is supported and encouraged, so that if a certificate has been revoked and the CRL successfully retrieved, intermediate web servers can cache the CRL to speed up subsequent queries. If the relying party is unable to make a connection to the revocation URL, then the relying party can check its cache to see if a previous request to either URL has succeeded or not. If neither URLs are available, the relying party SHOULD use its local risk assessment procedure to decide what to do when there are network problems. For example, if the transaction is low risk, it may decide to treat the certificate as valid. Alternatively it may decide to try contacting the URLs again, or alternatively to treat the certificate as revoked. Clients may use either HTTPS or HTTP depending upon their and the issuers security requirements. HTTP presents a number of security weaknesses compared to HTTPS. Firstly HTTP provides public access to the certificate, which may violate the privacy of the certificate subject. (There is no equivalent privacy leakage for a CRL.) Furthermore intermediate Web servers may cache copies of frequently accessed web pages to improve performance, but this would negate the proposed revocation service. To counteract this, the issuers Web server MUST use the no-cache cache-response-directive [RFC 2616] in the HTTP response of successful certificate requests and Not Found CRL requests, to prevent intermediate servers from caching these responses. This will ensure that all subsequent queries are directed to the authoritative source of the information and that stale cached responses are not received. Finally HTTP is susceptible to redirection, substitution and man in the middle attacks. Consequently, if the certificates are not meant to be publicly available or stronger security is required, then secure access should be provided using HTTP with TLS [RFC 4346]. This will stop network redirection, substitution attacks and intermediate caching. TLS can also provide confidentiality of the retrieved certificates during transfer, in cases where privacy protection of sensitive certificates is required by the issuer. TLS can also provide strong client side authentication, which will allow access controls to be placed on the WebDAV repository, further protecting the privacy of the subjects certificates. The privacy of CRLs is less important, and it enhances security if more copies of these are publicly available. 5. References 5.1 Normative References [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC 4346] T. Dierks, E. Rescorla. "The Transport Layer Security (TLS) Protocol Version 1.1". RFC 4346. April 2006. [RFC 2518] Y. Goland, E. Whitehead, A. Faizi, S. Carter, D. Jensen. "HTTP Extensions for Distributed Authoring WEBDAV". RFC 2518, February 1999 [RFC 2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. "Hypertext Transfer Protocol -- HTTP/1.1." June 1999. [RFC 3280] Housley, R., Ford, W., Polk, W., and Solo, D., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile," RFC 3280, April 2002 [RFC 3978] Bradner, S., "IETF Rights in Contributions" BCP 78, RFC 3978, March 2005. [RFC 4514] K. Zeilenga. "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names". RFC 4514, June 2006. [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, June 1997. 5.2 Informative References [REST] see http://en.wikipedia.org/wiki/Representational_State_Transfer [Search] J. Reschke et al. "Web Distributed Authoring and Versioning (WebDAV) SEARCH". , 9 Feb 2007. 6. Author's Address David Chadwick Computing Laboratory University of Kent Canterbury CT2 7NF England d.w.chadwick@kent.ac.uk 7. Acknowledgements The author would like to thank Sassa Otenko for first proposing this mechanism, Sean Anthony for implementing it and providing a workable proof of concept, and members of the Europki 2007 program committee and Denis Pinkas for providing feedback on earlier versions of this document. 9 Intellectual Property Rights Copyright (C) The IETF Trust (2007) This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.