Re: Unbelievable!

[Daniel Veditz]

Paul Hoffman wrote:
> At 1:16 AM +0200 12/24/08, Eddy Nigg wrote:
>> Select Preferences -> Advanced -> View Certificates -> Authorities.
>>  Search for AddTrust AB -> AddTrust External CA Root and click 
>> "Edit". Remove all Flags.
> 
> Doesn't this seem like a better solution than "sue Mozilla for
> theoretical future damages incurred by using their free software"?
> Put more rudely, why do you expect Daddy to fix it for you when you
> can fix it yourself, more easily and more quickly, if you want to?

Isn't that a bit like an auto maker issuing a notice "If you don't want
your car to explode in a fender bender you can crawl under the right
rear and remove the screw marked 34A on the following diagram."

Everyone should be able to do that so I'm sure that gets the auto maker
off the hook, right? Assuming all 200 million Firefox users even hear
about the problem.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: WebTrust

[Eddy Nigg]

On 12/25/2008 05:42 AM, David E. Ross:

At one time, the WebTrust Web site included a page that listed
certificate authorities that had obtained the WebTrust seal.  The page
was at.

That link no longer deals with WebTrust seals.  The URI redirects to
, which is a page
about the Canadian Institute of Chartered Accountants (one of the groups
that created WebTrust).

I found the page to be useful when trying to resolve broken chains of
certificates, especially when a root certificate's CA no longer existed
because it had been bought out by another CA.  I can't find such a page
now, either by searches within the www.webtrust.org and www.cica.ca
domains or by more global searches of the Web.

Is there a authoritative list of WebTrust CAs anywhere?



Frank just recently posted:

[1] I find it annoying that WebTrust doesn't publish an index of 
reports, so periodically I run a script to download all "sealfile" files 
 from the site by number; that's how I found this one just now.


The URL looks something like this: 
http://cert.webtrust.org/SealFile?seal=816&file=pdf



--
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: WebTrust

[Nelson B Bolyard]

David E. Ross wrote, On 2008-12-24 19:42:
> At one time, the WebTrust Web site included a page that listed
> certificate authorities that had obtained the WebTrust seal.  The page
> was at .
> 
> That link no longer deals with WebTrust seals.  The URI redirects to
> , which is a page
> about the Canadian Institute of Chartered Accountants (one of the groups
> that created WebTrust).

I wonder if something has happened to AICPA and its relationship with
WebTrust.  There's no mention of AICPA on the webtrust.org home page,
( http://www.webtrust.org/index.cfm/ci_id/43988/la_id/1.htm )
and if I start at http://aicpa.org/ and follow the link from the menu
to WebTrust, it takes me to http://www.cpawebtrust.org/ which returns
a page saying
   Bad Request (Invalid Hostname)

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

WebTrust

[David E. Ross]

At one time, the WebTrust Web site included a page that listed
certificate authorities that had obtained the WebTrust seal.  The page
was at .

That link no longer deals with WebTrust seals.  The URI redirects to
, which is a page
about the Canadian Institute of Chartered Accountants (one of the groups
that created WebTrust).

I found the page to be useful when trying to resolve broken chains of
certificates, especially when a root certificate's CA no longer existed
because it had been bought out by another CA.  I can't find such a page
now, either by searches within the www.webtrust.org and www.cica.ca
domains or by more global searches of the Web.

Is there a authoritative list of WebTrust CAs anywhere?

-- 
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: Unbelievable!

[Paul Hoffman]

At 1:46 PM -0800 12/24/08, Nelson B Bolyard wrote:
>Paul Hoffman wrote, On 2008-12-24 09:55:
> > - Remove all trust anchors one-by-one
>> - Add your single trust anchor
>> - Sign the certs of any CA you want
>> - Add those signed certs to the pre-loaded validation path (not root)
> > cert list
>
>Of course, that is COMPLETELY equivalent to simply setting trust flags on
>the CA certs you want to trust, and removing those flags from the ones you
>don't want to trust, which is already a part of Mozilla browsers (and
>Netscape browsers, before them) for over 14 years.

Not "COMPLETELY", but close. What I proposed has a signature at the top of the 
hierarchy, which is what I thought that Kyle was asking for. The result is 
completely equivalent, but the format is slightly different.

Of course, it is much easier for the people on this list to Insist With 
Exclamation Marks! that Mozilla fix this for them instead of them doing it 
themselves, but that problem is at different layer.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

[Paul Hoffman]

At 11:35 AM -0800 12/24/08, Kyle Hamilton wrote:
>In the terminology of ASN.1 and PKIX, I want a standardized PKIX
>extension that allows for a SEQUENCE OF Certificate within the
>tbsCertificate structure.

That makes no sense to me, but I would have to see a complete proposal to 
understand why you would want that.

>I'm trying to figure out how I'm supposed to extract all the
>certificates from my database without any version of keytool that I
>can find available for OSX 10.5 (Leopard).

That's a completely different problem, of course.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

[sayrer]

On Dec 23, 10:33 pm, Paul Hoffman  wrote:
> At 1:16 AM +0200 12/24/08, Eddy Nigg wrote:
>
> >Select Preferences -> Advanced -> View Certificates -> Authorities. Search 
> >for AddTrust AB -> AddTrust External CA Root and click "Edit". Remove all 
> >Flags.
>
> Put more rudely, why do you expect Daddy to fix it for you when you can fix 
> it yourself, more easily and more quickly, if you want to?

Mozilla is in the business of protecting all users, not just those
with sysadmin levels of skill. I'm not advocating drastic action with
the Comodo roots, but a workarounds of this sort are probably not
distinguishable from total failure when the entire user base is taken
into account.

The truth is that we are basically unable to act without a lot of
collateral damage. We should keep this in mind with future security
technology. Relying on companies willing to take money for doing
absolutely nothing (not even the bare minimum they agreed to) is not a
pleasant thing to do to our users. We didn't learn this lesson with
EV--maybe next time! :)

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

Re: JSS doesn't support AES key unwrapping

[Nelson B Bolyard]

alex.agra...@gmail.com wrote, On 2008-12-24 11:32:
>> oh?  This is the first report of this problem that I recall seeing.
> 
> Here is a similar report that I was referring to:
> http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/01028c36412d94bf

Hmm.  That message never received any replies.  Maybe our JSS guru was
on vacation that week. (?)  Thanks for pointing that out.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

[Nelson B Bolyard]

Kyle Hamilton wrote, On 2008-12-24 14:53:
> On Wed, Dec 24, 2008 at 2:46 PM, Eddy Nigg  wrote:
>> On 12/25/2008 12:36 AM, Kyle Hamilton:
>>> To be honest, Mozilla doesn't distribute keytool with Firefox, which
>>> means that I have to try to go into the (unbatchable) interface and
>>> remove the flags one. by. one. by. one. and then select the next
>>> certificate and remove those trust flags, and the next, and the next,
>>> and the next...

What is the relevance of keytool here?
The tool relevant to NSS is certutil.  It is scriptable.
It's quite possible to write scripts to use certutil to do mass trust
modification.  I've done it.  But there's probably a much easier way
than that.

>> Kyle, why don't you blow that libnssckbi away from your Firefox
>> installation? Would make it easier I think. (Hope I picked the right one ;-)
>> )
> 
> Primarily because I want those certs on one profile, but not another,
> and disk space is kind of at a premium right now. :)
> 
> (Oh yeah, if one person who uses a computer doesn't want the built-in
> roots, but another does, they have to have separate Firefox
> installations.)

No, it is possible to accommodate both with a single installation.
There are several ways to do it.  Here's one.
Move the nssckbi file from the Firefox code directory where it normally
lives to the profile directory (where the cert8.db file lives) for the
user profile that wants to use it.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: dispute resolution procedures for Mozilla CA module

[Nelson B Bolyard]

Kyle Hamilton wrote, On 2008-12-24 14:42:

> Thanks for the explanation.
> 
> I do agree that the separation of responsibility would be good, since
> Frank (appears to?) does the actual CA approval 

Yes

> and you appear to be the one primarily who implements his directives as
> regards the updates to nssckbi?

I did it at one time.  Presently, and for the last year or more, keeping
nssckbi up to date with Frank's list has been done by Kai Engert who
also works on PSM, the browser component that interfaces to NSS.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

[Kyle Hamilton]

On Wed, Dec 24, 2008 at 2:46 PM, Eddy Nigg  wrote:
> On 12/25/2008 12:36 AM, Kyle Hamilton:
>>
>> To be honest, Mozilla doesn't distribute keytool with Firefox, which
>> means that I have to try to go into the (unbatchable) interface and
>> remove the flags one. by. one. by. one. and then select the next
>> certificate and remove those trust flags, and the next, and the next,
>> and the next...
>
> Kyle, why don't you blow that libnssckbi away from your Firefox
> installation? Would make it easier I think. (Hope I picked the right one ;-)
> )

Primarily because I want those certs on one profile, but not another,
and disk space is kind of at a premium right now. :)

(Oh yeah, if one person who uses a computer doesn't want the built-in
roots, but another does, they have to have separate Firefox
installations.)

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

Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation

[Eddy Nigg]

On 12/25/2008 12:40 AM, Nelson B Bolyard:

The answer is not that simple.  The cited wiki page explains PKCS#10
Certificate Signing Requests (CSRs).  CSRs are ONE way in which
certificates can be requested from a CA after generating a key pair,
but they are not the only way.  IIRC, FF implements two other ways,
and one of those ways may include private key "escrow" capability.

I think the relevant questions are:
a) which of Firefox's methods does Thawte use to cause Firefox to generate
a key pair and request a certificate?
b) Is there any way for a Firefox user to detect that his CA has requested
private key escrow?
c) When requesting a certificate from a CA, what can a Firefox user do to
prevent escrowing the newly generated private key?

I think the answers to these questions will likely not be available until
next month.


I think Thawte uses the keygen tag as well. This is a signed public key 
and challenge (SPKAC).


--
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: Unbelievable!

[Eddy Nigg]

On 12/25/2008 12:36 AM, Kyle Hamilton:

To be honest, Mozilla doesn't distribute keytool with Firefox, which
means that I have to try to go into the (unbatchable) interface and
remove the flags one. by. one. by. one. and then select the next
certificate and remove those trust flags, and the next, and the next,
and the next...


Kyle, why don't you blow that libnssckbi away from your Firefox 
installation? Would make it easier I think. (Hope I picked the right one 
;-) )


--
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: dispute resolution procedures for Mozilla CA module

[Kyle Hamilton]

On Wed, Dec 24, 2008 at 1:42 PM, Nelson B Bolyard  wrote:
> Kyle Hamilton wrote, On 2008-12-23 21:20:
>> On Tue, Dec 23, 2008 at 6:16 PM, Nelson B Bolyard  wrote:
>>> Anyway, I would support the creation of a "CA certificate" non-code module.
>>
>> I think this would be a really good idea.  I'm aware that my opinion
>> carries little weight, but I think that since it relies on business-
>> and legal-side undertakings, it shouldn't be managed by the coders.
>>
>> How would this work?  Split nssckbi out to be managed by the non-code
>> module owner, though a coder would need to be enlisted to finalize the
>> decisions made by that person?
>
> No, it would be a NON-CODE module.  It would not contain any code.
> Its output would be the list of trusted root certs, perhaps as a web page,
> and/or also as a set of requests (in the form of Bugzilla bugs) to have
> certs inserted into nssckbi.
>
> nssckbi is just a medium for the conveyance of that list, potentially one
> of several.  The task for the NSS module owner would be to ensure that
> the copy of the list in nssckbi is kept reasonably up to date, and doesn't
> differ from the official list (or a very recent version of that list) as of
> the date on which it is released.
>
> That's really how things operate now.  I'm merely suggesting that that
> separation of responsibility be formalized by making the maintenance of
> the official CA list be a separate "module".

Thanks for the explanation.

I do agree that the separation of responsibility would be good, since
Frank (appears to?) does the actual CA approval and you appear to be
the one primarily who implements his directives as regards the updates
to nssckbi?

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

Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation

[Nelson B Bolyard]

Kyle Hamilton wrote, On 2008-12-24 13:49:
> Firefox does not send any private key.
> http://en.wikipedia.org/wiki/Certificate_signing_request provides a
> very good overview of what it does.

The answer is not that simple.  The cited wiki page explains PKCS#10
Certificate Signing Requests (CSRs).  CSRs are ONE way in which
certificates can be requested from a CA after generating a key pair,
but they are not the only way.  IIRC, FF implements two other ways,
and one of those ways may include private key "escrow" capability.

I think the relevant questions are:
a) which of Firefox's methods does Thawte use to cause Firefox to generate
a key pair and request a certificate?
b) Is there any way for a Firefox user to detect that his CA has requested
private key escrow?
c) When requesting a certificate from a CA, what can a Firefox user do to
prevent escrowing the newly generated private key?

I think the answers to these questions will likely not be available until
next month.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

[Kyle Hamilton]

I'm also going to state that yes, I know this, because I HAVE DONE IT.
 And I wouldn't wish that hell on anyone who didn't have a DETAILED
knowledge of how the X.509 model operates, and I wouldn't wish the
user-interface hell on ANYONE.

-Kyle H

On Wed, Dec 24, 2008 at 2:36 PM, Kyle Hamilton  wrote:
> On Wed, Dec 24, 2008 at 1:46 PM, Nelson B Bolyard  wrote:
>> Of course, that is COMPLETELY equivalent to simply setting trust flags on
>> the CA certs you want to trust, and removing those flags from the ones you
>> don't want to trust, which is already a part of Mozilla browsers (and
>> Netscape browsers, before them) for over 14 years.
>
> To be honest, Mozilla doesn't distribute keytool with Firefox, which
> means that I have to try to go into the (unbatchable) interface and
> remove the flags one. by. one. by. one. and then select the next
> certificate and remove those trust flags, and the next, and the next,
> and the next...
>
> ...for all hundred or so certs that Firefox includes.
>
> And then, once I DO manage to do that, then with the "new and
> improved" user interface updates, I then have to click at least six
> times to try to figure out what's going on, and then when I do find a
> site that's protected by an unknown CA certificate (OR that I've
> removed the trust bits on), I have to do the following:
>
> 1) Click 'add an exception'
> 2) click 'get certificate' (why I should have to do this is beyond me,
> since firefox obviously already has the certificate downloaded since
> it told me 'sec_error_untrusted_issuer', which it couldn't have known
> without the certificate in its possession ANYWAY)
> 3) click 'view'
> 4) get the name of the Issuer
> 5) hope to all the gods that there's enough information in the chain
> to figure out what root it's supposed to be going to
> 6) close the window
> 7) go into Preferences
> 8) click Advanced
> 9) click Encryption
> 10) click 'View Certificates'
> 11) Scroll through the list, with each click giving me approximately
> 0.6 useful results (given the preponderance of 'section headings by
> root owner', which by the way doesn't work at all with the Addtrust AB
> stuff since those are Comodo roots)
> 12) find the appropriate root and re-enable it for identification of websites
> 13) refresh the page.
>
> How 'bout this, Nelson (and I invite Frank and the entire security UI
> team to do this, as well): YOU do it.  Create a new profile and
> manually remove the trust on every CA.  Then, browse around, and see
> which CAs are actually used by you in your day-to-day browsing,
> reenabling them manually (since you're trying to emulate not having
> keytool around).
>
> Furthermore, even when keytool IS available, it's entirely likely that
> its name conflicts with Java's keytool.  (especially on Mac OSX.)
>
> This is completely unworkable, and discourages users that want to from
> taking their security into their own hands.
>
> -Kyle H
>
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

[Kyle Hamilton]

On Wed, Dec 24, 2008 at 1:46 PM, Nelson B Bolyard  wrote:
> Paul Hoffman wrote, On 2008-12-24 09:55:
>> At 9:14 AM -0800 12/24/08, Kyle Hamilton wrote:
>>> I'd like to see an extension that allows other certificates (for the
>>> same public key) to be included in a certificate (self-signed or not).
>>
>> Are you asking for a Mozilla extension or a PKIX extension? If the
>> latter, none is needed: it is already inherent in PKIX. In fact, I am not
>> sure that anything needs to be done by Mozilla. The following should
>> theoretically work:
>>
>> - Remove all trust anchors one-by-one
>> - Add your single trust anchor
>> - Sign the certs of any CA you want
>> - Add those signed certs to the pre-loaded validation path (not root)
>> cert list
>>
>> I haven't tried this myself, but it should work. I have been told that
>> something very similar to it works fine in XP/Vista for IE.
>
> Of course, that is COMPLETELY equivalent to simply setting trust flags on
> the CA certs you want to trust, and removing those flags from the ones you
> don't want to trust, which is already a part of Mozilla browsers (and
> Netscape browsers, before them) for over 14 years.

To be honest, Mozilla doesn't distribute keytool with Firefox, which
means that I have to try to go into the (unbatchable) interface and
remove the flags one. by. one. by. one. and then select the next
certificate and remove those trust flags, and the next, and the next,
and the next...

...for all hundred or so certs that Firefox includes.

And then, once I DO manage to do that, then with the "new and
improved" user interface updates, I then have to click at least six
times to try to figure out what's going on, and then when I do find a
site that's protected by an unknown CA certificate (OR that I've
removed the trust bits on), I have to do the following:

1) Click 'add an exception'
2) click 'get certificate' (why I should have to do this is beyond me,
since firefox obviously already has the certificate downloaded since
it told me 'sec_error_untrusted_issuer', which it couldn't have known
without the certificate in its possession ANYWAY)
3) click 'view'
4) get the name of the Issuer
5) hope to all the gods that there's enough information in the chain
to figure out what root it's supposed to be going to
6) close the window
7) go into Preferences
8) click Advanced
9) click Encryption
10) click 'View Certificates'
11) Scroll through the list, with each click giving me approximately
0.6 useful results (given the preponderance of 'section headings by
root owner', which by the way doesn't work at all with the Addtrust AB
stuff since those are Comodo roots)
12) find the appropriate root and re-enable it for identification of websites
13) refresh the page.

How 'bout this, Nelson (and I invite Frank and the entire security UI
team to do this, as well): YOU do it.  Create a new profile and
manually remove the trust on every CA.  Then, browse around, and see
which CAs are actually used by you in your day-to-day browsing,
reenabling them manually (since you're trying to emulate not having
keytool around).

Furthermore, even when keytool IS available, it's entirely likely that
its name conflicts with Java's keytool.  (especially on Mac OSX.)

This is completely unworkable, and discourages users that want to from
taking their security into their own hands.

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

Re: Unbelievable!

[Nelson B Bolyard]

Paul Hoffman wrote, On 2008-12-24 09:55:
> At 9:14 AM -0800 12/24/08, Kyle Hamilton wrote:
>> I'd like to see an extension that allows other certificates (for the
>> same public key) to be included in a certificate (self-signed or not).
> 
> Are you asking for a Mozilla extension or a PKIX extension? If the
> latter, none is needed: it is already inherent in PKIX. In fact, I am not
> sure that anything needs to be done by Mozilla. The following should
> theoretically work:
> 
> - Remove all trust anchors one-by-one
> - Add your single trust anchor
> - Sign the certs of any CA you want
> - Add those signed certs to the pre-loaded validation path (not root)
> cert list
> 
> I haven't tried this myself, but it should work. I have been told that
> something very similar to it works fine in XP/Vista for IE.

Of course, that is COMPLETELY equivalent to simply setting trust flags on
the CA certs you want to trust, and removing those flags from the ones you
don't want to trust, which is already a part of Mozilla browsers (and
Netscape browsers, before them) for over 14 years.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: dispute resolution procedures for Mozilla CA module

[Nelson B Bolyard]

Kyle Hamilton wrote, On 2008-12-23 21:20:
> On Tue, Dec 23, 2008 at 6:16 PM, Nelson B Bolyard  wrote:
>> Anyway, I would support the creation of a "CA certificate" non-code module.
> 
> I think this would be a really good idea.  I'm aware that my opinion
> carries little weight, but I think that since it relies on business-
> and legal-side undertakings, it shouldn't be managed by the coders.
> 
> How would this work?  Split nssckbi out to be managed by the non-code
> module owner, though a coder would need to be enlisted to finalize the
> decisions made by that person?

No, it would be a NON-CODE module.  It would not contain any code.
Its output would be the list of trusted root certs, perhaps as a web page,
and/or also as a set of requests (in the form of Bugzilla bugs) to have
certs inserted into nssckbi.

nssckbi is just a medium for the conveyance of that list, potentially one
of several.  The task for the NSS module owner would be to ensure that
the copy of the list in nssckbi is kept reasonably up to date, and doesn't
differ from the official list (or a very recent version of that list) as of
the date on which it is released.

That's really how things operate now.  I'm merely suggesting that that
separation of responsibility be formalized by making the maintenance of
the official CA list be a separate "module".
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation

[Kyle Hamilton]

Firefox does not send any private key.
http://en.wikipedia.org/wiki/Certificate_signing_request provides a
very good overview of what it does.

2008/12/24 Fost1954 :
> Dear Firefox Developers,
>
> I understand that this should be the right place to ask:
>
> Using Firefox we would like to generate Thawte X.509 E-Mail Certificates.
>
> When generating the Private/Public key pair using Firefox as well as
> requesting
> the certificate, we are logged in on the Thawte Website.
>
> Our security relevant question:
> Which data is transmitted to Thawte during the Private/Public key pair and
>
> certificate generation process using Firefox (and Thawte) ?
>
> Does Firefox send to Thawte any form of "private" key during this process,
> or
> not ?
>
> If the private key was transmitted to Thawte, in theory a Thawte staff
> member
>
> –would he gain access to the private key at thawte- could decrypt emails
> encrypted by us, or sign an email in our names …
>
> We would be happy to understand better the key and certificate generation
> process using Firefox (and Thawte), considering the security critical point
>
>
> mentioned above.
>
> Thank you in advance,
> Proud Firefox users
>
>
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
>
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Security-Critical Information (i.e. Private Key) transmitted by Firefox to CA (i.e. Thawte) during X.509 key/cert generation

[Fost1954]

Dear Firefox Developers,

I understand that this should be the right place to ask:

Using Firefox we would like to generate Thawte X.509 E-Mail Certificates.

When generating the Private/Public key pair using Firefox as well as requesting
the certificate, we are logged in on the Thawte Website.

*Our security relevant question:*
Which data is transmitted to Thawte during the Private/Public key pair and
certificate generation process using Firefox (and Thawte) ?

*Does Firefox send to Thawte any form of "private" key during this process, or
not ?*

If the private key was transmitted to Thawte, in theory a Thawte staff member
–would he gain access to the private key at thawte- could decrypt emails
encrypted by us, or sign an email in our names …

We would be happy to understand better the key and certificate generation
process using Firefox (and Thawte), considering the security critical point

mentioned above.

Thank you in advance,
Proud Firefox users
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: CA liability. was: Publishing CA information documents in PDF format

[Nelson B Bolyard]

Kyle Hamilton wrote, On 2008-12-24 08:39:
> On Wed, Dec 24, 2008 at 4:25 AM, Ian G  wrote:
>> PS: on an earlier comment, check this out:
>>
>> http://blogs.technet.com/mmpc/archive/2008/11/06/malware-and-signed-code.aspx
>>
>> This is, IMHO, the sort of work that Mozilla should be treating as more
>> important than today's case, because it evidences PRESENT danger.
> 
> "In most cases, CAs participating in the Microsoft Root Certificate
> Program issue code signing certificates to a software publisher who
> uses the certificate to sign malware. [...] In most cases, CAs
> participating in the Microsoft Root certificate program are tricked
> into issuing a valid certificate to the malware author."
> 
> Uhm... how is it "being tricked" to issue a code signing certificate
> to a malware author, if the malware author proves his bona fides, and
> it's issued in the name of the malware author?

Microsoft defines two set of requirements to which an author must agree as
a condition of receiving a code signing certificate (one set for individual
authors and one set for corporate publishers).  See MS's statement about
this at
http://msdn.microsoft.com/en-us/library/ms537361(VS.85).aspx#Criteria_for_Commerc
http://msdn.microsoft.com/en-us/library/ms537361(VS.85).aspx#Criteria_for_Individ

These are requirements to be enforced by the issuer.  The issuer CA is
required to enforce those requirements by its agreement with Microsoft,
which (as I understand it) is a condition of being recognized as a code
signing CA by MS software.

In both sets of criteria, the authors/publishers must agree "that they will
not distribute software that they know, or should have known, contains
viruses or would otherwise harm a user's computer or code."

(Oddly, that definition seems to exclude harm to the user's data.  It also
seems to exclude key loggers or other malware that would harm the user
without harming his computer [no smoke] or its code.)

So, from MS's perspective, if some malware is signed with a cert issued by
one of the CAs that MS has added to their trusted code signing CA list,
then it must be the case that (at least) one of the following has
occurred:
- The software publisher did not know that it was signing malware, or
- The software publisher breached its agreement with the issuer of its
cert, or
- The issuer breached its agreement with MS.

It appears that the author of the page you cited chose to describe the
breach of the publisher's agreement with the issuer as the publisher
having tricked the issuer into issuing the certificate.  That choice of
words seems to imply that the publisher had intent to publish malware at the
time he applied to receive the certificate.  I think MS is saying that
they believe that, in most cases, that's what happened; the publisher
of the malware sought to obtain the cert expressly to publish signed
malware.

I don't recall Mozilla's CA policy having any provisions requiring code
signing CAs to require any pledge against signing malware. :(
Maybe that's Ian's point.

But I also observe that Mozilla's community of browser developers mostly
wish to avoid code signing.  The perception that code signing certs are
prohibitively expensive is, once again, the issue.  Consequently,

- Mozilla does not require that code be signed in a way that identifies
the signer as a condition of publishing browser extensions on
addons.mozilla.org.  Instead, they have devised a scheme that attempts to
ensure that any automatic updates to an extension come from the same
(potentially anonymous) source as the original extension, through the use
of anonymous public keys embedded in the original extension.

- A Firefox user sees almost no distinct UI behavior between downloading an
unsigned extension vs a signed one.  AFAIK, the ONLY difference is the
appearance of the word "unsigned" in red letters in the dialog box that asks
the user whether to go ahead with the installation.  That dialog always
appears, for signed and unsigned extension downloads, and there are
no additional hurdles to installing unsigned downloads.

- Until recently, web pages whose javascript wanted to take special
privileged actions needed to be signed pages, but that requirement is being
(or has been) removed, IINM.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

[John Nagle]

   As a user of SSL certificates in our SiteTruth system, which
attempts to identify and rate the business behind a web site, we're
concerned about CA reliability and trust.  We've been using Mozilla's
approved root cert list for our system, and are considering whether
we should continue to do so.  Given the situation described in

"http://markmail.org/message/rje3lssql55l2rev?q=unbelievable";

the use of Mozila's root CA list is now questionable.

   There seem to be several problems here.

   1.   AddTrust, a company which apparently no longer exists, has an approved
root CA certificate.  This in itself is troublesome.  Comodo does
not seem to have taken on the obligations of AddTrust; see
"http://markmail.org/message/3zr4e5hxwmxjbgnp?q=Comodo+AddTrust";.
Yet Comodo is still issuing certificates under the root CA of
this dead company.

   2.   Comodo is apparently not only allowing resellers like CertStar,
but is allowing them to do their own validation of the legitimacy
of the certificate requestor.  Who takes financial responsibility
for such errors?  CertStar itself disclaims financial responsibility
at "http://www.certstar.com/terms.html";.

   3.   Microsoft requires an annual audit for root CAs:
"http://technet.microsoft.com/en-us/library/cc751157.aspx";.
Mozilla seems willing to accept a one-time audit.  That seems
to be why the disappearance of AddTrust wasn't noticed.
Microsoft's audit requirements extend all the way down the
chain of trust.  Their policy is:
"The CA must complete an audit and submit audit results to Microsoft
every twelve (12) months. The Audit must cover the full PKI hierarchy
that will be enabled by Microsoft through the assignment of Extended
Key Usages (EKUs). All certificate usages that we enable must be
audited periodically. The audit report must document the full scope
of the PKI hierarchy including any sub-CA that issues a specific type
of certificate covered by an audit."  Microsoft uses the standards of
the WebTrust Program for Certification Authorities
("http://www.cica.ca/download.cfm?ci_id=45239&la_id=1&re_id=0";)
managed by the Canadian Society of Chartered Accountants.  That's
a good guideline for Mozilla to follow.

At this point, I would suggest that the following actions are appropriate
to bring Comodo and Mozilla into compliance with the WebTrust standards:

   1.   Comodo must undergo an audit to WebTrust standards, and the audit
report must be published. An in-house self-investigation is not
acceptable. The audit must be conducted by a recognized outside
auditing firm.
   2.   CertStar must separately undergo an audit to WebTrust standards,
and the audit report must be published.  An in-house
self-investigation is not acceptable. The audit must be conducted
by a recognized outside auditing firm.  CertStar should not be
permitted to issue any new certificates until this process is
complete and the audit results are satisfactory.  If this process
is not complete within 3 months, all CertStar-issued certificates
should be revoked.
   3.   Comodo must disclose the identities of all "resellers" to which
it has outsourced any validation functions.
   4.   All AddTrust root CA certificates must be phased out.  An
expiration date in Q1 or Q2 2009 is suggested.  Since no company
stands behind the AddTrust name, it's necessary to force expiration
of that root.
   5.   The Mozilla Foundation should contact Microsoft's CA Root Certificate
group to coordinate their actions.

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

Re: Unbelievable!

[Kyle Hamilton]

In the terminology of ASN.1 and PKIX, I want a standardized PKIX
extension that allows for a SEQUENCE OF Certificate within the
tbsCertificate structure.

I'm trying to figure out how I'm supposed to extract all the
certificates from my database without any version of keytool that I
can find available for OSX 10.5 (Leopard).

-Kyle H

On Wed, Dec 24, 2008 at 9:55 AM, Paul Hoffman  wrote:
> At 9:14 AM -0800 12/24/08, Kyle Hamilton wrote:
>>I'd like to see an extension that allows other certificates (for the
>>same public key) to be included in a certificate (self-signed or not).
>
> Are you asking for a Mozilla extension or a PKIX extension? If the latter, 
> none is needed: it is already inherent in PKIX. In fact, I am not sure that 
> anything needs to be done by Mozilla. The following should theoretically work:
>
> - Remove all trust anchors one-by-one
> - Add your single trust anchor
> - Sign the certs of any CA you want
> - Add those signed certs to the pre-loaded validation path (not root) cert 
> list
>
> I haven't tried this myself, but it should work. I have been told that 
> something very similar to it works fine in XP/Vista for IE.
>
> --Paul Hoffman
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: JSS doesn't support AES key unwrapping

[alex . agranov]

> oh?  This is the first report of this problem that I recall seeing.

Here is a similar report that I was referring to:
http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/01028c36412d94bf
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

[Kyle Hamilton]

On Tue, Dec 23, 2008 at 5:14 AM, Frank Hecker
 wrote:
> Eddy Nigg wrote:
>>
>> Disabling the trust bits of "AddTrust External CA Root" could be a
>> temporary measure to prevent damage to relying parties until Mozilla
>> receives full report and disclosure from Comodo about its resellers and
>> conclusion of their investigation.
>
> Do you mean the UTN-UserFirst-Hardware root? According to the screenshot on
> your blog post, that's the root the bogus cert chains up to. Also, if we
> were to take action of this general sort (as a hypothetical), what about
> adding the PositiveSSL CA cert to NSS with the SSL trust bit disabled;
> wouldn't that accomplish the same purpose, without interfering with other
> parts of the hierarchy under the UTN-UserFirst-Hardware root? (I seem to
> recall we've discussed this sort of thing in the past.)

What is the effect of this problem on the request to enable the
UTN-UserFirst-Hardware root for EV,
https://bugzilla.mozilla.org/show_bug.cgi?id=401587 ?

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

Re: Facts about Comodo Resellers and RAs

[Eddy Nigg]

On 12/24/2008 08:14 PM, Paul C. Bryan:

Eddy: I personally believe you are working for the good of the PKI
infrastructure, but you have to see that being a competitor to Comodo
puts you in a perceived conflict of interest here. Is there no one you
could put your contact(s) in touch with that is in a more neutral
position to evaluate this issue and inform the community?


Paul, I have been active here for some time already. I'm providing my 
knowledge and experience to Mozilla and the community, which might be 
specially interesting, because I know more than many. I see the 
potential issues from various different sides. I have maintained my 
loyalty to Mozilla which doesn't have to be in conflict with any other 
interests I may have. And my interest is to maintain an even level of 
PKI security in the browser for the good of all of us.


Having said that, neither myself nor the company I run have gained 
financially from this - currently it seems that all CAs have taken 
damage. Reckless behavior is ruining our businesses, the trust we try to 
build and the strengthening of Internet security at large is put into 
jeopardy. It is my duty to prevent that if possible.


There is no conflict of interest even if the result of my involvement 
would put a competitor out of business - it's their failure not mine. 
And with it, they risk the reputation and security of Mozilla and all 
relying parties which depend on it.


Unfortunately many others which are in the known haven't come forward 
for unknown reasons. I'd be more than glad if they did. But would you 
prefer if I'd put a middle-man in front of myself? Would you prefer that 
I've sorted it out with Comodo directly? The personal gain could have 
been much higher perhaps.


Rest be assured, that not I'm making any final decisions at Mozilla. 
Frank Hecker who is currently responsible, knows me well enough and has 
the knowledge about this subject. He will make the ultimate decision 
about which actions to take. In this specific case I'm the messenger and 
reporter, but also others have already made their call for action here 
at dev.tech.crypto.


At last, this and other issues concerns all of us - many million users 
depend on the work we are doing here and elsewhere. I have nothing to 
hide, I openly disclose my affiliation (see my signature) upfront. I 
always did. I'm active and involved at different open source and open 
standards projects, maintain connection with major organizations 
throughout the world. I'm certain that my contributions and expertise 
are usually valued.


Thank you for your time!

--
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: Unbelievable!

[Paul Hoffman]

At 9:14 AM -0800 12/24/08, Kyle Hamilton wrote:
>I'd like to see an extension that allows other certificates (for the
>same public key) to be included in a certificate (self-signed or not).

Are you asking for a Mozilla extension or a PKIX extension? If the latter, none 
is needed: it is already inherent in PKIX. In fact, I am not sure that anything 
needs to be done by Mozilla. The following should theoretically work:

- Remove all trust anchors one-by-one
- Add your single trust anchor
- Sign the certs of any CA you want
- Add those signed certs to the pre-loaded validation path (not root) cert list

I haven't tried this myself, but it should work. I have been told that 
something very similar to it works fine in XP/Vista for IE.

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

Re: Unbelievable!

[Kyle Hamilton]

On Wed, Dec 24, 2008 at 6:17 AM, Frank Hecker
 wrote:
> Gen Kanai wrote:
>>
>> More discussion on this topic over at Programming Reddit:
>>
>>
>> http://www.reddit.com/r/programming/comments/7lb96/ssl_certificate_for_mozillacom_issued_without/
>
> Unfortunately the discussion devolved (as it always does :-) into the merits
> of self-signed certificates. Oh well.
>
> Frank

Honestly, I get more mileage out of doing my own diligence.  This is
why I want to have my own root certificate that I can cross-sign the
various commercial CA certificates with, so that I can revoke those
cross-signatures if they turn out to have a problem.

I'd like to see an extension that allows other certificates (for the
same public key) to be included in a certificate (self-signed or not).
 This would protect against one of the threats against the OpenPGP
model, would create a means for certifications to be cherry-picked for
any given application, and would allow other identities for that
public key to be added by the identity collector -- but would also
create a linkage back to the identity collector's public key.
(realistically, the only reason for the signature on an external
certificate that contains an extension like this would be because no
X.509 software handles the TBSCertificate structure without the
signature.)

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

Re: CA liability. was: Publishing CA information documents in PDF format

[Kyle Hamilton]

On Wed, Dec 24, 2008 at 4:25 AM, Ian G  wrote:
> PS: on an earlier comment, check this out:
>
> http://blogs.technet.com/mmpc/archive/2008/11/06/malware-and-signed-code.aspx
>
> This is, IMHO, the sort of work that Mozilla should be treating as more
> important than today's case, because it evidences PRESENT danger.

"In most cases, CAs participating in the Microsoft Root Certificate
Program issue code signing certificates to a software publisher who
uses the certificate to sign malware. [...] In most cases, CAs
participating in the Microsoft Root certificate program are tricked
into issuing a valid certificate to the malware author."

Uhm... how is it "being tricked" to issue a code signing certificate
to a malware author, if the malware author proves his bona fides, and
it's issued in the name of the malware author?

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

Re: CA liability. was: Publishing CA information documents in PDF format

[David E. Ross]

On 12/24/2008 3:36 AM, Ian G wrote:
> Hi David,
> 
> On 24/12/08 02:23, David E. Ross wrote:
> {long diatribe by iang on liability snipped}
> 
>> See the thread "Unbelievable" in this newsgroup.
>>
>> Now we have the situation in which Comodo allowed third-party CAs under
>> its root to issue site certificates without proper authentication of the
>> subscribers (e.g., whether they actually owned the domain).  Apparently,
>> Comodo failed to enforce its own CP/CPS with regard to the operation of
>> external CAs for which Comodo signed their intermediate certificates.
> 
> 
> That might be how it ends up being stated, sure.
> 
> 
>> It is known that bogus site certificates did indeed result (at least for
>> testing to determine if the situation was really happening).
> 
> Right, tested as possible, 2 certs.
> 
>> Now, what is Comodo's liability to consumers if any of those consumers
>> were defrauded through this situation?  I too am not an attorney.
> 
> 
> None of us are attorneys, it seems.
> 
> I would expect that Comodo would say that their RPA sets the scene, the 
> baseline.  I found this:
> 
> http://www.comodo.com/repository/
> http://www.comodo.com/repository/docs/relying_party.html
> 
> Now, this might not be the right doc.  But, let's assume it is, for 
> discussion purposes.  In section 11, it says, rather cumbersomely:
> 
> 
> 11.2 Subject to clause 11.1, Comodo shall not be liable to the Relying 
> Party whether in contract (including under any indemnity or warranty), 
> in tort (including negligence), under statute or otherwise for any loss 
> of profit, loss of revenue, loss of anticipated savings, loss or 
> corruption of data, loss of contract or opportunity or loss of goodwill 
> whether that loss is direct, indirect or consequential and if Comodo 
> shall be liable to the Relying Party in contract (including under any 
> indemnity or warranty), in tort (including negligence), under statute or 
> otherwise, Comodo's maximum liability to the Relying Party for SSL 
> Certificates shall be limited to
> 
> 11.2.1 $0.01 for a TrialSSL Certificate, and
> 
> 11.2.2 $50 for an InstantSSL Certificate, and
> 
> 11.2.3 $2500 for an InstantSSL Pro Certificate, and
> 
> 11.2.4 $10,000 for a PremiumSSL Certificate and PremiumSSL Wildcard 
> Certificate, and
> 
> 
> Amongst other things  If I read this right, it says in simple terms:
> 
>  *CA is not liable*.  For anything we can think of.
> 
>  And, if it is found liable (by a court?), the following applies
>$0.01 for a Trial, and
>$50 for an InstantSSL , and
>$2500 for a Pro, and
>$10,000 for a Premium, and...
> 
> (Yeah, I heavily edited that for readability and to make my point.)
> 
> 
> 
>> However, it seems to me that any denial of liability by Comodo might be
>> nullified by its failure to enforce its publish policies.
> 
> 
> This is one of those really difficult questions that can only be 
> answered in a real court case.  Which has never happened.  All we can 
> do, as armchair generals, is express opinions as to our current 
> understanding of how that court case might unfold.
> 
> 
> 
> My opinion is that it would be tough.  Pointwise:
> 
> 1. The RPA document is clear enough, and the user hasn't got much of 
> anything else as a document.  1.b  I would be surprised if the CPS added 
> anything of benefit to the user, although I haven't looked.  1.c  the 
> RPA does not say liability is higher if the CA mucks up, however expressed.
> 
> 2. The user would have to claim that there was another agreement or 
> understanding than the above, that has some standing.
> 
> 3. As the user hasn't paid anything, the user's standing is not strong.
> 
> 4.  Nobody else is standing up and saying that liability exists.
> 
> 4.b  Case in point: EV sets minimum liability limits of $2k when the CA 
> mucks up (only).  For EV.  This isn't EV, so we can conclude:  almost 
> certainly less, probably zero, because of the context of EV.  The 
> parties who wrote EV will say that EV Guidelines is the combined wisdom 
> of all the important parties;  so that document is likely to impress the 
> court as to industry understanding.
> 
> 
> 5.  What we do have is a sort of general understanding that "certs are 
> trusted."
> 
> But this means by itself means little in a court, the end-user would 
> have to present to the court why this is worth something.  I am told 
> (which means I don't really understand) that the relevant doctrine is 
> "duty of care."  Which is to say, we are hoping here that a CA has a 
> duty of care, and that the court recognises that.  But this has never 
> been tried in a court, so the user has to make this case all by herself.
> 
> Which would be fine, if it were the case, but today's case does not 
> support the existence of a duty of care.  5.a The RPA doesn't support 
> it.  5.b No other RPA I have read accepts it.  CAs are more or less 
> unifi

Facts about Comodo Resellers and RAs

[Eddy Nigg]

...as the story unfolds in front of us just before the holiday season, 
I'm going to provide more information and try to summarize the recent 
event(s). Nevertheless I wish to everybody happy Hanukkah and Xmas.


Hereby the facts about Comodo and recent events:

- Registration Authority (RA) of Comodo operates a robot to search for 
SSL secured sites.
- Same RA sends email messages to the owners of those sites, by 
pretending that the site owner has to renew the certificate with them 
(spam + misleading).

- Same RA ignores complaints, so does Comodo (at least initially).
- Same RA issues domain control validated certificates without validating.
- Comodo fails to have sufficient controls in place to prevent such 
issuance.
- Comodo fails to have controls in place to prevent issuance of 
high-profile targets (like Mozilla, Microsoft, Paypal, etc.)
- Comodo fails to (self) audit the facilities of the RA and its 
implementations.

- Comodo maintains many RAs and Resellers.

Additionally I received testimonials and evidences [1] that resellers 
(apparently mainly hosting providers) don't use a central domain 
validation utility or checks, instead there is a confirmation checkbox. 
Comodo delays the issuance of some of the certificates which it receives 
from resellers. According to the testimonial, they compare the data 
submitted with the WHOIS records on these spot checks. No email ping or 
web site modification check is performed to retain evidence about domain 
control by the requesting party (or authorization thereof). With this we 
can assume that


- Comodo does not perform domain control validation.
- Comodo has not sufficient controls in place to prevent issuance of 
fraudulent certificates by resellers and RAs.
- Comodo issued unvalidated server certificates (according to their own 
accounts and myself). Such certificates may be still valid and in the wild.

- Comodo fails to conform to the Mozilla CA Policy in various accounts.

I have received also testimonials that Mozilla and Microsoft received 
previously complaints and evidences about the business practices of 
Comodo. I'm not aware which specific actions were taken back then. 
However I'm quoting Frank Hecker's summary after the "inclusion" 
discussion of Comodo from April 08,


"...discussions around various Comodo-related issues, most notably the
wildcard DV cert issue and the long-lived DV cert issue. Although I
acknowledge that there were/are valid concerns associated with those
issues...",

which were concerns raised by myself back then. Unfortunately the 
failures by Comodo listed above and their issuance policy for 
long-living low-assurance and wild card certificates makes it even 
worse. In light of the recent events and in light of the collective 
potential damage to all certification authorities which those events may 
have caused, and in light of the potential damage to relying parties, I 
request immediate and appropriate actions by Mozilla and other browser 
vendors. I also request from Comodo to urgently review their practices, 
implementations and controls in place and take appropriate actions.



[1] As I'm writing this mail, I'm receiving more evidences, testimonials 
and phone calls by people in the knowledge. I'll present all the 
material to Frank once he gets in touch with 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

Re: Unbelievable!

[Frank Hecker]

Eddy Nigg wrote:
My blog article and exposure has provoked somebody to come forward with 
additional evidences concerning the reseller activities of Comodo. In 
order to protect the innocent I decided to provide this information 
confidentially to Frank Hecker for now. Stay tuned.


To expand on what I wrote to Eddy via email, I really don't want to be 
dealing with information sent to me in confidence. I'm skeptical about 
dealing with reports where the originators of the reports aren't willing 
to go on public record with their complaints, especially when there are 
possibly mixed motives on the part of the person or organization 
reporting the problem. (For example, CAs reporting on either CAs, or 
resellers reporting on other resellers.)


Frank

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

Re: Unbelievable!

[Frank Hecker]

Gen Kanai wrote:

More discussion on this topic over at Programming Reddit:

http://www.reddit.com/r/programming/comments/7lb96/ssl_certificate_for_mozillacom_issued_without/ 


Unfortunately the discussion devolved (as it always does :-) into the 
merits of self-signed certificates. Oh well.


Frank

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

Re: CA liability. was: Publishing CA information documents in PDF format

[Ian G]

On 24/12/08 12:36, Ian G wrote:

Hi David,
I would expect that Comodo would say that their RPA sets the scene, the
baseline. I found this:

http://www.comodo.com/repository/
http://www.comodo.com/repository/docs/relying_party.html

Now, this might not be the right doc. But, let's assume it is, for
discussion purposes.


I was just about to close that page and discovered this:

http://www.comodo.com/repository/docs/SSL_relying_party_warranty.html

Which probably has some bearing on the question.  A quick look brings up 
lots of big numbers, and some cunning caveats (which possibly knocks 
Eddy out of any jackpot).


I've no time to read it all now, just to agree in advance that my 
earlier comments might be wrong!


iang

PS: on an earlier comment, check this out:

http://blogs.technet.com/mmpc/archive/2008/11/06/malware-and-signed-code.aspx

This is, IMHO, the sort of work that Mozilla should be treating as more 
important than today's case, because it evidences PRESENT danger.

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

Re: CA liability. was: Publishing CA information documents in PDF format

[Ian G]

Hi David,

On 24/12/08 02:23, David E. Ross wrote:
{long diatribe by iang on liability snipped}


See the thread "Unbelievable" in this newsgroup.

Now we have the situation in which Comodo allowed third-party CAs under
its root to issue site certificates without proper authentication of the
subscribers (e.g., whether they actually owned the domain).  Apparently,
Comodo failed to enforce its own CP/CPS with regard to the operation of
external CAs for which Comodo signed their intermediate certificates.



That might be how it ends up being stated, sure.



It is known that bogus site certificates did indeed result (at least for
testing to determine if the situation was really happening).


Right, tested as possible, 2 certs.


Now, what is Comodo's liability to consumers if any of those consumers
were defrauded through this situation?  I too am not an attorney.



None of us are attorneys, it seems.

I would expect that Comodo would say that their RPA sets the scene, the 
baseline.  I found this:


   http://www.comodo.com/repository/
   http://www.comodo.com/repository/docs/relying_party.html

Now, this might not be the right doc.  But, let's assume it is, for 
discussion purposes.  In section 11, it says, rather cumbersomely:



11.2 Subject to clause 11.1, Comodo shall not be liable to the Relying 
Party whether in contract (including under any indemnity or warranty), 
in tort (including negligence), under statute or otherwise for any loss 
of profit, loss of revenue, loss of anticipated savings, loss or 
corruption of data, loss of contract or opportunity or loss of goodwill 
whether that loss is direct, indirect or consequential and if Comodo 
shall be liable to the Relying Party in contract (including under any 
indemnity or warranty), in tort (including negligence), under statute or 
otherwise, Comodo's maximum liability to the Relying Party for SSL 
Certificates shall be limited to


11.2.1 $0.01 for a TrialSSL Certificate, and

11.2.2 $50 for an InstantSSL Certificate, and

11.2.3 $2500 for an InstantSSL Pro Certificate, and

11.2.4 $10,000 for a PremiumSSL Certificate and PremiumSSL Wildcard 
Certificate, and



Amongst other things  If I read this right, it says in simple terms:

*CA is not liable*.  For anything we can think of.

And, if it is found liable (by a court?), the following applies
  $0.01 for a Trial, and
  $50 for an InstantSSL , and
  $2500 for a Pro, and
  $10,000 for a Premium, and...

(Yeah, I heavily edited that for readability and to make my point.)




However, it seems to me that any denial of liability by Comodo might be
nullified by its failure to enforce its publish policies.



This is one of those really difficult questions that can only be 
answered in a real court case.  Which has never happened.  All we can 
do, as armchair generals, is express opinions as to our current 
understanding of how that court case might unfold.




My opinion is that it would be tough.  Pointwise:

1. The RPA document is clear enough, and the user hasn't got much of 
anything else as a document.  1.b  I would be surprised if the CPS added 
anything of benefit to the user, although I haven't looked.  1.c  the 
RPA does not say liability is higher if the CA mucks up, however expressed.


2. The user would have to claim that there was another agreement or 
understanding than the above, that has some standing.


3. As the user hasn't paid anything, the user's standing is not strong.

4.  Nobody else is standing up and saying that liability exists.

4.b  Case in point: EV sets minimum liability limits of $2k when the CA 
mucks up (only).  For EV.  This isn't EV, so we can conclude:  almost 
certainly less, probably zero, because of the context of EV.  The 
parties who wrote EV will say that EV Guidelines is the combined wisdom 
of all the important parties;  so that document is likely to impress the 
court as to industry understanding.



5.  What we do have is a sort of general understanding that "certs are 
trusted."


But this means by itself means little in a court, the end-user would 
have to present to the court why this is worth something.  I am told 
(which means I don't really understand) that the relevant doctrine is 
"duty of care."  Which is to say, we are hoping here that a CA has a 
duty of care, and that the court recognises that.  But this has never 
been tried in a court, so the user has to make this case all by herself.


Which would be fine, if it were the case, but today's case does not 
support the existence of a duty of care.  5.a The RPA doesn't support 
it.  5.b No other RPA I have read accepts it.  CAs are more or less 
unified in this, so we can likely expect the other CAs RPAs to be 
presented as evidence of a unified position.


5.c Mozo:  Nothing Mozilla says supports the existence of a duty of 
care;  they instead rely on their policy, the audit process and their 
own due diligence.


6.  The

Re: dispute resolution procedures for Mozilla CA module

[Ian G]

On 24/12/08 03:16, Nelson B Bolyard wrote:

Ian G wrote, On 2008-12-23 05:58:


3.  How to resolve a dispute.  This is a Mozilla action&
responsibility.  Reverse-engineering and referring, I would suggest this
as a teaser:

a.  The CA certificate "module owner" at Mozilla foundation is
responsible.  Ref, the policy, pt 15.
b.  The dispute is investigated and ruled on by module owner.


For there to be a "CA certificate module owner", there would have to be
a "CA certificate Module".  Presently, there is no such module.  Maybe
there should be.


I was searching for the role, and found that term in the policy, I 
think.  Mentally, I call it "the CA desk" and sometimes use that term. 
The earlier text had a term "CA Manager" which is a bit old-fashioned.


It's whatever it ends up being called, the point for me was "one person 
at Mozo who knows this stuff, decides!"



As you probably know, Mozilla now has "code modules"
and "non code modules".  I think the CA certificate module would be a
non-code module.  Yeah, ultimately whatever certs are accepted by Mozilla
do get stored in NSS, but the NSS developers just abide with Mozilla's
decisions about that.  There's only ever been one real disagreement
between Mozilla and NSS about root CA certs, and that was how the whole
process we have now got started.  Since then, it's been smooth sailing.
I expect it will continue to be that for a long time.

Anyway, I would support the creation of a "CA certificate" non-code module.



OK.



To address Frank's comment:

>> 4. Finality. ... In the policy, it says "... mozilla.org staff..."

> There is no longer a "mozilla.org staff" ...

(In which case, a policy change will be needed one day.)

I would let my comment stand.  The point here is that if the day-to-day 
manager is disputed, an immediate next-desk-warmer isn't going to help 
much.  Go for the top, hand it to the ultimate responsible party, the 
board.  The need here is to send a serious signal, short circuit the 
process, and avoid any additional layers of bureaucracy.




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