Re: [pkix] Last Call: <draft-ietf-pkix-rfc2560bis-15.txt> (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]