One document matched: draft-greevenbosch-tls-ocsp-lite-00.txt
TLS B. Greevenbosch
Internet-Draft Huawei Technologies
Intended status: Standards Track December 31, 2012
Expires: July 4, 2013
OCSP-lite - Revocation of raw public keys
draft-greevenbosch-tls-ocsp-lite-00
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.
Greevenbosch Expires July 4, 2013 [Page 1]
Internet-Draft OCSP-lite December 2012
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 July 4, 2013.
Copyright Notice
Copyright (c) 2012 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
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.
Greevenbosch Expires July 4, 2013 [Page 2]
Internet-Draft OCSP-lite December 2012
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Pre-conditions . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Request handling . . . . . . . . . . . . . . . . . . . . . . . 9
6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Response handling . . . . . . . . . . . . . . . . . . . . . . 12
8. Open topics . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Greevenbosch Expires July 4, 2013 [Page 3]
Internet-Draft OCSP-lite December 2012
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].
Greevenbosch Expires July 4, 2013 [Page 4]
Internet-Draft OCSP-lite December 2012
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
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.
Greevenbosch Expires July 4, 2013 [Page 5]
Internet-Draft OCSP-lite December 2012
3. 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.
Greevenbosch Expires July 4, 2013 [Page 6]
Internet-Draft OCSP-lite December 2012
4. 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.
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".
Greevenbosch Expires July 4, 2013 [Page 7]
Internet-Draft OCSP-lite December 2012
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.
Greevenbosch Expires July 4, 2013 [Page 8]
Internet-Draft OCSP-lite December 2012
5. 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:
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.
Greevenbosch Expires July 4, 2013 [Page 9]
Internet-Draft OCSP-lite December 2012
6. 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 4.
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.
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".
Greevenbosch Expires July 4, 2013 [Page 10]
Internet-Draft OCSP-lite December 2012
publicKeyStatus: The requested public key status, as defined in
section Section 5.
responseExtensions: Extensions for future use.
Greevenbosch Expires July 4, 2013 [Page 11]
Internet-Draft OCSP-lite December 2012
7. 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.
Greevenbosch Expires July 4, 2013 [Page 12]
Internet-Draft OCSP-lite December 2012
8. Open topics
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.
Greevenbosch Expires July 4, 2013 [Page 13]
Internet-Draft OCSP-lite December 2012
9. Security Considerations
This section is very important, and needs input from several security
experts.
Cover at least:
o Safe keeping of responder's public 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
Greevenbosch Expires July 4, 2013 [Page 14]
Internet-Draft OCSP-lite December 2012
10. IANA considerations
Until now, no IANA requests are required for this document.
Greevenbosch Expires July 4, 2013 [Page 15]
Internet-Draft OCSP-lite December 2012
11. 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.
Greevenbosch Expires July 4, 2013 [Page 16]
Internet-Draft OCSP-lite December 2012
12. References
12.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.
12.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.
[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-06 (work in progress),
October 2012.
[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.
Greevenbosch Expires July 4, 2013 [Page 17]
Internet-Draft OCSP-lite December 2012
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 July 4, 2013 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-24 02:52:41 |