Philipp Dunkel | 1 Jan 01:13 2009

Happy New Year!!!


---
Philipp Dunkel
Tel: +43-720-407204
Fax: +43-1-3060903-9
---
Your reality and mine may not entirely coincide. Therefore you may not  
rely on this message meaning what you believe it means.
---

Ian G (Audit | 2 Jan 10:32 2009

[Fwd: CACert place in the world]

Question for the older guys:  Does anyone know when or where or why 
gmane.org was asked to not archive the lists of CAcert?

Is there any reason to believe that we shouldn't just write to them and 
tell them it is ok to archive the lists?

iang

-------- Original Message --------
Subject: CACert place in the world
Date: Thu, 01 Jan 2009 21:44:12 -0800
From: someone
To: Iang <iang@...>

Ian G wrote, On 2009-01-01 11:35:
> CAcert, the CA I
> audit, are like Mozilla, more aligned to open processes and slowly
> adopting a totally open model [2], and do not demand a WebTrust.

> [2] Some may dispute this, so an update / advocacy:  CAcert was a
> closed, confidential operation in the old days.  That has changed.  A
> big decision last 2007 was to make everything generally open.  All
> decisions are published.  Source is now under GPL.  Last month they were
> deciding to make even the private board mailing list open, and the same
> with sysadm lists.  It's slow, but it is happening.

Ian,
Please let me ask you some questions about all that.  I'm asking off 
list because I don't want to open the flood gates for another torrent of
discussion about CACert on Mozilla's dev-tech-crypto list.
(Continue reading)

Teus Hagen | 2 Jan 13:13 2009

Re: response to CCC CA attack paper?

DRAFT. Please comment so we can get this published by the PR cmtee.

There are two issues which got coverage in the press, raised last week
on certificates:
1. Server certificate bought on a CA and domain was not checked by the
Certificate Authority Remote Agent (CA RA).
2. Rogue certificate can be made when signature is based on MD5 checksum
signing algorithm.

On MD5: CAcert "Root CA"class 1 serial 00 self signed on 03/30/2003 as
well the later class 3 serial 01 self signed on 10/14/2005 have
signature based on MD5. However CAcert signs issued certificates based
on SHA-1 checksum from more as 2 years ago (max expiration date is 2
years for issued certificates).
(**** Please check if this info is correct. I did my check on this
statement by viewing my certs ****).
A certificate holder is advised to check with which algorithm his
certificate is checked: it should be with at least the SHA-1 algorithm.
The stronger SHA-2 algorithm is argued to be better but is not commonly
available or supported yet.

The CAcert Root certificates have been created before the report in
2004. In t2004 it was reported that it should be possible to create
information with an MD5 checksum that would be similar to a previous
defined MD5 checksum. In the end of 2008 a report showed a that this
(certificates were used in this exercise) could be practically be done.
Conclusion: issued certificates signed with the MD5 checksum algorithm
can eventually be forged and so can be considered harmful.

It is good to reread a statement of Bruce Schneier: "Any person can
(Continue reading)

guillaume romagny | 2 Jan 14:05 2009
Picon

Re: response to CCC CA attack paper?

Hi,

Teus Hagen a écrit :
> 
> On MD5: CAcert "Root CA"class 1 serial 00 self signed on 03/30/2003 as
> well the later class 3 serial 01 self signed on 10/14/2005 have
> signature based on MD5. 

Both root certs will never be included in any mainline browsers, so it
is not a big issue.

There is no cert expiration relieve : once the certificate is MD5
hashed, RSA signed by the class1 root cert, you can change any data in
the certificate, so you can make an old expired certificate looking
brand new (AFAIK).

The new root certificates are SHA1 hashed : we will need to replace the
subroot certificates when Mozilla & MS have added SHA-2 in mainline.

--

-- 
Cordialement, Best regards,
Guillaume
Tiebogos (by L'Oreal), parce que je le 'veau' bien.

Vision without action is a daydream.
Action without vision is a nightmare.  -- Japanese Proverb

Attachment (smime.p7s): application/x-pkcs7-signature, 4582 bytes
Robert Cruikshank | 2 Jan 12:28 2009
Picon

Re: [Fwd: CACert place in the world]

Unaware of why this would have been done. I have no issue with re- 
establishing it.

Regards
Rob

On 02/01/2009, at 8:32 PM, "Ian G (Audit)" <iang@...> wrote:

> Question for the older guys:  Does anyone know when or where or why  
> gmane.org was asked to not archive the lists of CAcert?
>
> Is there any reason to believe that we shouldn't just write to them  
> and tell them it is ok to archive the lists?
>
> iang
>
> -------- Original Message --------
> Subject: CACert place in the world
> Date: Thu, 01 Jan 2009 21:44:12 -0800
> From: someone
> To: Iang <iang@...>
>
> Ian G wrote, On 2009-01-01 11:35:
>> CAcert, the CA I
>> audit, are like Mozilla, more aligned to open processes and slowly
>> adopting a totally open model [2], and do not demand a WebTrust.
>
>> [2] Some may dispute this, so an update / advocacy:  CAcert was a
>> closed, confidential operation in the old days.  That has changed.  A
>> big decision last 2007 was to make everything generally open.  All
(Continue reading)

Philipp Guehring | 2 Jan 14:39 2009

Re: response to CCC CA attack paper?

Hi,
> Both root certs will never be included in any mainline browsers, so it
> is not a big issue.
>   
Well, there are a few million computers out there that have the CAcert
root certificate, but since the existing certificates aren't useable
with the current attack vector, this shouldn't be a problem.
The problem we have is our class 3 intermediate certificate, which is
using MD5, and is being warned about by the new extensions, since it
can't be differentiated from a rogue CA.
Our class1 root certificate is not a problem.
> There is no cert expiration relieve : once the certificate is MD5
> hashed, RSA signed by the class1 root cert, you can change any data in
> the certificate, so you can make an old expired certificate looking
> brand new (AFAIK).
>   
Not with the current attack, but potentially with strongly improved attacks.
As far as I know, there are no second-preimage attacks known against MD5
yet, so old certificates are safe for now.
I expect a complete breach of MD5 in 3-5 years, perhaps even much later.
> The new root certificates are SHA1 hashed : we will need to replace the
> subroot certificates when Mozilla & MS have added SHA-2 in mainline.
>   

Best regards,
Philipp Gühring

Teus Hagen | 2 Jan 14:49 2009

Re: [Fwd: CACert place in the world]

So who is writing them?
teus

On 01/02/2009 12:28 PM, Robert Cruikshank wrote:
> Unaware of why this would have been done. I have no issue with re- 
> establishing it.
>
> Regards
> Rob
>
>
> On 02/01/2009, at 8:32 PM, "Ian G (Audit)" <iang@...> wrote:
>
>   
>> Question for the older guys:  Does anyone know when or where or why  
>> gmane.org was asked to not archive the lists of CAcert?
>>
>> Is there any reason to believe that we shouldn't just write to them  
>> and tell them it is ok to archive the lists?
>>
>> iang
>>
>> -------- Original Message --------
>> Subject: CACert place in the world
>> Date: Thu, 01 Jan 2009 21:44:12 -0800
>> From: someone
>> To: Iang <iang@...>
>>
>> Ian G wrote, On 2009-01-01 11:35:
>>     
(Continue reading)

Ian G (Audit | 2 Jan 15:51 2009

Re: [Fwd: CACert place in the world]

Might be worth scanning this.

   http://gmane.org/faq.php

There are some questions to answer.  It looks like the list admin is 
considered the person, so you could ask Daniel to write them, once a 
decision in principle is made?

iang

On 2/1/09 14:49, Teus Hagen wrote:
> So who is writing them?
> teus
>
> On 01/02/2009 12:28 PM, Robert Cruikshank wrote:
>> Unaware of why this would have been done. I have no issue with re-
>> establishing it.
>>
>> Regards
>> Rob
>>
>>
>> On 02/01/2009, at 8:32 PM, "Ian G (Audit)"<iang@...>  wrote:
>>
>>
>>> Question for the older guys:  Does anyone know when or where or why
>>> gmane.org was asked to not archive the lists of CAcert?
>>>
>>> Is there any reason to believe that we shouldn't just write to them
>>> and tell them it is ok to archive the lists?
(Continue reading)

Teus Hagen | 2 Jan 16:55 2009

Re: (Audit) Minor Changes to DRC

Good to see you have an established and responding contact now with
David Ross.
Good!
teus

On 12/28/2008 07:50 PM, Ian G (Audit) wrote:
> On 28/12/08 19:14, David E. Ross wrote:
>> Please Note:
>>
>> The "DRC" is marked:
>>         DRAFT
>>       This Checklist is NOT yet ready for use in reviewing
>> certificate authorities.
>>
>> The marking appears on all pages as a red background image that is
>> fixed (floats to remain in the center of the browser window).
>
>
> Hi David,
>
> I understand that your criteria are marked DRAFT, however CAcert is
> using them anyway.  Before I started this process, apparently Mozilla
> agreed to their being used in this one case.  Obviously, this is at
> CAcert's risk, Mozo might decide to change its mind.
>
> I understand that you'd like Mozilla to approve them generally.  I
> suspect Frank will more likely consider approving DRC only when forced
> to do so .... e.g., by seeing a completed audit according to the
> criteria, and being asked to review the criteria, against WebTrust,
> etc, at the same time.  I detect that they are seriously overworked
(Continue reading)

Alejandro Mery | 2 Jan 17:09 2009
Picon

Re: [CAcert-board] CAcert software availabilty

> I want to know if the board agrees on removing the absurd obstacles
> we are placing to people get libressl (GPL) and get involved in it's
> development.

Ok... this is my first time. so I'm not sure what to do next

In favour (voting order): Phil, Evaldo, Teus, Robert, Guillaume and me.

Absent: Greg.

against: no one

cool! so we have unanimity! :) but, how does one make this an
official decision?

I talked with PG and he said libressl is kept in CVS in local mode.
This could be made "public" simply by pushing with rsync to a
publicly reachable place running cvsd in read-only mode.

BUT, there is private data there too (outch).

the only vcs I know which can import[1] cvs' history completely and
then lets you filter out[2] of the history what you don't want is `git`.

[1] http://www.kernel.org/pub/software/scm/git/docs/git-cvsimport.html

[2]
http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html

should I rise a flame war in cacert-support or we can agree on one
(Continue reading)


Gmane