[Smcwg-public] some thoughts on s/mime requirement sets

[Buschart, Rufus]

Hello Andreas!

> a. certificates on (highly) secure token
> 	-> it is not a good idea to encrypt anything with keys, which could not have any backups, but encryption is one of the key
> features of s/mime certificates

It is in corporate environments a typical scenario, that encryption private key pairs are centrally generated and stored for recovery at an Enterprise Trust Service Provider and securely injected into the (high) secure token. Both, Microsoft Minidriver and PKCS11 have a mechanism to do so over insecure connections. Currently, at Siemens, we have 350k active smart cards provisioned that way.

With best regards,
Rufus Buschart (still waiting for my TeleTrust-Footer)

Siemens AG
Siemens Operations
Information Technology
Value Center Core Services
SOP IT IN COR
Freyeslebenstr. 1
91058 Erlangen, Germany 
Tel.: +49 1522 2894134
mailto:rufus.buschart at siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Klaus Helmrich, Cedrik Neike, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

> -----Original Message-----
> From: Smcwg-public <smcwg-public-bounces at cabforum.org> On Behalf Of Henschel, Andreas via Smcwg-public
> Sent: Donnerstag, 20. August 2020 14:21
> To: smcwg-public at cabforum.org
> Subject: [Smcwg-public] some thoughts on s/mime requirement sets
> 
> Dear smcwg members,
> 
> please let me share some thoughts on our yesterdays call of the smcwg.
> 
> S/mime certificates are kind of different to all other certificates handled by cabforum so far, because of the very different usecases
> and user environments.
> 
> Just to bring some cases and related topics up:
> 
> a. certificates on (highly) secure token
> 	-> it is not a good idea to encrypt anything with keys, which could not have any backups, but encryption is one of the key
> features of s/mime certificates
> 
> b. group or domain certificates
> 	-> key management done by an email gateway
> 	-> just copy and distribute the encrypted key to any user of the group address
> 
> c. certificates on mobile devices
> 	-> nearly no key management possible done by the user
> 	-> quite impossible to use hardware token on mobiles
> 
> d. certificates stored in an OS keystore
> 
> e. different purposes or different combinations of purposes
> 	-> signing mails to guarantee integrity
> 	-> signing mails to claim authenticity
> 	-> encrypting mails to guarantee confidentiality
> 	-> signing mails for content commitment or wilful acts
> 
> 
> I think, we could find a lot more usecases and user environments of s/mime certificates easily.
> But from my point of view, it could be quite impossible to find all usecases, where thoses certificates are allready used.
> 
> So it could be more helpful for the first step of collecting the requirements, to start with the absolute minimum level, such for
> example to set the maximum validity period in general to 39 months or even a bit longer. As far as I know, many CAs offer certificates
> with a validity period of three years, but i've seen even five years.
> For example, if we start just with the purpose of "signing mails to guarantee integrity" the validity periode of the certificate does not
> even really matter.
> 
> With this mind set, we should step through all points of applicable requirements for the first draft.
> 
> After having a basic and accepted (and usable) minimum level, we can and should tighten security requirements where applicable.
> 
> 
> Kind regards,
> Andreas
> 
> 
> 
> Andreas Henschel
> 
> Principal product certification ETSI / eIDAS DTr PCS CM
> ------------------------------------------------------------------
> D-Trust GmbH | A Bundesdruckerei company Kommandantenstr. 15
> 10969 Berlin , Germany