[Cscwg-public] Conflict with RFC 3161 and CSBR 11.2.1

Dean Coclin dean.coclin at digicert.com
Thu Mar 18 13:24:13 UTC 2021


Bruce-Let's add this to the parking lot list and maybe we can add it to an
upcoming ballot as it does not appear controversial and is rather, a clean
up item.


Dean

 

From: Cscwg-public <cscwg-public-bounces at cabforum.org> On Behalf Of Bruce
Morton via Cscwg-public
Sent: Thursday, March 18, 2021 8:27 AM
To: Corey Bonnell <Corey.Bonnell at digicert.com>; cscwg-public at cabforum.org
Subject: Re: [Cscwg-public] Conflict with RFC 3161 and CSBR 11.2.1

 

HI Corey,

 

Good catch. This text was brought in as part of the merge and can be found
in the EV Code Signing Guidelines v 1.4 in section 11.2.1,
https://cabforum.org/wp-content/uploads/EV-Code-Signing-v.1.4.pdf. I have no
idea why this text was appended to this section in the old EV CS Guidelines.

 

I have no issues with deleting this text from section 11.2.1 of the CSBRs.

 

Thanks, Bruce.

 

From: Cscwg-public <cscwg-public-bounces at cabforum.org
<mailto:cscwg-public-bounces at cabforum.org> > On Behalf Of Corey Bonnell via
Cscwg-public
Sent: Wednesday, March 17, 2021 5:49 PM
To: cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org> 
Subject: [EXTERNAL] [Cscwg-public] Conflict with RFC 3161 and CSBR 11.2.1

 

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the
content is safe.

  _____  

Hello,

There appears to be contradictory language in CSBR 11.2.1, as it states the
following:

A Timestamp Authority is NOT REQUIRED to validate in any way data submitted
to it for timestamping.  It simply adds the time to the data that are
presented to it, signs the result and appends its own Timestamp Certificate.

 

The clause "and appends it own Timestamp Certificate" is an unconditional
requirement for a timestamp response to include the TSA certificate chain.
This conflicts with CSBR 16.1 (1), which mandates compliance with RFC 3161,
which in turn states in RFC 3161 section 2.4.1:

               If the certReq field is missing or if the certReq field is
present

               and set to false then the certificates field from the
SignedData

               structure MUST not be present in the response.

 

The introduction of the contradictory language in 11.2.1 was introduced as
part of the OV CS/EV CS BR document merge last year, as I am unable to find
any instances of that text in previous versions of the documents.
Additionally, the intent of the document merge was not to introduce
normative changes, so I believe the intent is that CAs should respect the
certReq field value in the timestamp request and conditionally include the
certificate chain.

 

If there is agreement on this interpretation, I'd be happy to draft a
clarification ballot.

 

Thanks,

Corey

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210318/51556900/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4916 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210318/51556900/attachment-0001.p7s>


More information about the Cscwg-public mailing list