[Cscwg-public] Conflict with RFC 3161 and CSBR 11.2.1
ianmcm at microsoft.com
Thu Mar 18 16:27:11 UTC 2021
Bruce, Dean, Corey:
I have a ballot in flight, CSC-8, that is about to end in the discussion week and start the voting window. Do you all feel comfortable if I added this change in as well for clean up? If not, I can add to the next ballot I have on key protection coming up next.
From: Cscwg-public <cscwg-public-bounces at cabforum.org> On Behalf Of Dean Coclin via Cscwg-public
Sent: Thursday, March 18, 2021 6:25 AM
To: Bruce Morton <Bruce.Morton at entrust.com>; cscwg-public at cabforum.org; Corey Bonnell <Corey.Bonnell at digicert.com>
Subject: [EXTERNAL] Re: [Cscwg-public] Conflict with RFC 3161 and CSBR 11.2.1
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.
From: Cscwg-public <cscwg-public-bounces at cabforum.org<mailto: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<mailto:Corey.Bonnell at digicert.com>>; cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>
Subject: Re: [Cscwg-public] Conflict with RFC 3161 and CSBR 11.2.1
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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcabforum.org%2Fwp-content%2Fuploads%2FEV-Code-Signing-v.1.4.pdf&data=04%7C01%7Cianmcm%40microsoft.com%7Cc43021a2567e40b36d5508d8ea112b65%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637516707048805737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3w5HwzWkcsZDN8aTf7othm1DXx5TMJFKz7Va%2FOQ%2Bvzk%3D&reserved=0>. 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.
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cscwg-public