Internet DRAFT - draft-greevenbosch-tls-ocsp-lite
draft-greevenbosch-tls-ocsp-lite
TLS B. Greevenbosch
Internet-Draft Huawei Technologies
Intended status: Standards Track June 07, 2013
Expires: December 09, 2013
OCSP-lite - Revocation of raw public keys
draft-greevenbosch-tls-ocsp-lite-01
Abstract
This document provides an online mechanism for checking the
revocation status of raw public keys. The mechanism is based on its
older brother for X.509 certificates, OCSP.
Note
Discussion and suggestions for improvement are requested, and should
be sent to tls@ietf.org.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 09, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Greevenbosch Expires December 09, 2013 [Page 1]
Internet-Draft OCSP-lite June 2013
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Possible hierarchical architecture . . . . . . . . . . . . . 3
6. Pre-conditions . . . . . . . . . . . . . . . . . . . . . . . 5
7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8. Request handling . . . . . . . . . . . . . . . . . . . . . . 6
9. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. Response handling . . . . . . . . . . . . . . . . . . . . . . 8
11. Open topics . . . . . . . . . . . . . . . . . . . . . . . . . 8
12. Security Considerations . . . . . . . . . . . . . . . . . . . 9
13. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 10
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
16.1. Normative References . . . . . . . . . . . . . . . . . . 10
16.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Requirements notation
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 [RFC2119].
2. Introduction
In [I-D.ietf-tls-oob-pubkey], a format to store and convey a raw
public key has been defined. This format is designed as a
lightweight alternative to X.509 certificates.
An important feature of a public key infrastructure (PKI) is the
possibility to revoke certificates. This is important to keep the
environment safe, even when some of the public keys have been
compromised.
For X.509 certificates, there are two ways to revoke public keys:
through Certificate Revocation Lists (CRLs, see e.g. [X.509] or
[RFC5280]), or through an OCSP responder [RFC2560]. The former is a
list that contains identifiers for revoked certificates, and is
distributed to the clients that need to check revocation status. The
Greevenbosch Expires December 09, 2013 [Page 2]
Internet-Draft OCSP-lite June 2013
latter is an online service, to which the client can send requests to
verify the revocation status of a particular X.509 certificate. OCSP
has the advantage above CRLs that it can provide more timely
information, and does not need to provide more information than is
required by the client.
This draft proposes a similar mechanism to the X.509 OCSP responder
for raw public keys. It is based on X.509 OCSP, but aims at
remaining as lightweight as possible, especially to cater those
constrained devices that rely on raw public keys because of their
low-complexity.
3. Terminology
o RPK: raw public key as defined in [I-D.ietf-tls-oob-pubkey].
o Requester: the entity that wants to verify the validity of a RPK.
o Responder: the entity that provides information about the
revocation/authentication status of a RPK to the requester.
4. Requirements
This section lists requirements for authentication and revocation
checking of raw public keys (RPK):
1. It SHALL be possible for a receiver of an RPK to determine
whether that RPK has been revoked.
2. It SHALL be possible to verify the binding between the RPK and
the entity associated with it.
3. The revocation checking mechanism SHALL NOT require much
complexity on the requester's side.
4. The revocation checking mechanism SHALL be scalable, allowing
potentially millions of requesters to verify RPKs.
5. The revocation checking mechanism MAY use a hierarchical ordering
of RPKs, to delegate revocation checks.
6. The RPK MAY be accompanied with an identifier that indicates the
issuer of the RPK and/or associated certificate chain.
5. Possible hierarchical architecture
Greevenbosch Expires December 09, 2013 [Page 3]
Internet-Draft OCSP-lite June 2013
Figure 1 shows an example architecture, where the OCSP-lite
responders use more thorough checking through regular OCSP
responders.
The OCSP-lite responders obtain the complete certificate chain
related to the RPK. The OCSP-lite responders verify the certificate
chains, with requests to regular OCSP responders or lookups in CRLs
where appropriate.
Hints where the certificate chain can be found may be included by the
requesters. The OCSP-lite responder could cache the certificate
chains and the regular OCSP responses.
+---------------+
| Requester 1 |----+
+---------------+ |
| +-----------+
+---------------+ +----| OCSP-lite |----+
| Requester 2 |---------| responder | |
+---------------+ +----| A |--+ |
| +-----------+ | | +-----------+
: | | +----| OSCP |
| | | responder |
+---------------+ | | +----| P |
| Requester n |----+ | | +-----------+
+---------------+ | |
| |
| |
| |
+---------------+ | |
| Requester n+1 |----+ | |
+---------------+ | | |
| +-----------+ | |
+---------------+ +----| OCPS-lite |----+
| Requester n+2 |---------| responder | |
+---------------+ +----| B |----+
| +-----------+ | |
: | | |
| | |
+---------------+ | | |
| Requester n+k |----+ | | +-----------+
+---------------+ | +----| OCSP |
| | responder |
+------| Q |
+-----------+
Figure 1: OCSP + OCSP-lite hierarchical architecture
Greevenbosch Expires December 09, 2013 [Page 4]
Internet-Draft OCSP-lite June 2013
[Kessler2000] evaluates and discusses a similar certificate
revocation framework.
6. Pre-conditions
The following pre-conditions are assumed:
o The requester knows which responder is associated with the public
key it wants to verify.
o The requester knows the public key of the responder.
o The requester knows the identifier of the responder, or can
calculate it from the responder's public key.
7. Request
The request has the following syntax:
OCSPliteRequest ::= SEQUENCE {
request Request,
optionalSignature EXPLICIT Signature OPTIONAL
}
Request ::= SEQUENCE {
version Version DEFAULT v1,
nonce BIT STRING,
requesterID BIT STRING OPTIONAL,
publicKeyID BIT STRING,
requestExtensions EXPLICIT Extensions OPTIONAL
}
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
publicKey BIT STRING OPTIONAL
}
Version ::= INTEGER { v1(0) }
The fields have the following meaning:
optionalSignature: The signature by the requester over the "request"
field. This signature MAY be mandated depending on trust policy.
request: The actual request. Only the status of one public key can
be requested at a time.
Greevenbosch Expires December 09, 2013 [Page 5]
Internet-Draft OCSP-lite June 2013
version: The version of the protocol. The value MUST be 0,
indicating this version 1.
nonce: An integer chosen by the requester to ensure the response is
fresh.
requesterID: The identifier for the client's public key. This is
the hash over the client's public key. (Algorithm TBD)
publicKeyID: The identifier for the public key of which the
revocation status is requested. Calculated similarly as
"requesterID".
requestExtensions: Extensions for future use.
signatureAlgorithm: The algorithm used for the signature. The
algorithm identifiers are Object Identifiers (OIDs).
signature: The signature data.
publicKey: The public key of the requester. This field MAY NOT be
needed depending on whether the responder has other means to
acquire the public key. If included, the responder MUST verify
that the publicKey matches with the requesterID.
8. Request handling
If the responder receives a request, it MUST perform the following
checks:
o Verify the version of the protocol.
o Verify the supported algorithms.
o Verify that the requester is eligible to perform the request.
o If the signature is included, verify the requester's public key
and ID binding.
o If the signature is included, verify the signature.
o Verify the requester's own revocation status.
If any of these checks fail, the responder MUST discard the message.
TBD: Error feedback useful, or is ignoring the message enough?
After these verifications, the responder verifies the status of the
requested public key. The following statusses have been defined:
Greevenbosch Expires December 09, 2013 [Page 6]
Internet-Draft OCSP-lite June 2013
GOOD: The public is known and has not been revoked.
REVOKED: The public key has been revoked and MUST NOT be used.
EXPIRED: The public key's lifetime has expired.
UNKNOWN: The public key is unknown to the responder.
9. Response
The OCSP-lite response has the following syntax:
OCSPliteResponse ::= SEQUENCE
{
response Response,
signature EXPLICIT Signature
}
Response ::= SEQUENCE {
version EXPLICIT Version DEFAULT v1,
nonce BIT STRING,
responderID BIT STRING OPTIONAL,
publicKeyID BIT STRING,
publicKeyStatus PubKeyStatus,
responseExtensions EXPLICIT Extensions OPTIONAL
}
PubKeyStatus :== ENUMERATED {
good (0),
revoked (1),
expired (2),
unknown (3)
}
The fields have the following meanings:
signature: The signature by the responder over the "response" field.
For the format, see section Section 7.
response: The actual response.
version: The version of the protocol. The value MUST be 0,
indicating this version 1.
nonce: This field MUST carry the same value as "nonce" in the
request.
Greevenbosch Expires December 09, 2013 [Page 7]
Internet-Draft OCSP-lite June 2013
responderID: The identifier for the responder. This is the hash
over the responder's public key. (Algorithm TBD)
publicKeyID: The identifier for the public key of which the
revocation status is provided. Calculated similarly as
"responderID".
publicKeyStatus: The requested public key status, as defined in
section Section 8.
responseExtensions: Extensions for future use.
10. Response handling
Upon receipt of the response, the requester MUST verify the
following:
o The responder's ID.
o The signature is valid.
o The nonce in the response matches the nonce in the request.
o The public key ID in the response matches the public key ID from
the request.
If any of these checks fails, the client MUST discard the response as
it is invalid. The client SHALL NOT consider the public key valid,
without receipt of a valid response. The requester MAY resend the
request to try to acquire a valid response.
The following rules hold upon receiving a valid response:
o The requester MUST assume the public key is valid upon receiving a
response with status code "GOOD".
o The requester SHALL NOT trust a public key which has been revoked
or expired.
o Depending on the application, the requester MAY trust a public key
upon receiving a valid response with status code "UNKNOWN".
The requester SHALL NOT trust a public key for which it has sent a
request but not received a response. The requester MAY resend the
request.
11. Open topics
Greevenbosch Expires December 09, 2013 [Page 8]
Internet-Draft OCSP-lite June 2013
o Avoid ASN.1 (and BER) and define a lightweight binary format?
o Reserve Object Identifiers where necessary.
o If applicable, clean up pseudo-ASN syntax to valid ASN syntax.
o Reduce complexity by removal of extensibility mechanism?
o If extensibility mechanism is maintained, define how to handle
extensions.
o Change name to something more distinct from "The Lightweight
Online Certificate Status Protocol (OCSP) Profile for High-Volume
Environments" [RFC5019].
o An identifier for the issuer of the RPK may be useful. This may
be included in the ID of the RPK, which would then consist of more
(or something other) than just the hash of the RPK.
o To cater for a single compromised OCSP-lite responder, the trust
model may require a requester to consult multiple OCSP-lite
responders, refusing the RPK if at least one of the responders
does not return "good".
12. Security Considerations
This section is very important, and needs input from several security
experts.
Cover at least:
o Safe keeping of responder's private key
o Complications of revoking the responder's own public key
o Requirement (or not) of signed requests
o Possibility of outdated data
o Undiscovered compromise of public keys
o Issues with delegating regular OCSP/CRL checks to an OCSP-lite
responder
13. IANA considerations
Until now, no IANA requests are required for this document.
Greevenbosch Expires December 09, 2013 [Page 9]
Internet-Draft OCSP-lite June 2013
14. Acknowledgements
This document has heavily been inspired by [RFC2560]. Thanks to the
authors of that document.
Thanks to Kepeng Li for his ideas and feedback.
15. Change Log
v00 -> v01:
o Added requirements section
o Added hierarchical architecture
o Added some security considerations bullets
16. References
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
16.2. Informative References
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online
Certificate Status Protocol (OCSP) Profile for High-Volume
Environments", RFC 5019, September 2007.
[I-D.ietf-tls-oob-pubkey]
Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
T. Kivinen, "Out-of-Band Public Key Validation for
Transport Layer Security (TLS)", draft-ietf-tls-oob-
pubkey-07 (work in progress), February 2013.
Greevenbosch Expires December 09, 2013 [Page 10]
Internet-Draft OCSP-lite June 2013
[X.509] , "Information technology - Open Systems Interconnection -
The Directory: Public-key and attribute certificate
frameworks. ", ITU-T Recommendation X.509, ISO/IEC
9594-8:2005, 2005.
[Kessler2000]
Kessler, O., "The Certificate Revocation Framework ",
2000.
Author's Address
Bert Greevenbosch
Huawei Technologies Co., Ltd.
Huawei Industrial Base
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone: +86-755-28978088
Email: bert.greevenbosch@huawei.com
Greevenbosch Expires December 09, 2013 [Page 11]
