Subject: [therightkey] Certificate Transparency Working Group?

From: Ben Laurie <[email-masked]>
Date: Thu, 6 Sep 2012 15:32:05 +0100

Would people be interested in starting a WG on Certificate
Transparency? If so, how about a BoF in Atlanta?

Here's a draft charter...

CT IETF WG Draft Charter

Objective

Specify mechanisms and techniques that allow Internet applications to
monitor and verify the issuance of public X.509 certificates such that
all public issued certificates are available to applications, and each
certificate seen by an application can be efficiently shown to be in
the log of issued certificates. Furthermore, it should be possible to
cryptographically verify the correct operation of the log.

Optionally, do the same for certificate revocations.

Problem Statement

Currently it is possible for any CA to issue a certificate for any
site without any oversight. This has led to some high profile
mis-issuance of certificates, such as by DigiNotar, a subsidiary of
VASCO Data Security International, in July 2011
(http://www.vasco.com/company/about_vasco/press_room/news_archive/2011/news_diginotar_reports_security_incident.aspx).

The aim is to make it possible to detect such mis-issuance promptly
through the use of a public log of all public issued certificates.
Domain owners can then monitor this log and, upon detecting
mis-issuance, take appropriate action.

This public log must also be able to efficiently demonstrate its own
correct operation, rather than introducing yet another party that must
be trusted into the equation.

Clients should also be able to efficiently verify that certificates
they receive have indeed been entered into the public log.

For revocations, the aim would be similar: ensure that revocations are
as expected, that clients can efficiently obtain the revocation status
of a certificate and that the log is operating correctly.

Also, in both cases, the solution must be usable by browsers - this
means that it cannot add any round trips to page fetches, and that any
data transfers that are mandatory are of a reasonable size.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 6 Sep 2012 10:33:59 -0400 (EDT)

On Thu, 6 Sep 2012, Ben Laurie wrote:

> Subject: [therightkey] Certificate Transparency Working Group?
> 

Skeptical, but willing to attend a BoF to be convinced otherwise.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 06 Sep 2012 15:39:03 +0100

Hi all,

Just so's you know, Ben and I have been chatting a little
about this and Sean and I would be happy to sponsor a BoF
on the topic if it looks like it might gain traction and
all the other usual things look like they might pan out.

The timing for Atlanta is tight though for a formal BoF
so if this is of interest (or if you hate it;-) please
speak up in the next week.

If we don't get sufficient interest for a formal BoF
then we can arrange a room for a side-meeting if that's
of any use.

Cheers,
S.

On 09/06/2012 03:32 PM, Ben Laurie wrote:
> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey
> 
>

---

From: Scott Rea <[email-masked]>
Date: Thu, 06 Sep 2012 08:41:13 -0600

I'd be willing to attend a BoF and see where things go...
_Scott

---

From: Scott Rea <[email-masked]>
Date: Thu, 06 Sep 2012 08:43:23 -0600

-- 
Scott Rea, CISSP
VP GOV/EDU Relations & Sr. PKI Architect
DigiCert, Inc.
355 South 520 West
Canopy Building II, Suite 200
Lindon, Utah 84042
http://www.digicert.com
(800) 896-7973

Em [email-masked]
Ph#(801) 701-9636
Ce#(801) 874-4114

---

From: Yoav Nir <[email-masked]>
Date: Thu, 6 Sep 2012 17:50:01 +0300

On Sep 6, 2012, at 5:32 PM, Ben Laurie wrote:

> Transparency?

Getting interest is the easy part. Getting people to do the work and locking down the deliverables is harder.

> If so, how about a BoF in Atlanta?

The cut-off date for BoF proposals is 24-Sep. That's 18 days away, but we need people who will commit to more than being in the room. This is one of those subjects (like HTTP authentication) that will get half the security area regulars into the room. This should not be confused with having a large group of people willing to work on the same deliverables.

> cryptographically verify the correct operation of the log.

We'll need a good definition of the roles: what is a web application? who keeps the log? who can verify the log, etc.

> data transfers that are mandatory are of a reasonable size.

There is some work already being done in this area. One is certificate transparency, and another is the sovereign keys. Maybe there are others. These should be presented.

Yoav

---

From: Ben Laurie <[email-masked]>
Date: Thu, 6 Sep 2012 15:53:33 +0100

On 6 September 2012 15:33, Paul Wouters <[email-masked]> wrote:
> Skeptical,

Curious why?

> but willing to attend a BoF to be convinced otherwise.
>
> Paul

---

From: Tim Moses <[email-masked]>
Date: Thu, 6 Sep 2012 15:16:55 +0000

Hi Ben.  I am supportive of this initiative, and intend to participate.

Perhaps a small clarification is warranted.  Consider limiting the proposed solution to "Publicly-Trusted Certificates", which are defined as follows by CABForum: "A Certificate that is trusted by virtue of the fact that its corresponding Root Certificate is distributed as a trust anchor in widely-available application software".

All the best.  Tim.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Laurie
Sent: Thursday, September 06, 2012 10:32 AM
To: [email-masked]
Subject: [therightkey] Certificate Transparency Working Group?

Would people be interested in starting a WG on Certificate Transparency? If so, how about a BoF in Atlanta?

CT IETF WG Draft Charter

Objective

Specify mechanisms and techniques that allow Internet applications to monitor and verify the issuance of public X.509 certificates such that all public issued certificates are available to applications, and each certificate seen by an application can be efficiently shown to be in the log of issued certificates. Furthermore, it should be possible to cryptographically verify the correct operation of the log.

Problem Statement

Currently it is possible for any CA to issue a certificate for any site without any oversight. This has led to some high profile mis-issuance of certificates, such as by DigiNotar, a subsidiary of VASCO Data Security International, in July 2011 (http://www.vasco.com/company/about_vasco/press_room/news_archive/2011/news_diginotar_reports_security_incident.aspx).

The aim is to make it possible to detect such mis-issuance promptly through the use of a public log of all public issued certificates.
Domain owners can then monitor this log and, upon detecting mis-issuance, take appropriate action.

This public log must also be able to efficiently demonstrate its own correct operation, rather than introducing yet another party that must be trusted into the equation.

Clients should also be able to efficiently verify that certificates they receive have indeed been entered into the public log.

For revocations, the aim would be similar: ensure that revocations are as expected, that clients can efficiently obtain the revocation status of a certificate and that the log is operating correctly.

Also, in both cases, the solution must be usable by browsers - this means that it cannot add any round trips to page fetches, and that any data transfers that are mandatory are of a reasonable size.
_______________________________________________
therightkey mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/therightkey

---

From: "Thomas Hardjono" <[email-masked]>
Date: Thu, 6 Sep 2012 13:33:10 -0400

Hi Ben,

> through the use of a public log of all public issued certificates.

(a) Is this a log (repository) of just CA certs only, or does it
include every cert on the planet?

(b) Does it apply to public CAs only (or can private CA also
contribute to this log).

> they receive have indeed been entered into the public log.

(c) Will there be legal trust-frameworks to oversee the operations of
the contributing CAs as well as the log-operators?

(d) Will the end-user (client side) have to pay to access the log?

(e) Who are the potential operators of the log(s) & how do they make
money?

(f) History has shown that server-side certs are rarely ever validated
by the client.  What's different this time that would make the clients
willing to look-up the log.

(g) Will the CT-WG define Web APIs for accessing the log? (or will the
APIs be non-standard defined by log-operators).

ps. anyone remember UDDI?

Thanks.

/thomas/

> From: [email-masked] [mailto:therightkey-
> [email-masked]] On Behalf Of Ben Laurie
site
> without any oversight. This has led to some high profile
mis-issuance
> of certificates, such as by DigiNotar, a subsidiary of VASCO Data
> Security International, in July 2011
>
(http://www.vasco.com/company/about_vasco/press_room/news_archive/2011
/
> news_diginotar_reports_security_incident.aspx).
> 
>

---

From: Carl Wallace <[email-masked]>
Date: Thu, 06 Sep 2012 14:04:45 -0400

On 9/6/12 11:16 AM, "Tim Moses" <[email-masked]> wrote:

>Perhaps a small clarification is warranted.  Consider limiting the
>proposed solution to "Publicly-Trusted Certificates", which are defined
>as follows by CABForum: "A Certificate that is trusted by virtue of the
>fact that its corresponding Root Certificate is distributed as a trust
>anchor in widely-available application software".

Tim, are you suggesting the mechanisms and techniques produced by a
working group should be limited in this way or a service that makes use of
those mechanisms and techniques be limited in this way?

---

From: Ben Laurie <[email-masked]>
Date: Thu, 6 Sep 2012 19:25:17 +0100

> include every cert on the planet?

Every public cert on the planet.

> (b) Does it apply to public CAs only (or can private CA also

Private CAs can contribute.

> the contributing CAs as well as the log-operators?

Our proposal does not require trust, so I certainly don't intend to
propose legal frameworks. Others may have other ideas, which I look
forward to hearing about.

> (d) Will the end-user (client side) have to pay to access the log?

Not our log.

> (e) Who are the potential operators of the log(s) & how do they make

It is surprisingly cheap to run a Certificate Transparency log, we
believe. So, we hope that there will be sufficient interest in the
stability of the 'net to not require a way to make profit from a log.
Google intends to run one, in any case.

> willing to look-up the log.

Certificate Transparency does not require lookup. I'd also note that
browsers _do_ validate certs. Other clients are less diligent, agreed
- this is a different problem which is also worth solving.

> APIs be non-standard defined by log-operators).

I believe that such APIs (I would call them protocols :-) are in scope
for the WG.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 6 Sep 2012 19:30:29 +0100

> Perhaps a small clarification is warranted.  Consider limiting the proposed solution to "Publicly-Trusted Certificates", which are defined as follows by CABForum: "A Certificate that is trusted by…

I don't think we should place a bar to other certificates being
logged, but certainly this is the set of certs that should be
mandatory. I already said "public" in various places, so I presume you
are suggesting I switch that to "publicy-trusted"?

---

From: Tim Moses <[email-masked]>
Date: Thu, 6 Sep 2012 18:41:32 +0000

Hi Ben. Yes.  That's right.  But, maybe that's unnecessarily restrictive. I was trying to come up with a response to Denis' objection.  As only a subset of all certificates will appear in the log (at the very least during a transitional phase) and a subset of certificate-using software will only accept certificates that do appear in the log, we need a graceful way of lining the two subsets up.

All the best. Tim.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 6 Sep 2012 19:45:52 +0100

On 6 September 2012 19:41, Tim Moses <[email-masked]> wrote:
> Hi Ben. Yes.  That's right.  But, maybe that's unnecessarily restrictive. I was trying to come up with a response to Denis' objection.

Perhaps I missed something - I am not sure what Denis' objection was?

> As only a subset of all certificates will appear in the log (at the very least during a transitional phase) and a subset of certificate-using software will only accept certificates that do appear in the log, we need a graceful way of lining the two subsets up.
>
> All the best. Tim.
>
>
>

---

From: Tim Moses <[email-masked]>
Date: Thu, 6 Sep 2012 18:54:24 +0000

He said ...

 The second part of the objective (i.e. making all public issued certificates available to applications) may be dangerous in many situations.

---

From: Rob Stradling <[email-masked]>
Date: Fri, 07 Sep 2012 10:53:11 +0100

Hi Ben.  There is interest at Comodo.  I would like to participate in a 
CT WG.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Leif Johansson <[email-masked]>
Date: Fri, 07 Sep 2012 12:21:30 +0200

> Transparency? If so, how about a BoF in Atlanta?

I'd go to that bof