Re: A question regarding certificate status service delegation

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



[cid:[email protected]]



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:



[cid:[email protected]]



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 protected]<mailto:[email protected]> | 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 protected]] On Behalf Of Peter Gutmann
Sent: Tuesday, November 24, 2020 3:32 AM
To: Santosh Chokhani <[email protected]>; 'pkix' <[email protected]>; [email protected]; [email protected]
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:



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: pkix [mailto:[email protected]] On Behalf Of Santosh Chokhani
Sent: Monday, November 23, 2020 7:50 PM
To: 'Thomas Kopp' <[email protected]>; 'pkix' <[email protected]>
Cc: [email protected]; [email protected]
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 protected]] On Behalf Of Thomas Kopp
Sent: Monday, November 23, 2020 10:39 AM
To: pkix <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[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 ?

[LuxTrust_logo_blue_signature]
Thomas KOPP
Chief Scientist

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






_______________________________________________

pkix mailing list

[email protected]<mailto:[email protected]>

https://www.ietf.org/mailman/listinfo/pkix

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