On 3/08/11 8:38 PM, Nelson B Bolyard wrote:
When the
framework was developed, and all that remained to be done was writing any
tests that run in it, the framework developers quit.
"You need a framework" is the 21st century version of that old epigram,
"I've got a bridge to sell you..." :)
S
On 7/02/11 2:38 AM, Florian Weimer wrote:
* Gervase Markham:
Goal: fix bug 570252. Provide 2-factor authentication for some
Bugzilla accounts.
https://bugzilla.mozilla.org/show_bug.cgi?id=570252
The IP address restriction is a pretty strong factor. Basically, it
means that a potential attack
On 11/12/2009 15:02, Konstantin Andreev wrote:
Hello, Nelson.
On Fri, 11 Dec 2009, Nelson B Bolyard wrote:
On 2009-12-10 02:12 PST, Gregory BELLIER wrote:
I noticed the 3DES cipher is used to encrypt emails with S/MIME and I
would like to use another one.
According to the version of S/MIME
Nelson,
can you say something about whether & when Firefox will deliver "relief"
for this issue?
My motivation for the question is here:
http://financialcryptography.com/mt/archives/001210.html
iang
On 07/12/2009 10:22, Nelson B Bolyard wrote:
NSS version 3.12.5 has been released in source
On 30/11/2009 22:47, Kyle Hamilton wrote:
On Mon, Nov 30, 2009 at 1:07 PM, Ian G wrote:
I agree. It breaches that fundamental law of the Iang's mind-space: there
is only one mode, and it is secure. Break the law, time folds and inverts
on itself, and Mallory slips between your
Good article!
On 01/12/2009 01:38, Nelson B Bolyard wrote:
There are two schools of thought about the vulnerabilities related to the
use of renegotiation in SSL 3.x (including TLS 1.x). Briefly, they are:
a) It's SSL/TLS's fault, a failure in the design of renegotiation, or
b) It's the fault o
On 30/11/2009 20:46, Kyle Hamilton wrote:
interesting description folded.
Apache's willingness to do per-Location/per-Directory/per-Whatever
renegotiation for client authentication is what forced us into this
situation in the first place. I believe it should be considered a
bug, and fixed on A
On 24/11/2009 10:25, Jean-Marc Desperrier wrote:
Nelson B Bolyard wrote:
CAs that
make this mistake typically have to abandon and completely replace their
entire PKI (entire tree of issued certificates) when a CA cert expires
and
its serial number appears in the AKI of other subordinate certs. M
Hi Nelson,
On 20/11/2009 20:57, Nelson B Bolyard wrote:
On 2009-11-19 08:24 PST, Daniel Joscak wrote:
Or is this a question about the behavior of Mozilla's crypto code?
In that case, this is the right list.
I read it is a question as to what goes wrong when it is done, and why
it is that
On 22/10/2009 19:22, Nelson B Bolyard wrote:
As my program is single-threaded (built on a reactor),
A reactor? What's that?
http://en.wikipedia.org/wiki/Reactor_pattern
(nuclear? :)
more like a substation :)
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
http
On 15/10/2009 15:21, Gervase Markham wrote:
On 13/10/09 16:18, Anders Rundgren wrote:
IMO putting OCSP or CRLs in public SSL certificates was never a
particularly good idea because the only likely case for a revocation
is when a CA fails to validate a customer. That has happened
but not often en
Apropos Gerv's strawman question about trying to make OCSP soft fail
better, here is a fairly eloquent article from Bruce Schneier that might
help. I don't always agree with him, but on this article, I am in full
agreement. First and last paras only.
http://threatpost.com/blogs/difficulty-
On 13/10/2009 15:54, Gervase Markham wrote:
Firefox uses OCSP but, by default, any response other than a definite
"is revoked" response is treated as "is not revoked". There is a user
pref that allows the user to change that, so that any response other
than "is not revoked" is treated as "is revo
On 08/10/2009 22:30, Daniel Veditz wrote:
On 10/7/09 4:00 PM, Guenter wrote:
Hi,
is there any way to overwrite the default behaviour that a remote SSL
host is verified against the CA list in the certdb?
At what level? Assuming you're asking in this newsgroup because you're
writing code to use
On 07/10/2009 22:09, Nelson B Bolyard wrote:
On 2009-10-07 10:32 PDT, Kyle Hamilton wrote:
The problem with this analysis is that I have yet to see any situation
where Mozilla's client certificate support meets *anyone's* needs.
Well, of course, we don't hear from the people for whom it works
On 07/10/2009 22:17, Anders Rundgren wrote:
I don't believe that client certificates in PCs will ever become mainstream
since
credential mobility and distribution issues have proved to be insurmountable;
not
technically but politically.
However, in mobile phones at least the mobility issue is
On 07/10/2009 13:24, Eddy Nigg wrote:
On 10/07/2009 07:25 AM, Kyle Hamilton:
Your comments suggest to me that NSS (and Firefox) *should not* be
enforcing any checks on the certificates, other than noting that
they're expired or revoked to the user in the certificate selection
dialog. If it has o
On 07/10/2009 15:46, Anders Rundgren wrote:
Ian G wrote:
For Mozilla, which should be interested in end-user security, an
entirely different subject to client-wallet security, this should be
much closer to something interesting.
It should but it isn't since nobody from Mozilla (u
On 07/10/2009 15:27, Gervase Markham wrote:
On 06/10/09 12:18, Ian G wrote:
It is somewhat of an eternal discussion at the pub as to why this part
of the SSL project moved to the "demo" stage and then stopped. I would
say that it is because the industrials that were interested in i
On 06/10/2009 00:48, Robert Relyea wrote:
Fortunately, I don't believe this is the final word on the matter.:)
One would hope not :)
Thing is, client certs is one of the few bright spots in security,
looking forward. They remove the passwords from the equation. This
forces that phisher-at
On 05/10/2009 01:24, Peter Djalaliev wrote:
It is our standard security nightmare. Side A thinks it is Side B's
problem. Side B thinks it is Side A's problem. In the meantime the
user doesn't use the tech because it doesn't work, and the sides are too
busy arguing to solve the problem. So z
On 04/10/2009 22:37, Eddy Nigg wrote:
On 10/04/2009 09:23 PM, Nelson B Bolyard:
On 2009-10-03 15:52 PDT, Jereme Bulzor wrote:
I've enabled client authentication in Sun One Web Server 6.1 and it does
work fine when the client certificate is valid.
I would like to present the user with a good er
On 21/08/2009 20:30, Ellen Chan wrote:
Hi again Ian,
Yes I can appreciate that there are priorities and you're reluctant to
get into something overly complex.
Well, I won't be coding it :) I'm just offering my opinion, which we
might recognise as being polarised against the majority here.
Hello Justin,
On 20/08/2009 17:45, Justin wells wrote:
Hi Ian,
Thanks for your reply! It's very enlightening, and I do agree that in
the real world there are a lot of issues other than the cryptographic
issues. Just to be sure, I am not suggesting that the weakest link
should be as strong as th
On 19/08/2009 20:30, Justin wells wrote:
Plainly the concern is that 256 bit AES does you no good if they AES
keys were exchanged insecurely. The security of the connection is the
lesser of the security of the content encryption, and the security of
the key agreement protocol
Yes, this is
On 14/08/2009 19:46, Aditya Ivaturi wrote:
An explanation of the alphabetic characters may be found on mozilla's web
site at
http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html#...
Back in college, I used to have a professor who had a RTFM rubber
stamp. And if he were here,
This really belongs on dev-tech-coffee-talk :)
On 01/08/2009 07:11, Nelson Bolyard wrote:
On 2009-07-31 12:38 PDT, Ian G wrote:
On 31/07/2009 11:29, William L. Hartzell wrote:
Nelson B Bolyard wrote:
Some lax CAs will evidently issue certs with just about anything in the
DNS names. I&#
On 31/07/2009 11:29, William L. Hartzell wrote:
Nelson B Bolyard wrote:
On 2009-07-30 19:46 PDT, Ian G wrote:
On 31/7/09 04:29, Nelson B Bolyard wrote:
... So, a name with a NULL in it will appear
as something like www.mybank.com\00*.badguy.org
There must be something I am missing. Since
On 31/7/09 04:29, Nelson B Bolyard wrote:
... So, a name with a NULL in it will appear
as something like www.mybank.com\00*.badguy.org
There must be something I am missing. Since when is a NULL a legal
character in a domain?
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozi
On 23/7/09 11:13, Eddy Nigg wrote:
On 07/22/2009 06:33 PM, Ian G:
3. You'll still get massive resistance. That's because all of the
mozilla security code, security developers, most of the committees,
and the companies that pay for the developers, the CAs, etc etc are
all invested heav
On 22/7/09 17:03, Udo Puetz wrote:
On 21 Jul., 14:34, Eddy Nigg wrote:
Udo, that's all fine and understood. What are the improvements you think
should be made to Thunderbird (and/or Firefox) besides what you claim to
be a bug in TB? Is the bug the only thing which prevents hardware tokens
and c
On 20/7/09 09:18, Udo Puetz wrote:
From a usability point of view I would consider the WHOLE
thing to be a nightmare. I intended to write up a howto, gave that up
now for the time being.
And by the way: ASN1, PKCS#7, PKCS#12. Who was the (pardon my french)
braindead person to name these things?
On 12/7/09 21:58, Anders Rundgren wrote:
Nelson B Bolyard wrote:
On 2009-07-12 05:51 PDT, Anders Rundgren wrote:
This is an interesting project.
What's not completely obvious is how this relates (or could relate) to
for example Firefox.
I must confess that I know absolutely nothing about NSS
On 9/7/09 17:33, Peter Djalaliev wrote:
AFAIK, 2^119 is the worst-time complexity of the attack. Breaking a
256-bit key through a brute-force attack takes 2^256 operations in the
worst case. The 'X/2' you are talking about is the average case,
right? We are not looking for collisions here, so
On 8/7/09 19:52, Eddy Nigg wrote:
On 07/08/2009 08:35 PM, Paul Hoffman:
At 8:08 PM +0300 7/8/09, Eddy Nigg wrote:
Funny that today it's better to use AES-128.
Why do you say that? It's the opposite of what the people who wrote
the paper say.
I've not read it today, but IIRC AES-128 remained
On 6/7/09 08:42, Nelson Bolyard wrote:
On 2009-07-05 16:03 PDT, Ian G wrote:
On 4/7/09 23:19, Nelson B Bolyard wrote:
You provide customer support for Firefox?
Yup. Doesn't everyone who is a techie? I mean, I don't want to, but
because I am a techie, people assume that I know Fi
On 4/7/09 23:19, Nelson B Bolyard wrote:
On 2009-07-04 04:19 PDT, Ian G wrote:
Some remarks.
On 4/7/09 12:18, Martin Paljak wrote:
Firefox displays a "Please enter password for ..." dialog, which is
ambiguous for casual users who need to be said very clearly when they
need to ent
Some remarks.
On 4/7/09 12:18, Martin Paljak wrote:
Firefox displays a "Please enter password for ..." dialog, which is
ambiguous for casual users who need to be said very clearly when they
need to enter the PIN of 4 or more digits. Right now my Firefox speaks
Estonian but I also remember a ph
On 3/7/09 17:39, Anders Rundgren wrote:
This demonstrates that standardization is an option but an increasingly
difficult
option as well in an ever faster-moving world:
http://www.w3.org/2009/06/xhtml-faq.html
I'm sure that (for example) a signature scheme done by a handful of committed
people
On 3/7/09 09:30, Martin Paljak wrote:
...
2. Fix Firefox/NSS - Firefox still thinks that you should be able to
authenticate to websites with certificates *without* TLS client
authentication extension. Add automatic certificate selection, and you
get trouble.
Yes, this makes cert login as bad a
On 3/7/09 07:15, Anders Rundgren wrote:
Nelson B Bolyard wrote:
but please don't take it out on us. Please refrain from further sniping
in this mailing list and newsgroup. Constructive contributions are welcome.
I'm sorry about that. Is there any other place where Mozilla people hang
out wh
On 26/6/09 23:51, Anders Rundgren wrote:
Google's Wave will hopefully be the finale for S/MIME.
Hmmm, tell me more. It does look interesting!
How is it secured? I read some blurbs and things but I'm hoping someone
knows the answers.
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@li
On 22/6/09 22:23, Kyle Hamilton wrote:
Is there an updated request in the queue for O=ABC.ECOM, INC? That
one expires 7/9/2009, which is less than a month from now.
Good question.
Are we going to enforce a 2048-bit root requirement after Dec 31, 2010
(per NIST non-classified recommendation
On 19/6/09 15:36, Jean-Marc Desperrier wrote:
Nelson B Bolyard wrote:
if you send an encrypted message to
someone from whom you have never received a signed S/MIME message, you
will
use weak encryption.
Does this assume LDAP for acquiring the certificate without a signed
S/MIME message? (So
On 15/5/09 00:51, Eddy Nigg wrote:
Whatever improvements can be made in the future, I'd really like to see
NSS shipped with the latest approved roots and EV enablements. Just to
remind the valued audience that an enormous effort was made to ship the
leading CAs with EV in the FF 3.0 release, a s
On 4/5/09 22:04, Nelson Bolyard wrote:
A very similar hack has already been done. It's a Firefox extension that
(IIRC) silently installs some roots and shows the green bar for
(some of) the certs that chain up to those roots. See it at
https://addons.mozilla.org/en-US/firefox/addon/4828
Nice,
On 3/5/09 15:43, Eddy Nigg wrote:
On 05/03/2009 10:06 AM, Ian G:
(2), there exists a standard need in audits to discuss disaster
recovery. Curiously, this does not appear to be documented anywhere,
draw your own speculations
It's usually addressed in internal CA documentation
On 3/5/09 15:32, Ben Bucksch wrote:
On 03.05.2009 09:06, Ian G wrote:
(5) possibly as consequence of all the above, it can be claimed that
it is an empty threat, and no more than a security/marketing tool for
PKI people.
Consequently, we need to either:
* Make that threat not empty
This is
On 2/5/09 17:50, Paul Hoffman wrote:
Peter Gutmann asked on a different mailing list:
Subject says it all, does anyone know of a public, commercial CA (meaning one
baked into a browser or the OS, including any sub-CA's hanging off the roots)
ever having their certificate revoked? An ongoing pr
On 27/3/09 00:54, Eddy Nigg wrote:
On 03/27/2009 01:46 AM, Ian G:
The original idea was how to improve Thunderbird's existing abilities
to work with crypto and deliver security.
Could you define security please?
Of course, in many and various ways! For this particular thing, I
On 25/3/09 08:45, Kyle Hamilton wrote:
However, the fact that the NSS layer handles
authentication of data makes this the only logical place to bring up
these issues.
Agreed, either here or in the new policy list, iff it can be sustained
as a security policy. But I suspect not.
The reason
On 25/3/09 01:06, Eddy Nigg wrote:
On 03/25/2009 12:35 AM, Kyle Hamilton:
I don't understand how this is connected to the initial idea of finding
some better ways to use client certificates for mail (was actually
client certificate authentication IIRC). I think I lost you here...
The origin
On 24/3/09 21:21, Kyle Hamilton wrote:
(The US Patent and Trademark Office does it by sending a transaction
ID number via postal mail, and a verification code via email to the
address-of-record, only after a notarized jurat is physically mailed
in. I honestly think the current batch of CAs are
On 24/3/09 01:48, Eddy Nigg wrote:
On 03/24/2009 02:25 AM, Ian G:
I haven't followed it in depth, but the primary way that the E.B.s
have responded is to move their existing TAN system to a cellphone SMS
(which the europeans call "handys", brits call them mobiles). A TAN i
On 22/3/09 00:32, Eddy Nigg wrote:
On 03/22/2009 12:55 AM, Ian G:
I don't know about these things, but I recognise that badly configured
servers are a pain. The servers I have experienced this with are
Apache. They may be misconfigured, but the sysadms aren't agreeing at
the moment, a
On 23/3/09 20:36, Nelson B Bolyard wrote:
Ian G wrote, On 2009-03-22 16:01 PDT:
Man in the Browser. It is a term that seems to have caught on to
describe what happens when the browser is taken over by malware, and it
owns the interface. To solve the security problems that arises in
online
On 22/3/09 02:09, Nelson B Bolyard wrote:
Ian G wrote, On 2009-03-21 07:00:
After MITB surfaced (and scared the European bankers into action)
What is that? Man In The Bank?
I suppose you meant MITM, but if not, please clarify.
Man in the Browser. It is a term that seems to have caught
On 22/3/09 22:20, Anders Rundgren wrote:
Nelson B Bolyard wrote:
Solution: One solution would be to define signature support as a
browser component.
Especially the component you've invented and have been trying to get
Mozilla to adopt for some time, right? Anders?
At this stage it is enoug
On 22/3/09 05:17, Nelson B Bolyard wrote:
I wrote:
Here's the TB RFE: https://bugzilla.mozilla.org/show_bug.cgi?id=437683
BTW, this client auth problem is MUCH MUCH worse for Thunderbird users than
for browser users, because evidently a higher percentage of free email
servers are crap.
I'll ha
09 12:26 AM, Ian G:
Right, the problem perhaps is better expressed that some of these
comments *aren't written with emoticons at the end* so it is not easy
for those from diverse cultures to figure out the joke. Oh, and I save
my stuff for those that appreciate fine red wine ;-)
A, at la
On 21/3/09 21:43, Nelson B Bolyard wrote:
Ian G wrote, On 2009-03-21 12:32:
It seems that we have a consensus that client
certificates (in a client authentication role at least) are unusable
with the current system. Approximately, for many reasons.
Sorry, I disagree. There are many places
On 21/3/09 22:19, Eddy Nigg wrote:
On 03/21/2009 09:32 PM, Ian G:
On 21/3/09 16:54, Eddy Nigg wrote:
Well, I just thought that I'd remind you about how outraged you were
when I said the same thing
I know I know, I apologise... I tried, but was stopped for reasons
without value
On 20/3/09 19:29, Anders Rundgren wrote:
This is a stupid comment.
Pardon me. I just don't agree with the majority of this list since
many governments and banks in the EU are working in another
direction. This may be due to ignorance
Folks, Anders is right about this "worldview" difference
On 21/3/09 16:54, Eddy Nigg wrote:
Huu? No outcry about rudeness in mailing lists here?
Eddy, I agree that rudeness was carrying us away from the problem and on
to the personalities. Indeed, it's up to all of us to be be minded of
this. For reasons that are too wordy to be worth the bytes
On 20/3/09 22:30, Kyle Hamilton wrote:
'since you obviously shouldn't have different PKI UIs for signatures
and authentication'? What crack are you smoking?
Hey Kyle, I think you are thinking way to far ahead here...
In the Real World, we have a different UI for authentication -- the
princ
On 20/3/09 08:32, Anders Rundgren wrote:
This is a stupid discussion.
Authentication schemes in general begin with authenticating the user.
How long the authentication should be considered as valid is
not something the client-end has anything to do with unless it
has gotten some kind of expirati
On 18/3/09 11:28, Nelson B Bolyard wrote:
Joe Orton wrote, On 2009-03-17 08:55:
It seems like a poor trade-off to require a larger memory footprint of
all the SSL servers in the world,
I hear that disk space is pretty cheap these days. 1TB == USD 85
rather than improve Firefox to be a bit
On 17/3/09 13:45, Johnathan Nightingale wrote:
On 17-Mar-09, at 7:55 AM, Ian G wrote:
<https://bugzilla.mozilla.org/show_bug.cgi?id=295922> Now, this is a
So we have seem to have a choice: client certificates are unusable
because they always ask, or they are unusable because they alway
Hi all,
I'd like to ask a couple of questions to those people closer to the
development effort. I spent some hours trying to get a couple of users
up and going on the weekend using client certs and ff/tb combinations.
On the Firefox side, there were problems because of the popup madness
wher
On 10/3/09 09:22, Eddy Nigg wrote:
On 03/03/2009 11:35 PM, kathleen95...@yahoo.com:
Kathleen,
are we planning to move the discussions of accepting CAs into the root
list over to the other list? I think that dev-security-policy is going now?
iang
--
dev-tech-crypto mailing list
dev-tech-cry
On 25/2/09 23:28, Nelson B Bolyard wrote:
Kyle Hamilton wrote, On 2009-02-25 14:04:
Postel's first rule of interoperability: be liberal in what you
accept, be conservative in what you send.
Yeah. Lots of nasty Internet vulnerabilities have results from applying
that to crypto protocols and fo
On 24/2/09 02:11, Eddy Nigg wrote:
On 02/24/2009 02:35 AM, Ian G:
The point that is made is that the "positive response" is so weak that
it doesn't support the overall effect; the attacker just prefers to
trick the user using HTTP and some favicons or other simple symbols. And
To amplify the response to Gerv's question on "positive / negative
imbalance in responses in FF3", here's a forward from another list.
On 21/2/09 15:34, Peter Gutmann wrote:
"Steven M. Bellovin" writes:
http://www.theregister.co.uk/2009/02/19/ssl_busting_demo/ -- we've talked
about this at
On 24/2/09 00:20, Gervase Markham wrote:
On 19/02/09 17:36, Ian G wrote:
1. He has clearly laid out the trap of negative versus positive
feedback, and explained why Firefox 3 UI changes make the result less
secure than Ff2.
You'll need to elaborate on what you are saying here, because th
On 23/2/09 13:41, Eddy Nigg wrote:
On 02/23/2009 02:01 PM, Jean-Marc Desperrier:
When issuing a SSL server cert there is no need for a special checking
at the CA level, because nobody will first be able to obtain a dangerous
domain name within that TLD.
Like the IANA requirement to state corre
On 21/2/09 03:18, David E. Ross wrote:
On 2/13/2009 11:52 AM, Eddy Nigg wrote:
On 02/13/2009 09:36 PM, Ben Bucksch:
FWIW, this is irrelevant. *We* require the ETSI. We can also require
additional requirements, like that the CPS is published.
or you have to add a new policy or practices point
On 20/2/09 20:07, Nelson B Bolyard wrote:
Benjamin Smedberg wrote, On 2009-02-20 10:28:
Homomorphic characters aren't a problem for wildcard matching. They're a
problem for users' eyeballs. The attack that was demonstrated could have
been done without wildcards. Changing the wildcard matchi
On 18/2/09 23:05, Frank Hecker wrote:
Paul Hoffman wrote:
A Mozilla policy that says "we allow trust anchors for which we cannot
do revocation checking" seems wrong.
Well, yes, but as Eddy pointed out for the past 10+ years we've had a
policy that basically amounted to the same thing, at lea
On 19/2/09 16:39, Benjamin Smedberg wrote:
http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
Other than this specific attack, what are the concerns about wildcards that
would make us take such a drastic action?
It sounds to me that we cou
On 19/2/09 14:30, Jean-Marc Desperrier wrote:
Moxie Marlinspike in Black Hat has just demonstrated a very serious i18n
attack using a *.ijjk.cn certificate.
http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
PS : Some of his other remarks a
Guys,
is there a page in wiki/CA: where we can collect points of discussion
for a future review of the policy? The problem being of course that we
have long discussions, reach some conclusions, but do not record those
conclusions as reminders to change the policy.
https://wiki.mozilla.org/C
On 14/2/09 02:15, Eddy Nigg wrote:
On 02/13/2009 11:46 AM, Ian G:
Don't fixate on the title. CAs generally have some set of documents that
are internal / not published, and some set of documents that are
published. If someone like the WebTrust people come along and say "CPS
must be
On 13/2/09 16:15, Ben Bucksch wrote:
For reference, Ian added, and Eddy reverted:
(old text)
The CP/CPS should be publicly available from the CA's official web site
(added text)
(we rely on public documents only).
If you do not publish the CP/CPS (not recommended), you will need to
publish an e
On 12/2/09 20:46, Eddy Nigg wrote:
On 02/12/2009 09:04 PM, Ian G:
Eddy, you change your tune so fast you must be salsa dancer ...
I don't think so. I wondered if we need a list of 20 items in order to
clarify what a CA should provide in terms of audited documents. As I
already said,
On 13/2/09 00:22, Eddy Nigg wrote:
On 02/12/2009 09:11 PM, Ian G:
Once the CA desk decides that is how it is, after consultation, that's
how it is. Frank held the line against requiring publication, and I for
one will support that against the steamrolling.
But there were calls ma
On 11/2/09 21:26, Eddy Nigg wrote:
On 02/11/2009 06:43 PM, Ian G:
OK, I made some changes on the wiki
First of all I think we should edit this document only after some sort
of agreement here. I think we haven't finished discussion concerning
this issue yet, can you hold back for a m
On 12/2/09 19:00, Eddy Nigg wrote:
On 02/12/2009 07:47 PM, Ian G:
[2] Actually I think I am a long way from nailing down the issues here.
Even though I agree usually on providing clear statements and
requirements, I wonder if we really have to go into such details? You
know, many times it was
So there appear to be several things that might require an additional
audit interaction over some delivery to Mozilla, outside the normal
audit opinion.
Here's my list of things, as spotted recently:
1. a CA's clarification or comment over a key document (e.g., CPS).
2. an additional documen
On 12/2/09 01:17, Eddy Nigg wrote:
On 02/12/2009 01:37 AM, Ian G:
Audit does an audit context. The two are different. Don't mix them; most
all audits are done according to defined audit criteria, such as
WebTrust or ETSI or DRC.
Yes, and Mozilla relies on them, period.
Yes, it&#
On 12/2/09 00:58, Kyle Hamilton wrote:
A notary does not verify content, a notary verifies identity.
Actually I meant a notary rather than a notary public, but the
difference is moot.
What we need is an opinion (hey! using your own terminology, Ian,
that means AUDIT, and thus AUDITOR) that
On 11/2/09 21:29, Eddy Nigg wrote:
On 02/11/2009 07:12 PM, David E. Ross:
However, the last sentence should be modified to say:
* All documents supplied as evidence should be publicly available and
must be addressed in any audit.
I don't have (don't want) an account to update the Wiki.
I ag
On 11/2/09 05:20, Frank Hecker wrote:
Ian G wrote:
The policy says, we need published information, *eg* the CPS.
Not, "CPS must be published."
Yes, exactly. We typically use the CPS and/or CP because almost all CAs
publish those documents; however there is no requirement that the
i
On 11/2/09 02:19, Kyle Hamilton wrote:
That's a very good question. The most important part of the answer to
it would have to be: don't discount what they say.
Right.
However, I have a suggested strategy for reviewers: don't limit your
review to only those trust bits that are initially requ
On 11/2/09 17:20, Paul Hoffman wrote:
At 5:09 PM + 2/4/09, Frank Hecker wrote:
1. To what extent do typical CPSs and CPs address this issue? In other words,
if we were to read the average CPS/CP, would it have language that would
unambiguously tell us whether our policy requirement were me
On 11/2/09 01:59, Eddy Nigg wrote:
It's perhaps an opportunity for me to explain why I'm here and why I
think others - specially representatives and employees of CAs - should
too.
OK, invitation accepted! I'm here to get a couple of fixes spliced into
the Mozilla DNA:
1. add a feedbac
On 10/2/09 21:06, Frank Hecker wrote:
I acknowledge your comment that ETSI TS 102 042 does not require the CPS
to be published. However we depend on public documents to document the
exact claims that CAs make and whether these meet our policy
requirement. So this causes a problem for us when we
On 10/2/09 23:02, Eddy Nigg wrote:
On 02/10/2009 09:42 PM, Frank Hecker:
And in any case, I don't see people being as much concerned about having
more Mozilla-employed people involved, but as getting more community
feedback. And I don't have any good answers there because it depends on
having mo
On 10/2/09 16:42, :
The initial comment was written on august 2008, and now we have code
signing
certificates, and it appears in our CP/CPS.
To my understanding the audit wasn't performed with those changes.
In general terms, and without commenting at all on the current case,
here are a few
On 10/2/09 14:16, Eddy Nigg wrote:
On 02/10/2009 02:15 PM, Ian G:
I think -- personal & likely biased opinion only -- you might get more
value by looking inside the foundation and asking them to expand the
resources available on the CA desk. Their job is to be independent, and
so
On 10/2/09 02:23, Nelson B Bolyard wrote:
I'd post this in the policy working group, if that was operational ... :(
I also don't like this discussion about waiting for some perfect A-list
of tech. We've got the NNTP thing, we've got the ordinary mail, what
are we waiting on now? google-pho
1 - 100 of 357 matches
Mail list logo
