support in the browser.
For a screendump please refer to: http://www.vandersman.org/certstore.PNG
Thanks.
Kind regards,
Michael
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
>
> Attach a copy of the binary DER cert to the bug. Please put my email address
> on the CC list for that bug.
>
> Are those fields encoded with UTF8String as they should be? Can you send a
> URL pointing to the cert to this list?
Thanks for the super quick response. I got the details on my
Just uploaded the certificate in DER and PEM file format.
It can be found here:
www.boraxx.nl/Mozilla/Thai.der
www.boraxx.nl/Mozilla/Thai.crt
The required CA chain can be found here:
www.boraxx.nl/Mozilla/ChainUCAcert.pem
___
dev-tech-crypto mailing list
ect experience I can confirm that it's exactly like what Kyle
suspects. I won't mention names but bringing your CA certs into MS IE
and the Mozilla products is simply a cash cow. Nothing else. In the
cases I know no audits were conducted on sub-CAs by
giving
guarantees and deny any warranties in your Mozilla policy. ;-}
> The only responsible body where I can influence anything of the
> mentioned above, is the Mozilla Foundation.
Eddy, thanks for doing this work. Again: Good luck.
Ciao, Michael.
about issuer of a certificate such as
issuer's name, country, organization and so on.
Any suggestions are appreciated.
Thanks for your attention,
Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozill
ponder just for that.
Any clue how to let Mozilla locate the KDC via normal DNS SRV RRs?
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Michael Ströder wrote:
>
> If I configure the KDC in /etc/krb5.conf in section [realms] everything
> works fine. But I'd like to let the clients lookup the KDC in DNS SRV
> records. This works fine for the MIT utils like kinit etc. but not for
> Firefox and/or Seamonkey
or vendor simply does not work with 4096 bit
root.
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
mediately admit that (a) is silly from a security perspective.
But it's not silly from a practical migration perspective. It does make
sense for CAs.
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
ontrol and you can freely choose to
change them all at a time.
Obviously that's not the case for the pre-installed root CA certs.
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Kyle Hamilton wrote:
> I do know that some Cisco VPN equipment doesn't like 4096-bit root
> keys.
Yupp.
> I don't know if it likes 2048-bit keys.
It works with 2048-bit keys.
Ciao, Michael.
___
dev-tech-crypto mailing l
omers'
(subscriber) side. But as a relying party I'd want that certs for weak
keys are revoked in any case.
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Glancing over these documents I found no provision that the dNSName in
subjectAltName MUST specify a fully-qualified domain name. But maybe
this issue should raised on the ietf-pkix mailing list.
Ciao, Michael.
___
dev-tech-crypto mailing list
Jean-Marc Desperrier wrote:
> Michael Ströder wrote:
>> [...]
>> RFC 2818 (only INFORMATIONAL) references RFC 2459 concerning matching
>> rules which was obsoleted by RFC 3280 which was recently obsoleted by
>> RFC 5280. RFC 5280 references "Preferred name syntax&q
ch is IMHO not
only made up by the key's bit-length) then the CA should revoke the
accompanying cert.
> They keys are not "broken", they are "trivial to break if an attacker
> wants to". That's an important difference, and one that needs to b
s conducted the fully-qualified domain name used to
connect to the host must be displayed to the user and must be verified
to be in the cert.
I'd prefer 1. For both solutions only fully-qualified domain names are
needed in the certs.
Ciao, Michael.
bout https://com/ (top-level domain)? As I noted in a previous
posting technically you can't tell without actually trying to lookup a
hostname in DNS (without search suffix automagic).
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-cry
lic evidence), then there can be no further
> true assurances for the binding, and the CA is responsible to act, IMO.
I strongly agree. Especially in this particular case.
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mo
in to FF3
> and IE7, and they're covered, because the CAs will do a competent job of
> revocation for them." That's real value that any Debian user can see.
Yes! To CA staff lurking here: Prove your trustability now to save your
own business!
Ciao, Michael.
__
hould revoke it, right?
Eddy, this is not comparable. We're talking about the likelihood of a
key being in the range of what we now consider "weak Debian keys".
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-cry
[EMAIL PROTECTED] wrote:
> On Jun 9, 2:55 pm, Michael Ströder <[EMAIL PROTECTED]> wrote:
>> I really wonder what makes a host name an "unqualified hostname"?
>
> One workable definition is a host name without a dot "." (ignoring any
> trailing dots).
t; "Any"? Do you really think that a typical Firefox user, even when this
> is all explained to them, would be as strident as you are here?
The typical Firefox user trusts the PKI. It delegates security checks to
a trusted third party. The CA's *business* is to help th
other groups working on it do not want to
publish their results...
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
> Revocation requests are trickling in due to the messages we sent and I
> hope that the larger part will have their certificates revoked and
> re-created during the next few days. The remaining certificates will be
> revoked forcefully wi
Yevgeniy Gubenko wrote:
>
> 1.export public key from Solaris to Windows in JKS format
>
> 2.import public key from Windows to Solaris into NSS database
I would export as PKCS#12 format and import that to NSS cert DB.
Ciao, Michael.
Nelson Bolyard wrote:
> I'm working on some code to handle the "Issuing Distribution Point"
> extension in CRLs.
What happens if the CRL's URL is redirected to another URL?
Ciao, Michael.
___
dev-tech-crypto ma
Nelson B Bolyard wrote:
> Michael Ströder wrote, On 2008-06-28 02:03:
>> What happens if the CRL's URL is redirected to another URL?
>
> I think you're asking what happens if the attempt to fetch a CRL itself
> (say, via an http GET request) results in an http red
mmended. Also RFC 2585 (referenced in above text)
does not say anything like this in section "3 HTTP Conventions".
I'm rather scared of implementations not capable to follow HTTP redirects.
Ciao, Michael.
___
dev-tech-crypto mailing list
d
is is an oversight that should
> be fixed
Full ack!
> (this is separate from the "SSL to non-SSL" config preference
> which isn't enabled by default).
Which is also sad anyway... :-(
Ciao, Michael.
___
dev-tech-crypto mailing
fc/rfc2585.txt
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
penldap-devel:
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg02484.html
Did you actually read this thread? Especially this posting:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg02510.html
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Nelson B Bolyard wrote:
> Michael Ströder wrote, On 2008-07-25 06:13:
>> Nelson B Bolyard wrote:
>>> I suggest you look at
>>> http://developer.mozilla.org/en/docs/NSS_Certificate_Download_Specification
>>> for ideas on importing certs.
>> I wonder why Moz
ot;, O_WRONLY|O_CREAT|O_TRUNC, 0666) = 6
read(0,
- snip -
This is all done with openSUSE 11.0 packages:
mozilla-nss-3.12.0-23.4
mozilla-nss-tools-3.12.0-23.4
Ciao, Michael.
___
dev-tech-crypto mailing list
Michael Ströder wrote:
>
> I'd like to generate and verify a detached signature (in a separate
> file) with a key from my Seamonkey profile. Is this approach with
> cmsutil ok (single command-line wrapped here)?
>
> cmsutil -S -d ~/.mozilla/xxx/ -N "cer
Michael Ströder wrote:
> I also tried signver but this hangs:
>
> signver -V -v -d ~/.mozilla/xxx/ -i name.tar.gz -s name.tar.gz.p7m
>
> strace output of hanging signver:
>
> - snip -
> open("name.tar.gz"
Nelson B Bolyard wrote:
> Michael Ströder wrote, On 2008-08-05 15:44:
>> Michael Ströder wrote:
>>> I also tried signver but this hangs:
>>>
>>> signver -V -v -d ~/.mozilla/xxx/ -i name.tar.gz -s name.tar.gz.p7m
>>>
>>> strace output of h
following message:
-- snip --
signer 0 status = DigestMismatch
cmsutil: problem decoding: Signature verification failed: no signer
found, too many signers found, or improper or corrupted data.
------ snip --
Ciao, Michae
Nelson B Bolyard wrote:
> Michael Ströder wrote, On 2008-08-06 04:07:
>> Nelson B Bolyard wrote:
>>>> cmsutil -D -d ~/.mozilla/xxx/ -c name.tar.gz -i name.tar.gz.p7m -o test
>>> I remember running into this long ago. As I recall, the pass/fail result
>>
Michael Ströder wrote:
> Nelson B Bolyard wrote:
>> The binaries for the NSS 3.11.4 release may be obtained from
>> ftp://ftp.mozilla.org/pub/security/nss/releases/NSS_3_11_4_RTM/
>> If the -s option also behaves as you found with those binaries, I'd like
>> to know
Wan-Teh Chang wrote:
> Which Linux distribution is this?
openSUSE Linux 11.0
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
3rd-party docs around and people are
familiar with it.
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
with which DB version. I remember a serious
problem with cert7.db used by a 3rd-party product and different media
releases of NSS.
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
at the moment.
Well, that would be something I'd like to use. ;-)
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Howard Chu wrote:
> Michael Ströder wrote:
>> I'd really appreciate if the OpenLDAP client libs could make use of
>> client certs I have in my Mozilla profile.
>
> Don't be so sure; it's not as good as it sounds... Without the new
> shared DB support in N
cmsutil also opens in read-write mode
which would IMHO not be necessary.
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
ert.
IIRC Firefox (and Seamonkey) never showed the 50 subject alt names when
asking for the peer trust. If the UI wouldn't be so terse the user would
have understood this.
Regarding PKI/LDAP features there are still things lacking in recent
Mozilla apps which worked pretty well
I'm having a problem signing my Firefox extension on Mac OS X. The error
I get is:
signtool: function failed: An I/O error occurred during security
authorization.
I built NSS and NSPR myself using Darwin Ports
sudo port install nspr (4.7_1)
sudo port install nss (3.11.9_0)
I have had no
Wan-Teh Chang wrote:>
> Please provide the signtool command line you used, and the
> content of the relevant directories.
>
> "An I/O error occurred during security authorization" is
> SEC_ERROR_IO. This error often has nothing to do
> with I/O. SEC_ERROR_IO is reported when
> libsoftokn3.dylib
For the record, everything works fine with an NSS 3.12 that I built on
my machine.
So I don't know if it is an NSS 3.11 problem (which might be the case
since other people have reported it) or a problem with darwin ports
(which I doubt)
Mike Kaply
__
With NSS 3.12 it looks like this after import (and works)
c1dfd405-9dc0-4b7c-8e98-7b2772a81922 u,u,u
Thawte Code Signing CA - Thawte Consulting cc,,
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.or
Nelson B Bolyard wrote:
> Michael Kaply wrote:
>> Wan-Teh Chang wrote:>
>>> Please provide the signtool command line you used, and the
>>> content of the relevant directories.
>>>
>>> "An I/O error occurred during security authorization"
Nelson B Bolyard wrote:
> Michael Kaply wrote:
>> Nelson B Bolyard wrote:
>
>>> what does
>>> certutil -d ~ -L
>>> output?
>> c1dfd405-9dc0-4b7c-8e98-7b2772a81922 u,u,u
>> Thawte Code Signing CA -
For the record, I just checked my Windows machine (where all this works)
It's NSS 3.11
The extra "thawte" is not in the database
c1dfd405-9dc0-4b7c-8e98-7b2772a81922 u,u,u
Thawte Code Signing CA - Thawte Consulting ccc,,c
I used exactly the same PFX file
Julien R Pierre - Sun Microsystems wrote:
> Mike,
>
> Michael Kaply wrote:
>> For the record, everything works fine with an NSS 3.12 that I built on
>> my machine.
>>
>> So I don't know if it is an NSS 3.11 problem (which might be the case
>> since
Nelson B Bolyard wrote:
> Michael Kaply wrote:
>> For the record, I just checked my Windows machine (where all this works)
>>
>> It's NSS 3.11
>>
>> The extra "thawte" is not in the database
>>
>> c1dfd405-9dc0-4b7c-8e98-7b2772a81922
OK, so basically it's the darwin ports version of NSS 11.9 that is
causing the problem.
If I build it myself everything is great.
What a waste of two hours yesterday.
Anyone have a script that shows how NSS/NSPR should be installed on Mac?
Mike
___
d
b application server has to fully
trust the web frontend server.
But behind this web frontend server you can do filtering of requests.
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
ntication to replace "Basic Authentication".
Not really. HTTP basic authc is security-wise worse than form-based
authc with session handling because the user's credential goes over the
wire in clear with each HTTP request and the browser caches it for the
Michael Ströder wrote:
> Anders Rundgren wrote:
> > Today I was in a meeting with Swedish bank-people. They
> > told me that they are planning exodus from TLS-client-cert-auth
> > because it (in their opinion) works really bad.
>
> Well, most times I don't
en most banks do not get their
simple web sites right to really prevent CSS attacks I'm strictly
against such things.
I'm scared that users are tricked. Period.
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Kyle Hamilton wrote:
> http://www.darwinports.com/ -- the version they claim is 3.11.9.
>
They actually download, build and install the real thing, but they make
some changes.
Here are their makefile changes:
http://svn.macports.org/repository/macports/trunk/dports/net/nss/files/patch-Darwin.m
Wan-Teh Chang wrote:
n/NSS_reference/Building_and_installing_NSS
>
> For Mac OS X, copy all the *.dylib and *.chk files from
> mozilla/dist/Darwin...OBJ/lib to the installation directory.
> Then copy the command-line tools you want from
> mozilla/dist/Darwin...OBJ/bin to the installation directory
Anders Rundgren wrote:
> Michael Ströder wrote:
>> Sure the UI for choosing the client cert could be improved, e.g. just by
>> displaying more informational attributes from the cert and the PKI
>> properly filling this attributes.
>
> Essentially you are saying that In
in the TLS selection GUI based on [for example] key usage.
> I don't consider this a bug in FF, but a deficiency in TLS-
> client-cert-auth which didn't take this issue in consideration.
> The "fat-app" alternatives usually offer much be
OK, so now I'm really confused. I've done some testing and I am getting
predictable but very confusing results.
I've figured out when the extra thawte cert shows up in my DB and screws
things up.
Note this is all with NSS 3.12
I built NSS 3.12 opt.
Then I put the dylibs and the bin for certut
Anders Rundgren wrote:
> "Michael Ströder" <[EMAIL PROTECTED]> wrote
>
>> I fail to see how this could be improved by new shiny XML-based protocol
>> but cannot be improved with the existing protocols (like TLS).
>
> Because the people that works with new
Some more test info.
I put everything (dylibs, executables) into usr/local/bin
certutil works
pk12util works (although I get the extra thawte that we talked about
earlier)
signtool fails with:
signtool: function failed: Failure to load dynamic library.
Unknown error: -2804
if I move a
Eddy Nigg wrote:
> The keygen tag is used widely and Mozilla supports smart cards with the
> associated PIN excellent.
I agree. And I'd prefer it over the scripted approach of MS IE.
Some issues could be solved by adding attributes for further parameters.
Ci
256_sha
Are the Tomcat developers aware of this issue?
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
system to be to make use of it as well.
Currently the project creation request resides in the freedesktop.org
bugtracker:
http://bugs.freedesktop.org/show_bug.cgi?id=16581
Please CC me on replies as I'm currently not subscribed to this list.
Regards,
Michael
pt their e-mail. So they simply avoid
additional work. This cannot be solved technically.
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
largely funded by the US government).
"Michael Ströder" <[EMAIL PROTECTED]> wrote:
The biggest obstacle preventing people to use S/MIME (or even PGP) is
that they don't have to. They are not forced by security policies,
business contracts etc. to encrypt their e-mail.
olved by yet another
technical approach which looks more "easy" to some people.
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Julien R Pierre - Sun Microsystems wrote:
Michael,
Michael Ströder wrote:
Anders Rundgren wrote:
IM[NS]HO, S/MIME encryption using PKI is one of the biggest security
farces ever.
I don't see why.
Regarding the guide, I believe that e-mail encryption would be fairly
common
if it had
st glad to contribute something to others that are trying to
wack themselves a way through the jungle of getting secure email
off the ground.
And that's much appreciated!
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mo
extension.
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
have
a lab where each and every version of the software is installed for
testing by assessors.)
Also when signing a contract by hand I usually get a physical copy of it
which I can archive. That's not the case when doing web-signing. That's
another important flaw of that scheme.
Ciao, Mi
protect
the user by specifying minimal requirements for the signature process
and components used. I guess that's what Anders calls "(German
nfluences...) monstrosity" in his other posting.
Ciao, Michael.
___
dev-tech-crypto mailing list
de
TTPS connection to the webserver to
make it happen?
No.
This is a business problem not a tech problem.
Exactly!
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
data from
the simple HTML which was signed.
Store it somewhere? Verify it somehow?
Nope.
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
racts.
That's the whole point. And there's no technical solution for it.
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
h could
be your employer or Google, and for the really paranoid a server you run
yourself.
As I wrote even if you have your domain-wide PKI the other end has to
also do the homework. If there's no real business requirement to do so
they will not.
Ciao, Michael.
- Original Message -
persistent secret in the game - likely the
user's password which is being used as shared secret. Kerberos works
that way. The caveat is that it needs network on-line access to a
central infrastructure. X.509 PKI does not require this.
Ciao, Michael.
_
Ian G wrote:
Michael Ströder wrote:
Anders, that's not the real problem with S/MIME or PGP.
Encrypting/signing is simply not a business requirement.
...
=> Encrypting/signing must be made a business requirement in
contracts. That's the whole point. And there's no technica
all the control the cell phone provider has over them,
2. all the gadgets installed with security issues,
3. with the limited data storage size on today's SIM cards.
And the main point: You fail to explain how trust is to be established.
Ciao, Michael.
__
Ian G wrote:
Michael Ströder wrote:
Ian G wrote:
Michael Ströder wrote:
Anders, that's not the real problem with S/MIME or PGP.
Encrypting/signing is simply not a business requirement.
...
=> Encrypting/signing must be made a business requirement in
contracts. That's the who
ity reviewers know a lot about Windows (and Linux and Mac
OS X) in comparison to public knowledge about Android. So you can't tell
at this time.
I don't expect a reply on this because it will anyway take some five
years or so to figure out if the ab
nticate the checksum over the results.
Yupp. But that's kind of an enrollment process which is what Anders
would like to avoid.
(Mind you, let's not get too hung up on this, as "trust" is not defined
yet!)
Trust is like beauty. Beauty is in the eye of the behold
device key certified to establish trust?
http://tinyurl.com/6rg7ap <http://tinyurl.com/6rg7ap>
Pretty vague.
This all does not solve the basic problem which is: People are too lazy
to use this technology to mitigate risks if they are not forced to use
it (by law or security policy).
Ciao,
Anders Rundgren wrote:
Michael Ströder wrote:
Ian G wrote:
* it has no open + effective key distribution mechanism. (I exclude
the LDAP stuff as that is generally for internal / corporates, and is
not a general solution for the users.)
Just exchanging signed S/MIME e-mails is quite easy
Ian G wrote:
Michael Ströder wrote:
Anders Rundgren wrote:
Michael Ströder wrote:
>
I can offer a counterpoint: a recent well-thought-out project to do
something similar started out with S/MIME, and concluded that S/MIME
should be optional because it is brittle,
The phrase "becau
not want to use these keys for personal communication
exchanging intimate details of your private life.
The problem is that there are as many
points of ultimate trust as there are people.
I'd argue that there even are many points of trust per person. ;-)
But the trust model is not the
Ian G wrote:
Michael Ströder wrote:
The root cause is that protecting e-mails is not enforced/endorsed
within companies even if they have a working infrastructure. The lack of
training is the consequence of this.
OK, so would you agree that this is not very useful for the non-company
don't know which cert
is in use. Or, if set to "ask-me", it asks me practically every click
which to choose, and sometimes twice or thrice per click. If I had more
time I'd chase the bugzilla.)
I think these issues are mainly caused by misconf
?id=45107
Status is still NEW...and will probably forever.
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
t on this. If in doubt this should
be clarified (e.g. on ietf-smime mailing list).
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Ian G wrote:
Michael Ströder wrote:
Eddy Nigg wrote:
On 12/05/2008 08:58 AM, Ian G:
> When I lose a key, all the old encrypted email is no
longer readable ... which presumably happens when revocation happens as
well.
For your protection, yes.
???
If the private key is no lon
Anders Rundgren wrote:
Ian G wrote:
Michael Ströder wrote:
If the private key is no longer available, yes, encrypted data
technically cannot be decrypted anymore.
Note the decision here to store the email in private-key encrypted form,
instead of (for example) cleartext or re-encrypting it
h X.509-PKI is that you need online network access to a
central infrastructure to make use of it. That's ok for a phone
application or instant messenger but not necessarily for e-mail. (I
already pointed this out but you ignored it.)
Ciao, Michael.
1 - 100 of 273 matches
Mail list logo
