Re: A question regarding certificate status service delegation

On CRL, it is not a different CA, it is a different Authority (e.g., it need
not be authorized to issue certificates).

 

Both indirect CRL and OCSP delegation suffer from a class of errors or
attacks without crypto binding.  In 6960, some of us requested that the OCSP
have crypto binding by requiring the CA to sign the Responder delegation
certificate using the same key that the CA used to sign the certificate for
which the Responder is authoritative.  The language you see is compromise
since some folks did not want to mandate crypto binding.

 

Indirect CRLs are inherently vulnerable to lack of crypto binding problem
and I would recommend against their usage.  There is a mitigation I proposed
in 2004 but no known client uses that mitigation.

 

From: pkix [mailto:[email protected]] On Behalf Of Thomas Kopp
Sent: Monday, November 23, 2020 10:39 AM
To: pkix <[email protected]>
Cc: [email protected]; [email protected]
Subject: [pkix] A question regarding certificate status service delegation

 

Dear all,

 

According to RFC 5280, a certificate issuer can delegate CRL issuance to a
different CA which may particularly be part of a different hierarchy than
the one the certificate issuer belongs to (cf. the crlDistributionPoints
extension, specifically sections 4.2.1.13 and 6.3.3. (b) 1) of the RFC).

 

By contrast, in the case of OCSP delegation, it is required that an OCSP
responder belongs to the same hierarchy like the certificate issuer (cf.
section 2.6 of RFC 6960). Which is the motivation for this latter
limitation? Is it just the lack of an OCSP-specific certificate extension
that corresponds to the CRL-related crlDistributionPoints extension or are
there any other reasons; if yes, which ones ?

 


Thomas KOPP
Chief Scientist

Email:  <mailto:[email protected]> [email protected]
Mobile:+352 621 229 316
Office: +352 26 68 15 - 574
LuxTrust S.A. |  IVY Building | 13-15, Parc d’activités | L-8308 Capellen |
Luxembourg | ww <http://www.luxtrust.lu/> w.luxtrust.lu

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix