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
<draft-chadwick-webdav-00.txt>
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". <draft-reschke-webdav-search-11>, 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.