[Cscwg-public] [EXTERNAL] Suspension of code signing certs

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Mon Feb 15 18:02:30 UTC 2021



On 12/2/2021 10:14 μ.μ., Bruce Morton wrote:
>
> Hi Dimitris,
>
> Good point that it is risky using the BRs, but that was the way that 
> the CSBRs were originally written. The same might be said about the EV 
> Guidelines.
>

You are referring to the same sentence that exists in the EV Guidelines 
under section 1

/"These Guidelines incorporate the Baseline Requirements established by 
the CA/Browser Forum by reference. A copy of the Baseline Requirements 
is available on the CA/Browser Forum’s website at www.cabforum.org."

/I guess I'm still unclear about what "incorporate by reference" means. 
Is it adherence to the entirety of the reference? Only when there is a 
lack of a similar section? Things are equally ambiguous (EVG and Code 
Signing BRs) because of the different numbering scheme.

//
>
> I think that this might be best addressed if we move the CSBRs to RFC 
> 3647 format. After which, we review the CSBRs to either confirm that 
> the section of the BRs if fine or the CSBRs should be updated.
>

I agree with that approach.

> I don’t believe that we should eliminate the BRs. The reason is that 
> there are some items that we want to be the same to help ensure 
> consistency across offerings and operations.
>

I believe the WG has made a decision in previous meetings to copy the 
entirety of the BRs for TLS that are meaningful for Code Signing, into 
the "BRs for Code Signing" to avoid any ambiguities and challenges 
regarding the version changes of the TLS BRs. The risk that was 
highlighted at that meeting was that the BRs for TLS might introduce an 
update that affects the Code Signing requirements by reference, without 
the Code Signing Working Group having evaluated these changes and how 
they affect the Code Signing ecosystem.


> For instance, we have one Subscriber Agreement for all certificates, 
> so we would not want the documents to conflict with each other on 
> these requirements. I also assume that we create root CAs to support 
> many certificate types, so root key generation should be the same for all.
>

We would have direct references to the BRs, which means that the Working 
Group has thought about it and makes an consious decision to refer to a 
specific section of the BRs or other documents. Copying sections of the 
TLS BRs into the CS BRs has been identified as the most secure way to 
avoid any unintentional consequences for the code signing ecosystem.

> It would be good if we could close any important items before going 
> through this project. I think that it would be best if we could get 
> the subscriber key generation/protection/audit ballot done first.
>

That seems like a good way to proceed.

Dimitris.

> Thanks, Bruce.
>
> *From:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
> *Sent:* Tuesday, February 2, 2021 12:02 PM
> *To:* Adriano Santoni <adriano.santoni at staff.aruba.it>; 
> cscwg-public at cabforum.org; Bruce Morton <Bruce.Morton at entrust.com>
> *Subject:* Re: [Cscwg-public] [EXTERNAL] Suspension of code signing certs
>
>
> This interpretation is very risky because the BRs were not developed 
> with code signing in mind but with TLS Certificates. I believe the 
> working group should focus on finding areas that are in the BRs, don't 
> exist in the CSBRs but are considered meaningful for code signing 
> certificates and update the CSBRs. This will avoid any ambiguities 
> about the expectations and keep CAs and auditors focused on one 
> document with direct references to TLS BRs and EV Guidelines.
>
> For example, in 17.5 of the CSBRs, we have clear requirements for EV 
> Code Signing Certificates. Does this mean that 8.7 of the BRs applies 
> and this requirement is also applicable for the non-EV Code Signing 
> Certificates? One is explicitly called out and the other is implicit 
> according to this interpretation.
>
> Similarly for the CRL profile 
> <https://urldefense.com/v3/__https:/github.com/cabforum/servercert/blob/main/docs/BR.md*722-crl-and-crl-entry-extensions__;Iw!!FJ-Y8qCqXTj2!KXIOcoWJx5dE6sqoBkQJNaMOEeSvD_TggxYHH8QDL11Vr-0pB1zooot9p1bigHR3YZA$> 
> and many other cases. These were recent changes to the TLS BRs. Are 
> they implicit requirements for code signing certificates?
>
> I believe we should discuss and clarify this issue soon.
>
>
> Dimitris.
>
>
> On 2/2/2021 6:47 μ.μ., Adriano Santoni via Cscwg-public wrote:
>
>     Thank you Bruce.
>
>     That answers my doubt, although indirectly, and I agree with your
>     interpretation.
>
>     I am not sure if it is worth to explicitate this in the CSBR ....
>
>     Adriano
>
>     Il 02/02/2021 14:56, Bruce Morton ha scritto:
>
>         The CSBRs state, “Except where specifically stated or in the
>         event of conflict in which case these Requirements will
>         prevail, this document incorporates by reference the Baseline
>         Requirements for the Issuance and Management of
>         Publicly-Trusted Certificates (“Baseline Requirements”), the
>         Network and Certificate System Security Requirements and, in
>         the case of EV Code Signing Certificates, the Guidelines For
>         The Issuance And Management of Extended Validation
>         Certificates as established by the CA/Browser Forum, copies of
>         which are available on the CA/Browser Forum’s website at
>         www.cabforum.org
>         <https://urldefense.com/v3/__http:/www.cabforum.org__;!!FJ-Y8qCqXTj2!KXIOcoWJx5dE6sqoBkQJNaMOEeSvD_TggxYHH8QDL11Vr-0pB1zooot9p1biqVQaYfI$>.”
>
>         The CSBRs do not state any requirements about suspension of
>         code signing certificates.
>
>         BR 4.9.13 states, “The Repository MUST NOT include entries
>         that indicate that a Certificate is suspended.”
>
>         My conclusion is that suspension of code signing certificates
>         is not supported by the CSBRs. If there is agreement, we could
>         make an update to the CSBRs to make this clear.
>
>         Bruce.
>
>         *From:* Cscwg-public <cscwg-public-bounces at cabforum.org>
>         <mailto:cscwg-public-bounces at cabforum.org> *On Behalf Of
>         *Adriano Santoni via Cscwg-public
>         *Sent:* Tuesday, February 2, 2021 4:38 AM
>         *To:* cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org>
>         *Subject:* [EXTERNAL] [Cscwg-public] Suspension of code
>         signing certs
>
>         WARNING: This email originated outside of Entrust.
>         DO NOT CLICK links or attachments unless you trust the sender
>         and know the content is safe.
>
>         All,
>
>         this is probably an old matter, but I could not solve my
>         doubts browsing the past posts.
>
>         I suppose, but I am not certain, that - as for SSL Server
>         certificates - Code Signing certificates must not be suspended
>         (that is, there must not be a CRLReason "certificateHold" in a
>         CRL entry). But maybe I am wrong, as I cannot find the
>         relevant language in the Code Signing BR. Anybody, please
>         point me at the right spot in the document.
>
>         TIA
>
>         Adriano
>
>         Il 01/02/2021 10:32, Dimitris Zacharopoulos (HARICA) via
>         Cscwg-public ha scritto:
>
>
>             According to the requirements, and section 13.2.1:
>
>             "CAs MUST provide OCSP responses for Code Signing
>             Certificates and Timestamp Certificates for the time
>             period specified in their CPS, which MUST be at least 10
>             years after the expiration of the certificate"
>
>             However, according to Certificate Consumer policies,
>             either CRL or OCSP is required to be used.
>
>             I would like to ask for Members to consider requiring
>             either CRL or OCSP information to be required in
>             end-entity certificates used for Time-stamping. The
>             rationale is that Time-stamping Certificates are very few
>             compared to other end-entity certificates and CRLs should
>             be considered sufficient because their size is not
>             significant.
>
>             Please let me know your thoughts, concerns or objections.
>
>
>             Thank you,
>             Dimitris.
>             _______________________________________________
>             Cscwg-public mailing list
>             Cscwg-public at cabforum.org <mailto:Cscwg-public at cabforum.org>
>             https://lists.cabforum.org/mailman/listinfo/cscwg-public
>             <https://urldefense.com/v3/__https:/lists.cabforum.org/mailman/listinfo/cscwg-public__;!!FJ-Y8qCqXTj2!KXIOcoWJx5dE6sqoBkQJNaMOEeSvD_TggxYHH8QDL11Vr-0pB1zooot9p1biIl3XcW0$>
>
>
>
>
>     _______________________________________________
>
>     Cscwg-public mailing list
>
>     Cscwg-public at cabforum.org  <mailto:Cscwg-public at cabforum.org>
>
>     https://lists.cabforum.org/mailman/listinfo/cscwg-public  <https://urldefense.com/v3/__https:/lists.cabforum.org/mailman/listinfo/cscwg-public__;!!FJ-Y8qCqXTj2!KXIOcoWJx5dE6sqoBkQJNaMOEeSvD_TggxYHH8QDL11Vr-0pB1zooot9p1biIl3XcW0$>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210215/b488edc8/attachment.html>


More information about the Cscwg-public mailing list