[Cscwg-public] [EXTERNAL] Re: Signing Service Discussion of 10 March 2022

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Wed Mar 16 18:31:54 UTC 2022



On 11/3/2022 9:07 μ.μ., Bruce Morton wrote:
>
> Hi Dimitris,
>
> I see the value in creating greater improvements to signing, but as 
> you stated, I would prefer to make smaller improvements. I believe 
> that the first phase is to update the CSBRs based on the model changes 
> which we have discussed. I don’t think there would be a lot of effort 
> to get this done. I would be happy to draft proposed changes after we 
> have changed the CSBR format.
>
> I was reviewing TS 119 431-1, but also need to see EN 419 241-1. I 
> can’t find this document in my ETSI search. I am hoping that we will 
> find ETSI requirements which we might be able to use in the CSBRs, if 
> we find a gap.
>

EN 419 241-1 standard is produced with CEN and it follows a policy like 
ISO. You need to purchase a copy.

We probably need to focus on ETSI TS 119 431-1 (publicly available) 
which is precisely what we are trying to accomplish with the "signing 
service" in today's CSBRs. At the very minimum, we need to clarify what 
"signing service" means. Inigo, please chime-in if I missed anything 
related to the ETSI/CEN standards.

If members detect something in this ETSI document that is "too European" 
as some colleagues mentioned in our last call, we can take a closer 
look. In my personal opinion, I believe the document can work as a 
stand-alone standard that would allow any CA or entity that wants to 
manage keys on behalf of subscribers to be audited separately from the 
CSBRs.

As mentioned by others, the current CSBRs don't have any enforceable 
audit requirements for entities managing keys on behalf of subscribers. 
The goal would be to introduce some audit requirements in such services 
so they can be used in 16.2 and 16.3 as an alternative option for 
Subscribers to manage (generate/protect/use/destroy) their private keys.


Dimitris.

> Thanks, Bruce.
>
> *From:* Cscwg-public <cscwg-public-bounces at cabforum.org> *On Behalf Of 
> *Dimitris Zacharopoulos (HARICA) via Cscwg-public
> *Sent:* Friday, March 11, 2022 7:40 AM
> *To:* Bruce Morton via Cscwg-public <cscwg-public at cabforum.org>
> *Subject:* [EXTERNAL] Re: [Cscwg-public] Signing Service Discussion of 
> 10 March 2022
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know 
> the content is safe.
>
> ------------------------------------------------------------------------
>
> Following-up on the discussion about signing services, and the 
> decisions of previous meetings that a signing service is basically an 
> entity that manages private keys on behalf of Subscribers, please take 
> a look at the latest relevant ETSI TS available at:
>
>   * https://www.etsi.org/deliver/etsi_ts/119400_119499/11943101/01.02.01_60/ts_11943101v010201p.pdf
>     <https://urldefense.com/v3/__https:/www.etsi.org/deliver/etsi_ts/119400_119499/11943101/01.02.01_60/ts_11943101v010201p.pdf__;!!FJ-Y8qCqXTj2!Ijvhfy-9g01wuZ723tQAyBgBJgGeKkaTuxMc5JXiF3j2ydaMont9Piw0M6hmZP9Hk00$>
>
> The responsibility to manage keys on behalf of subscribers is not to 
> be taken lightly as the current CSBRs do. Agreed that we can take some 
> small improvements to the current CSBRs but if we believe that the 
> goal is to define a secure environment with secure policies/practices 
> that will make the ecosystem safer for subscribers and ultimately 
> Relying Parties, then we probably need to invest more time if we want 
> to copy good practices from other schemes.
>
> On the other hand, this ETSI standard is already auditable and a legal 
> entity could be audited and certified against ETSI TS 119 431. If a CA 
> or a Subscriber wants to use a signing service, that signing service 
> could either comply with the CSBRs and be audited against the 
> requirements of section 17.1, or be audited against ETSI TS 119 431.
>
> Thoughts?
>
> Dimitris.
>
> On 10/3/2022 10:00 μ.μ., Bruce Morton via Cscwg-public wrote:
>
>     Here is the text we were discussing in the CSCWG meeting today.
>
>     Thanks, Bruce.
>
>     =================================
>
>     Proposed Signing Service items:
>
>      1. Signing Service is may be performed by the CA or a third party
>      2. Signing Service is not a CA requirement, so is NOT a function
>         of a Delegated Third Party – this will limit scope
>      3. Signing Service references may be removed when not required -
>         this will limit implied scope
>      4. Signing Service is not a Subscriber, so all Private Keys are
>         only associated to certificate Subscriber
>      5. Signing Service is not an RA, so will not receive certificate
>         requests from an Applicant – CA or Delegated Third Party RA
>         will receive certificate requests
>      6. Signing Request requirements will not be defined in the CSBRs
>
>     Private key generation
>
>      1. Signing Service must provide evidence to the CA that the
>         private key was created by the Signing Service.
>      2. Question - Ballot CSC-13 allows the Signing Service to use
>         cloud-based key generation. Can the CA can operate the
>         cloud-based service?
>
>     Audit
>
>      1. Specific compliance sections of CSBRs and NetSec should be
>         stated in the CSBRs as the compliance/audit scope should not
>         be determined by the CA, Signing Service and Auditor. Note,
>         WebTrust for CA or ETSI EN 319 411-1 would not be in scope for
>         Signing Service.
>      2. For cloud-based key generation, is there a compliance
>         requirement for the cloud-based service?
>
>     /Any email and files/attachments transmitted with it are
>     confidential and are intended solely for the use of the individual
>     or entity to whom they are addressed. If this message has been
>     sent to you in error, you must not copy, distribute or disclose of
>     the information it contains. _Please notify Entrust immediately_
>     and delete the message from your system./
>
>     _______________________________________________
>
>     Cscwg-public mailing list
>
>     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!Ijvhfy-9g01wuZ723tQAyBgBJgGeKkaTuxMc5JXiF3j2ydaMont9Piw0M6hmIfo-ikE$>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20220316/8229979e/attachment.html>


More information about the Cscwg-public mailing list