Talk:S/MIME

This is the talk page for S/MIME, the Wikimedia software has some funny ideas about the slash, please ignore this technical oddity.

S/MIME

What it is ??? Secure transport or secure storage or both ?? For me secure storage storage is bad (no search and indexing). —Preceding unsigned comment added by 82.193.205.189 (talk) 08:53, 11 November 2008 (UTC)[reply]

Was the standard S/MIME named in reference to the German S-mine, the terrible antipersonnel mine (also known as the Bouncing Betty)?

Maybe, but I wouldn't have thought it to be very likely, personally. — Matt Crypto 16:17, 14 November 2005 (UTC)[reply]

I don't think there is any connection. It began life simply as Secure MIME. It appears as S-MIME in some early emails. The reason for the separator is to stop it reading smime which sounds like slime. --Gorgonzilla 15:39, 7 April 2006 (UTC)[reply]

It's simply S as in SSL Secure Sockets Layer or similar and TLS Transport Layer Security plus MIME Multipurpose Internet Mail Extensions. -- Omniplex 21:27, 7 April 2006 (UTC)[reply]

CryptoDox - S/MIME link

I would think, that this link shouldn't be in the article, because it leads to an article with the same name but much smaller (tiny). Why people should loose their time going there? —The preceding unsigned comment was added by Dinno (talk • contribs) 00:40, 17 April 2006 (UTC)

Agreed. The CryptoDox guy has spammed Wikipedia with lots of links to articles on his site, none of which, as far as I recall, have been anything that but poor in comparison to the corresponding Wikipedia article. If it's better, then fine, it's reasonable to include it. Not until then, however. — Matt Crypto 16:14, 17 April 2006 (UTC)[reply]

Gmail extension

The text should read "... functionality is availible in the ..." rather than "... functionality is built into the ...", as "built into" implies that S/MIME is provided with no modifications; this is not the case for some of these listed mail clients. Any objections?

Jdstroy 05:15, 11 October 2006 (UTC)[reply]

No longer applies. :( jdstroy 06:51, 12 December 2006 (UTC)[reply]

External Links

Someone has removed the external links that point to free and paid for Certificates but has left this in the body of the article.

"or from a public CA such as one of those listed below" Just think that it should be reworded to take the lack of CA's that are now no longer available. (81.19.57.186 16:35, 27 December 2006 (UTC))[reply]

Good catch. While Wikipedia is not a directory, it is acceptable to give a link to the appropriate dmoz directory category, which I have done. Wrs1864 16:47, 27 December 2006 (UTC)[reply]

Outlook Express

I do not think all versions of OE have the mentioned bug. The comment should be limited to the appropriate versions (if at all present). —The preceding unsigned comment was added by Herbys (talk • contribs).

Hello, please keep in mind to sign your comments on talk pages. -- intgr 06:07, 29 March 2007 (UTC)[reply]

I removed the statement altogether, for now. If anyone wishes to restore it with a proper source and with a specified version number, you can restore it from the edit history: diff. -- intgr 06:09, 29 March 2007 (UTC)[reply]

Email Encryption

I removed the Email Encryption link from the "See Also" section as the link was a dead-end and E-mail encryption is simply redirected to Pretty Good Privacy which is already in the "See Also" section. Perhaps a generic E-mail Encryption page needs to be created as both PGP and S/MIME are valid E-mail Encryption techniques. --Maetrics 01:50, 11 May 2007 (UTC)[reply]

I've placed E-mail encryption back into the "See Also" section as apparently 12 hours after my removal, someone planted an article which included the suggestions I made --Maetrics 23:20, 9 October 2007 (UTC)[reply]

Obstacles to deploying S/MIME in practice

The third bullet point down (currently) includes the sentence "Another argument is that servers often contain data that is confidential to the organization anyway, so what difference does it make if additional data, such a private keys used for decryption, are also stored and used on such servers?" The "another argument" part makes it sound like this will be an argument AGAINST using S/MIME for corporate webmail (given the section heading and parent bullet), but the gist of the sentence seems to be an argument FOR using it - or at least an argument for why it would be OK to use it. I guess what I'm saying is that this section is confusing! I'd try to fix it myself, but I don't know enough about the topic (which is why I'm looking it up...). Anybody care to clarify? -- Wegsjac (talk) 21:36, 16 November 2007 (UTC)[reply]

I can't say I agree with that part, but here is what I understand about the controversy of S/MIME on mail servers:

Anything encrypted with S/MIME is unreadable by those managing the mail server, or the server itself for that matter. This makes things like filtering spam nearly impossible, short of a DNSBL.
If the company mail server must be able to read all messages passing through the server, as is typically done for spam control, enforcement of company policies, etc. then he must either:

have a copy of the user's private key (defeating the purpose of public key cryptography) or
have the user send a copy to a separate recipient for all incoming and outgoing messages

If the server administrator does have one of the above, that means he can eavesdrop on any company communications, possibly infringing on trade trade secrets.

In cases like this, administrators have been known to use this information to trade stocks, based on CEO communications with other companies, thus the controversy. Do you risk letting the IT manager see everything that goes on, or do you let everyone get peppered with spam and let the IT manager foot the bill for more bandwidth to deal with it? 164.107.194.180 (talk) 22:08, 12 May 2009 (UTC)[reply]

Help needed in adding citations

We need to recruit volunteers to help by adding suitable citations - see http://wiki.riteme.site/wiki/Wikipedia:Verifiability - CecilWard (talk) 14:43, 13 August 2010 (UTC)[reply]

Should "Free S/MIME certificate issuers" belong to the article?

Between two editors, there is a dispute whether the "Free S/MIME certificate issuers" section in the article is against Wikipedia's policies on notability and inclusion, or valuable to the reader. 15:02, 5 March 2020 (UTC)

@8poland7: I noticed your account is new to Wikipedia, so it'd be good to familiarize yourself with Wikipedia's policy on what Wikipedia isn't; specifically, WP:LINKFARM (or WP:NOTDIR). WP:EL states Wikipedia articles may include links to web pages outside Wikipedia (external links), but they should not normally be placed in the body of an article. There are alternative outlets for link directories, such as DMOZ.
Two external links are referenced to WP:UGC sources, which are not reliable sources. While they follow WP:V on verifiability to exist, they do not follow WP:N for notability.
Two more external links are self-referential to the website, but lack any notability. A third one, CAcert.org, is notable with its own Wikipedia article and found from the "See also" section.
I propose any listed entries should be encouraged to be wiki-linked and have WP:WTAF, before inclusion in this article.
84.250.17.211 (talk) 15:27, 5 March 2020 (UTC)[reply]

This page was listed at WP:3O. It says there, "Before making a request here, be sure that the issue has been thoroughly discussed on the article talk page. 3O is only for assistance in resolving disagreements that have come to a standstill." Apart from 84.250.17.211's post above, there has been no discussion of anything for ten years! I'm removing the request until there has been a substantial discussion here. Scolaire (talk) 17:33, 13 March 2020 (UTC)[reply]

"not widely trusted"

Proof? Citation? Does this rating need to be part of the list Issuer List? It's an additional attribute and should be explained or listed somewhere else.LS (talk) 08:10, 30 May 2020 (UTC)[reply]

eFail was mitigated by S/MIME 4.0

Section on security should discuss S/MIME 4.0 (RFC 8551) especially as it pertains to mitigating or eliminating the problems identified by eFail.