Internet DRAFT - draft-pinkas-2560bis-certinfo
draft-pinkas-2560bis-certinfo
INTERNET-DRAFT D.Pinkas
Intended Status: Proposed Standard Bull SAS
Updates: 2560bis (if approved) August 31, 2012
Expires: March 1, 2013
CertInfo single response extension
Update to OCSP
< draft-pinkas-2560bis-certinfo-00.txt >
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License 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.
Denis Pinkas Expires March 1, 2013 [Page 1]
INTERNET DRAFT CertInfo single response extension August 31, 2012
Abstract
OCSP [RFC2560] has been designed to allow an OCSP server to use
any kind of trustable information to answer to a client varying
from CRLs to an access to a database of issued certificates.
In its original version, OCSP does not allow taking full advantage
of an access to a database of issued certificates.
When a database of issued certificates is used by an OCSP server,
this document explains how the OCSP server shall respond and how
OCSP clients shall react.
The proposal is intended to update 2560bis. It defines a new single
extension in a single response, called certInfo. The extension is
non critical. The meaning of "good", "revoked" and "unknown" are
unchanged.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. CertInfo single extension . . . . . . . . . . . . . . . . . . . 3
3. Text to be placed in the Security Considerations section . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
9. ASN.1 module . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
This document is intended to be incorporated in 2560bis, a draft
document being currently discussed in the PKIX WG to replace
RFC 2560 [RFC2560].
1.1. Terminology
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 [RFC2119].
Denis Pinkas Expires March 1, 2013 [Page 2]
INTERNET DRAFT CertInfo single response extension August 31, 2012
2. certInfo single extension
This single extension may be used in singleExtensions within a
SingleResponse. It either contains:
- an indication that the serial number of the target
certificate is not present in the database, or
- a hash value of the target certificate computed using the
value of the certificate that is present in the database.
This extension may only be used when an OCSP server has access to
a database maintained by a CA which contains, for every issued
certificate, the following up-to-date information:
- its serial number,
- its revocation status, and
- the value of the certificate.
The use of this single extension is RECOMMENDED, when the server is
able to support it.
The following only applies when this single extension is supported
by the OCSP server.
When the serial number of the target certificate is present in the
database, then the OCSP server SHALL indicate the revocation
status of the target certificate accordingly to the revocation
status indicated in the database and the extension SHALL contain
a hash value of the target certificate computed using the value of
the certificate that is present in the database. The critical flag
SHALL NOT be set.
When the serial number of the certificate is not present in the
database, then the OCSP server SHALL indicate that the revocation
status of the target certificate is "unknown" and the extension
SHALL contain an indication that the serial number of the target
certificate is not present in the database. The critical flag
SHALL NOT be set.
The identifier for this extension is id-pkix-ocsp-certInfo,
while the value is CertInfo.
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-certInfo OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 }
CertInfo ::= CHOICE {
certSerialNumberUnknown [0] BOOLEAN DEFAULT TRUE,
certHashValue [1] CertHashValue
}
Denis Pinkas Expires March 1, 2013 [Page 3]
INTERNET DRAFT CertInfo single response extension August 31, 2012
CertHashValue ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashValue OCTET STRING
}
certSerialNumberUnknown is a Boolean which indicates that the serial
number of the target certificate is not present in the list of the
certificates issued by the CA to which the OCSP responder has
access. In that case, certStatus SHALL be set to "unknown".
certHashValue contains a hash value of the target certificate
computed using the same hash function that was used by the OCSP
client in the CertID field from the OCSP request.
If this extension is not understood by the OCSP client, then it
SHALL be ignored.
If this extension is understood by the OCSP client, the OCSP
client should make sure that there is no mistake with the serial
number value. It should also make sure that it holds a certificate
which includes that serial number and for which a certification
path has been verified valid up to a trusted root (except the
revocation status of the target certificate).
The processing of this extension by an OCSP client is as follows:
If the certSerialNumberUnknown Boolean is returned in the single
extension, then the CertStatus is necessarily "unknown". The OCSP
client SHOULD use this information to alert the OCSP server using
out of bands means.
If a hash of the certificate is returned in the single extension,
the OCSP client SHALL compare its value with a hash computed
locally on the target certificate it holds.
If the hashes match, then the revocation status of the target
certificate, as indicated by the OCSP server, is valid.
If the hashes do not match, then the OCSP client SHOULD use this
information to alert the OCSP server using out of bands means.
Denis Pinkas Expires March 1, 2013 [Page 4]
INTERNET DRAFT CertInfo single response extension August 31, 2012
3. Text to be placed in the Security Considerations section
X.X. Certificate not regularly issued
The advantages and the limitations provided through the use of the
single extension "CertInfo" are indicated below:
When certSerialNumberUnknown is returned, this extension indicates:
- either that the target certificate has indeed not been
issued and thus is a forged certificate,
- or that the target certificate which was indeed regularly
issued has been removed from the database by an attacker
(denial of service attack) or by accident.
When certHashValue is returned and the hashes do not match, this
extension allows detecting an abnormal situation : there exists two
certificates with the same serial number: one regularly issued by
the CA and another one which has either been forged or obtained
irregularly.
When certHashValue is returned and the hashes match, then everything
looks fine, but this case does not allow detecting an abnormal
situation if the RA software has been corrupted or if the database
to which the OCSP server has access has been maliciously corrupted.
When an OCSP server receives an alert from an OCSP client, it should
use the information provided by the OCSP client to investigate the
case.
If the target certificate is unknown to the OCSP server, but has
been regularly issued, it is necessary to discriminate between a
denial of service attack or an accident and to correct the problem
so that the situation does not persist.
If the target certificate has not been regularly issued, its serial
number should be immediately added by the CA to the list of revoked
certificates.
Then after, the OCSP server should continue to investigate the case:
- either the extend of the damage can be evaluated by the CA and
only those certificates which have been fraudulently issued
shall be revoked by the CA, or
- the extend of damage cannot be evaluated and in that case the CA
should ask to its superior CA to revoke its CA certificate.
Denis Pinkas Expires March 1, 2013 [Page 5]
INTERNET DRAFT CertInfo single response extension August 31, 2012
It is up to the CA and to the OCSP server to cooperate together in
order to attempt to recover from these situations. OCSP servers and
CAs should include in their recovery plans, the above situations.
4. Security Considerations
The text covering the security considerations is provided in
section 3.
5. IANA Considerations
This document has no actions for IANA.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
June 2010.
6.2. Informative References
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and
Adams, C., "X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP", RFC 2560,
June 1999.
7. Acknowledgements
Several of the ideas present in this document came from discussions
on the PKIW WG list and with Romain Santini.
8. Author's Address
Denis Pinkas
Bull SAS
BP 78
78340 Les Clayes sous bois
France
EMail: denis.pinkas@bull.net
Denis Pinkas Expires March 1, 2013 [Page 6]
INTERNET DRAFT CertInfo single response extension August 31, 2012
9. ASN.1 Module
CERTINFO-2012 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-ocsp-cert-info-2012-93(79) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
EXPORTS ALL; -- export all items from this module
IMPORTS
Extensions, AlgorithmIdentifier
FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) }
id-pkix-ocsp
FROM OCSP-2009 -- From [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-02(48) }
;
certInfo EXTENSION ::= {
SYNTAX CertInfo,
IDENTIFIED BY id-pkix-ocsp-certInfo
}
id-pkix-ocsp-certInfo OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 }
CertInfo ::= CHOICE {
certSerialNumberUnknown [0] BOOLEAN DEFAULT TRUE,
certHashValue [1] CertHashValue
}
CertHashValue ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashValue OCTET STRING
}
END
Denis Pinkas Expires March 1, 2013 [Page 7]
