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]