[cabfpub] Teleconference Agenda

[Ben Wilson]

FWIW - Today at IETF Bruce Schneier reiterated that math and science are
sound foundations to build upon.   

If anyone is interested, here is a link to an RSA Europe Presentation on
Random Number Generation -
http://www.rsaconference.com/writable/presentations/file_upload/ads-r08-entr
opy_-random-numbers-and-keys-whats-good-enough.pdf and a link to  NIST
800-90a review that has also been mentioned –
http://csrc.nist.gov/publications/nistbul/itlbul2013_09_supplemental.pdf. 

So, the discussion in this area tomorrow might focus on areas where we can
do something as a CAB Forum to improve end user security (get the biggest
ROI for our efforts).

 

On the first item, private key possession by CAs.  We ought to address
secure private key generation by CAs, secure delivery to subscribers, and
secure deletion of subscriber private keys from CA systems.  We ought to
look what we already have written and then to policies that others have
written as guidance for improvements to CABF policy.

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Erwann Abalea
Sent: Wednesday, November 06, 2013 8:10 AM
To: public at cabforum.org
Subject: Re: [cabfpub] Teleconference Agenda

 

Le 06/11/2013 14:59, Håvard Molland a écrit :

On 11/05/2013 10:16 PM, Ben Wilson wrote:

Besides reviewing working group status, new web site, and draft bylaws,
which I'll send out soon, what other hot topics should we add to Thursday's
discussion?  Remember, it will be an hour earlier for most of you.


I would like that we discuss that some CAs generate the site certificate's
private key for their customers.  It is my opinion that this breaks the
trust model and, especially in the light of recent events, I believe this is
a bad practice. 


In the light of older published results (weak Debian keys, lack of entropy
on some devices as explained in the "Mining your P's and Q's" and subsequent
papers), it can also be seen as a good practice. We at Keynectis don't do
that, but I can accept the positive arguments for such practices.




We could also discuss elliptic curves and recent worries that certain curve
constants might have been manipulated:
http://slashdot.org/submission/2947823/are-the-nist-standard-elliptic-curves
-back-doored


Please distinguish the Dual_EC_DRBG and NIST curves concerns. Dual_EC_DRBG
has certainly been weakened, while there's still some doubts regarding NIST
curves. Maybe it's time to allow for other curves, Brainpool ones come to
mind (RFC5639).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131106/1867ab5f/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5453 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131106/1867ab5f/attachment-0001.p7s>