Thanks Kai for clarification, I will try getting this attribute into our next
batch of certificates.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On 23.11.18 12:58, Martin Büchler wrote:
> That is exactly what I am looking for: Where are the certificate requirements
> specified other than in TB source code? I then would like to instruct our PKI
> to add/change missing extensions, fields, or anticipated X500 name formats.
I agree it would
t one of the above mentioned email addresses in TB account
settings, then choose S/MIME settings, choose Select and dialog appears:
Zertifikateverwaltung kann kein gültiges Zertifikat finden, das verwendet
werden kann, um Ihre Nachrichten mit der Adresse @
digital zu unterschreiben.
(sorry for
On 22.11.18 17:38, mbch...@gmail.com wrote:
> Now, I want to import a certificate, originally created by our company PKI as
> SSL-Client certificate for use with Cisco Anyconnect VPN clients.
>
> I realized that it differs in its DN format, misses explicit mail
> sing/encryption flags and has ad
figure out why Thunderbird refuses to accept this cert for use
with either
@
or
@
but there seems to be no diagnostic output, nor any documentation, what the
minimum requirements for Thunderbird to accept a given cert for S/MIME actually
are.
I once debugged Thunderbird and NSS code to figure
+1 It's possible to sign a message with an S/MIME ECC cert, not encrypt it
with an ECC key though. Is there no plan to support elliptic curve
cryptography any time soon?
--
View this message in context:
http://mozilla.6506.n7.nabble.com/ECC-S-MIME-encryption-on-Thunderbird-tp353283p361985
Should Thunderbird allow encrypting of S/MIME email using an ECC
certificate? I can successfully sign and receive signed messages that
use an ECC certificate, but attempts to use the same certificate for
encryption get a pop-up window (during save or attempting to send) with
Unable to save
ve my issue.
- Why is there no option to attach my key into Thunderbird ? It is
present in OpenPGP but I would like to use S/MIME without this OpenPGP.
Thanks a lot for your help!
Best regards,
Thibault
--
Upozorneni: Neni-li v teto zprave vyslovne uvedeno jinak, neni tato e-mailova
n to attach my key into Thunderbird ? It is
present in OpenPGP but I would like to use S/MIME without this OpenPGP.
Thanks a lot for your help!
Best regards,
Thibault
smime.p7s
Description: S/MIME Cryptographic Signature
--
Upozorneni: Neni-li v teto zprave vyslovne uvedeno jinak, neni
re no option to attach my key into Thunderbird ? It is
present in OpenPGP but I would like to use S/MIME without this OpenPGP.
Thanks a lot for your help!
Best regards,
Thibault
smime.p7s
Description: S/MIME Cryptographic Signature
--
Upozorneni: Neni-li v teto zprave vyslovne uvedeno j
HI!
Mozilla Thunderbird and Seamonkey both choose triple-DES as default cipher for
S/MIME messages although the S/MIME caps in a former message of the recipient
contained AES256-CBC.
Can these be influenced by a property?
Or is this a NSA backdoor in the S/MIME standard?
Ciao, Michael.
--
dev
1 priority...
A workaround could be creating 2 thunderbird profiles (ie: thunderbird -P)
and configuring one account on each.
Regards
On Sat, Nov 15, 2014 at 5:19 AM, Serj wrote:
> Hi,
> I have two email accounts in Thunderbird. I want to test S/MIME and send
> an encrypted message.
> I
Hi,
I have two email accounts in Thunderbird. I want to test S/MIME and send
an encrypted message.
I have a problem with Certificate Manager. When I have installed 2 email
certificates for both accounts, after that I can't import a certificate
into "People" tab of Certificate Ma
Hi,
I have two email accounts in Thunderbird. I want to test S/MIME and send
an encrypted message.
I have a problem with Certificate Manager. When I have installed 2 email
certificates for both accounts, after that I can't import a certificate
into "People" tab of Certificate Ma
Hi,
I have two email accounts in Thunderbird. I want to test S/MIME and send
an encrypted message.
I have a problem with Certificate Manager. When I have installed 2 email
certificates for both accounts, after that I can't import a certificate
into "People" tab of Certificate Ma
ument ;-)
> And how does the MUA get this then?
Using a HTTP GET request.
> Because it's the S/MIME-enabled MUA which extracts e.g. the S/MIME
> capabilities.
The recieved file is then treated the same way a mail attached as a file
attachment to another mail.
Kind reagards,
Jan
On 16.06.2011 13:52, Gervase Markham wrote:
On 11/06/11 12:03, Michael Ströder wrote:
This means if the user accidently sent in contact information in an
e-mail footer this information is also disclosed. If not already there
you should put a strong hint on the web page that the signed S/MIME
On 11/06/11 12:03, Michael Ströder wrote:
> This means if the user accidently sent in contact information in an
> e-mail footer this information is also disclosed. If not already there
> you should put a strong hint on the web page that the signed S/MIME
> messages should not contain
the e-mail?
With which MIME-type? And how does the MUA get this then? Because it's the
S/MIME-enabled MUA which extracts e.g. the S/MIME capabilities.
Ciao, Michael.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Am 2011-06-10 15:54, schrieb Kai Engert:
>
> If you want an easier solution, you could write a client that integrates
> keyserver lookup by doing the web request from within your email client,
> and ask the user to solve the captcha in a popup message.
Maybe offer a download of the e-mail? This w
Kai Engert wrote:
On 08.06.2011 13:51, Jean-Marc Desperrier wrote:
Is the script smart enough to identify and extract the encryption
certificate in the mail when the sender uses separate signature and
encryption certificates ? (and of course the S/MIME properties are
correctly set to identify
On 06/10/2011 06:54 AM, Kai Engert wrote:
> On 10.06.2011 13:33, Jean-Marc Desperrier wrote:
>> Kai Engert wrote:
I'm thinking the following could solve the problem
>>>
>>> Please help me: which problem is it, that you want to solve, that isn't
>>> yet solved by the current implementation?
>>
box and click on it, etc.
The email redirection thing works, but we just can't "sell" it. It's not
a product, it's a lab's prototype.
Are you complaining about S/MIME in general?
The keyserver eliminates the hassle you experience when you're blocked
because you&
Kai Engert wrote:
I'm thinking the following could solve the problem
Please help me: which problem is it, that you want to solve, that isn't
yet solved by the current implementation?
Ease of use, understandability of the process for the average user.
Average users fills a form, and that's al
On 08.06.2011 14:15, Jean-Marc Desperrier wrote:
This seems to be solved with my implementation, because my keyserver can
forward the original signed message.
But it's not really a great solution.
Why not?
I'm thinking the following could solve the problem
Please help me: which problem
On 08.06.2011 13:51, Jean-Marc Desperrier wrote:
Is the script smart enough to identify and extract the encryption
certificate in the mail when the sender uses separate signature and
encryption certificates ? (and of course the S/MIME properties are
correctly set to identify this, and propagate
Kai Engert wrote:
> Another short note: The problem with solely distributing the S/MIME
> certs is that a MUA does not have the S/MIME capabilities of the cert
> owner's MUA. So the sender MUA might choose a weak symmetric cipher.
> ...
> So the safest way is still to
the S/MIME properties are
correctly set to identify this, and propagate the encryption certificate
in the signed mail in addition to the signature certificate)
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On 03.06.2011 00:12, Kai Engert wrote:
In short, go to
http://kuix.de/smime-keyserver/
and give it a try.
...
(as of today, the keyserver accepts the same signing roots
as Mozilla software. It also allows certs from cacert.org)
In addition it will also accept the certs from
http://ec.europa.
m with solely distributing the S/MIME
> certs is that a MUA does not have the S/MIME capabilities of the cert
> owner's MUA. So the sender MUA might choose a weak symmetric cipher.
> ...
> So the safest way is still to send a signed e-mail for cert exchange. :-/
This seems to b
: The problem with solely distributing the S/MIME certs is
that a MUA does not have the S/MIME capabilities of the cert owner's MUA. So
the sender MUA might choose a weak symmetric cipher.
We already had some discussion here about the Microsoft X.509v3 extension for
storing those in the certs
Kai Engert wrote:
In short, go to
http://kuix.de/smime-keyserver/
and give it a try.
I proposed such an idea in 2001 but never got the time to implement it.
Glad you did!
http://www.terena.org/activities/tf-lsd/docs/tf-lsd-4-tpp-certcollect.ppt
How are cert renewals handled? Will you send an
rvers - public
places from where you can download the keys of other people.
I was not aware of comparable solutions for S/MIME certificates.
I know that it's possible to stored personal certificates in LDAP
directories, but that's usually limited to closed environments, like
corporations.
Hello,
I want to protect my digital identity online. I want to digitally sign
all my emails. I've look really quickly and it seems that most major
provider have S/Mime certs for around $20/year.
I want to choose a good provider. So for instance I want to be able to
report that the cer
On 22.03.11 12:23, Sergei Evdokimov wrote:
I think, being able to support encryption or having an option that enables or
disables verification of email addresses in certificates would make sense.
Here is a hint for you.
At the lowest level, NSS doesn't track [email]->[certificate] relations,
On 22.03.11 21:00, Robert Relyea wrote:
On 03/22/2011 02:23 AM, silent...@gmail.com wrote:
<...> the requirement is to allow having more than one <...> email provider
AFTER the card was issued.
<...>
Unless there is an authoritative way to bind the cert to a given email address,
there is no w
t; later it appears that the message was forged). We are aware of the
> > risks that usage of such certificates introduces, but since the
> > attachment (sensitive medical data) will be signed with a qualified
> > signature, S/MIME signature will not be the only way for ensuring
>
n our case the CA performs
> identity verification (or from whom the certificate was stolen, if
> later it appears that the message was forged). We are aware of the
> risks that usage of such certificates introduces, but since the
> attachment (sensitive medical data) will be signed with
re of the
risks that usage of such certificates introduces, but since the
attachment (sensitive medical data) will be signed with a qualified
signature, S/MIME signature will not be the only way for ensuring
integrity and authenticity. But what is critical for us is the
confidentiality protection again
On 2011/03/22 02:23 PDT, silent...@gmail.com wrote:
> Well, the reasons are at least obvious to us :) - the card is supposed
> to be in use for least 5 years. Card owners (Health Care Providers in
> our case) should be able to use various email providers for exchanging
> medical reports.
Nothing
address in the certificate. Otherwise
you are completely loosing any value for signed and encrypted email.
Within an infrastructure, it's fine to use some other means to mind cert
to email (like ldap).
> Concerning compliance with S/MIME 3.0 and 3.1 - the sentence
> "Receiving ag
the requirement is to allow having more than one as
well to provide possibility to register or switch the email provider
AFTER the card was issued. And in general, as electronic IDs are
spreading (at least in Europe) this becoming quite a relevant
scenario.
Concerning compliance with S/MIME 3.0 and
On 2011/03/17 02:41 PDT, silent...@gmail.com wrote:
> It seems that Thunderbird refuses to use X.509 certificates for S/MIME
> encryption when these certificates do not contain email address of the
> subject. We want to use S/MIME with keys stored on smart cards and
> certificates dis
It seems that Thunderbird refuses to use X.509 certificates for S/MIME
encryption when these certificates do not contain email address of the
subject. We want to use S/MIME with keys stored on smart cards and
certificates distributed via LDAP. For obvious reasons we cannot
attach certificates to
; Unfortunately, the
> software I am using (ASN.1 Editor) doesn't read the p7m file despite the
> fact that it looks as a DER-encoded file at a first glance (even after
> removing the zero-byte padding).
You should see the RecipientInfos SEQUENCE.
Please consult the relevan
On 01/30/2011 03:04 AM, Nelson B Bolyard wrote:
> On 2011-01-30 02:30 PDT, Matej Kurpel wrote:
>> On 30. 1. 2011 10:57, Nelson B Bolyard wrote:
>>> Yes, the P7M holds all those encrypted copies of the key that
>>> encrypts the main message, and of course, the ciphertext produced
>>> with that key,
On 2011-01-30 02:30 PDT, Matej Kurpel wrote:
> On 30. 1. 2011 10:57, Nelson B Bolyard wrote:
>> Yes, the P7M holds all those encrypted copies of the key that
>> encrypts the main message, and of course, the ciphertext produced
>> with that key, And cert chains, and capabilities, and ... it's like
>
On 30. 1. 2011 10:57, Nelson B Bolyard wrote:
On 2011-01-29 06:41 PDT, Matej Kurpel wrote:
Hello,
as far as I know, Thunderbird sends encrypted e-mails as an attachment
named "smime.p7m".
Can anybody let me briefly know what this file contains?
Yes, it contains a message in the "Cryptographic
On 2011-01-29 06:41 PDT, Matej Kurpel wrote:
> Hello,
>
> as far as I know, Thunderbird sends encrypted e-mails as an attachment
> named "smime.p7m".
> Can anybody let me briefly know what this file contains?
Yes, it contains a message in the "Cryptographic Message Syntax" (CMS).
CMS is NOT SIM
Hello,
as far as I know, Thunderbird sends encrypted e-mails as an attachment
named "smime.p7m".
Can anybody let me briefly know what this file contains? I know this
from previous e-mail conversation from this mailing list:
"The sender generates an ephemeral 3-DES key one for each receiver, t
Nelson B Bolyard wrote:
> On 2010-06-12 00:50 PDT, Kaspar Brand wrote:
> That's a quote directly from
> http://social.technet.microsoft.com/Forums/en-US/officeappcompat/thread/3a19bbc7-9c6b-40ec-823d-16fd88e8de38
> or vice versa.
>
>> The statement about the SignerIdentifier is definitely incorrec
On 6/12/2010 2:50 AM, Kaspar Brand wrote:
>
> The statement about the SignerIdentifier is definitely incorrect. It
> seems that Microsoft does not yet fully understand the issue - does
> anyone here have straight contact to the Outlook dev team, or know
> people who have? I'd be happy to help (
On 2010-06-12 00:50 PDT, Kaspar Brand wrote:
> Sigh. I just came across this:
>
> http://support.microsoft.com/kb/2142236
> Non-Outlook email clients unable to decrypt email sent from Outlook 2010
>
> which states under "Cause":
>
>> Outlook 2010 now more fully implements the Cryptographic Mess
> As seen from the table above, this is currently a non-issue (Outlook
> will always encode SignerIdentifier with issuer name + serial). But
> I agree that the Outlook developers should pay attention to this as
> well when they are touching the code to fix the RecipientIdentifier
> stuff.
Sigh. I
On 10.06.2010 21:00, Nelson B Bolyard wrote:
> Kaspar, would you care to clarify what you mean by "old" format there?
> It appears to me that it always uses the KeyID format for the
> SignerIdentifier. I'd call the KeyID format the "new" format.
>
> Maybe you mean "old" as in the Outlook 2010 def
On 2010-06-03 21:52 PDT, Kaspar Brand wrote:
> On 03.06.2010 22:57, PDF3 SecureEmail wrote:
>> I suspect that NSS is not supporting "sender key ID" yet/properly.
>
> If you replace "sender key ID" by RecipientIdentifier, then that
> statement is true, yes. (Note, however that the MSFT moderator mi
On 03.06.2010 22:57, PDF3 SecureEmail wrote:
> I suspect that NSS is not supporting "sender key ID" yet/properly.
If you replace "sender key ID" by RecipientIdentifier, then that
statement is true, yes. (Note, however that the MSFT moderator mixes up
SignerIdentifier and RecipientIdentifier in his
On 2010/06/03 13:57 PDT, PDF3 SecureEmail wrote:
> According to the link at
> http://social.technet.microsoft.com/Forums/en-US/officeappcompat/thread/3a19bbc7-9c6b-40ec-823d-16fd88e8de38
> Outlook 2010 is OL2010 is using “sender key ID” instead of “issuer
> name and serial number” – as per an SMIM
On Apr 10, 7:37 am, Jean-Marc Desperrier wrote:
> On 31/03/201017:11, Kaspar Brand wrote:
>
> > On 31.03.201007:49, Michael Ströder wrote:
> >> It seems it's a CMS structure and recipientInfos contains subject key ids
> >> instead of issuerAndSerialNumber. It seems Seamonkey 2.0.x does not support
Yes, I'm sure that libmime uses nsCMSMessage for decrypting S/MIME
messages (and nsCMSMessage in turn uses libsmime). The path with the
code I previously pointed to is definitely hit when Thunderbird or
Seamonkey deal with an "enveloped-data" message.
> When I checked, I concluded
On 31/03/2010 17:11, Kaspar Brand wrote:
On 31.03.2010 07:49, Michael Ströder wrote:
It seems it's a CMS structure and recipientInfos contains subject key ids
instead of issuerAndSerialNumber. It seems Seamonkey 2.0.x does not support
that. Is it supported by the underlying libs?
I believe so,
On 01.04.2010 07:42, Michael Ströder wrote:
>> That aspect is covered by the CMS spec, actually. From RFC 5652, section
>> 6.2.1:
>>
>> When an X.509
>> certificate is referenced, the key identifier matches the X.509
>> subjectKeyIdentifier extension value.
>>
>> IOW, Outlook shou
Kaspar Brand wrote:
> On 31.03.2010 19:00, Michael Ströder wrote:
>> Strange because my e-mail cert does not have subjectKeyIdentifier at all.
>>
>> Hmm, in theory a S/MIME MUA could calculate it on-the-fly even if the cert
>> does not have one and build a lookup tabl
On 31.03.2010 19:00, Michael Ströder wrote:
> Strange because my e-mail cert does not have subjectKeyIdentifier at all.
>
> Hmm, in theory a S/MIME MUA could calculate it on-the-fly even if the cert
> does not have one and build a lookup table. Maybe it's worth to look what RFC
so by Seamonkey.
>
> Did you verify that the key id in the recipientInfo indeed matches the
> one from your cert? Otherwise libsmime might simply fail to find the
> correct private key.
Strange because my e-mail cert does not have subjectKeyIdentifier at all.
Hmm, in theory a S/MIME MUA cou
On 31.03.2010 07:49, Michael Ströder wrote:
> It seems it's a CMS structure and recipientInfos contains subject key ids
> instead of issuerAndSerialNumber. It seems Seamonkey 2.0.x does not support
> that. Is it supported by the underlying libs?
I believe so, see
http://bonsai.mozilla.org/cvsblam
HI!
Someone sent me an encrypted S/MIME message which I could not decrypt in
Mozilla's Seamonkey. It was generated by Outlook 2010 beta.
It seems it's a CMS structure and recipientInfos contains subject key ids
instead of issuerAndSerialNumber. It seems Seamonkey 2.0.x does not suppor
On 2010-03-05 15:58 PST, Wan-Teh Chang wrote:
> On Wed, Mar 3, 2010 at 4:05 AM, Jean-Marc Desperrier wrote:
>> TLS depends on the cipher-suites, and fortunately it's not hard-coded.
>>
>> Unfortunately, the first cipher suites using SHA256 are the one defined in
>> TLS1.2 (RFC5246), and I believe
On Wed, Mar 3, 2010 at 4:05 AM, Jean-Marc Desperrier wrote:
>
> TLS depends on the cipher-suites, and fortunately it's not hard-coded.
>
> Unfortunately, the first cipher suites using SHA256 are the one defined in
> TLS1.2 (RFC5246), and I believe the support for this RFC is still not
> included b
Gregory BELLIER wrote:
Ok, so it's still sha1 by default for S/Mime ?
Is it also sha1 by default for TLS ?
TLS depends on the cipher-suites, and fortunately it's not hard-coded.
Unfortunately, the first cipher suites using SHA256 are the one defined
in TLS1.2 (RFC5246), and I b
NSS and for Dogtag. I CC'ed you on the NSS RFE.
https://bugzilla.mozilla.org/show_bug.cgi?id=502139
This enhancement will be useless until Mozilla/"MailNews Core" attends
these capabilities. Given that TB security enhancements are stalled
for years, I wouldn't rely on this.
Nelson B Bolyard wrote:
> On 2010-02-18 03:06 PST, Michael Ströder wrote:
>
>> I'm using Seamonkey 2.0.3 under Linux. Is there a way to list and tweak the
>> cached S/MIME capabilities for certain recipients?
>
> There is no way to list them, at present. There could
Nelson B Bolyard wrote:
> On 2010-02-18 03:06 PST, Michael Ströder wrote:
>
>> I'm using Seamonkey 2.0.3 under Linux. Is there a way to list and tweak the
>> cached S/MIME capabilities for certain recipients?
>
> There is no way to list them, at present. There could
On 2010-02-18 03:06 PST, Michael Ströder wrote:
> I'm using Seamonkey 2.0.3 under Linux. Is there a way to list and tweak the
> cached S/MIME capabilities for certain recipients?
There is no way to list them, at present. There could be. It just doesn't
exist. As for "twe
Michael Ströder wrote:
This is because some influential people consider:
> * S/MIME caps are just a part of "mail security protocol"
Which is IMO complete non-sense.
Yes, and I don't believe this is the major reason why it's not possible
in Seamonkey/Thunderbir
Konstantin Andreev wrote:
> No. No such mail client exists that allow tune/edit recipient's S/MIME
> caps.
>
> This is because some influential people consider:
>
> * S/MIME caps are just a part of "mail security protocol"
> * protocol shouldn't b
Hello, Michael.
No. No such mail client exists that allow tune/edit recipient's S/MIME caps.
This is because some influential people consider:
* S/MIME caps are just a part of "mail security protocol"
* protocol shouldn't be exposed to end user to prevent securit
HI!
I'm using Seamonkey 2.0.3 under Linux. Is there a way to list and tweak the
cached S/MIME capabilities for certain recipients?
Ciao, Michael.
--
Michael Ströder
E-Mail: mich...@stroeder.com
http://www.stroeder.com
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
On 2009-12-25 08:28 PST, Konstantin Andreev wrote:
> On Wen, 03 Jun 2009, Nelson B Bolyard wrote:
>> Finally, I will add that (IINM) Thunderbird 3 has support for AES.
>> I don't know about the SHA1 vs SHA2 issue.
>
> No, it hasn't, TB hardcodes SHA1. No variations:
>
> ( begin cite )
On Wen, 03 Jun 2009, Nelson B Bolyard wrote:
Finally, I will add that (IINM) Thunderbird 3 has support for AES.
I don't know about the SHA1 vs SHA2 issue.
No, it hasn't, TB hardcodes SHA1. No variations:
( begin cite )
nsresult
nsMsgComposeSecure::MimeInitMultipartSigned()
{
...
Michael Ströder wrote:
Against which component?
Product: MailNews Core
Component: Security: S/MIME
A smart thing to do would be to test also Trustedbird
http://www.trustedbird.org and open a bug on their bug system if it fails.
They are much more likely to fix this than anyone else. And
Jean-Marc Desperrier wrote:
> Michael Ströder wrote:
>> I switched back to use SHA-1 and the very same
>> e-mails are now correctly validated in Seamonkey 1.1.18 and 2.0.
>
> So they were not before ?
Yes, the S/MIME signatures with SHA-256 were not correctly validated by
S
Michael Ströder wrote:
I switched back to use SHA-1 and the very same
e-mails are now correctly validated in Seamonkey 1.1.18 and 2.0.
So they were not before ? So you already know the answer ?
And should open a bug :-)
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https:
2009/12/7 Michael Ströder :
> HI!
>
> Are Outlook and Outlook Express currently capable of verifying S/MIME signed
> e-mails where SHA-256 is used as hash algorithm?
The Windows CryptoAPI supports SHA-256 on Windows Vista and Windows 7
(all service pack levels). On Windows XP, Crypto
Nelson B Bolyard wrote:
> On 2009-12-07 07:30 PST, Michael Ströder wrote:
>> Are the Mozilla-based MUAs Thunderbird and Seamonkey currently capable of
>> verifying S/MIME signed e-mails where SHA-256 is used as hash?
>
> Should be. Why don't you send me one?
Hmm, not a
On 2009-12-07 07:30 PST, Michael Ströder wrote:
> Are the Mozilla-based MUAs Thunderbird and Seamonkey currently capable of
> verifying S/MIME signed e-mails where SHA-256 is used as hash?
Should be. Why don't you send me one?
> Are Outlook and Outlook Express currently capable
HI!
Are Outlook and Outlook Express currently capable of verifying S/MIME signed
e-mails where SHA-256 is used as hash algorithm?
Ciao, Michael.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
HI!
Are the Mozilla-based MUAs Thunderbird and Seamonkey currently capable of
verifying S/MIME signed e-mails where SHA-256 is used as hash?
Ciao, Michael.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
2009/6/26 Michael Ströder :
Nelson B Bolyard wrote:
But only a small minority of mail users use MUAs
that reside on their own computers today. Webmail rules,
That might be true in the U.S. It's not true here in Germany.
and entrusting your private key to your free webmail provider makes
n
Michael Ströder wrote:
- add a time-stamp and update the S/MIME capabilities
and timestamp whenever a new S/MIME message is received.
- use the cert extension solely when no signed S/MIME message was received
so far or the notBefore date of the e-mail cert is newer than the
timestamp of the last
Jean-Marc Desperrier wrote:
> Nelson B Bolyard wrote:
>>> Does this assume LDAP for acquiring the certificate without a signed
>>> > S/MIME message? (So it is only relevant in corporate setting?)
>
>> No. There are many ways to get a cert for an email correspon
ls and security considerations.
I don't know how NSS caches the S/MIME capabilities received in signed
S/MIME messages.
But I'd suggest to add a time-stamp and update the S/MIME capabilities
and timestamp whenever a new S/MIME message is received. I'd suggest to
use the cert extens
I wrote:
>> If Microsoft has merely taken a DER-encoded object from another standard
>> and has incorporated it into a cert extension, that seems fine to me.
>> I hope they did it in such a way that existing BER/DER parsers of the
>> sMIMECapabilities attribute can just parse the extension body dir
Nelson B Bolyard wrote:
If Microsoft has merely taken a DER-encoded object from another standard
and has incorporated it into a cert extension, that seems fine to me.
I hope they did it in such a way that existing BER/DER parsers of the
sMIMECapabilities attribute can just parse the extension bod
On 2009-06-30 07:39 PDT, Jean-Marc Desperrier wrote:
> Nelson B Bolyard wrote:
>>> Does this assume LDAP for acquiring the certificate without a signed
>>>> S/MIME message? (So it is only relevant in corporate setting?)
>
>> No. There are many ways to get
Nelson B Bolyard wrote:
Does this assume LDAP for acquiring the certificate without a signed
> S/MIME message? (So it is only relevant in corporate setting?)
No. There are many ways to get a cert for an email correspondent.
There is only one way to get that correspondent'
Ian G wrote:
>> Google's Wave will hopefully be the finale for S/MIME.
>Hmmm, tell me more. It does look interesting!
>How is it secured? I read some blurbs and things but I'm hoping someone
>knows the answers.
I must confess that I don't have detailed knowled
On 26/6/09 23:51, Anders Rundgren wrote:
Google's Wave will hopefully be the finale for S/MIME.
Hmmm, tell me more. It does look interesting!
How is it secured? I read some blurbs and things but I'm hoping someone
knows the answers.
iang
--
dev-tech-crypto mailing list
dev-t
rule...otherwise somebody explain to me from what MS
>makes their revenues if not from Office, Exchange, Windows Mobile etc...
Oh, the two "big-brains" are again out on a crusade to save S/MIME and
fat e-mail clients.
We other "idiots" who occasionally need to access our
On 06/26/2009 09:18 PM, Michael Ströder:
Nelson B Bolyard wrote:
But only a small minority of mail users use MUAs
that reside on their own computers today. Webmail rules,
That might be true in the U.S. It's not true here in Germany.
Webmail doesn't rule...otherwise somebody explain
1 - 100 of 153 matches
Mail list logo
