Johannes Merkle wrote:
Limitations
~~~~~~~~
- Works only if attacker fraudulently issued a certificate with a serial
that is not associated with a good certificate.
This can be remedied by using an extension in which a server providing
white-list information conveys a hash of the (genuine) certificate
having this serial number. Note, that such an extension does not only
exist but is already used in the context of qualified certificates
in Germany: CertHash (OID 1.3.36.8.3.13), defined in CommonPKI.
Including URLs for publicly availble specs&infos will be appreciated!
(it is my first encounter with CommonPKI)
Peter Rybar seemed to have suggested inclusion of CertHash in July 2012:
http://www.ietf.org/mail-archive/web/pkix/current/msg31385.html
but only had a reference to a powerpoint presentation from 2004
with an "experimental" tag.
Google led me here:
http://www.t7ev.org/ws/T7-en/Common-PKI-V20-Specification
The v2.0 specification PDF document is a concatenation of several documents,
In Common PKI Part 4: Operational Protocols (page 150 of 361) there
is the definition of a CertHash extension to be used in OCSP response
singleExtension:
3.1.2 Common PKI Private OCSP Extensions
Table 15: CertHash (Positive Statement)
id-commonpki-at-certHash OBJECT IDENTIFIER ::= {1 3 36 8 3 13}
CertHash ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
certificateHash OCTET STRING }
certificateHash -- A hash over the DER-encoding of the entire PKC or
AC (i.e. NOT a hash over tbsCertificate).
[...]
Common PKI Profile: The responder may include this extension in a
response to send the hash of the requested certificate to the responder.
This hash is cryptographically bound to the certificate and serves as
evidence that the certificate is known to the responder (i.e. it has
been issued and is present in the directory). Hence, this extension
is a means to provide a positive statement of availability as described
in T8.[8]. As explained in T13.[1], clients may rely on this information
to be able to validate signatures after the expiry of the corresponding
certificate. Hence, clients MUST support this extension. If a positive
statement of availability is to be delivered, this extension syntax
and OID MUST be used.
CommonPKI seems to be about qualified electronic signatures for the German
Digital Signature Act. Are there any similar standards published
by other (european or otherwise) countries for an private OCSP extension
with a positive statement about certificate issuance?
I think we should have added this to rfc2560bis!
-Martin