As some of you may be aware, we are about to move to a new newsgroup
hierarchy for mozilla.org.
http://weblogs.mozillazine.org/gerv/archives/2005/08/new_newsgroups_1.html
http://www.mozilla.org/community/newsgroups.txt
Currently, n.p.m.crypto.checkins still exists in the new hierarchy, as
Peter Gutmann wrote:
Only if clocks are perfectly synchronised (see my previous post). If the
client's clock is slow, I can prolong the life of a cert effectively
indefinitely.
True - but you are therefore restricted to attacking clients with bad
clocks. I'm quite happy to admit that many
Peter Gutmann wrote:
It's a high-performance proposal, not a high-performance proposal (in other
words unmodified OCSP doesn't scale at all, so the broken version by
comparison is labelled as high-performance). Anyway, what it does is remove
replay protection, so the responder (or an outside
Ian G wrote:
New part:
The mouse-over says Signed by ThisCA.
That sounds incorrect to me. Bravo is definately
not signed by ThisCA. Even if I clicked on the OK
button, Bravo is still not signed by ThisCA. If I've
clicked on the OK button, the mouse-over might
say Because you clicked OK but
[EMAIL PROTECTED] wrote:
you could use a realtime, certificateless, onfile public key retrieval
from trusted DNS infrastructure ... for using in establishing encrypted
SSL session (instead of obtaining server public key from a
certificate).
If we wanted to boil the sea, we could do that too
Ian G wrote:
If for example the status bar were to display the
name from the URL then it would serve no purpose,
it would simply be duplicating existing info,
The former does not follow from the latter.
a) the URL bar is not always visible
b) URL bars contain a lot of other information, and
Duane wrote:
And for those of us that don't book mark?
Any implementation of pet names needs to work in harmony with other
browser features, in a manner compatible with the usage patterns of an
average web user.
You are definitely not the latter; you can continue to install the
petname
Jean-Marc Desperrier wrote:
In the more secure version of OCSP, you use no validity duration, you
include a nonce in your request that must be present in the response, so
the response must be generated on demand and can't be cached.
In other words, a nonce is a way of having a lifetime of zero
Nelson Bolyard wrote:
Yes. You are unlikely to find them anywhere except in exterprise
intranet situations where the enterprise has chosen to standardize on
mozilla or
other NSS-based clients.
(The reason it's interesting is that the lack of existence of | in the
wild makes the algorithm for
Tyler Close wrote:
It won't be fooled, it will correctly record the SSL identity of the
spoof site. When you later connect using DNS information that is not
poisoned,
How do you know that will ever happen?
If I can introduce a new URL scheme, such as httpsy, I think I can
improve upon this
Nelson B wrote:
Is this question being asked in the context of the UMO project?
No - it was a general question, in response to someone telling me that
they didn't want to use SSL for identity verification due to the overhead.
Gerv
___
mozilla-crypto
Nelson Bolyard wrote:
You don't need the overhead, but how about the secrecy?
Surely that is part of the assurance comes from SSL.
Some folks in this group think that is the ONLY value of SSL.
Would you give that up?
I'm just musing, based on a problem someone articulated. I'm not
completely
Ian G wrote:
So what this suggests is a principle of the warning
dialog being dominating. That is, if the user clicks
through any warning dialog then there is no more
protection.
Defence in depth is not employed. OK, that would
be useful if there were a compelling reason here. I
would be
Peter Gutmann wrote:
OCSP doesn't scale at all, which is why recent high-performance OCSP
proposals break the protocol's security to allow replay attacks (Verisign for
example broke their implementation last year some time in order to get it to,
uhh, scale, other vendors have done the same). The
Nelson B wrote:
RFC 2818 (which is informational, NOT a proposed standard, but which reads
like a proposed standard) in section 3.1 only allows * (not |) and that is
all IE supports.
That's extremely interesting.
Given the existence of subjectAltName, I assume there's no value in IE
ever
Say I'm a website owner who wants to give my users the assurance that
(theoretically; let's not go there right now) comes with an SSL
connection, but don't want or need the overhead of encryption.
Would it be possible (i.e. what would the side effects be) to enable the
null cyphers in our SSL
Ian G wrote:
When Firefox goes to one of the non-default sites, it is
presented with the default cert and indicates it is wrong.
I then click through and accept it, so https is opened up
on the site. But, down in the bottom right, instead of
displaying the correct details about the certificate
Ian G wrote:
I see! Tough one. Question of clarification - are you
saying that the status bar always displays the target
host name rarther than the domain field out of the cert?
That would mean that the status bar is simply another
confirmation of the original host.
Yes, that is correct.
This
Duane wrote:
I see the phising problem the same as the spam problem (while in one
respect they're the same thing).
There's several important differences. What phishers do is illegal
(fraud, involving money), whereas spammers, in most countries, are legal
but irritating. Therefore, they have a
Tyler Close wrote:
On 4/21/05, Gervase Markham [EMAIL PROTECTED] wrote:
Petnames is not an authentication mechanism. It merely tells you that
the person you talked to last week is the person you are talking to now
For the sake of clarity, could you define what you mean by authentication.
Good
Tyler Close wrote:
Because an HTTP connection is neither encrypted, nor possible to
authenticate. If Firefox will let us have encryption and key exchange
without any annoying dialog, we can layer on our own accreditation
mechanism, such as petnames. For many use cases, this solution is not
only
Frank Hecker wrote:
Incidentally note that IIRC I did not suggest that an https connection
with an unknown CA have the exact same UI as an http connection; I think
an informational error message (not a modal dialog) is appropriate in
this case, since the result is unexpected behavior (i.e., if
Tyler Close wrote:
I think it's important that any UI not be pejorative, as the current
UI is. If the UI is pejorative, it will encourage people to just use
plain HTTP and forgo the encryption and key-exchange offered by SSL.
Firefox should not convey the impression that an HTTPS connection with
Tyler Close wrote:
1. As Frank previously suggested, make SSL sites certified by an
unknown CA have the same UI features as an http:// site.
2. As I've suggested, make the petname tool a default part of the browser UI.
In what way do either of these suggestions relate to the subject of this
Peter Gutmann wrote:
That's what's been amusing me about this whole high-assurance CA debate, you
can have any assurance level you want (a CA located under 30m of reinforced
concrete at the bottom of a surplus ICBM silo who only issues certs to people
who turn up in person and provide blood and
Nelson B wrote:
The problem with CRL DPs is the patent issue.
Who owns the patent or patents? Do you have a reference?
I think it likely that
CRL DP support will be implemented as a plugin for NSS, where the plugin
will not be open source nor freely available while the patent remains.
It could be
Frank Hecker wrote:
A couple of points: First, you (and I think Ian as well) are confusing
two separate proposals. Gerv has proposed keeping track of SSL history
(i.e., a list of https URLs visited, hashed for privacy), so the browser
can alert people when they visit a new SSL site they haven't
Duane wrote:
Frank Hecker wrote:
can alert people when they visit a new SSL site they haven't been to
before (e.g., a phishing site that purports to be the banking site
they visit regularly). For the record, I think this proposal is worth
considering.
So even more annoying messages that people
Ram A M wrote:
For this position to hold up I think it would also have to be the case
that a phisherman would not find value in buying the more expensive
certificate. If an extra US$500 gets a larger return, perhaps $50,000
instead of $10,000, I think they'll spend the 500. Do you agree? Do you
There's been some discussion of revocation services deep in other threads.
I think understanding these is important, and I suspect my knowledge is
too limited; does anyone have a link to a primer?
What proportion of CAs run a revocation service?
What proportion of them use OCSP?
Can someone
Frank Hecker wrote:
Thawte SSL123:
This service requires generating a CSR with at least CN, coutry, and
state filled in; CN is used for the server domain name.
It seems (not that it's important) that there's no checking of the
Country and State values you give?
Go Daddy TurboSSL:
...
that Go
Frank Hecker wrote:
Radical though it might be, something like this might actually work.
However rather than using the phrase site identity verified (what does
this actually mean to users?)
Just to clarify - my proposal wasn't supposed to suggest any UI at all,
and particularly not that :-)
Ian G wrote:
I can think of 3 other ways that the above page is
not true.
1. paypal's CA issues a false cert
2. any other CA issues a false cert
These things have happened a handful of times in the history of the web,
and no-one has lost any money to my knowledge. It's not comparable.
3. any
Ian G wrote:
OK, but those are only objections to branding if
you can suggest a better way...
There have been a whole bunch of ideas about mitigating the phishing
problem floating around, several of which have been suggested by me. :-)
But, none of them seem to be that serious, compared
to
Nelson B wrote:
SSL is site identity verification PLUS encrytion. Site identity
verification, by itself, is NOT good enough for banking.
Sure. Maybe I wasn't clear:
Site-ID-verified-by-DNSSec: site identity verified indicator
low-assurance cert: site identity verified indicator
high-assurance
Ram A M wrote:
Concurr. Google is an oddball exception here, gmail reading is
protected
I suspect that might be to be more firewall and proxy-compatible;
neither of those things can mess with the HTTPS data stream.
Gerv
___
mozilla-crypto mailing list
Ian G wrote:
Yes, that may lock down the homograph thing, but it
does nothing to address the wider class of attacks.
Indeed not. Did I say it was the only solution? I was merely commenting
on your use of the Shmoo example.
I'm confused by one thing. Why is it that the Shmoo
IDN bypassing was so
Frank Hecker wrote:
Gerv, if you review the discussions on n.p.m.crypto over the past few
months, plus the iterated drafts of the proposed CA certificate policy,
I believe you will find that I have tried to address Nelson's concerns
as well as those of others who have participated in the
Ian G wrote:
I'm not sure what your objection to brand is?
You continue to assert that I object to brand. I'm well aware of the
power of branding in people's lives; I'm also aware that very often
brand perception doesn't match reality, that branding favours those with
large marketing budgets.
Frank Hecker wrote:
Fair enough. So let me ask a specific question: If the level of cert
assurance is the key issue, do you believe that the binary security UI
in combination with potential threats of phishing attacks justifies
rejecting CAs that issue domain validation only certs, and removing
Nelson B wrote:
a great deal of sense
The meta-message Nelson's post gives me is that we would be highly
foolish to ignore his expertise and experience and implement a CA
certificate policy with which he was unhappy.
Gerv
___
mozilla-crypto mailing
Ian G wrote:
Given, c) it is apparently easily bypassed for SSL
phishing (c.f., Shmoo), I would say that the padlock
only represents your low assurance grade.
Do not use the Shmoo Group IDN exploit as an example of being easily
bypassed. The community has reacted very strongly to this problem for
Frank Hecker wrote:
My conclusion is that outside of the top CAs we could remove any CA in
our list and the immediate consequences would be pretty limited.
Given the very interesting data you've shown; I'd concur. I was thinking
of the big ones when I made that comment.
Gerv
Ian G wrote:
Gervase Markham wrote:
Therefore, a good thing (merchants switching CAs), as defined by
this strategy, has almost exactly the same UI effect as a bad thing
(spoofing). This is deeply concerning.
Right, it is up to the merchant to manage that
process, and the user to be aware
Nelson B wrote:
Very little of this has happened historically because the existing CAs
now in mozilla's list have been very very good at not issuing duff
certs. As evidence of this truth, I offer the HUGE amount of press
(not to mention postings in this group) that a *single* duff cert incident
Frank Hecker wrote:
First, what's a duff cert in this context? A cert issued by a CA in
violation of its own policies (i.e., CP and CPS)? A cert issued by a CA
to someone that the CA should have known might use it for fraudulent
purposes? A cert issued by a CA to someone who turns out to use
Ian G wrote:
The point I am making is that users understand
branding. Their understanding of branding gives
them information that they can use. You're right
to point out that that will use this branding info
in different ways.
In this case, they can use the information to understand
the risks.
Ian G wrote:
Secondly, what you are pointing at is a *derivative*
problem. The primary problem is that the CA issued
a duff cert. How do you solve that? Well, there has
to be some pain somewhere, and the closer it is to
the users, the more likely the pain will actually respond
to user security
Frank Hecker wrote:
I am quite interested in seeing Firefox, Thunderbird, and our other
products implement effective anti-phishing strategies. I just don't
think that the SSL protocol and the CA infrastructure can bear all or
even most of the burden of protecting users from phishing. I think
Julien Pierre wrote:
Seems that you are running into a cygwin issue .
https://bugzilla.mozilla.org/show_bug.cgi?id=257071
The fix is to use cygwin's gmake .
Thanks, Julien. :-)
Gerv
___
mozilla-crypto mailing list
mozilla-crypto@mozilla.org
Frank Hecker wrote:
4. I would like clarity on how existing Mozilla/Firefox/Thunderbird/etc.
implementations may interact with such a policy. (For example, I think
you previously alluded to Mozilla implicity trusting JavaScript in some
context if it were downloaded from an SSL-enabled site.) I
I've just written the first version of A Plan for Scams - a summary of
my views on the action required to tackle the phishing problem. I
believe a co-ordinated effort from browser and mail client vendors,
website owners, ISPs, domain registrars and certificate authorities is
necessary, and I
Jean-Marc Desperrier wrote:
It doesn't seem their communication can be called anything but
deceitful, and I'm seriously afraid mozilla.org must be very careful in
order not to be seen as having endorsed it.
Rafael Ebron, Mozilla Foundation PR person, said by email:
Hi Gerv,
We ran the release
Pete Collins wrote:
I wrote up a doc on how to sign an XPI package using a test cert.
http://www.mozdevgroup.com/docs/pete/Signing-an-XPI.html
Pete,
I believe it's true that NSS 3.9, which you link to, is not usable for
signing XPIs because the signcode.exe included does not support the -X
Nelson B wrote:
mozilla treats SSL server certs like code
signing certs for java script served over https, IINM,
I don't think this is correct. JS served over HTTPS has exactly the same
abilities and restrictions as JS served over HTTP.
Gerv
___
Ian G wrote:
I just read your page, great stuff. Now, are comments
solicited for this group, a bugzilla page, or in private?
Anywhere's good. My blogpost has some discussion:
http://weblogs.mozillazine.org/gerv/archives/007508.html
I'm not sure what you are saying here. If it is branding
doesn't
Ian G wrote:
Unfortunately, there is no good basis
in economics for the case that the user
cannot be trusted to choose a good bank.
By your second good, I assume you mean more secure.
I'm not arguing that, given 5 otherwise identical banks with different
levels of trustworthiness, one could teach
Pete Collins wrote:
But yes, it's obvious that malicious developers can do whatever they
want. 100% of all xpi packages out there now are all unsigned,
untrusted, unaudited, etc.
99%. Yahoo's latest toolbar beta is signed. :-)
Gerv
___
mozilla-crypto
Ian G wrote:
OK. Well, both are required. The Logo that the
user selects *and* the logo for the CA. Ideally,
the logo for the CA should be encoded into the
Cert / signed by it. This limits a false cert attack
to the site's cert supplier, and thus paves the
way to force the CAs to start
Ian G wrote:
I'd challenge the 1st part of that. Why does
a CA need to be equally secure and verifiable?
Because, like it or not, we have a binary security model. And, even if
we didn't, most users aren't in a position to correctly judge relative
levels of risk.
Gerv
Nelson Bolyard wrote:
b) some way for a computer to perform that comparison. The computer
can do dns lookups to find other names that might be similar, even
if those names are registered by competing domain registrars.
Today, I doubt that either of these methods is employed by any CAs
or
Jean-Marc Desperrier wrote:
To help prevent confusion between characters that are visually
similar, it is suggested that implementations provide visual indications
where a domain name contains multiple scripts. Such mechanisms can also
be used to show when a name contains a mixture of
Ian G wrote:
Good, I'm glad you understand what is meant by
branding. By forcing VeriSign to brand themselves
like Virgin, they are laid bare to their trusting public.
Who knows, maybe they will surprise us all.
You expect Verisign to start taking out brand-building ads based on a
change we make
Ian G wrote:
There may be support for this statement,
but I've never been able to find its scientific
basis, in cryptography, user design, nor in
economics. In particular, the last 10 years
of experience only bear it out to the extent
that users were denied the chance to make
a choice. So it may
Ian G wrote:
'bare minimum' ... your thinking is possibly influenced
by the popup experiences of the past. Which were of
course pushed into the direction of less is better.
Not really. It seems fairly self-evident to me that the more security UI
there is, the more likely users are to ignore it.
Juergen Nieveler wrote:
Domain registrars seem to accept just about any fake name provided you
pay on time.
CAs however earn their living by confirming the identity of people -
therefore they HAVE to check the identity - apart from the Class1-
certificates issued for free, they have to check
Alex Wight wrote:
What I meant by that was that with other character sets, certain characters
are more similar than others and each society will have differing levels of
similarity. But you are right it ultimately boild down to perception (even
if perception is different between societies).
And
Alex Wight wrote:
Well yah HTTP, IM, email, FTP, anything that uses DNS is somewhat
susceptible, although the other protocols are less prone to phishing for
reasons I'm sure we can all deduce, but the threat is there.
No-one (statistically speaking) buys stuff over IM, email or FTP.
Gerv
Ian G wrote:
Whose logo is that?
The specific answer is mine if the question
is in the context of the TrustBar paper.
Ah; we're talking at cross-purposes. I was referring to the plan to make
it clear in the UI which CA issued a particular cert.
Have I seen it somewhere before?
Yes, I chose it to
Duane wrote:
H re-reading these emails I think I'd just like to point our for the
record I've stated for a very long time that I'd like to see the people
not-assured be severely limited in terms of certificates being issued,
however this is a chicken an egg problem for us, how does a
Duane wrote:
I assume you guys know about international languages bug in URLs, but
didn't see anything else on it...
http://www.shmoo.com/idn/
Even effects SSL!
Indeed. Unless we do something about this quick, IDN is screwed, because
more and more people will switch it off, and no-one will
Frank Hecker wrote:
IMO the issue of authenticating the identity of certificate applicants
is to a large degree orthogonal to the issue of preventing phishing
attacks based on misleading domain names.
It is. My point is not that CAs should be refusing certificates to
people with similar
Alex Wight wrote:
I believe the main purpose of any SSL CA is simply to vouch for domain name
ownership (how they do this is beside my point). If any efforts are done to
limit or prohibit misleading domains, I feel it should be done at the
registrar level. Doing it at the CA level will only
Ian G wrote:
Right. This is one reason why the branding ideas
of Amir Ahmad converge with my ideas so that
both the site's logo and the CA's logo appear on
the chrome.
I don't want to get into the branding debate again, but if Verisign
issue a cert to www.amaz0n.com and people lose money,
Ian G wrote:
Yes, I'd say that is the issue. Bear in mind that
this is *not* happening now as it is too easy to
attack without using SSL at all.
Indeed. There has to be a minimum level of user education - that's
unavoidable. What we are trying in Firefox is to get people to look at
the status
Frank Hecker wrote:
I don't want to speak for Gerv, but I don't believe he's concerned about
CAcert or other CAs issuing fraudulent SSL certs for amazon.com, he's
concerned about CAs issuing SSL certs for misleading domain names like
amaz0n.com.
Not about them issuing them - but about being
Alex Wight wrote:
Absolutely. I want to see the registrar automatically sign up amazon.com to
have all of the possible phishing permutations of that domain so that no one
can buy one similar enough to result in successful phishing attacks. This
can be easily automated, the hard part is coming up
Simon Anderson wrote:
I'll assume that you're not being obtuse. This is the most well known
issue from Verisign;
http://www.pcworld.com/news/article/0,aid,45284,00.asp
So any CA which makes a single issuing mistake should be removed from
the database?
Gerv
Frank Hecker wrote:
Gervase Markham wrote:
CAcert's policy of giving certs to anyone with a working email address
Gerv, I'll let others give the definitive answer to this, but a number
of CAs will issue certificates based solely on verification of a working
email address. This is usually
Ian Grigg wrote:
The main game is getting the user back in control of
the certificate-protected SSL connection. This means
adding the CA's brand, petname capabilities, visit
counts, and the site's logo preferably signed off by
the user (c.f., AmirAhmad) , all onto the chrome.
BTW, if you are
Amir Herzberg wrote:
We have been using our prototype personally for some time and it seems
to work well on several platforms, so we now want to offer it to
experienced, security-aware users, for feedback and improvements;
Amir,
Last time you mentioned this in the newsgroup (13th July), there
Julien Pierre wrote:
Perhaps we should have something like this too. Do we have something in
NSS to clear the cache for all SSL client sessions ? I don't seem to
recall that we do.
I seem to remember that the function has been implemented, but it has no UI.
checks
No, I was thinking of HTTP
Nelson Bolyard wrote:
The first two paragraphs on that page say, in part:
TinyCDB is a very fast and simple package for creating and reading
*constant* data bases, [emphasis added]
CDB is a /constant/ database, that is, it cannot be updated at a
runtime, only rebuilt.
Maybe this isn't as bad
I took a task a few weeks ago to investigate the Sleepycat license
(http://www.opensource.org/licenses/sleepycat.php) to see if it was
compatible with the MPL/LGPL and GPL in a way that would allow code
released under it to be used by Mozilla.
As far as I can see, I'm afraid it's not. The
Frank Hecker wrote:
Note that I can't make that change, because I am neither the assignee or
the submitter for those other bugs, nor do I have sufficient privileges
to override bugzilla and change the bugs anyway.
You do now (as [EMAIL PROTECTED]). I've migrated the initial owner to
that
Frank Hecker wrote:
However I do not agree that we should require CAs to use bugzilla
instead of email to submit the original requests. Not everybody knows
how to use bugzilla, and there's a little bit of overhead to get
yourself a login before you can submit a bug report. I think it would be
Robert Relyea wrote:
Unfortunately mozilla, which it's shrinking user base,
cough According to every set of stats I've seen, our userbase is
increasing at a reasonably rapid rate.
Gerv
___
mozilla-crypto mailing list
[EMAIL PROTECTED]
Jean-Marc Desperrier wrote:
Well the current Sleepycat license is OSI Certified open source.
Is it really? I assumed it wasn't, because of the way he phrased his
point about restricting commercial use.
If
http://www.opensource.org/licenses/sleepycat.php
is the license in question, then there
Nelson Bolyard wrote:
Not on my browser it won't.
Presumably you have the status bar permanently enabled?
Gerv
___
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
Nelson Bolyard wrote:
AFAIK, no part of mozilla's source is presently licensed under terms that
say, in effect, it's OK to use this source in any product that you give
away for free, but not OK to use this source in a product for which you
charge. Do I have that right?
You are correct. Such a
Keith Bostic wrote:
Sleepycat Software is (of course!) happy to have Mozilla use
Berkeley DB in any way at all. Our only concern would be in
granting blanket rights to companies developing proprietary
products as part of granting rights to the Mozilla group.
Wouldn't it be possible to put
Nelson Bolyard wrote:
Every few years, we re-investigate this issue. Last time, we came up
empty.
Most DBs have licenses incompatible with MPL. I think the mozilla/NSS
developer community doesn't want NSS to depend on a DB that isn't as
readily reusable and redistributable as the rest of NSS
Julien Pierre wrote:
Actually having separate builds for localized versions is a can of worms
in itself. Are the localized builds built from separate branches ?
I was under the impression that they simply had additional language
modules.
The usual practice, I believe, is to swap out the
Right. If the moz browser folks are doing things right, they will ensure
that 1.7b is built from an NSS tag other than NSS_CLIENT_TAG. To put it
another way, if a mozilla release ever shipped with NSS built from the
NSS_CLIENT_TAG, that would (IMO) be an error of the mozilla builders,
and not of
Ian Grigg wrote:
1. Mozilla Foundation is not a utility, nor a public service.
It's not a charity nor a group of do-gooders.
It is a non-profit organisation. I don't know if US rules about
non-profits require them to have some sort of public good element.
2. There is nothing wrong with the
Ian Grigg wrote:
Unfortunately, I don't think there are any retail
level suppliers of just browsers - presumably Netscape
no lists a price.
Indeed. The end-user browser market is commoditised. It's hard to make a
buck (although Opera are trying.)
Whatever policy we decide, millions of people
Frank Hecker wrote:
1. The Mozilla Foundation should formally take over selection of CA
certs to be included in Mozilla.
Another option might be to try and set something up with the Konqueror
guys (or even with Apple and/or Opera). This would be a nominally
separate organisation (which happens
Wan-Teh Chang wrote:
Thank you. Is it possible to just set up an information
page for NSS on Sourceforge, which would contain links
to the NSS page on www.mozilla.org, the NSS bugs in
bugzilla.mozilla.org, and the mozilla.crypto newsgroup?
Isn't this what http://www.mozilla.org/projects/nss/
Jean-Marc Desperrier wrote:
I'm surprised this problem has no solution.
Well most database solutions seems to be available only under the GPL,
but a special agreement could probably be negotiated.
But unless the special agreement was a relicensing under the
MPL/GPL/NPL (or a BSD-like license)
William Allen Simpson wrote:
It sometimes seems that folks are designing this in a vacuum. Think
about those of us that have been using PGP/GPG in all its forms for
the better part of a decade Let's learn our lessons.
This is probably not the best way to get experienced cryptography
100 matches
Mail list logo
