On 10/11/2013 11:50 PM, From Wan-Teh Chang:
I would use a timeout of 5 seconds. 3 seconds seem a little short. I
agree 10 seconds are too long.
+1
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com
a need for such a functionality, go to the
standards bodies and propose one, then implement and remove the
non-standard functions.
I believe there are a few smart card related functions that could do
some good.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.or
certificate
without having to restart the browser.
Actually FF does a full handshake, what kind of error you get depends
on what bits the server said. If you pass request not require, then
the handshake completes with the server getting no cert for the
connection.
Right, but I don't like this real
cation controlled session.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
discussed here for removal. I assume it was put into
the capabilities of FF exactly for this purpose in first place.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypt
plementing a dedicated UI. And client certificates (which may be used
on smart cards) are part of the browser capabilities.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto ma
r-specific solutions that are not standardized, interoperable
behaviour?
No, since it works for us there was never a desire for such a
punishment. Besides that I'm not a browser vendor really.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startc
ted with can trigger session termination and/or authentication.
Whereas without it the card could be removed and the session would stay
valid like any other session.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://t
alues, and all of window.pkcs11.*
(smart card events).
Just for the record, we are using the
window.crypto.enableSmartCardEvents and friends - also note that IE
provides a similar functionality for that.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blo
(note that I'm using the newsgroup and not
email).
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.or
erisign root with the
correct organization field.
Just a small warning - they should not attempt to use "Norton" in the
organization field, this would clearly violate the Mozilla policy and
Baseline Requirements.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startc
ble
belts. Which type of revocation are you? Make your choice
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
dy else is doing it and we don't want to look
less secure.
Well, in fact the Mozilla based browsers were one of the first to
successfully support OCSP. Most, if not all other browsers either didn't
even exist at that time or didn't support OCSP (and CRL checking was not
turned
top 500 sites and leave the rest to the CAs. There would be probably
also the highest gains.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@li
, expired or revoked. A revoked
certificate is not valid, no matter the reason (which does not have to
be present in the CRL).
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto
ively somewhere
not encrypted - making any other encryption somewhat useless. For SSL to
work correctly, the entire content must be encrypted, otherwise
important information can be obtained to exploit the session.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
t's the browsers which fail to use the full potential.
For CAs that don't provide sufficient alternatives (multiple OCSP URIs,
CRLs), redundant servers etc., subscribers will find better sources for
their certificates.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP
On 09/19/2011 08:34 PM, From Robert Relyea:
If you really want pathlen of '0', then just set the isCA bit to FALSE;).
Well wellNSS (or PSM) doesn't even accept an end user certificate
with CA=TRUE as we found out recently. And that's very good IMO.
--
Regards
ds
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
used and applied at signing.
Is this what you did?
Maybe this helps:
http://adblockplus.org/blog/trying-to-get-rid-of-author-not-verified-or-signing-extensions-with-sitecom-certificate
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org
e bag. The client doesn't have to have the intermediate
CA certificates, it only must chain to a valid root however.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailin
ectly usable request. :-(
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
w DANE could be useful with CA issued certificates. The
above is a non-starter (at least for me) and rather dangerous for any
third party relying on it. But those are my opinions at least if and
until this gets implemented anywhere and I can prove my point.
--
Regards
Signer: Eddy Nigg, Sta
more compelling
argument than you have
as if your arguments are more convincing and the only ones that count :-)
but I don't think that the two of us will make any progress with more
back-and-forth.
Full agreement this time between us.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP
we police our own policy
differently in first place?
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
should continue to let them insert
themselves into a process that could be run far more securely and
efficiently without a third party.
I believe that CAs provide exactly the value necessary to make a
difference which you think is superfluous.
I don't buy it.
Fine with me.
7;t revoke their own certificate and
it's not meant to be that way. The issuer is obviously not the same
entity as the end user - surprise.
It's the assertion by a third party that provides the value.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startc
ly trusting DNS, as I originally stated.
Well, you can call white black and vice versa and we'll probably will
not convince each other. Also not necessary.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitt
ikely entirely meaningless. Instead I believe that CAs should take
the best out of DNSSEC for their validation procedures and this is my
intention too. Time will tell if I'm right.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.start
On 02/11/2011 12:36 AM, From Eddy Nigg:
I didn't say DV doesn't rely on DNS, almost everything on the *NET*
uses DNS.
Corrected.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_ni
ke
certificates by a responsible third party is however probably a strong
point in favor for CA issued certificates, CA provided warranties on top
yet another.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.c
en if
you deny it.
I'm not ranting against you. I'm trying to focus the discussion on
actual claims and verifiable facts.
Good.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
which you want them to
give up partly. Or in addition. Or a combination of those.
I just mentioned in the previous mail a couple of arguments, perhaps
you've got some answer to those instead of ranting against me?
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startco
On 02/06/2011 05:38 PM, From Florian Weimer:
The IP address restriction is a pretty strong factor.
Florian, tell me what your IP is and I'll log into Bugzilla next time
with that IP. Getting to know your IP is fairly easy too.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:
ng a CA take responsibility is obviously not only a technical
solution to a certain problem.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-
st likely this is not what the Anti-CA crowd wants to achieve, but
nevertheless might get in the end. :-)
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-
r possible usability issues.
Considering the technically more experienced users of Bugzilla could
benefit from such an option. My experience is that if they know how to
obtain a client cert, they'll know to handle its use usually as well.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
med in the article.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On 05/21/2010 05:51 PM, From Gervase Markham:
On 21/05/10 12:11, Eddy Nigg wrote:
And your whole arguing starts to become ridiculous.
Not at all. He is saying that the browser cannot tell whether a
certificate problem is the result of an attack or the result of a
misconfiguration. And
On 05/21/2010 09:49 AM, From Matt McCutchen:
Once again, I make no such claim. I said that if there is in fact no
impersonation, then the error is a false positive.*Of course the
browser cannot determine that.*
And your whole arguing starts to become ridiculous.
--
Regards
Signer: Eddy
understanding as to how this all works.
I could have saved myself a response - you've said that way better.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing lis
cate is valid and this is, if you
trust the issuer. Feel free to add any CA root to your trusted
authorities, but don't expect that Mozilla will add any of them without
proper vetting and compliance procedure.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Bl
end-user as to the differences between those classes?
I believe that it's not the CAs but the software vendors which refuse to
do so.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
de
On 05/21/2010 03:23 AM, From Matt McCutchen:
On May 19, 11:28 am, Eddy Nigg wrote:
Well, just for the record, lets get this strait - there are no false
positives. I have NEVER encountered an error with a web site and there
was no reason for it. Either the certificate was not trusted or the
On 05/19/2010 07:44 PM, From Marsh Ray:
Perhaps one identifiable improvement here is that this ability to get
acceptable certs easily could be made more widely known?
Yes, perhaps...but it might be difficult for Mozilla to do so too
openly...not sure.
--
Regards
Signer: Eddy Nigg
xpired certificate, which
often is just a bad manipulation when the cert is *shortly* expired.
The browser could be smarter about that.
Yes, I agree with that.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.c
On 05/19/2010 01:30 PM, From Jean-Marc Desperrier:
Eddy Nigg wrote:
Isn't this actually a sign that the technology works? I mean, 100% false
positives means literally 100% success.
Shit no !
The higher the false positive rate, the more acute the failure.
Well, just for the record, let
nts. That's why we hang out here in first place.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
ng exposed to attack should be "we failed",
not "users have poor judgment".
I think I start to agree with you - so what is it that you are proposing?
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
T
it's a problem for those which want the "freedom" to
use their home-grown weed. Except that security ends there.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypt
dge, laziness or stubbornness, but has little to do how
browsers treat such errors.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozil
On 05/17/2010 09:25 PM, From Marsh Ray:
This is half in jest, but half serious too. There may be something here.
Imagine how fast sites would fix their certs if the scary page proposed
keyword alternative sites that did not have cert issues.
Truly evil :-)
--
Regards
Signer: Eddy Nigg
ining paragraph starts:
Apparently there are some that prefer dancing pigs, so what?! But lets
not start this debate all over again... :-(
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-c
On 05/17/2010 06:22 PM, From Jean-Marc Desperrier:
Eddy Nigg wrote:
- Do other applications (like thunderbird and other mail), would make
sure that they search through all the e-mail addresses to look for a
match?
Yes, this appears to be the case.
IIRC, they do but they are some place
ds
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
pgrade. When that
will happen, who knows...
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On 12/04/2010 15:29, Eddy Nigg wrote:
updated servers need updates clients and break older ones, whereas old
servers will not allow new clients.
I haven't seen one yet, that doesn't have a flag to accept older
clients. If you set that flag, *and* disable renegotiation at least
On 04/12/2010 11:27 PM, Nelson B Bolyard:
Yup, just test files used by the automated QA scripts run in Tinderbox.
They must be replaced every year or so.
http://tinderbox.mozilla.org/showbuilds.cgi?tree=NSS
Nice :-) and thanks.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start
On 04/12/2010 08:18 PM, Eddy Nigg:
http://bonsai.mozilla.org/cvsview2.cgi?command=DIRECTORY&subdir=mozilla/security/nss/tests/libpkix/certs&files=OCSPCA1.cert:OCSPCA1.p12:OCSPCA2.cert:OCSPCA2.p12:OCSPCA3.cert:OCSPCA3.p12:OCSPEE11.cert:OCSPEE12.cert:OCSPEE13.cert:OCSPEE14.cert:
OCSPEE23.cert:OCSPEE31.cert:OCSPEE32.cert:OCSPEE33.cert:OCSPRoot.cert:OCSPRoot.p12&root=/cvsroot
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev
cally if not the whole Internet moves to the new protocol in one
day, there is going to be nightmare. It's starting already with updated
clients or updated servers, we'll have always a group which isn't served.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startc
certificate is signed
by the above CA certificate.
If I navigate to the same website with Firefox 3.6.3, the SSL
handshake is successful because the CA certificate is present.
What needs to be done to get this remedied?
I suspect that might be because the server doesn't send the complet
certificate is signed
by the above CA certificate.
If I navigate to the same website with Firefox 3.6.3, the SSL
handshake is successful because the CA certificate is present.
What needs to be done to get this remedied?
I suspect that might be because the server doesn't send the complet
t; Enable FIPS.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
gards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
See this article, section 4.2, conclusion #1:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.140.2584&rep=rep1&type=pdf
Where exactly? I haven't see that this information is not subject to
user modification.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:sta
rsh Ray wears a white hat!
Unfortunately we don't know how many times this has been used
successfully. Thanks for the explanations, it broadened my understanding
about its potential misuse.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http
e next steps to include it in the certificates. Peter has
been working with us for the XMPP certificates, but unfortunately we
haven't come about to actually do that. It's still on my plate though...
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:
://tools.ietf.org/html/draft-saintandre-tls-server-id-check-02
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org
ntributing fact which obviously shouldn't happen, but even without it
it's certainly no guaranty for protection for this kind of coding.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
-
ier? Isn't it amazing that such a fairly
trivial exploit existed for such a long time? Yourself know the SSL
protocols in and out and never thought about it?
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://
RSA key sizes above 1024 to mention only a few.
This is not a mozilla unilateral decision. It's made in concert with
other browser vendors.
If all parties pull at the same string, this might work. So far this has
seldom worked.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:star
rs will do and when. When I did the risk assessment I came to the
conclusion that when using an RFC 5746 compliant client, the risk for
exploiting it, is incredible low. I believe the risks of SSLv2 were
higher on a practical level.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP
On 03/31/2010 06:48 PM, Eddy Nigg:
On 03/31/2010 04:45 PM, Kai Engert:
== snip quote begin ==
E.g., the attacker would send:
GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1
X-Ignore-This:
And the server uses the victim's account to send a pizza to the
att
On 04/01/2010 02:40 PM, Michael Ströder:
You could also spend ~5000 EUR and have your own corporate sub-CA issuing
certs for whatever DNS name you want.
Which doesn't imply that no domain control validation is performed.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:
We've been
discussion this issue to death already and Verisign committed to it.
Apparently they haven't done so, despite their commitment.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
r of the domain
portugalmail.pt can not.
I suggest to add another item to the Mozilla CA Policies that:
A) CAs are required to accept revocation requests by third parties and
investigate any request
B) CAs are required to revoked certificates upon key comprise and
wrongful issuance
--
Regards
Sig
iming is a bit
questionable ;-)
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Hi Kurt,
Terrific! What's your next step now? Where do you intend to publish it?
PS. I know a real person who's name is Marco Polo ;-)
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. <http://www.startcom.org>
XMPP: start...@startcom.org
Blog: Join the R
n any case.
Effectively, the attacker can execute a request on behalf of the user,
without needing to know the user's credentials.
Your assumptions are wrong and the whole thing is over-hyped as I
mentioned in the bug.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start
concern IMO.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
flags possible to
impose by the requesting web site.
I prefer keygen because of it's simplicity and it simply works. Before
we can add more sophisticated features, lets get to the point where
browsers support something that works across the band.
--
Regards
Signer: Eddy Nigg, StartCom
On 03/30/2010 01:23 PM, Jean-Marc Desperrier:
And making more obvious that keygen is not a good long term solution
is a very good thing.
Only in case the alternative will be supported by all or most browsers.
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog
On 03/29/2010 10:41 PM, Peter Djalaliev:
Matt Blaze seems to imply that this is already
happening. I have not seen a confirmation of such a case.
No such evidence exists.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org
cation for both
"authenticated" and "not authenticated" icons.)
My first thought was that this should be really where Larry is.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
effort! I hope I'll find the time to study your documents a
bit more, just browsed through them for now.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
, the arguments were usually exactly the point I made. Firefox (and
other applications) have their own crypto store, making it independent
from what happens at the system level. There are obviously pros and cons
for this approach.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start.
On 03/07/2010 11:23 AM, aerow...@gmail.com:
On Thu, Mar 4, 2010 at 6:42 AM, Eddy Nigg wrote:
I think it would make much, much more sense to use the OS store for
private keys across all Firefox versions !
Yes, and with a compromise of the system you'd also loose those
installed at
much, much more sense to use the OS store for
private keys across all Firefox versions !
Yes, and with a compromise of the system you'd also loose those
installed at the Mozilla applications. Not nice :S
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.or
other major browser? :-)
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
ly do they do (it seems that certificate
approval duty floats around between a few people).
Currently Kathleen Wilson is module owner and in charge for CA issues.
There are another few Mozilla employees involved from time to time. And
a couple of volunteers performing the reviews.
--
Regards
Signer:
On 02/21/2010 10:56 PM, Eddy Nigg:
On 02/21/2010 09:34 AM, Nguyễn Đình Nam:
The way to solve it is not to inform people of each potential attack,
because there will be too many false positive, pushing people to just
ignore it, rendering the scheme ineffective. The way to solve it is to
let a
#x27;s not feasible.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
oblem in such an easy way, why isn't
it already in use for more than a decade? Recent studies going at task
with those accessing SSH servers have shown that most users simple edit
their known_hosts file - those people are way more knowledgeable than
the casual users. It doesn't work.
On 02/21/2010 03:10 AM, Jean-Marc Desperrier:
On 20/02/2010 03:25, Eddy Nigg wrote:
Apache performs a renegotiation when none is needed when configuring
client authentication at a particular location, is there a logical
explanation for that? Or even considered correct implementation?
Yes
On 02/20/2010 12:22 AM, Eddy Nigg:
On 02/19/2010 08:59 PM, Jean-Marc Desperrier:
I just tried configuring a similar configuration, and thought more
and more whilst doing that it doesn't make sense, that it can't fail
in the way you described. And it doesn't (with tw
t that.
Right. And does that omit renegotiation by the server?
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Eddy Nigg wrote:
Trying the different sub domain trick doesn't work on the same server
but different host and IP.
Let me phrase this explicitly :
- You use only one Apache instance
Correct.
- You configured two virtual hosts inside that instance
- either each virtual host listens
On 02/18/2010 03:54 PM, Eddy Nigg:
Which reminds me that we were at this stage already in the past.
Basically the authenticated session would have to be relayed through
to the second server, something I rather prefer not to do. I suspect
that there is no other way around that.
Trying the
On 02/18/2010 02:43 PM, Eddy Nigg:
This requires that you split your content into two separate servers,
jump to authent.secure.startcom as soon as a user wishes to use a
cert, and remain at secure.startcom while you don't need the user to
be authenticated.
OK, now I got it...inde
1 - 100 of 1203 matches
Mail list logo
