Re: PositiveSSL is not valid for browsers

[Eddy Nigg]

On 01/04/2009 12:05 AM, Gervase Markham:

You want us to make a IV certificate which can be issued to businesses
without "verifiable physical existence and business presence"?


Yes, that is, many times small businesses and "trading as" are run from 
home or small offices. Some aren't exactly businesses, but one would 
nevertheless want to know with whom you are dealing. Additionally, there 
are of course different ways to perform reasonable checks for a 
presence, where "reasonable" depends.





You mean that want a price point in between DV and EV? :-)

Yeah also. And why not? For many EV is an overkill,


But it's not for their benefit they are getting that level of vetting,
it's for the benefit of their customers.


Certainly. But as shown above, those customers might not need them nor 
would the subscriber be able to qualify for EV in first place. Do we 
want to exclude this group from getting verified even though it would be 
better than nothing at all?




Let's put it another way: how do we explain the difference between EV
and this new level to consumers? "You can do transactions up to $X if
there's an EV cert, but only $X / 10 if it's a NewV cert?" Who's going
to pay attention to that?


I think that's the better question here. This is certainly something we 
would have to think about - and I suggest that there are those which 
have better qualifications for that than we do. But basically, if people 
can be educated to a certain degree about EV, I believe that it's 
possible to educate that there are other options, like DV...or IV/OV.




Proper identity validation takes time, and so costs money. The only way
to make it cheaper is to do less validation. And the less validation you
do, the easier it is to get dodgy certs issued.


Mmmhhh yes, maybe. Obviously your statement is correct theoretically, 
but for this type of validation, the validation should be reasonable. 
This of course needs to be signaled somehow, like: This person or 
"trading as" was validated by different meansas opposed to this 
organization has been thoroughly validated according to EV. (Don't pick 
on the wording now)



If it's possible to
reduce the amount of validation without running that risk, let's change
the EV standard.


No, I don't think this is what I really meant. I think EV as such is 
fine, that's not the purpose for my proposal. It certainly would devalue 
EV itself.



If you think the current CAs are overcharging, get
certified for EV yourself and charge less.



We are getting there...this exactly was also one of your advices which 
influenced that...but it ain't really cheap either :S



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to split this list

[Kyle Hamilton]

On Sun, Jan 4, 2009 at 4:45 PM, Paul Hoffman  wrote:
>>Ian G wrote, On 2009-01-04 16:01:
>>There's no mozilla.policy hierarchy.  So I'm searching for ideas for a
>>good hierarchy for these discussions.  Here are some ideas.  How about:
>>
>>mozilla.security.CA
>>mozilla.security.UI
>>mozilla.security.pki
>
> +1 to .CA or .PKI, -1 to .UI. There is more to the security UI than PKIX, and 
> there is much more to trust anchors than UI.

Paul, I believe you're correct, but I also believe that Ian was
suggesting an AND, not an OR.

.CA (I'd actually suggest 'trustanchors') for trust anchor
inclusion/exclusion discussion. +1 under either name.
.UI for user interface issues (and ho boy there are many of them).  +1 to this.

Interestingly, I can't really see much reason for a .pki (except
possibly as an adjunct to .UI, since any changes to the PKI should
only be brought about due to usability requirements, and since .pki
would be more of a technical discussion of the changes that need to be
made... eventually [hopefully] leading to spec documents that code can
be written to adhere to).  +0, but I'm willing to listen to arguments
for and against.

-Kyle H
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: CABForum place in the world

[Eddy Nigg]

On 01/05/2009 02:49 AM, Nelson Bolyard:


And right next to the lock icon is the DNS name that matched the cert.
This solves one problem with confusing URLs.



I view the padlock and the DNS name in that area completly superfluous. 
It serves no real purpose and is so90's really. Browsers really 
advanced since...or do you look up and down just to compare the URL in 
the address bar and then what's listed in the status bar?



It's however inconvenient and I personally never look there. Instead I
set browser.identity.ssl_domain_display to 1 in about:config.


That's also a good indicator.  Setting it to 2 makes it show the same
value as shown down by the lock icon, the verified DNS name.


Yes, but it makes it sometimes too long. Additionally I like to know the 
base domain since www.paypal.com.some.more.sub.domain.com/?p=sdlfhkd can 
become confusing too.



I was thinking of the "scheme" in the address bar, e.g. https://


:-) Welltry to tell that to my mother

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: CABForum place in the world

[Nelson Bolyard]

Eddy Nigg wrote, On 2009-01-04 14:48:
> On 01/05/2009 12:42 AM, Nelson B Bolyard:
>> Eddy Nigg wrote, On 2009-01-04 14:28:
>>> On 01/04/2009 09:32 PM, Nelson B Bolyard:
 do that, too, and phishers will be quick to imitate it.  The main point of
 "chrome" is that content cannot effectively mimic it.  It's unspoofable.
 (It wasn't, always, but browsers have finally gotten wise to that.)
>>> And what about this? https://blog.startcom.org/?attachment_id=90
>> If the blue shading around the "favicon" was the ONLY indication that a
>> page was served via https, then I would agree that that's too weak to be
>> considered unspoofable (or even noticeable).  But IIRC, there are at least
>> two other non-spoofable indicators.
> 
> I know about the padlock in the lower right bottom in the status bar. 

And right next to the lock icon is the DNS name that matched the cert.
This solves one problem with confusing URLs.

> It's however inconvenient and I personally never look there. Instead I 
> set browser.identity.ssl_domain_display to 1 in about:config.

That's also a good indicator.  Setting it to 2 makes it show the same
value as shown down by the lock icon, the verified DNS name.

> But what is the second indicator?

I was thinking of the "scheme" in the address bar, e.g. https://
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to split this list

[Paul Hoffman]

>Ian G wrote, On 2009-01-04 16:01:
>> On 4/1/09 21:32, Paul Hoffman wrote:
>>
>>> I propose that Mozilla form a new mailing list,
>>> dev-policy-trustanchors. The topics for that list would include:
>>>
>>> - All new trust anchors being added to the Mozilla trust anchor pile
>>> - Proposals for changes to the Mozilla trust anchor policy
>>> - Complaints about particular participants in the current trust anchor pile
>>> - Discussion of the UI aspects of the PKI in various Mozilla software
>>
>> I agree in principle.  I would suggest "policy-ca" or "ca-policy" being
>> anything in or around the CA policy, as that is the name of the thing.
>>
>> Comments:
>>
>>1. I don't think the discussions here are anything to do with dev.
>>2. trustanchors seems a too precise term, and I would prefer to see
>> it dropped (for liability reasons).
>>3. I would love to see real discussion of the UI aspects.  I have no
>> idea how to talk to those people, they should be here.
>>4. This topic is also about legal relationships.  Calling it "policy"
>> tends to sweep the liabilities under the carpet.
>
>There's no mozilla.policy hierarchy.  So I'm searching for ideas for a
>good hierarchy for these discussions.  Here are some ideas.  How about:
>
>mozilla.security.CA
>mozilla.security.UI
>mozilla.security.pki

+1 to .CA or .PKI, -1 to .UI. There is more to the security UI than PKIX, and 
there is much more to trust anchors than UI.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to split this list

[Nelson B Bolyard]

Ian G wrote, On 2009-01-04 16:01:
> On 4/1/09 21:32, Paul Hoffman wrote:
> 
>> I propose that Mozilla form a new mailing list,
>> dev-policy-trustanchors. The topics for that list would include:
>>
>> - All new trust anchors being added to the Mozilla trust anchor pile
>> - Proposals for changes to the Mozilla trust anchor policy
>> - Complaints about particular participants in the current trust anchor pile
>> - Discussion of the UI aspects of the PKI in various Mozilla software
> 
> I agree in principle.  I would suggest "policy-ca" or "ca-policy" being 
> anything in or around the CA policy, as that is the name of the thing.
> 
> Comments:
> 
>1. I don't think the discussions here are anything to do with dev.
>2. trustanchors seems a too precise term, and I would prefer to see 
> it dropped (for liability reasons).
>3. I would love to see real discussion of the UI aspects.  I have no 
> idea how to talk to those people, they should be here.
>4. This topic is also about legal relationships.  Calling it "policy" 
> tends to sweep the liabilities under the carpet.

There's no mozilla.policy hierarchy.  So I'm searching for ideas for a
good hierarchy for these discussions.  Here are some ideas.  How about:

mozilla.security.CA
mozilla.security.UI
mozilla.security.pki

others?
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to split this list

[Eddy Nigg]

On 01/05/2009 01:36 AM, Nelson B Bolyard:

3. I wonder if the non-developer topics are already within the scope of
another extant low-traffic list, namely dev-security (a.k.a.
mozilla.dev.security), except that I think the new list does not belong
in the "dev" hierarchy.


A dev.security...yes, the forgotten step child of crypto. At times 
we used to post there (and cross post to crypto) and don't know why 
crypto became the de-facto list for all CA/SSL/Policy related issues.


BTW, I unsubscribed from all Mozilla mailing lists and use now the 
fabulous NNTP support of Thunderbird. Lightweight, fast and without the 
headache of passwords and subscription preferences. Nelson you can 
deduct one of the "unsubscribes" which was me moving to the news reader. 
I wish there were more mailing lists with NNTP support, I can only 
recommend it.


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to split this list

[Ian G]

On 4/1/09 21:32, Paul Hoffman wrote:


I propose that Mozilla form a new mailing list, dev-policy-trustanchors. The 
topics for that list would include:

- All new trust anchors being added to the Mozilla trust anchor pile
- Proposals for changes to the Mozilla trust anchor policy
- Complaints about particular participants in the current trust anchor pile
- Discussion of the UI aspects of the PKI in various Mozilla software



I agree in principle.  I would suggest "policy-ca" or "ca-policy" being 
anything in or around the CA policy, as that is the name of the thing.


Comments:

  1. I don't think the discussions here are anything to do with dev.
  2. trustanchors seems a too precise term, and I would prefer to see 
it dropped (for liability reasons).
  3. I would love to see real discussion of the UI aspects.  I have no 
idea how to talk to those people, they should be here.
  4. This topic is also about legal relationships.  Calling it "policy" 
tends to sweep the liabilities under the carpet.




Topics that would still be germane for dev-tech-crypto would include

- Questions on how to add or remove trust anchors from various Mozilla software 
(without any discussion of why someone wants to do it)
- Discussion of how to implement alternate UI schemes for PKI (that is, what 
hooks are available in NSS for detecting positive and negative results)



Agreed.  It would be nice if we could do that.


All of Eddy's recent threads (being slimed by a Comodo reseller, finding a 
reseller that doesn't do domain validation, advertising that he had a domain 
validation bug but fixed it) would all be appropriate on the new list.

The current list is way too unfocused. People asking actual tech questions get 
drowned out by threads that have literally nothing to do with crypto but 
everything to do with policy.

Thoughts?



Absolutely, +1.

iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to split this list

[Nelson B Bolyard]

Paul Hoffman wrote, On 2009-01-04 12:32:
> I propose that Mozilla form a new mailing list, dev-policy-trustanchors.

> The current list is way too unfocused. People asking actual tech
> questions get drowned out by threads that have literally nothing to do
> with crypto but everything to do with policy.
> 
> Thoughts?

Did you mean to start a new thread?  Doing so requires more than merely
changing the subject.  You must post a message that is not a reply to do so.

1. In my view, there are 3 broad categories of discussion that go on in
this list.  They are (in no particular order):

a) technical discussion about NSS, JSS and PSM code and protocols
   (primarily of interest to developers, IMO)
b) root CA certs and related policy
c) UI/GUI ("ooey gooey" :) for crypto and certs in Mozilla products.

One of those clearly belongs in Mozilla's "developer technology"
hierarchy.  It's less clear that the other two belong there.

2. As moderator of the dev-tech-crypto mailing list, I receive an email
each and every time someone subscribes or unsubscribes.  Every month the
list receives a certain number of subscriptions and unsubscriptions,
with the result that the list has steadily grown at a rate of 1-3 a month
for a long time.  When the volume of non-developer discussions greatly
increased (approximately in September or October), we saw an increase in
the number of monthly unsubscriptions.  It reached (and briefly surpassed)
the rate of subscriptions.  But the number of subscriptions rose again in
November, and since December 21, it has suddenly jumped up.

I think those observations suggest that the discussion of non-developer
topics such as root certs and browser UI has increased the level of
participation (even if mostly passive) in the subject of cryptographic
security in Mozilla products, which is good, but that has come at a cost
to the level of participation by those who were primarily interested in
developer topics.

I think both groups (developers and non-developers) might be better
served by separating the discussions into separate lists.  But developers
may be very interested in both classes of topics and may not wish to
subscribe to yet another list to follow both.

3. I wonder if the non-developer topics are already within the scope of
another extant low-traffic list, namely dev-security (a.k.a.
mozilla.dev.security), except that I think the new list does not belong
in the "dev" hierarchy.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: SECOM Trust EV root inclusion request

[Eddy Nigg]

On 12/30/2008 06:23 PM, István Zsolt BERTA:

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 resolved: As I recall, on the short
run it does not cause problems with the current release of Firefox.
However, we accepted your arguments, we made some changes in our
systems and promised further changes in the future, so that it shall
not cause problems on the long run either.


Are you saying that your OCSP is (going to be) operating now as expected?


I may accept this statement, but if there is such a requirement, it
should be stated in advance.


I agree with you.


If there is no such requirement, it should not hinder the process, but
there should be defined ways to resolve this issue.


Apparently it does hinder the process (not intentional, just by the fact 
that it's hard to get to the information).



We were requested to submit further documentation on the audit in
English. We had the detailed report of our auditor translated and we
sent it to Microsoft. (This is a non-public document that describes
our systems in depth similar to our CPS.)


So there is a disadvantage to Mozilla as you aren't willing to provide 
the same information as you did to Microsoft.




They did not examine our CPS. (If we had been asked to submit a
translation of the current CPSs, we would have done so.) They relied
on the audit statement and on the detailed report of our auditor.


Well, yes, that's pretty detailed I guess. It might be actually easier 
to read the detailed report than the CPS many times.



At that time, Microsoft stated that OCSP responders under a separate
root are not supported, so our OCSP root was not included in Windows.
However, the OCSP URL in the AIA field was not raised as a problem.


Therefore OCSP is effectively not working for Microsoft software too, 
correct? I know however that CRLs are better supported than with NSS.



was going to happen at what time, what was examined, what the exact
criteria was, and when they wanted us to submit some documentation,
they asked us to do so.


Yes, I guess Mozilla can make such a request too.


OK, thanks, I tried to summarize the main points above.


And sorry for the late reply, your message almost drowned at the list 
(but I marked it to respond to you later).



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to split this list

[Justin Dolske]

On 1/4/09 12:32 PM, Paul Hoffman wrote:


I propose that Mozilla form a new mailing list, dev-policy-trustanchors.


Yes. I'd also very much like to see this split. I'm interested in the 
technical side of things, but not so much the policy stuff (and, 
frankly, the incessant bickering and advocacy that goes along with it).


Maybe policy-crypto, instead of policy-trustanchors? That might be a bit 
more discoverable, makes the connection to dev-crypto clearer, and is a 
more general policy-vs-tech split. Usenet-wise, I'd think it should 
probably be mozilla.policy.crypto (or mozilla.policy.trustanchors), 
instead of in the .dev hierarchy.


Justin
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: CABForum place in the world

[Eddy Nigg]

On 01/05/2009 12:42 AM, Nelson B Bolyard:

Eddy Nigg wrote, On 2009-01-04 14:28:

On 01/04/2009 09:32 PM, Nelson B Bolyard:

do that, too, and phishers will be quick to imitate it.  The main point of
"chrome" is that content cannot effectively mimic it.  It's unspoofable.
(It wasn't, always, but browsers have finally gotten wise to that.)

And what about this? https://blog.startcom.org/?attachment_id=90


If the blue shading around the "favicon" was the ONLY indication that a
page was served via https, then I would agree that that's too weak to be
considered unspoofable (or even noticeable).  But IIRC, there are at least
two other non-spoofable indicators.


I know about the padlock in the lower right bottom in the status bar. 
It's however inconvenient and I personally never look there. Instead I 
set browser.identity.ssl_domain_display to 1 in about:config.


But what is the second indicator?

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: CABForum place in the world

[Nelson B Bolyard]

Eddy Nigg wrote, On 2009-01-04 14:28:
> On 01/04/2009 09:32 PM, Nelson B Bolyard:
>> do that, too, and phishers will be quick to imitate it.  The main point of
>> "chrome" is that content cannot effectively mimic it.  It's unspoofable.
>> (It wasn't, always, but browsers have finally gotten wise to that.)
> 
> And what about this? https://blog.startcom.org/?attachment_id=90

If the blue shading around the "favicon" was the ONLY indication that a
page was served via https, then I would agree that that's too weak to be
considered unspoofable (or even noticeable).  But IIRC, there are at least
two other non-spoofable indicators.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: CABForum place in the world

[Eddy Nigg]

On 01/04/2009 09:32 PM, Nelson B Bolyard:

do that, too, and phishers will be quick to imitate it.  The main point of
"chrome" is that content cannot effectively mimic it.  It's unspoofable.
(It wasn't, always, but browsers have finally gotten wise to that.)


And what about this? https://blog.startcom.org/?attachment_id=90

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to split this list

[Eddy Nigg]

On 01/04/2009 10:32 PM, Paul Hoffman:

The current list is way too unfocused. People asking actual tech questions get 
drowned out by threads that have literally nothing to do with crypto but 
everything to do with policy.

Thoughts?



+1 from me.


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Proposal to split this list (was: Re: Full Disclosure!)

[Paul Hoffman]

At 12:11 AM +0100 1/4/09, Jan Schejbal wrote:
>>Why is this relevant to this mailing list?
>
>Because there was a security failure in one of the Firefox trusted CAs 
>allowing anyone to get fake certificates. This event and the reaction of the 
>CA are important to determine if the CA is (still) trustworthy. It's the same 
>as the Commodo thing. Just with a way better reaction and without the dodgy 
>background of dozens of resellers doing (or, in at least one case, not doing) 
>the Domain Verification.

Sorry, but I don't see that listed as a topic for discussion on the mailing 
list's information page .

I propose that Mozilla form a new mailing list, dev-policy-trustanchors. The 
topics for that list would include:

- All new trust anchors being added to the Mozilla trust anchor pile
- Proposals for changes to the Mozilla trust anchor policy
- Complaints about particular participants in the current trust anchor pile
- Discussion of the UI aspects of the PKI in various Mozilla software

Topics that would still be germane for dev-tech-crypto would include

- Questions on how to add or remove trust anchors from various Mozilla software 
(without any discussion of why someone wants to do it)
- Discussion of how to implement alternate UI schemes for PKI (that is, what 
hooks are available in NSS for detecting positive and negative results)

All of Eddy's recent threads (being slimed by a Comodo reseller, finding a 
reseller that doesn't do domain validation, advertising that he had a domain 
validation bug but fixed it) would all be appropriate on the new list.

The current list is way too unfocused. People asking actual tech questions get 
drowned out by threads that have literally nothing to do with crypto but 
everything to do with policy.

Thoughts?

--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Pre- and Post- controls

[Eddy Nigg]

On 01/04/2009 09:27 PM, Daniel Veditz:

Eddy Nigg wrote:

On 01/04/2009 10:20 AM, Eddy Nigg:

On 01/04/2009 04:48 AM, Ian G:

On the punishment side, about all we have is "drop the root!" which I
earlier described as a blunt weapon. Are we being sensible when we now
have to "drop the root" for the three CAs who have reported problems?

Oh btw. where do you see three roots to drop?


The three CAs who have recently issued certs to unauthorized parties are
RapidSSL (md5 hack),


There could have been many more CAs which could have fallen under this 
category - RapidSSL was the unlucky one to be picked perhaps. 
Potentially you could add quite a few here...not sure.



Certstar/Comodo


Certstar is not a CA, but Comodo. As per previous suggestion, the issue 
of their resellers and RAs must be looked at and if needed a solution 
found in my opinion. Of course Mozilla must decide first what it exactly 
expects in this respect and what is unacceptable. On the other hand, the 
current Mozilla CA Policy could be applied as well, which is rather 
clear on this issue.


and StartCom.

Ahhh, yes :-)

Did you or anybody else see an issue with the policies and practices of 
StartCom which beyond the resolution StartCom offered and handled the 
incident would warrant further discussion and actions?


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Pre- and Post- controls

[Eddy Nigg]

On 01/04/2009 09:34 PM, Daniel Veditz:

Florian Weimer wrote:

EV is (also) an attempt to devalue existing infrastructure, so it's
some form of group punishment.


It also provides browsers with a slightly less blunt weapon. If a CA
clearly violates EV guidelines the browser could remove the EV-ness of
the root without removing the root itself. Users could still get to the
sites so we're not punishing users and not putting sites out of
business, but the site owners are no longer getting what they paid for
and that will put pressure on the CA.


It has been pointed out that this scenario is less likely than having a 
CA conform fully to the EV guidelines, but their other CA business might 
be considered unreliable. In such a case it would be advisable for 
keeping the EV-ness as you say and remove the trust bits from the root 
for their other certs. Now I don't remember if that's possible.


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Pre- and Post- controls

[Daniel Veditz]

Florian Weimer wrote:
> EV is (also) an attempt to devalue existing infrastructure, so it's
> some form of group punishment.

It also provides browsers with a slightly less blunt weapon. If a CA
clearly violates EV guidelines the browser could remove the EV-ness of
the root without removing the root itself. Users could still get to the
sites so we're not punishing users and not putting sites out of
business, but the site owners are no longer getting what they paid for
and that will put pressure on the CA.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: CABForum place in the world

[Nelson B Bolyard]

Ian G wrote, On 2009-01-03 19:19:
> On 3/1/09 23:40, Nelson B Bolyard wrote:

>> There's a great deal of anecdotal evidence (and some serious studies) 
>> that suggest that anything that goes on outside of the "content" area 
>> of the browser, and that does not actively engage the user, will be 
>> ignored by a huge percentage of users.  There are many users who, 
>> anecdotal evidence shows, ignore all "chrome" completely and pay no 
>> attention to anything except "content".  Because of the fact that good 
>> phishers always reproduce the desired content EXACTLY, users who
>> ignore chrome and only examine content will ALWAYS be victims to
>> phishers UNLESS we interrupt their view of the "content" with something
>> that they must deal with when the site's credentials are "phishy".
>> That's why warnings and clicks are different than all the other stuff
>> you describe above.
> 
> OK, so some discussion on how to display the info.  Bringing the two 
> together, the info that is considered relevant might be pasted over the 
> entire page.  Paste info for "good connections" over the entire page as a
> shadow display, with all there in big letters, and allow it to fade away
> after 2-3 seconds.  Pink or mild yellow?

The problem is that ANYTHING that you can put into the content area can
also be put there as content.  If you condition the user to accept large
but vanishing yellow letters saying "good connections", the content can
do that, too, and phishers will be quick to imitate it.  The main point of
"chrome" is that content cannot effectively mimic it.  It's unspoofable.
(It wasn't, always, but browsers have finally gotten wise to that.)

> The point being if the "chrome" is ignored, we go where it isn't ignored?
> (I really liked the addition of the top and bottom bars in light grey,
> within the content part.)

That can all be mimicked.

> If it is important, we can interrupt the user's info.  If it isn't
> important enough for that, then it isn't important.

That's the entire rationale for the current bad cert "error pages",
which replaced the old error dialogs.

The also found that users would dismiss any dialogs to get to that
precious content, so the only solution was to replace the content entirely.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Fully open operation

[Ben Bucksch]

On 04.01.2009 19:54, David E. Ross wrote:
The line from auditor to the public has been drawn in the courts, 
where lawsuits against auditors by investors injured by corporate 
fraud have been successful.


Yes.

But as Ian pointed out, and you can see in the audit documents, e.g. 
, the assurances 
and assertions made by the auditors are rather weak.


I don't know what the audits in the case of e.g. public stock companies 
and IPO, which you probably refer to, assert, and whether certain 
assertions are *required* by law, e.g. the rather strict US stock market 
laws and regulations by the SEC.


Therefore, I'd say that we should mandate assertions by the CA audits 
which are actually worth something, also in court. I.e. when the auditor 
didn't do its job, it must be possible to sue him (and the CA) for 
damages and win.


What I have seen in the last 2 weeks was extremely sobering. An audit 
which doesn't check the actual verifications done by the CA is entirely 
worthless.
See also "PositiveSSL is not valid for browsers", towards the end. I 
think that CPS should never have passed the audit.


Ben
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Pre- and Post- controls

[Daniel Veditz]

Eddy Nigg wrote:
> On 01/04/2009 10:20 AM, Eddy Nigg:
>> On 01/04/2009 04:48 AM, Ian G:
>>> On the punishment side, about all we have is "drop the root!" which I
>>> earlier described as a blunt weapon. Are we being sensible when we now
>>> have to "drop the root" for the three CAs who have reported problems?
> 
> Oh btw. where do you see three roots to drop?

The three CAs who have recently issued certs to unauthorized parties are
RapidSSL (md5 hack), Certstar/Comodo, and StartCom.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Fully open operation

[David E. Ross]

On 1/3/2009 6:51 PM, Ian G wrote:
> It was written:
>> But aren't auditors the eye of the public performing and recording those
>> operations?
> 
> 
> That's one theory.  Here is another:  Who is the client of the auditor? 
>   The auditor has a duty to the client that (arguably) outweighs the 
> duty to anyone else.
> 
> You might not agree to the above characterisation.  But, try this test: 
>   can you draw a line from the auditor to the public?
> 

The line from auditor to the public has been drawn in the courts, where
lawsuits against auditors by investors injured by corporate fraud have
been successful.

-- 
David E. Ross


Go to Mozdev at  for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications.  You can access Mozdev much
more quickly than you can Mozilla Add-Ons.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Pre- and Post- controls

[Florian Weimer]

* Ian G.:

> So what to do?  Should "Mozilla" become "the judge" in the post-event
> phase?  Do we leave this job to the courts?  Should we group together
> on this list and pass final judgement?  Should we all vote?  Demand
> changes?  Should we implement California rules -- 3 strikes and the
> root is killed?

A three strikes approach encourages confidence-reducing games, so I
don't like it.

I think that without court involvement, it's very difficult to run
proper discovery.  Suppose that you have got evidence which strongly
suggests that a CA keeps an equivalent of the private key of the root
in a non-secured data center.  The evidence is short of a conclusive
proof, though.  You ask the CA about it, and it says, "no, that's not
true".  You ask, "can you show us how you have structured control of
the private key?", and the answer is, "no, that's business
confidential information".  The same dialog might happen after you
have obtained actual proof (in the form of a certificate) that
something is amiss.  This time, the CA says that it has "implemented
adequate controls to prevent a recurrence of the event", and details
remain confidential.

But if all you've got is CA output due to lack of transparency, you
are in three strikes territory.

The downside of court involvement is that if all CAs are rotten and
don't want to enforce, the whole system continues to drift.

> We need something.  With nothing, we have no feedback.  With no
> feedback, any objective system drifts to subjectivity.  It is I think
> the case that for the entirety of the Internet PKI system, no
> participant has ever been punished;  how far into insecurity are we?

EV is (also) an attempt to devalue existing infrastructure, so it's
some form of group punishment.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Pre- and Post- controls

[Eddy Nigg]

On 01/04/2009 10:20 AM, Eddy Nigg:

On 01/04/2009 04:48 AM, Ian G:

On the punishment side, about all we have is "drop the root!" which I
earlier described as a blunt weapon. Are we being sensible when we now
have to "drop the root" for the three CAs who have reported problems?


Oh btw. where do you see three roots to drop?

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Pre- and Post- controls

[Eddy Nigg]

On 01/04/2009 04:48 AM, Ian G:

On the punishment side, about all we have is "drop the root!" which I
earlier described as a blunt weapon. Are we being sensible when we now
have to "drop the root" for the three CAs who have reported problems?


Actually we've discussed this issue just recently but before you started 
your valuable contributions here as well ;-)


It was suggested to work with the CAs in question to improve and solve 
those outstanding issues. I think this is what Frank has always done so 
far and which could be considered policy. However nothing is holding the 
hands of Mozilla back from removing a root if needed. That is specially 
when a risk for the users exists. Negligence by the CA and failure to 
conform to the Mozilla CA Policy are certainly on the table as well I guess.




Demand changes?


Where needed, yes.


Should we implement California rules -- 3 strikes and the root is killed?


It very much depends on the circumstances, but yes, I think repeated 
failure of a CA should have consequences. Requiring attestations about 
the requested changes could be more effective before actually removing a 
root.




We need something. With nothing, we have no feedback. With no feedback,
any objective system drifts to subjectivity. It is I think the case that
for the entirety of the Internet PKI system, no participant has ever
been punished; how far into insecurity are we?


Somewhat perhaps. On the other hand let me show you this example: When 
the Debian weak keys surfaced, I wasn't overly convinced on the need for 
action initially. This forum and members of it convinced me otherwise 
and I worked at my organization for a resolution. It resulted (as 
reported here [1]) in the following;


 "I've received reports that StartSSL was one of the first CAs to 
filter for bad keys, and others, such as GoDaddy and Netlock have 
followed suit.)"


The work here and the influence provoked actions which were picked up by 
others including the most important CAs. As I also indicated earlier, my 
participation here is a give and take and can provoke changes also at 
the organization I run. This shows that the right influence can have 
positive results without "punishments". On other matters this might not 
always be enough however, not entirely sure.


[1] http://codefromthe70s.org/sslblacklist.aspx

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto