Subject: [pkix] A question regarding certificate status service delegation

From: Thomas Kopp <[email-masked]>
Date: Mon, 23 Nov 2020 15:39:26 +0000

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 ?

[LuxTrust_logo_blue_signature]
Thomas KOPP
Chief Scientist

Email: [email-masked]<mailto:[email-masked]>
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 | www.luxtrust.lu<http://www.luxtrust.lu/>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 23 Nov 2020 13:49:55 -0500

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-masked]] On Behalf Of Thomas Kopp
Sent: Monday, November 23, 2020 10:39 AM
To: pkix <[email-masked]>
Cc: [email-masked]; [email-masked]
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-masked]> [email-masked]
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

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 23 Nov 2020 21:35:20 +0000

Santosh Chokhani <[email-masked]> writes:

>attacks without crypto binding.

For those members of the class who weren't present at the time, could you
explain the attacks?

Peter.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 23 Nov 2020 16:54:10 -0500

Peter,

I presented the slides at 2004 November PKIX WG at IETF held in Washington
DC.

Subsequently I wrote a paper and presented it at NIST PKI Research
Conference.

I am happy to send those two collaterals to you or you are welcome to locate
them if they are posted on some web sites.

-----Original Message-----
From: Peter Gutmann [mailto:[email-masked]] 
Sent: Monday, November 23, 2020 4:35 PM
To: Santosh Chokhani <[email-masked]>; 'Thomas Kopp'
<[email-masked]>; 'pkix' <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [pkix] A question regarding certificate status service
delegation

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 23 Nov 2020 21:57:07 +0000

>Subsequently I wrote a paper and presented it at NIST PKI Research

I meant for the list as a whole, since (I would assume) not many people would
remember the contents of a paper from sixteen years ago.  Links would be
useful...

Peter.

---

From: "Todd E. Johnson" <[email-masked]>
Date: Mon, 23 Nov 2020 22:00:53 +0000 (UTC)

https://csrc.nist.gov/publications/detail/nistir/7313/final#pubs-abstract-header
I *think* this is the resulting NISTR.  Can only immediately find back to 2006 though.

Peter.

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

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 24 Nov 2020 02:32:09 +0000

Santosh has forwarded me the two documents that describe the problem and given
his OK to post them, since posting binaries to the list may be a breach of
etiquette I've temporarily hosted them at:

http://www.cs.auckland.ac.nz/~pgut001/pubs/beta.zip

I'll take them down again in a day or two once people have had a chance to
read them.

Peter.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 23 Nov 2020 22:24:36 -0500

Thanks Peter.

-----Original Message-----
From: Peter Gutmann [mailto:[email-masked]] 
Sent: Monday, November 23, 2020 9:32 PM
To: Santosh Chokhani <[email-masked]>; 'pkix'
<[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [pkix] A question regarding certificate status service
delegation

Santosh has forwarded me the two documents that describe the problem and
given his OK to post them, since posting binaries to the list may be a
breach of etiquette I've temporarily hosted them at:

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 24 Nov 2020 10:38:43 +0000

Peter Rybár <[email-masked]> writes:

>The link (http://www.cs.auckland.ac.nz/~pgut001/pubs/beta.zip) contains your
>lib  instead of documents.

Argh, sorry!  And now someone who wanted a code release will wonder why they
got a CRL paper instead.  The correct link is:

http://www.cs.auckland.ac.nz/~pgut001/pubs/crl_pubs.zip

Peter.

---

From: Niklas Matthies <[email-masked]>
Date: Tue, 24 Nov 2020 20:32:52 +0100

>http://www.cs.auckland.ac.nz/~pgut001/pubs/crl_pubs.zip

Thanks for providing the documents!

This seems to be a slightly more recent version of the PPT: 
https://www.ietf.org/proceedings/61/slides/pkix-4/crldp-idp-v3.ppt

And for completeness sake here is a direct link to the online version 
of the CRL paper (starting at page 41): 
https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7313.pdf

Cheers,
Niklas

---

From: Peter Rybár <[email-masked]>
Date: Tue, 24 Nov 2020 10:32:35 +0000

Dear Peter,

The link (http://www.cs.auckland.ac.nz/~pgut001/pubs/beta.zip) contains your lib instead of documents.

Dear Santosh, (Both indirect CRL and OCSP delegation suffer from a class of errors or attacks without crypto binding.)

When the trust anchors are included in the store which is under responsibility of the supervisory body (signed by supervisory body), as it is the trusted list in the European Union, then the attacks are fixed by including the extension in the trusted list as it is the trusted list of one of the Member States of the European Union. This extension contains unique identifier of the authorized issuer of the indirect CRL or of the issuer of OCSP responses and is included in the record of the issuer of the certificate and only such issuer is able to authorise any indirect issuers of CRLs or OCSP responses.

The trusted list contains the record of the certificate issuer and the same record can contain also authorization for issuing e.g. indirect OCSP responses of certificates issued by this service.

See the trusted list (TL) https://www.nbu.gov.sk/en/trust-services/trusted-list/index.html

URL of TL http://tl.nbu.gov.sk/kca/tsl/tsl.xml

Additional XSD where the extension URLContentTypeAndAuthorizedServiceList is defined:

http://ep.nbu.gov.sk/kca/tsl/tlX509XMLSchemaDocumentation.pdf

See the record which contains <Name xml:lang="en">(10) CA Disig</Name>

This record contains also

<tlx509:URLContentTypeAndAuthorizedServiceList>

  <tlx509:URLContentTypeAndAuthorizedService>

    <tlx509:URL>http://ocsp.nbu.gov.sk/ocsp/pqc</tlx509:URL>

    <tlx509:ContentType>application/ocsp-request</tlx509:ContentType>

    <tlx509:AuthorizedService>

      <tlx509:TLServiceIdentifier>TLISK-99</tlx509:TLServiceIdentifier>

      <tlx509:notBefore>2019-12-08T12:46:26Z</tlx509:notBefore>

  </tlx509:AuthorizedService>

  </tlx509:URLContentTypeAndAuthorizedService>

</tlx509:URLContentTypeAndAuthorizedServiceList>

The identifier TLISK-99 is the identifier of the record in the Slovak (SK) TL containing the element:

  <Name xml:lang="en">(99) NSA OCSP</Name>

I also agree with the old document provided by Peter:

https://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt

For that reason I offer only the enveloped XML signature, e.g. used for the trusted list, in my QES application.

https://www.nbu.gov.sk/en/trust-services/trusted-list/tl-and-qes-applications/index.html

If the detached or enveloping XML signature formats are selected, then the selected format is switched to the CMS signature format and the following information is provided:

Kind regards,
Deputy Director COL Peter Rybár
Regulation and Supervision Department | NSA
Budatínska 30 | 851 06 Bratislava | Slovak Republic
tel.: +421 2 6869 2163| fax: +421 2 6869 1700
[email-masked]<mailto:[email-masked]> | www.nbu.gov.sk<http://www.nbu.gov.sk/>
Free QES application qes.webnode.sk/en/ <https://www.nbu.gov.sk/en/trust-services/trusted-list/tl-and-qes-applications/index.html>

-----Original Message-----
From: pkix [mailto:[email-masked]] On Behalf Of Peter Gutmann
Sent: Tuesday, November 24, 2020 3:32 AM
To: Santosh Chokhani <[email-masked]>; 'pkix' <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [pkix] A question regarding certificate status service delegation

read them.

Peter.

From: pkix [mailto:[email-masked]] On Behalf Of Santosh Chokhani
Sent: Monday, November 23, 2020 7:50 PM
To: 'Thomas Kopp' <[email-masked]>; 'pkix' <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [pkix] 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-masked]] On Behalf Of Thomas Kopp
Sent: Monday, November 23, 2020 10:39 AM
To: pkix <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [pkix] A question regarding certificate status service delegation

Dear all,

pkix mailing list

[email-masked]<mailto:[email-masked]>