On 29/12/08 19:28, Ben Bucksch wrote:
Background: CertStar issued certificates without verification
whatsoever. The faulty certs were signed with the PositiveSSL
certificate, which is chained to the UserTRUST root cert that Mozilla
ships. The UserTRUST cert is owned and operated by Comodo.
Our
You're failing to recognize one thing: if a Growl-like notification
came up whenever my browser established a TLS session, describing
This certificate is said to belong to subject. The one who's
saying it is Issuer. BEWARE: this issuer is NOT audited to
financial services standards, do NOT put
On 30/12/08 04:22, Nelson B Bolyard wrote:
Ian G wrote, On 2008-12-29 16:59:
As far as I heard, the CABForum was also formed or inspired from a
similar group of vendors (browsers) that got together at the invite of
the Konqueror guy to talk about phishing one day ...
I think Mozilla's own
On 30/12/08 06:30, Ben Bucksch wrote:
If we decide that a CA does not operate properly,.but we don't want to
cause problems for users, another option would be to shorten the expiry
date of the relevant root certs to one year or less.
Technically, that should be possible. The cert is public
Ben Bucksch wrote:
If we decide that a CA does not operate properly,.but we don't want to
cause problems for users, another option would be to shorten the expiry
date of the relevant root certs to one year or less.
Technically, that should be possible. The cert is public anyways.
But the
Kyle,
Assuming your DBs are in the current directory:
certutil -L -d . -h Builtin Object Token will list all of the nicknames
Then you just add the -n nickname (and optionally -a to get base64) for each
one like so:
certutil -L -d . -n Builtin Object Token:StartCom Certification Authority -a
On 30/12/08 06:45, Ben Bucksch wrote:
On 28.12.2008 14:23, Ian G wrote:
[1] disclosure, I work as an auditor
So, Ian, what are you trying to tell us? We can't yank roots. We can't
rely on audits. How are we supposed to restore and ensure proper
operation of the system?
Right. There are no
Ian G wrote:
Which language suggests they have to do verification *themselves* ?
The fact that the policy talks about a CA, and I didn't see talk about
external entities.
BTW, it would be quite problematic to insist that the CAs do this job
themselves.
CAs are not generally experts on
On 30/12/08 13:13, Kyle Hamilton wrote:
You're failing to recognize one thing: if a Growl-like notification
came up whenever my browser established a TLS session, describing
This certificate is said to belong tosubject. The one who's
saying it isIssuer. BEWARE: this issuer is NOT audited to
On 12/30/2008 01:43 PM, Ian G:
Most all certificates carry no warranty or have zero liability
disclaimers. Of course the words may differ, but even EV Guidelines
permit the CA to set zero liability, except where it shown that the CA
is at fault, and even that may be limited to something fairly
On 12/30/2008 03:24 PM, Kai Engert:
As I see verification as the core intention of the CA principle, I would
have assumed above requirement is obvious to everyone, at least to CAs
themselves.
One of Comodo's CPS (the one responsible for PositiveSSL) claims:
To validate PositiveSSL and
On 30/12/08 14:23, Eddy Nigg wrote:
On 12/30/2008 01:43 PM, Ian G:
Most all certificates carry no warranty or have zero liability
disclaimers. Of course the words may differ, but even EV Guidelines
permit the CA to set zero liability, except where it shown that the CA
is at fault, and even that
On 12/30/2008 03:51 PM, Ian G:
On 30/12/08 14:23, Eddy Nigg wrote:
On 12/30/2008 01:43 PM, Ian G:
Most all certificates carry no warranty or have zero liability
disclaimers. Of course the words may differ, but even EV Guidelines
permit the CA to set zero liability, except where it shown that
Hi. I'm developing an extension which, for other reasons already
contains a C++ component using NSS for several tasks.
Lately, I decided to add another task: Since we distribute a PKCS11
module with our application, I decided to install it on Firefox
startup without prompting the user.
Kyle Hamilton wrote, On 2008-12-30 04:13 PST:
(in fact, it wasn't until a LOT of people got infuriated at Netscape
over the Verisign tax that other CAs were even allowed into the
program
Do you have any evidence to support that claim? SSL2 was introduced in
Navigator 2, and there were many
I was playing around with the Sun PKCS11 provider and accessing NSS directly
while in FIPS mode. It appears nss 3.12 (on Vista 32-bit) has issues reporting
key sizes both to Java and using symkeyutil directly:
Attempting to create a 128 byte (1024 bit) aes key on the token:
On 30.12.2008 12:43, Ian G wrote:
[Audits reliabilty]
You already opened a thread about this (and I replied there). No point
to open another sub-thread about this.
Most all certificates carry no warranty
No. This particular sentence appears under heading Positive SSL
Certificate, as I
On 30.12.2008 13:49, Michael Ströder wrote:
I see no problem the schedule the removal of a trust flag. For
security reasons all users have to update browsers from time to time
anyway. ;-}
Yup, that's the low-tech version of effectively doing the same. And it
gives more flexibility.
Ian G wrote, On 2008-12-30 05:36:
Right, you are correct that those who built the process were orienting
SSL to credit cards and protection from eavesdropping.
The designers of SSL knew from the beginning of the many many uses that
SSL had. The emphasis in the PR story for SSL was around
István, even though I understand your frustration and agree with the
basic understanding that requirements should be published
accordingly, I also must state there has been at least one issue
(notably with your OCSP responder I think) in addition to our
I think the OCSP issue has been
Michael Ströder wrote, On 2008-12-30 04:49:
Ben Bucksch wrote:
If we decide that a CA does not operate properly,.but we don't want to
cause problems for users, another option would be to shorten the expiry
date of the relevant root certs to one year or less.
Technically, that should be
For years we've been reading stories of researchers making more and more
progress on breaking MD5. Well, now they've made enough progress that
it is possible to forge some certificates that use MD5 in their signatures.
You're going to be seeing a lot of breathless stuff in the media about this,
A presentation was given at this year's Chaos Communication Congress in
which it was described how researchers were apparently able to produce
authentic signed SSL certificates thanks to a handful of CAs who rely on
MD5. If true, is it time to disable MD5 by default?
Nelson B Bolyard wrote, On 2008-12-30 08:39:
For years we've been reading stories of researchers making more and more
progress on breaking MD5. Well, now they've made enough progress that
it is possible to forge some certificates that use MD5 in their signatures.
You're going to be seeing a
On 30/12/08 17:47, Nelson B Bolyard wrote:
I meant to add: The paper with the real facts is seen at
http://www.win.tue.nl/hashclash/rogue-ca/
In the meantime, could a list of the affected CA's be made available so
that we may remove the trust bits from our own certificate stores?
I have an idea for a nice make money fast business model:
I'll make a CA. I'll talk about trust-worthiness and doing sophisticated
verifications etc.. In my guidelines and processes, I say that I'll
offer HighSec high security certificates, where I'll get the in-person
signature and passport
On 30.12.2008 17:28, Nelson B Bolyard wrote:
Before any more people promote the removal of trust flags, I suggest you
read https://bugzilla.mozilla.org/show_bug.cgi?id=470897#c11
Yes, granted.
But
- we can yank the entire root. I *think* that's what Michael meant. It
may or may not be
On 30 dec, 17:49, Chris Hills c...@chaz6.com wrote:
In the meantime, could a list of the affected CA's be made available so
that we may remove the trust bits from our own certificate stores?
Networking4all created a tool to check if a certificate in the chain
has been signed with a insecure
On 30.12.2008 17:39, Nelson B Bolyard wrote:
For years we've been reading stories of researchers making more and more
progress on breaking MD5. Well, now they've made enough progress that
it is possible to forge some certificates that use MD5 in their signatures.
You're going to be seeing a
Chris Hills wrote, On 2008-12-30 08:49:
On 30/12/08 17:47, Nelson B Bolyard wrote:
I meant to add: The paper with the real facts is seen at
http://www.win.tue.nl/hashclash/rogue-ca/
In the meantime, could a list of the affected CA's be made available so
that we may remove the trust bits
On 30.12.2008 17:39, Nelson B Bolyard wrote:
The upshot of this is probably going to be that, in a short time, all
the world's browsers (and PKI software in general) stop supporting MD5
for use in digital signatures.
What is MD2? Is that a weaker predecessor of MD5? According to Wikipedia
On Dec 30, 4:49 pm, Chris Hills c...@chaz6.com wrote:
On 30/12/08 17:47, Nelson B Bolyard wrote:
I meant to add: The paper with the real facts is seen at
http://www.win.tue.nl/hashclash/rogue-ca/
In the meantime, could a list of the affected CA's be made available so
that we may remove
On 12/30/2008 08:17 PM, rseges...@googlemail.com:
The Networking4All checker confirms this for at least the
*.startcom.org cert:
https://www.networking4all.com/en/support/tools/site+check/?fqdn=www.startcom.org
This certificate expires in less than two days and will be replaced
tonight
Eddy Nigg wrote:
On 12/28/2008 01:13 PM, Kai Engert:
The current Mozilla CA Certificate Policy says:
6. We require that all CAs whose certificates are distributed with our
software products: ... provide attestation of their conformance to the
stated verification requirements ...
Kai, just
On 30.12.2008 17:49, Chris Hills wrote:
On 30/12/08 17:47, Nelson B Bolyard wrote:
I meant to add: The paper with the real facts is seen at
http://www.win.tue.nl/hashclash/rogue-ca/
In the meantime, could a list of the affected CA's be made available
so that we may remove the trust bits
On 27.12.2008 13:34, Gervase Markham wrote:
sayrer wrote:
The truth is that we are basically unable to act without a lot of
collateral damage. We should keep this in mind with future security
technology. Relying on companies willing to take money for doing
absolutely nothing (not even the
Nelson B Bolyard wrote:
The upshot of this is probably going to be that, in a short time, all
the world's browsers (and PKI software in general) stop supporting MD5
for use in digital signatures.
It would be nice if the user could define in about:config to stop
accepting certs with signatures
On 30.12.2008 19:50, Michael Ströder wrote:
Nelson B Bolyard wrote:
The upshot of this is probably going to be that, in a short time, all
the world's browsers (and PKI software in general) stop supporting MD5
for use in digital signatures.
It would be nice if the user could define
Paco wrote, On 2008-12-30 06:08:
Hi. I'm developing an extension which, for other reasons already
contains a C++ component using NSS for several tasks.
Lately, I decided to add another task: Since we distribute a PKCS11
module with our application, I decided to install it on Firefox
I got
On 30/12/08 18:19, Ben Bucksch wrote:
On 30.12.2008 17:39, Nelson B Bolyard wrote:
The upshot of this is probably going to be that, in a short time, all
the world's browsers (and PKI software in general) stop supporting MD5
for use in digital signatures.
What is MD2? Is that a weaker
On 30.12.2008 12:43, Ian G wrote:
PositiveSSL Certificates are low assurance level Secure Server
Certificates from Comodo ideal for mail servers and server to server
communications. They are not intended to be used for websites
conducting e-commerce or transferring data of value.
...
Due to the
David Stutzman wrote, On 2008-12-30 07:55:
I was playing around with the Sun PKCS11 provider and accessing NSS
directly while in FIPS mode. It appears nss 3.12 (on Vista 32-bit) has
issues reporting key sizes both to Java and using symkeyutil directly:
Attempting to create a 128 byte (1024
On 12/30/2008 08:39 PM, Kai Engert:
Eddy Nigg wrote:
On 12/28/2008 01:13 PM, Kai Engert:
The current Mozilla CA Certificate Policy says:
6. We require that all CAs whose certificates are distributed with our
software products: ... provide attestation of their conformance to the
stated
Ben Bucksch wrote:
a) PositiveSSL Certificate
PositiveSSL Certificates are low assurance level Secure Server
Certificates from Comodo ideal for mail servers and server to server
communications. They are not intended to be used for websites
conducting e-commerce or transferring data of value.
On 30/12/08 17:18, Nelson B Bolyard wrote:
What is particularly interesting here is that the online banking *is*
financially oriented, but SSL is not particularly good at it, has never
really been adequate or even compelling.
Ian, You're continuing to use the term SSL to describe something
On 30/12/08 20:41, Eddy Nigg wrote:
I edited the Problematic Practices page and added
https://wiki.mozilla.org/CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_by_third_parties
My comment: it is written like a requirement, using MUST. This is
confusing, and it bypasses
* Ben Bucksch:
Now, 3 years later, some scammers and spammers actually notice me and
set up fake SSL sites with my certs.
Not just fake sites. Some of the OEM software spammers use valid SSL
certificates for the checkout procedure, e.g.:
https://secure.securesoftmarket.com/
For those
On 12/30/2008 10:46 PM, Ian G:
On 30/12/08 20:41, Eddy Nigg wrote:
I edited the Problematic Practices page and added
https://wiki.mozilla.org/CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_by_third_parties
My comment: it is written like a requirement, using MUST. This
* Ben Bucksch:
Yet, when I went through the cert store, I see not only MD5 certs, but
MD2 certs as well. Partially from VeriSign. How comes?
These are self-signatures only. They should not be evaluated. (I
hope that NSS doesn't even contain an MD2 implementation. 8-/)
At 8:39 AM -0800 12/30/08, Nelson B Bolyard wrote:
The upshot of this is probably going to be that, in a short time, all
the world's browsers (and PKI software in general) stop supporting MD5
for use in digital signatures.
That is not what the paper advocates. It suggests stopping support for MD5
At 1:49 PM +0100 12/30/08, Michael Ströder wrote:
Please, we shouldn't mess around with PKIX cert validation mechs.
Fully agree. The definition of the notAfter field in PKIX has nearly nothing to
do with expiry. It is widely argued whether or not this field is even useful
in self-signed
On 30.12.2008 20:51, Frank Hecker wrote:
Ben Bucksch wrote:
not intended for ... e-commerce. ... the certificates carry no
warranty
Ben, this is a pretty common disclaimer that CAs (including CAs other
than Comodo, I believe) make for DV certs (i.e., certs for which only
the domain control
* Frank Hecker:
No e-commerce site should be using DV certs, and IMO all e-commerce
sites should consider upgrading to EV certs. The market for DV certs
is people like me, who want to provide basic security measures for a
web site (or email server) but are not dealing with data of any
* Michael Ströder:
Florian Weimer wrote:
Even if you've got the certificate, you need to attack IP routing or
DNS. If you can do that, chances are that you can mount this attack
against one of the domain-validating RAs, and still receive a
certificate. So the browser PKI is currently
Florian Weimer wrote, On 2008-12-30 13:04:
* Michael Ströder:
Florian Weimer wrote:
Even if you've got the certificate, you need to attack IP routing or
DNS. If you can do that, chances are that you can mount this attack
against one of the domain-validating RAs, and still receive a
On 30/12/08 22:16, Nelson B Bolyard wrote:
Paul Hoffman wrote, On 2008-12-30 12:43:
Well, of course, it's not the signature on the root CA cert itself that
matters. It's the signature algorithm used on the certs issued by the
root. And the issuer is always free to change that whenever they
At 1:16 PM -0800 12/30/08, Nelson B Bolyard wrote:
Paul Hoffman wrote, On 2008-12-30 12:43:
At 8:39 AM -0800 12/30/08, Nelson B Bolyard wrote:
The upshot of this is probably going to be that, in a short time, all
the world's browsers (and PKI software in general) stop supporting MD5
for use in
Ian G wrote:
From memory, EV is a supplement to WebTrust for CAs, leaving WebTrust
for CAs in place as a valid and useful audit, at least in the opinion of
the CABForum.
That is correct. The CAB Forum's EV guidelines document requires both an
audit according to the WebTrust for CAs criteria
Ben Bucksch wrote:
We try to train users to check that the bar is green (on sites where it
was green before), and not use the site when it's merely blue.
Otherwise, EV is useless, as the scammer could get a, say, CertStar
cert, to fake an EV site, right? Only when people start getting
That doesn't give me the list of nicknames in the Builtin Object
Token, that just gives me the list of nicknames in the softtoken. (I
doubt that nssckbi is supposed to include this...)
KyleMac:.netscape kyanha$ certutil -L -d . -h Builtin Object Token
[...]
StartCom Free Certificate Member's
I would suggest requiring all new roots approved to state that they do
not and will not use MD5 in any newly-minted certificate (except
possibly in a configuration like the TLS pseudo-random function).
This is not yet policy, though it should be. (FWIW, this was known
two years ago.)
-Kyle H
* Kyle Hamilton:
I would suggest requiring all new roots approved to state that they do
not and will not use MD5 in any newly-minted certificate (except
possibly in a configuration like the TLS pseudo-random function).
If they issue certificates for sub-CAs, they have no technical means
to
My two cents:
Trust anchors don't particularly need to have their hashes secure,
because they're obtained through a process other than comparing their
hash to an encrypted copy of the hash. It's certificates which are
NOT trust anchors which are subject to the problem.
-Kyle H
On Tue, Dec 30,
On 30/12/08 22:52, Frank Hecker wrote:
... I guess we could modify the
policy in future to make an explicit correspondence EV = e-commerce,
but that might run afoul of the whole qualified certificate issue in
the EU. (However in practice we don't accord qualified certificates any
special
Ian G wrote:
As far as I heard, the CABForum was also formed or inspired from a
similar group of vendors (browsers) that got together at the invite of
the Konqueror guy to talk about phishing one day ...
I'm fairly sure it wasn't at the invitation of the Konqueror guy (George
Staikos), but a
On Tue, Dec 30, 2008 at 1:04 PM, Florian Weimer f...@deneb.enyo.de wrote:
BCP 38 requires that active MITM attacks don't work on LANs. LANs
which violate that and are under attack are typically not very usable:
Search engines blocks you due to automated queries, DHCP and DNS
delivers data
SSL2 existed in Netscape 0.94, IIRC. I know that version had the blue
bar and skeleton-key icon, as I used it a fair amount when I was in
college.
As for evidence, I believe you can find it on the old SSLeay list
archives (pre-OpenSSL). That is where I first heard of the issue.
-Kyle H
On
Hello all,
I have proposed a few changes to SSL handling in response to the debian
openssl disaster. I also mentioned earlier that a way to limit CAs
would be nice, giving quite hypothetical cases where it would be
useful. With the recent Commodo verification failure and the MD5
weakness just
Florian Weimer wrote:
No e-commerce site should be using DV certs, and IMO all e-commerce
sites should consider upgrading to EV certs. The market for DV certs
is people like me, who want to provide basic security measures for a
web site (or email server) but are not dealing with data of any
Eddy Nigg wrote:
Frank, I think the problem Ben pointed out is, that it doesn't matter
for what exactly the certificate /should/ be used nor even for exactly
it /is/ used by the subscriber (note, Mozilla uses mainly regular SSL
for its sites). The fact that for domain validated (and higher
On 12/30/2008 11:52 PM, Frank Hecker:
certificates. According to Netcraft (from whom I got these figures) on
the order of half of the ~1M total certs are DV certs. (It's not 100%
clear to me how they distinguish DV certs from OV certs, so I'd take
this last figure with a grain of salt.)
I
Eddy Nigg wrote:
I edited the Problematic Practices page and added
https://wiki.mozilla.org/CA:Problematic_Practices#Delegation_of_Domain_.2F_Email_validation_by_third_parties
It might need some improvement. Frank, can you review? This will affect
obviously only future inclusion requests and
On 12/31/2008 01:11 AM, Frank Hecker:
Yes, but that doesn't necessarily have general implications for the way
we treat these cases. For example, it's possible that someone somewhere
has a site with a DV certificate, and that by breaking this cert
someone could gain access to assets worth (say)
On 12/31/2008 01:27 AM, Frank Hecker:
One reason I say this is good CA practice as opposed to a mandatory
requirement, is because of cases like enterprise PKIs where the
enterprises might act as RAs and do verification based on their own
internal systems (e.g., HR databases).
I think this is
On 30.12.2008 23:34, Kyle Hamilton wrote:
That difference /can/ be communicated to the end-user, unobtrusively.
Sure, but they can't use that information. I just asked a friend whether
she knows what VeriSign is - she never heard of it. If you have no
concept about how all that works, no
Florian, I think you refer to cert issued to spammers holding a domain,
and getting a DV cert for that domain that they registered? The cert is
issued correctly for the domain, just the organization does not do clean
business. This is a totally different issue.
I am talking about a phisher
Paul Hoffman wrote:
At 1:16 PM -0800 12/30/08, Nelson B Bolyard wrote:
I should have written: digital signatures on certificates.
The patch that I wrote only affects signatures on digital certificates.
Good. I am quite concerned if we start affecting signatures in things like
Thunderbird.
Frank Hecker wrote:
(It's not 100% clear to me how they distinguish DV certs from OV
certs, so I'd take this last figure with a grain of salt.)
[...]
In practice we have a de facto differentiation between EV certs and
all other certs, as embodied in the Firefox UI.
If Firefox could reliably
Daniel Veditz wrote, On 2008-12-30 17:37:
Paul Hoffman wrote:
At 1:16 PM -0800 12/30/08, Nelson B Bolyard wrote:
I should have written: digital signatures on certificates. The patch
that I wrote only affects signatures on digital certificates.
Good. I am quite concerned if we start affecting
Hmmm... actually, it would be possible, but only with the cooperation
of the CAs.
We currently know the EV policy OIDs for EV-enabled roots. What we
don't know is the policy OIDs assigned for different types of
validation, or the Subject names used by different CAs for DV
certificates.
If we
Ian G wrote, On 2008-12-30 13:38:
[...] is there any difficulty with announcing today that NSS is
going to deprecate MD5 and earlier algorithms, totally, for all
purposes, including Firefox and Thunderbird.
(Leave off the date as to when the rejection will take effect.)
The NSS team
Fost1954 wrote:
1. Can I spread the message into the world that Running Firefox in Safe
Mode when generating the key as well as requesting the Certificate with
Thawte does securely prevent unnotified private key transmission ?
I think so. Note that Thawte still uses the keygen tag, so
82 matches
Mail list logo
