Mailing List Archive

Hi

I just found that
https://extrassl.actalis.it/portal/uapub/doProcess

Provides a free smime certificate.

However the process is strange. Usually in comodo, I generated the
certificate with my browser, received an email with a link, which I had
to open with the browser I applied the certificate.

But this time not, I just obtained a pfx file which I could import, but
does somebody know whether there is a security breach, the way this
certificate was generated?

Thanks

Uwe Brauer

* Uwe Brauer via Gnupg-users:

> I just obtained a pfx file which I could import, but does somebody
> know whether there is a security breach, the way this certificate was
> generated?

Any process in which I do not create my private key, or in which a third
party asks me to provide them with my private key, is a process I would
refuse participating in.

-Ralph

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Sunday 20 October 2019 at 3:20:41 PM, in
<mid:87a79vsdl2.fsf@mat.ucm.es>, Uwe Brauer via Gnupg-users wrote:-


> I just found that
> https://extrassl.actalis.it/portal/uapub/doProcess

> Provides a free smime certificate.

[...]

> does somebody know whether there is a security
> breach, the way this
> certificate was generated?

I'm no expert but their Certificate Policy reads to me that the
private key is compromised right from the start. I think usually the
keys are generated on the subscriber's device and only the public key
goes to the CA to be certified.
https://www.actalis.it/documenti-it/caact-free-s-mime-certificates-policy.aspx

3.2.2 Proving possession of private key

The private cryptographic key corresponding to the public key
within the certificate is generated by the CA (with a suitable
algorithm, size, etc.) and subsequently sent to the subscriberin
PKCS#12 for-mat[PFX], via email, thereby insuring that the
subscriber does possess the private key.The password needed to
import the PKCS#12 file isprovided to the subscriber out-of-band
(via web), therefore protecting it from unwanted disclosure to
third parties. The CA does not retain such pass-word, so that the
legitimate subscriber –assuming that he/she keeps such password
confidential –remains the only person able to import the PKCS#12.

And

4.1Certificate Application, Processing and Issuance
To apply for a certificate pursuant to this CP, after accepting the
quote, the requestor shall fill in and submit aweb-basedrequest
formto be found on the CA web site.Before the requestor can
actually submit the certificate request form to the CA, he/she
must read and accept this Certificate Policy and the Terms &
Conditions; both documents are made available for download in the
same web form. The requestor’s acceptance is expressed by “point &
click”, as allowed by Italian and European legislation on distance
contracts. Furthermore, before the certificate request is
accepted, the CA shall perform I&A according to §3.2.Upon
submission of the certificate request form, the CA shall issue the
certificateand send this latter to the Subscriber via email.The
certificate is sent to the Subscriber requestor together with the
corresponding private key, both bundled into a PKCS#12 file[PFX].
The password needed to decipher the PKCS#12 file is shown to the
requestor in the browser, at the end of the certificate request
procedure. It is up to the Subscriber to keep that password
confidential and protect it from unwanted loss

- --
Best regards

MFPA <mailto:2017-r3sgs86x8e-lists-groups@riseup.net>

The cure for anything is salt water - sweat, tears, or the sea.
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXa5Apl8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw
Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju
+hLrAQDX3kiS9p18mUhVAnRBKf7feFGwxuY5AJR4sDXLNLIvaAD9FMxw2WwwSxSf
oUu2nNF725xRn2Ntz32fWx1LwrPWpwyJApMEAQEKAH0WIQRSX6konxd5jbM7JygT
DfUWES/A/wUCXa5Apl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw
REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/71GD/4kRUTdsHkJzBgmNue/KY9DEw5S
+LYPZU01uI3f4x+x5ECbXUhb5SmBiENKshhH1OcrGiZAV974scCJF2sjnZUfjHTX
IzXVbTKDI51WF1osGcLaHlrykNJ7HoV+qoZXrIUGts8KUipfUqqC9Zq7ZMHlDt/U
vjoUQxO9Akj7mBat4nWHO0f2bydULyxGwyLwdOKj3P/BoWQyG6eqHODr9iTceFnM
KZY6/Nabc9GO9HIRLQ48vMj+ElJNDefhyjg7P14GwGYRdzTxm1WaLCZNnz5aCfKo
rtRDvP6l/KiTTwezkIoBy3/YfwYYXlrJe7aklnhJVLnKGW+gpQrD2MYUztu+9r0J
doWEQnk8J6jIX47LaVC5KKoopD0ZSv4FGCSCRioqefVMQttSm5uPqim1zSZFNJBA
KIPXMlNbMTpoMvXjWGyYhEhkyg2GJeJeq84Qh9+D2SNCzglO7R1PCR7p/+JAX/Mi
CUG4s8MzRFH/9z0fRYXjrxxAX/aDX7hzInkw9Srw1L4n7JRJ5VQ/BO/wGGFFwmcq
uaJH4MFINSp6OgUppojGEGJaSLUsdGHVDxcmJMOg1047rjrf78aT1qhK6twSvMpv
aRtjZ/NJQDZt3eTdRVcb3aLvYzuha6A/mnSgH8KtrSlBZWRtRZtF+dEnP8o97sHN
hRogUjEPkCqkgFWzag==
=BJGA
-----END PGP SIGNATURE-----


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Sunday 20 October 2019 at 3:20:41 PM, in
<mid:87a79vsdl2.fsf@mat.ucm.es>, Uwe Brauer via Gnupg-users wrote:-


> I just found that
> https://extrassl.actalis.it/portal/uapub/doProcess

> Provides a free smime certificate.

[...]

> does somebody know whether there is a security
> breach, the way this
> certificate was generated?

I'm no expert but their Certificate Policy reads to me that the
private key is compromised right from the start. I think usually the
keys are generated on the subscriber's device and only the public key
goes to the CA to be certified.
https://www.actalis.it/documenti-it/caact-free-s-mime-certificates-policy.aspx

3.2.2 Proving possession of private key

The private cryptographic key corresponding to the public key
within the certificate is generated by the CA (with a suitable
algorithm, size, etc.) and subsequently sent to the subscriberin
PKCS#12 for-mat[PFX], via email, thereby insuring that the
subscriber does possess the private key.The password needed to
import the PKCS#12 file isprovided to the subscriber out-of-band
(via web), therefore protecting it from unwanted disclosure to
third parties. The CA does not retain such pass-word, so that the
legitimate subscriber –assuming that he/she keeps such password
confidential –remains the only person able to import the PKCS#12.

And

4.1Certificate Application, Processing and Issuance
To apply for a certificate pursuant to this CP, after accepting the
quote, the requestor shall fill in and submit aweb-basedrequest
formto be found on the CA web site.Before the requestor can
actually submit the certificate request form to the CA, he/she
must read and accept this Certificate Policy and the Terms &
Conditions; both documents are made available for download in the
same web form. The requestor’s acceptance is expressed by “point &
click”, as allowed by Italian and European legislation on distance
contracts. Furthermore, before the certificate request is
accepted, the CA shall perform I&A according to §3.2.Upon
submission of the certificate request form, the CA shall issue the
certificateand send this latter to the Subscriber via email.The
certificate is sent to the Subscriber requestor together with the
corresponding private key, both bundled into a PKCS#12 file[PFX].
The password needed to decipher the PKCS#12 file is shown to the
requestor in the browser, at the end of the certificate request
procedure. It is up to the Subscriber to keep that password
confidential and protect it from unwanted loss

- --
Best regards

MFPA <mailto:2017-r3sgs86x8e-lists-groups@riseup.net>

The cure for anything is salt water - sweat, tears, or the sea.
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXa5CFl8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw
Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju
+v+iAQCE1htzI++iZGPw3aWSdvYOtStbg/+RCOq/55iUo4AkXwD+Mpeawj+TjNNK
Kj7Bp9ciiGgtlsxqPeVtls8tMSNFDgaJApMEAQEKAH0WIQRSX6konxd5jbM7JygT
DfUWES/A/wUCXa5CFl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw
REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/+xoD/9rTd1kVPIlVjk9Worhv07MxsJ1
jLfWWifiLApgVG08JhOdjOSY8T3W4Ew/HbuvfS4/Xc1keGja7ZgEw7cSQf6LZxSz
GWH55I3y6zzh5B0JYqu+DWnsRjU3oxQhwWW2rwJFXEiEDBraerA28/8XO3CXBctm
0jjOAAA0VEfwJEJda7W32PqcSqfL+iRcoZc1vC3o6YjOdvpK/tHDNPL4KzAqt+rV
N4IraP1N/3oGKGT303G1U6eAR6Pvmsd7YSb0yLFKUVIsYzYW7GuhTiX65QvHC3ov
ss1vVDjTPxV8a7+0B1QuNlFRBpdrDAdG9t2ecblG5FcIeDrEaigabdN9QQG7RWtr
KPKv2E47bMUGgC3wqgeCO7qiCf6gSIdrI3aEi7Jvfpdu0vq4myf8ysuRL1yywaWJ
OD/taEJ50SNTwT38qWq2KWDEWo4jupPqqHfcWNLFG8ARa0mVu84GwkM7bB1bDsaF
DQKKukXsywq2EhE4CHgjWq/0jUbr6oDjxu7PIwxTdo7f/NWdOxqk9GPDMkIIsut/
fej/L6Rm0NgJfXmvWJAQ9ghCwGE3A+MoOoCWS30Czqz5+P3GpKpLyv54QEc1LrRz
CF8VNvEhMyRPlmlnns6QLvZmoYspXkygRho8xAYIqWQ/fS/ZufkS6FS82TY58fvf
rBJ7qMIUewF91bEIEQ==
=uB21
-----END PGP SIGNATURE-----


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

MFPA via Gnupg-users wrote in <1171562612.20191022004056@my_localhost_AR>:
|On Sunday 20 October 2019 at 3:20:41 PM, in
|<mid:87a79vsdl2.fsf@mat.ucm.es>, Uwe Brauer via Gnupg-users wrote:-
|
|> I just found that
|> https://extrassl.actalis.it/portal/uapub/doProcess
|
|> Provides a free smime certificate.
...
|> does somebody know whether there is a security
|> breach, the way this
|> certificate was generated?
|
|I'm no expert but their Certificate Policy reads to me that the
|private key is compromised right from the start. I think usually the

I think it is common that S/MIME and SSL certificates are
delivered via PKCS12, including the private key. You then seem to
extract the individual things like

$ openssl pkcs12 -in cert.p12 -out certpem.pem -clcerts -nodes
$ # Alternatively
$ openssl pkcs12 -in cert.p12 -out cert.pem -clcerts -nokeys
$ openssl pkcs12 -in cert.p12 -out key.pem -nocerts -nodes

|keys are generated on the subscriber's device and only the public key
|goes to the CA to be certified.

This is possible via CACert.org, at least still (out of money).
You create your local signing request, and the private key.pem never
leaves your own box:

$ openssl req -nodes -newkey rsa:4096 -keyout key.pem -out creq.pem

(Ensure all email addresses of desire are included in the web
form.)
Unfortunate that besides Comodo there seems no other provider of
free S/MIME certificates. You can only self-sign, and provide
a safe transport for a certificate to compare with. Which is why
PGP is so nice.

|https://www.actalis.it/documenti-it/caact-free-s-mime-certificates-polic\
|y.aspx
|
| 3.2.2 Proving possession of private key
|
| The private cryptographic key corresponding to the public key
| within the certificate is generated by the CA (with a suitable
| algorithm, size, etc.) and subsequently sent to the subscriberin
| PKCS#12 for-mat[PFX], via email, thereby insuring that the
| subscriber does possess the private key.The password needed to
| import the PKCS#12 file isprovided to the subscriber out-of-band
| (via web), therefore protecting it from unwanted disclosure to
| third parties. The CA does not retain such pass-word, so that the
| legitimate subscriber –assuming that he/she keeps such password
| confidential –remains the only person able to import the PKCS#12.

Better than nothing. Sometimes the browser is used to create
thins, i have done that once for StartSSL i think it was (now
defunct). I would not use this service, however, because why do
they want to do it like that? They could very well just offer the
one-liner and allow pasting of the signing request, then the
private key would never have been exposed to anyone but the user.

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> Hi
> On Sunday 20 October 2019 at 3:20:41 PM, in
> <mid:87a79vsdl2.fsf@mat.ucm.es>, Uwe Brauer via Gnupg-users wrote:-




> [...]


> I'm no expert but their Certificate Policy reads to me that the
> private key is compromised right from the start. I think usually the
> keys are generated on the subscriber's device and only the public key
> goes to the CA to be certified.
> https://www.actalis.it/documenti-it/caact-free-s-mime-certificates-policy.aspx

> 3.2.2 Proving possession of private key

> The private cryptographic key corresponding to the public key
> within the certificate is generated by the CA (with a suitable
> algorithm, size, etc.) and subsequently sent to the subscriberin
> PKCS#12 for-mat[PFX], via email, thereby insuring that the
> subscriber does possess the private key.The password needed to
> import the PKCS#12 file isprovided to the subscriber out-of-band
> (via web), therefore protecting it from unwanted disclosure to
> third parties. The CA does not retain such pass-word, so that the
> legitimate subscriber –assuming that he/she keeps such password
> confidential –remains the only person able to import the PKCS#12.


Oops this is really bad. I should have read this. Thanks for pointing it
out. I am wondering why they do such a bizarre thing? Maybe it is easier
to implement?

> MFPA via Gnupg-users wrote in <1171562612.20191022004056@my_localhost_AR>:
> |On Sunday 20 October 2019 at 3:20:41 PM, in
> |<mid:87a79vsdl2.fsf@mat.ucm.es>, Uwe Brauer via Gnupg-users wrote:-
> |
> |> I just found that
> |> https://extrassl.actalis.it/portal/uapub/doProcess
> |
> |> Provides a free smime certificate.
> ...
> |> does somebody know whether there is a security
> |> breach, the way this
> |> certificate was generated?
> |
> |I'm no expert but their Certificate Policy reads to me that the
> |private key is compromised right from the start. I think usually the

> I think it is common that S/MIME and SSL certificates are
> delivered via PKCS12, including the private key. You then seem to
> extract the individual things like


I think this is a severe security breach. The private key should never
leave your computer.

> $ openssl pkcs12 -in cert.p12 -out certpem.pem -clcerts -nodes
> $ # Alternatively
> $ openssl pkcs12 -in cert.p12 -out cert.pem -clcerts -nokeys
> $ openssl pkcs12 -in cert.p12 -out key.pem -nocerts -nodes

> |keys are generated on the subscriber's device and only the public key
> |goes to the CA to be certified.

> This is possible via CACert.org, at least still (out of money).
> You create your local signing request, and the private key.pem never
> leaves your own box:

> $ openssl req -nodes -newkey rsa:4096 -keyout key.pem -out creq.pem

> (Ensure all email addresses of desire are included in the web
> form.)
> Unfortunate that besides Comodo there seems no other provider of
> free S/MIME certificates. You can only self-sign, and provide

Comodo does not offer this any more. At the beginning of the year they
reduced the smime cerificates validity from 1 year to 1 month, now they
withdraw it all together.


> a safe transport for a certificate to compare with. Which is why
> PGP is so nice.

Well yes sort of, but I can tell you from my own experience PGP is more for
hackers while smime is not. I have convinced 6 of my friends to use
smime, but only one to pgp.

Self signed smime certificates are basically useless, because then you
have to tell the other user either to install a root certificate or to
trust the certificate, in which case smime looses its convenience
(compared to pgp)

* Steffen Nurpmeso:

> I think it is common that S/MIME and SSL certificates are delivered
> via PKCS12, including the private key. You then seem to extract the
> individual things [...]

Nope, that is the wrong way round. The correct sequence to obtain an
S/MIME certificate is as follows:

1. User X creates a private key *locally*. This private key must never
be handed to anybody else.

2. User X creates a certificate signing request (CSR) and sends it to a
certificate authority (CA).

3. The CA uses the CSR to create a signed certificate, and sends that
certificate back to user X.

4. User X can then optionally combine private key and signed certificate
in a .p12 file to ease importing the data *locally* in his MUA (it is
usually more convenient to deal with a single file that combines both
private key and certificate).

If the process is altered in any way in which a third party gets hold of
user X's private key, security is broken, no matter if the private key
is password protected or not.

-Ralph

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Hello,

please excuse the late reply.

Uwe Brauer via Gnupg-users wrote in <874kzz1var.fsf@mat.ucm.es>:
|> MFPA via Gnupg-users wrote in <1171562612.20191022004056@my_localhost_AR\
|> >:
|>|On Sunday 20 October 2019 at 3:20:41 PM, in
|>|<mid:87a79vsdl2.fsf@mat.ucm.es>, Uwe Brauer via Gnupg-users wrote:-
|>|
|>|> I just found that
|>|> https://extrassl.actalis.it/portal/uapub/doProcess
|>|
|>|> Provides a free smime certificate.
|> ...
|>|> does somebody know whether there is a security
|>|> breach, the way this
|>|> certificate was generated?
|>|
|>|I'm no expert but their Certificate Policy reads to me that the
|>|private key is compromised right from the start. I think usually the
|
|> I think it is common that S/MIME and SSL certificates are
|> delivered via PKCS12, including the private key. You then seem to
|> extract the individual things like
|
|I think this is a severe security breach. The private key should never
|leave your computer.
|
|> $ openssl pkcs12 -in cert.p12 -out certpem.pem -clcerts -nodes
|> $ # Alternatively
|> $ openssl pkcs12 -in cert.p12 -out cert.pem -clcerts -nokeys
|> $ openssl pkcs12 -in cert.p12 -out key.pem -nocerts -nodes
|
|>|keys are generated on the subscriber's device and only the public key
|>|goes to the CA to be certified.

With StartSSL it was like that, the browser generated the signing
request i hope. But i do not know.

And, the above i inherited in the manual of the software
i maintain. I have not seen this in the wild on my own.

|> This is possible via CACert.org, at least still (out of money).
|> You create your local signing request, and the private key.pem never
|> leaves your own box:
|
|> $ openssl req -nodes -newkey rsa:4096 -keyout key.pem -out creq.pem
|
|> (Ensure all email addresses of desire are included in the web
|> form.)
|> Unfortunate that besides Comodo there seems no other provider of
|> free S/MIME certificates. You can only self-sign, and provide

That i have done myself.

|Comodo does not offer this any more. At the beginning of the year they
|reduced the smime cerificates validity from 1 year to 1 month, now they
|withdraw it all together.

I did not know that. It was the only free service that i found
when i searched for a free S/MIME certificate last, but i kept
using CACert.org. (Until i support PGP, when i will switch.)

|> a safe transport for a certificate to compare with. Which is why
|> PGP is so nice.
|
|Well yes sort of, but I can tell you from my own experience PGP is more for
|hackers while smime is not. I have convinced 6 of my friends to use
|smime, but only one to pgp.
|
|Self signed smime certificates are basically useless, because then you
|have to tell the other user either to install a root certificate or to
|trust the certificate, in which case smime looses its convenience
|(compared to pgp)

Well, hm, yes. What should i say. It depends a bit, once you
know a certificate is correct some software allow to just agree to
the checksum of a certificate, for example, no need for a root
certificate no more. To know it is correct you need the
certificate which signed it in what you use as your local pool of
certificate authorities, of course.

I do have GPG keys in may keyring which were not signed by anyone
(when i downloaded them), too, i saw the fingerprint in some
announcement mail or on some website, searched SKS, and downloaded
the one key which did match. (I think Postfix releases are still
shipped with a gpg1 key sign that is revoked, last i looked,
i always have to look how i can actually use a revoked key
nonetheless.)

Personally i like S/MIME more, because it comes from the same pool
of standards etc. that TLS uses, and the same library can be used
to deal with it, than what i use for TLS anyway. In theory file
signing and all the other things would be possible via it, too,
the primitives are there, it is just not used in that there are no
omnipresent tools available, like GPG is.

There is no other reason really, except that for mail different
standards for MIME are used, and here i like the PGP one more ;)
That is just how it is, and having said that, i do use PGP since
many years, but only very rarely and mostly automatized (after
having had immense loss due to lost passwords of encrypted
backups).

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Hello,

sorry for the late reply.

Ralph Seichter wrote in <87pninuqns.fsf@wedjat.horus-it.com>:
|* Steffen Nurpmeso:
|> I think it is common that S/MIME and SSL certificates are delivered
|> via PKCS12, including the private key. You then seem to extract the
|> individual things [...]
|
|Nope, that is the wrong way round. The correct sequence to obtain an
|S/MIME certificate is as follows:
|
|1. User X creates a private key *locally*. This private key must never
|be handed to anybody else.
|
|2. User X creates a certificate signing request (CSR) and sends it to a
|certificate authority (CA).
|
|3. The CA uses the CSR to create a signed certificate, and sends that
|certificate back to user X.

Ok, but that is exactly what i have written a few lines later for
the CACert example that i posted, right. So not nope, Mr.
Where "user X" meant "browser of user X" when i did so for
a StartSSL certificate. I assume it did the right thing. But
i do not know.

|4. User X can then optionally combine private key and signed certificate
|in a .p12 file to ease importing the data *locally* in his MUA (it is
|usually more convenient to deal with a single file that combines both
|private key and certificate).
|
|If the process is altered in any way in which a third party gets hold of
|user X's private key, security is broken, no matter if the private key
|is password protected or not.

That is surely right.

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

P.S.:

Steffen Nurpmeso wrote in <20191023224323.KAODd%steffen@sdaoden.eu>:
...
||> I think it is common that S/MIME and SSL certificates are
||> delivered via PKCS12, including the private key. You then seem to
||> extract the individual things like
||
||I think this is a severe security breach. The private key should never
||leave your computer.

(Yes.)

||> $ openssl pkcs12 -in cert.p12 -out certpem.pem -clcerts -nodes
||> $ # Alternatively
||> $ openssl pkcs12 -in cert.p12 -out cert.pem -clcerts -nokeys
||> $ openssl pkcs12 -in cert.p12 -out key.pem -nocerts -nodes
||
||>|keys are generated on the subscriber's device and only the public key
||>|goes to the CA to be certified.
|
|With StartSSL it was like that, the browser generated the signing
|request i hope. But i do not know.
|
|And, the above i inherited in the manual of the software
|i maintain. I have not seen this in the wild on my own.

This is actually only half true. The original manual only
contains the first of the three.

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

* Steffen Nurpmeso:

> > * Steffen Nurpmeso:
> > > I think it is common that S/MIME and SSL certificates are delivered
> > > via PKCS12, including the private key. You then seem to extract the
> > > individual things [...]
> >
> > Nope, that is the wrong way round. [...]
>
> Ok, but that is exactly what i have written a few lines later for the
> CACert example that i posted, right. So not nope, Mr.

What you describe in the "I think..." paragraph is *not* the common way
to deliver certificates. Hence, nope.

-Ralph

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

So a trustful CA issueing free S/Mime certificates > 3 month and acceptance
in major browsers / mail tools is wanted.

Why doesn't Let's Encrypt offer this service?
https://letsencrypt.org/
Why isn't CAcert after years of participation listed as trusted CA in root
stores?
http://www.cacert.org/

kind regards Chris


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> Why doesn't Let's Encrypt offer this service?

Because it's outside the scope of what Let's Encrypt exists to do, which
is make it easy to provide HTTPS support to small websites.

SMTP is *totally* outside of Let's Encrypt's mission. If you've got a
problem with that, take it up with Let's Encrypt. They're pretty
responsive on Twitter at https://twitter.com/letsencrypt.

> Why isn't CAcert after years of participation listed as trusted CA in root
> stores?

Because CACert hasn't been able to comply with Mozilla's Root Store
Policy. Chrome has its own root store policy, as does Internet
Explorer. CACert hasn't been able to dot the is and cross the ts for
any of them, AFAIK.

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

* gnupgpacker@on.yourweb.de:

> Why doesn't Let's Encrypt offer this service?

S/MIME certificates have been repeatedly discussed and rejected in the
LE community, pretty much since LE's inception. There even used to be a
related FAQ entry.

One reason is that LE's self declared goal is to provide certificates
for web servers, and email communication between individuals is quite
a different beast.

-Ralph

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Robert J. Hansen wrote in <7e1208e4-aa1b-2e4c-3b3b-b74901456101@sixdemon\
bag.org>:
|> Why doesn't Let's Encrypt offer this service?
|
|Because it's outside the scope of what Let's Encrypt exists to do, which
|is make it easy to provide HTTPS support to small websites.
|
|SMTP is *totally* outside of Let's Encrypt's mission. If you've got a
|problem with that, take it up with Let's Encrypt. They're pretty
|responsive on Twitter at https://twitter.com/letsencrypt.

If i recall correctly Melnikov made a draft how the ACME stuff
could be extended to S/MIME, but it never left draft state. I do
not listen to the according IETF working groups, ... Wait, it is
still an active draft, version 6, last updated this year July: [1]
Unfortunately it wants DKIM/SPF/DMARC and a single MIME message
body, which counteracts my desire to vanquish that in favour of
a nice CMS thing that puts list addresses in From:, or so. Sigh.

[1] https://tools.ietf.org/html/draft-ietf-acme-email-smime-05

|> Why isn't CAcert after years of participation listed as trusted CA \
|> in root
|> stores?
|
|Because CACert hasn't been able to comply with Mozilla's Root Store
|Policy. Chrome has its own root store policy, as does Internet
|Explorer. CACert hasn't been able to dot the is and cross the ts for
|any of them, AFAIK.
|
|https://www.mozilla.org/en-US/about/governance/policies/security-group/c\
|erts/policy/

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users