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