Subject: [therightkey] Certrans BoF planning

From: Paul Hoffman <[email-masked]>
Date: Fri, 5 Oct 2012 14:10:56 -0700

Greetings again. The certrans BoF is tentatively scheduled for Tuesday afternoon at the IETF meeting; see <https://datatracker.ietf.org/meeting/85/agenda.html>.

I'll put together the agenda in a few weeks; I don't want to short-circuit free-flowing ideas, even if things are a bit quiet right now. I'll base the agenda around Internet-Drafts, and so far we have draft-laurie-pki-sunlight. If you have another draft that you think should be on the agenda, bring it to the list soon.

--Paul Hoffman, temporary leadership stuckee

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Oct 2012 07:43:58 -0700

Greetings again. The certrans BoF is scheduled for Tuesday after lunch at the IETF meeting; see <https://datatracker.ietf.org/meeting/85/agenda.html>. We have two hours, and we may not need all that time.

This is a call for agenda items. At the moment, we only have draft-laurie-pki-sunlight, but if anyone turned in any relevant drafts that I missed, please say so here.

It would be *very* useful if people continued to discuss draft-laurie-pki-sunlight and other drafts before the meeting. Meetings are more valuable for discussing topics that have already been brought up rather than "here's a presentation on a draft you should have already read".

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 17 Oct 2012 11:23:44 -0400

One draft that might be relevant here is my TLS security policy draft which
I will update later today and the OCSP 'Does not exist' response proposal
which I don't think made it to a draft.

http://tools.ietf.org/html/draft-hallambaker-tlssecuritypolicy-01

The relevance of TLS security policy is that it is a slightly more general
version of the proposed 'OCSP Must staple' certificate extension. The idea
is that a server puts this extension in a CSR when requesting a certificate
and this is then included in the certificate produced.

The server knows what version of TLS it supports and whether OCSP stapling
is supported and if so whether it is turned on. Putting these in a
certificate extension means that an OCSP client that does not get a stapled
OCSP response can reject the certificate immediately and hardfail without
having to try an OCSP request against the CA server which might be blocked
by an attacker or alternatively enable a DoS attack.

Including the version might not be strictly necessary but is by far the
biggest downgrade attack concern on TLS itself.

The relevance to CT is that this extension makes it practical to deliver
the CT proofs in the OCSP token rather than the certificate. That in turn
means that deployment of CT (1) has far less impact on CA operations and
(2) could potentially include a complete and current notary proof that is
up to date to the current day.

The reason I moved to the more general TLS policy rather than just doing
MUST STAPLE is that it is quite possible that we might want to propose new
TLS extensions to allow stapling of CT related data such as meta-notary
data.

The interest in a 'does not exist' response in OCSP is that it allows CAs
to deploy a weak form of transparency almost immediately. By weak
transparency I mean that a third party can audit the behavior of the CA
from public data alone but the requirements of this audit make it
unsuitable for incorporation into a client.

If an OCSP responder is required to distinguish 'this cert does not exist'
from 'this cert is valid' then a third party can check to see if the CA
knows which certificates have been issued and which are not by generating
requests for random serial numbers.

While most CAs would likely deliver the response as unsigned or sign it on
the fly (volume should be very small) the use of a scope scheme like I
proposed back in 1995 (and there is earlier prior art) allows the 'does not
exist' responses to be static as well.

The reason this was not done back in 1995 was that people raised objections
similar to zone walking. With CT we are asserting that public certs are
public knowledge anyway.

I would also like to suggest that as an interim step we define a simple
JSON format that CAs would use to report the list of all certificates
issued in the past hour. This is again a form of weak transparency but I
think having that data will make it a lot easier to get to a workable
system. The idea of publishing certs is pretty straightforward, the idea of
analyzing the published certs is pretty straightforward. Both deliver a
significant value that can be realized in a 12 month timeframe.

Design of the notary chains and making it possible for clients to do
validation is a much harder task. Not saying that it is impossible, just
that it will take us some time to do. From a design point of view it is a
lot harder than DANE which is now in what, its third year?

I would like us to have something that CAs can do right now rather than
wait three years before we approach them asking them for action. Three
years is a long time in business and people change jobs. If we end up
waiting three years before we ask people for action it is quite likely that
the people who are saying yes or maybe now will have moved on and we will
have to start the argument from scratch.

On Wed, Oct 17, 2012 at 10:43 AM, Paul Hoffman <[email-masked]>wrote:

> Greetings again. The certrans BoF is scheduled for Tuesday after lunch at
> the IETF meeting; see <https://datatracker.ietf.org/meeting/85/agenda.html>.
> We have two hours, and we may not need all that time.
>
> This is a call for agenda items. At the moment, we only have
> draft-laurie-pki-sunlight, but if anyone turned in any relevant drafts that
> I missed, please say so here.
>
> It would be *very* useful if people continued to discuss
> draft-laurie-pki-sunlight and other drafts before the meeting. Meetings are
> more valuable for discussing topics that have already been brought up
> rather than "here's a presentation on a draft you should have already read".
>
> --Paul Hoffman
> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey
>

-- 
Website: http://hallambaker.com/

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 18 Oct 2012 09:27:19 -0700

On Oct 17, 2012, at 8:23 AM, Phillip Hallam-Baker <[email-masked]> wrote:

> One draft that might be relevant here is my TLS security policy draft which I will update later today and the OCSP 'Does not exist' response proposal which I don't think made it to a draft.
> 

The BoF description is:

This non-WG forming BoF will discuss plans to specify mechanisms and techniques that allow Internet applications to monitor and verify the issuance of public X.509 certificates such that all 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.

The draft says it is an extension to PKIX certs "to prevent downgrade attacks that are not otherwise prevented by the TLS protocol".

> The relevance of TLS security policy is that it is a slightly more general version of the proposed 'OCSP Must staple' certificate extension. The idea is that a server puts this extension in a CSR when requesting a certificate and this is then included in the certificate produced.   . . .

The draft is focused on current use of OCSP and TLS. That seems possibly relevant for the PKIX or TLS WGs, but not here.

> The interest in a 'does not exist' response in OCSP is that it allows CAs to deploy a weak form of transparency almost immediately. By weak transparency I mean that a third party can audit the behavior of the CA from public data alone but the requirements of this audit make it unsuitable for incorporation into a client.

New work on weak transparency through OCSP would be relevant to this BoF, but probably not that useful unless we believed that the PKIX WG would actually allow those changes to OCSP.

> I would also like to suggest that as an interim step we define a simple JSON format that CAs would use to report the list of all certificates issued in the past hour. This is again a form of weak transparency but I think having that data will make it a lot easier to get to a workable system. The idea of publishing certs is pretty straightforward, the idea of analyzing the published certs is pretty straightforward. Both deliver a significant value that can be realized in a 12 month timeframe.

I recognize that you don't have an Internet Draft on that specific topic, but if you could put together a short presentation on it, it would be useful for the BoF.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Oct 2012 18:17:45 -0700

Proposed agenda is at <https://datatracker.ietf.org/meeting/85/agenda/certrans/>

Discuss any proposed changes here.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 23 Oct 2012 21:41:43 -0400

One of the key issues as far as acceptability to CAs is concerned is impact
on issue processes. In particular it has to be possible to deploy any
experimental infrastructure without touching the certificate issue code.

I think this is going to mean that CT proofs have to end up being embedded
in something other than the cert they relate to. I can't see the precert
idea as viable. Transporting the CT proofs in OCSP is viable though -
provided some changes are made there.

I don't mind if we discuss this as part of Ben's 60 mins or not but we do
need to discuss.

On Tue, Oct 23, 2012 at 9:17 PM, Paul Hoffman <[email-masked]> wrote:

> Proposed agenda is at <
> https://datatracker.ietf.org/meeting/85/agenda/certrans/>
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Oct 2012 19:02:09 -0700

[[ I changed the subject line because this should be discussed on the list *before* the meeting. It is not a separate agenda item, yet. ]]

On Oct 23, 2012, at 6:41 PM, Phillip Hallam-Baker <[email-masked]> wrote:

> One of the key issues as far as acceptability to CAs is concerned is impact on issue processes. In particular it has to be possible to deploy any experimental infrastructure without touching the certificate issue code.
> 
> I think this is going to mean that CT proofs have to end up being embedded in something other than the cert they relate to. I can't see the precert idea as viable. Transporting the CT proofs in OCSP is viable though - provided some changes are made there.
>

---

From: Ben Laurie <[email-masked]>
Date: Wed, 24 Oct 2012 11:18:19 +0100

>> One of the key issues as far as acceptability to CAs is concerned is impact on issue processes. In particular it has to be possible to deploy any experimental infrastructure without touching the c…

What? Why? Are you saying CAs can't test modified issuance code?

>> I think this is going to mean that CT proofs have to end up being embedded in something other than the cert they relate to. I can't see the precert idea as viable. Transporting the CT proofs in OC…

What changes?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Oct 2012 07:16:59 -0400

On Wed, Oct 24, 2012 at 6:18 AM, Ben Laurie <[email-masked]> wrote:

> > [[ I changed the subject line because this should be discussed on the
> list *before* the meeting. It is not a separate agenda item, yet. ]]
> >
> >> One of the key issues as far as acceptability to CAs is concerned is
> impact on issue processes. In particular it has to be possible to deploy
> any experimental infrastructure without touching the certificate issue code.
>

Proposing to change that code is like you proposing to change the Google
search algorithm to make CT work. Just not going to happen.

That is an audited system. It has a very complex and elaborate QA. It
extends across the resellers that take the orders and the CA issue center.

If CT had been proposed twenty years ago it might be viable to put the
proof in the cert. Any change now has to work around the existing
infrastructure.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 24 Oct 2012 12:25:36 +0100

On 24/10/12 12:16, Phillip Hallam-Baker wrote:
>
> On Wed, Oct 24, 2012 at 6:18 AM, Ben Laurie <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On 24 October 2012 03:02, Paul Hoffman <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      > [[ I changed the subject line because this should be discussed on
>     the list *before* the meeting. It is not a separate agenda item, yet. ]]
>      >
>      > On Oct 23, 2012, at 6:41 PM, Phillip Hallam-Baker
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      >
>      >> One of the key issues as far as acceptability to CAs is
>     concerned is impact on issue processes. In particular it has to be
>     possible to deploy any experimental infrastructure without touching
>     the certificate issue code.
>

FWIW, as lead developer of Comodo's issuance code and as one of the 
first people to propose both the pre-cert idea [1] and the idea of 
embedding CT proofs in OCSP Responses [2], I intend to seek permission 
from Comodo Management to implement both.  They might say "no", of 
course.  ;-)

[1] http://www.ietf.org/mail-archive/web/pkix/current/msg30146.html
[2] Message posted to the non-public CABForum list on 5th April 2012.

<snip>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Ben Laurie <[email-masked]>
Date: Wed, 24 Oct 2012 12:28:45 +0100

On 24 October 2012 12:16, Phillip Hallam-Baker <[email-masked]> wrote:
>> >> impact on issue processes. In particular it has to be possible to deploy any

That is not what I've heard from others.

> If CT had been proposed twenty years ago it might be viable to put the proof
> in the cert. Any change now has to work around the existing infrastructure.

If your infrastructure can't cope, fine, put it in OCSP, or in a TLS
extension. I don't believe all CAs are unable to modify their
software.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 24 Oct 2012 13:01:59 +0100

On 24 October 2012 12:25, Rob Stradling <[email-masked]> wrote:
> FWIW, as lead developer of Comodo's issuance code and as one of the first
> people to propose both the pre-cert idea [1] and the idea of embedding CT
> proofs in OCSP Responses [2], I intend to seek permission from Comodo
> Management to implement both.  They might say "no", of course.  ;-)

Good to hear. We now have a test log server up, so any time you're ready :-)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Oct 2012 08:53:10 -0400

> That is not what I've heard from others.

Hey, I am not trying to be obstructionist here, just trying to avoid the
pitfalls of previous efforts. CT itself is going to be the easy part. The
devil is all going to be in the deployment.

Other than Comodo and Symantec, how many CAs have a programmer on staff?

> proof

I think it is going to be very hard to get CAs to commit unless there is a
general consensus that the other CAs will also commit.

Also there is a technical cost and a political cost of making a change.
IETF has a tendency to focus only on the technical cost which depends on
the extent of the changes and so prefers incremental improvements that are
stand alone. But the political cost tends to be more a matter of deciding
to do something different and the advantage of doing it. If the political
cost is the blocking factor then you will do better with one big request
than a series of small ones.

---

From: Erwann Abalea <[email-masked]>
Date: Wed, 24 Oct 2012 15:18:04 +0200

2012/10/24 Phillip Hallam-Baker <[email-masked]>

> Other than Comodo and Symantec, how many CAs have a programmer on staff?

(Keynectis) I'd like to. Not just as a CA, but also as a log holder. I can
only fly over it for now, though. Frustration.
And we also have deployment constraints, certification constraints (CC
EAL4+ and local ones), and a lot of customers to satisfy.

> general consensus that the other CAs will also commit.

Agreed.

> than a series of small ones.

That's when IETF considers costs at all...

-- 
Erwann.

---

From: Rick Andrews <[email-masked]>
Date: Wed, 24 Oct 2012 10:09:36 -0700

> -----Original Message-----
> From: [email-masked] [mailto:therightkey-
> [email-masked]] On Behalf Of Ben Laurie
> Sent: Wednesday, October 24, 2012 4:29 AM
> To: Phillip Hallam-Baker
> Cc: [email-masked]; Paul Hoffman
> Subject: Re: [therightkey] Impact on issue processes
> 
> the
> <[email-masked]>
> >> > wrote:

It's not a question of being unable to modify our software. As a representative of Symantec, I will tell you that modifying our issuance code will be a very tough sell, for a number of reasons:
 - There's no obvious direct return on investment
 - For some types of certificates, speed of issuance is very important. Getting a CT proof will slow this down and cause it to fail if the log server isn't up 100% of the time.
 - It makes sense to avoid relying on external parties to fulfill part of our cert issuance process. At this point, it's unclear who would even host a log service, what SLA they would provide, how much attention they would pay to performance and availability, disaster recovery, etc.
 - Symantec would not be interested in hosting a log service because of unclear ROI.

-Rick

---

From: Chris Palmer <[email-masked]>
Date: Wed, 24 Oct 2012 17:56:52 -0700

>  - Symantec would not be interested in hosting a log service because of unclear ROI.

CT makes CAs less valuable targets. I'd call that ROI.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 25 Oct 2012 10:10:06 +0100

>  - There's no obvious direct return on investment

So protecting users is not a motivation, then?

>  - For some types of certificates, speed of issuance is very important. Getting a CT proof will slow this down and cause it to fail if the log server isn't up 100% of the time.

I'd like to hear more about these certificates - why is speed so important?

We redesigned the CT protocol precisely so that getting a proof (which
actually now is just a signed timestamp) is quick, and so that we have
a service that's easy to keep up. We also intend to run several
instances of the log so that in the event of one being down, others
can be used (for time critical issuance, you would obviously use them
in parallel, and perhaps just take the first one that answers -
there's no obligation to use a log's response so dropping the others
on the floor would be fine).

>  - It makes sense to avoid relying on external parties to fulfill part of our cert issuance process. At this point, it's unclear who would even host a log service, what SLA they would provide, how…

Google will run a log. We have not yet established an SLA, but we will
have one, and certainly our aim is to make it as available as is
possible. Disaster recovery is also critical, since any error in the
log is indistinguishable from malfeasance, at least technically, so we
are designing the system with a great deal of robustness and multiple
layers of backup.

We are not messing around here - the full capabilities of Google's
infrastructure are being applied to this problem.

>  - Symantec would not be interested in hosting a log service because of unclear ROI.

I find it interesting that trust is not considered an ROI.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Oct 2012 08:09:47 -0700

The thread from the past few days has show a few things that I hope influence the discussion before the meeting:

- Different CAs have different views about what is and is not desirable for them to do with respect to draft-laurie-pki-sunlight

- Different people within one CA have different views about what is and is not desirable for them to do with respect to draft-laurie-pki-sunlight

- Different CAs have different views about what is and is not possible for them to do with respect to draft-laurie-pki-sunlight

Given all that, it would be grand if people spoke for themselves, and for people to not assume that someone who is speaking is speaking for everyone who is like them.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 25 Oct 2012 12:44:14 -0500

You assume here I was speaking for Comodo and about the comodo ca

My experience is rather wider than one or two CAs

Sent from my iPhone

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Oct 2012 11:04:04 -0700

> You assume here I was speaking for Comodo and about the comodo ca

That is a false statement.

> My experience is rather wider than one or two CAs

That is a true statement, yet still irrelevant to this discussion.

--Paul Hoffman

---

From: Rob Stradling <[email-masked]>
Date: Thu, 25 Oct 2012 20:41:14 +0100

> That is a false statement.

Paul, in that case, would you mind explaining who you were referring to 
and what you meant by...
"Different people within one CA have different views about what is and 
is not desirable for them to do with respect to draft-laurie-pki-sunlight"
?

Thanks.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Oct 2012 13:05:37 -0700

On Oct 25, 2012, at 12:41 PM, Rob Stradling <[email-masked]> wrote:

> Paul, in that case, would you mind explaining who you were referring to and what you meant by...
> "Different people within one CA have different views about what is and is not desirable for them to do with respect to draft-laurie-pki-sunlight"
> ?

Sure. Neither you nor Phill have said you were speaking for Comodo, yet you have over time expressed different views of what is and is not desirable for some CAs (not just Comodo) to do with respect to draft-laurie-pki-sunlight. Phill told me long ago to not assume that he speaks for Comodo, and I still take him at his word for that.

So, now we can return to, you know, protocol discussion?

--Paul Hoffman

---

From: Rick Andrews <[email-masked]>
Date: Thu, 25 Oct 2012 15:40:16 -0700

> From: Chris Palmer [mailto:[email-masked]]
> Sent: Wednesday, October 24, 2012 5:57 PM
> To: Rick Andrews
> Cc: Ben Laurie; Phillip Hallam-Baker; [email-masked]; Paul
> Hoffman
> > It's not a question of being unable to modify our software. As a
> representative of Symantec, I will tell you that modifying our issuance
> code will be a very tough sell, for a number of reasons:
> >  - For some types of certificates, speed of issuance is very
> important. Getting a CT proof will slow this down and cause it to fail
> if the log server isn't up 100% of the time.
> >  - It makes sense to avoid relying on external parties to fulfill
> part of our cert issuance process. At this point, it's unclear who
> would even host a log service, what SLA they would provide, how much
> attention they would pay to performance and availability, disaster
> recovery, etc.

Ben, Chris,

Protecting users is certainly a motivation and making our customers and their end users safer on the Internet is my main goal. I'm not opposed to CT because I don't want to protect users or CAs. I'm just not convinced it's the best solution.

It's going to cost engineering time and money for CAs to implement CT. The bean counters and execs who control the purse strings are going to ask what they'll get for their $$$. They'll ask "so if I spend this money, we won't get hacked, right?" and I would have to say no, it's no guarantee that we wouldn't get hacked, but if we got hacked we would know about it.

CT is *a* solution, but by no means the only possible solution. Is there another solution that might be less expensive and intrusive to implement? CAA might get us 80% of the way there for a fraction of the cost. DANE and cert pinning also help, and might be simpler to implement. 

-Rick

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Oct 2012 16:17:37 -0700

> CT is *a* solution, but by no means the only possible solution. Is there another solution that might be less expensive and intrusive to implement? CAA might get us 80% of the way there for a fracti…

I'm pretty sure CAA is only about preventing good-conscious certificate issuance, not about preventing hacked, nor about knowing about it if you are. How do you see CAA getting you 80% of the way to the problem?

I also don't see DANE or cert pinning as solutions to that problem either, so I guess I'm missing something in your analysis.

--Paul Hoffman

---

From: Chris Palmer <[email-masked]>
Date: Thu, 25 Oct 2012 16:26:02 -0700

> It's going to cost engineering time and money for CAs to implement CT. The bean counters and execs who control the purse strings are going to ask what they'll get for their $$$. They'll ask "so if…

And the attackers have much less incentive to hack you. That is a
really big win. Obviously the cost is not $0, but the payoff is
significant. In a CT world, what does Comodo Hacker gain by causing
mis-issuance? It's a looooot less than now. Tell your bean counters
that.

> CT is *a* solution, but by no means the only possible solution. Is there another solution that might be less expensive and intrusive to implement? CAA might get us 80% of the way there for a fracti…

Obviously I like key pinning, but I consider CT (or a public log
solution generally) as the "true", long-term solution. Pinning would
probably continue to be of complementary value, as might
DANE/CAA/whatever else. But I consider that CT is where we want to be.

And other people are already offering to take on the really big costs.
Tell your bean counters that, too: It's a collaborative effort, and
other people have already started paying. It might be that all you
have to do is implement somebody else's design and talk to somebody
else's service (although obviously helping out sooner benefits you
too).

---

From: Rick Andrews <[email-masked]>
Date: Thu, 25 Oct 2012 16:58:00 -0700

> From: Paul Hoffman [mailto:[email-masked]]
> Sent: Thursday, October 25, 2012 4:18 PM
> To: Rick Andrews
> Cc: [email-masked]
> Subject: Other solutions to the problem
> 
> > Protecting users is certainly a motivation and making our customers
> and their end users safer on the Internet is my main goal. I'm not
> opposed to CT because I don't want to protect users or CAs. I'm just
> not convinced it's the best solution.
> >
> > It's going to cost engineering time and money for CAs to implement
> CT. The bean counters and execs who control the purse strings are going
> to ask what they'll get for their $$$. They'll ask "so if I spend this
> money, we won't get hacked, right?" and I would have to say no, it's no
> guarantee that we wouldn't get hacked, but if we got hacked we would
> know about it.
> >
> > CT is *a* solution, but by no means the only possible solution. Is
> there another solution that might be less expensive and intrusive to
> implement? CAA might get us 80% of the way there for a fraction of the
> cost. DANE and cert pinning also help, and might be simpler to
> implement.
> 
> 
> I'm pretty sure CAA is only about preventing good-conscious certificate
> issuance, not about preventing hacked, nor about knowing about it if
> you are. How do you see CAA getting you 80% of the way to the problem?
> 
> I also don't see DANE or cert pinning as solutions to that problem
> either, so I guess I'm missing something in your analysis.

The problem is that any CA can issue a certificate for a given domain name and all browsers will trust it. CT allows Paypal (just an example) to detect that some unexpected CA issued a cert for one of their domains. If CAA is used by the CA being hacked, their system should refuse to issue the cert to Paypal's domain. DANE or cert pinning would allow a client to detect that the certificate issued by the CA being hacked is bogus.

AFAICT, for CT to really work it will require participation from every CA whose roots are in browsers. I think you're underestimating how hard it will be to achieve that.

Further, no one has yet brought up the privacy issue. CAs sell a lot of certificates to companies for their internal use. Some of them may object to publishing all their internal domain names. 

-Rick

---

From: Chris Palmer <[email-masked]>
Date: Thu, 25 Oct 2012 17:49:28 -0700

> Further, no one has yet brought up the privacy issue. CAs sell a lot of certificates to companies for their internal use. Some of them may object to publishing all their internal domain names.

I'm still fuzzy on why people can't use private issuers for private
domains. Seems not only obvious, but preferable for everyone.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 26 Oct 2012 07:57:44 +0200

> domains. Seems not only obvious, but preferable for everyone.

It avoids the hassle of adding the private issuer to the browser of every single device that uses the web. It's fairly easy to do so for all the Windows machines connected to a Windows domain. But then you get a lot of helpdesk tickets for the people with Macs, the people who use Firefox on any platform, the people with iPhones, Android phones, Linux desktops, a Chromebook and something called a Wetab.

It's worth the little extra expense of getting a certificate from a known issuer to avoid getting warning screens on all other devices.

Yoav

---

From: Rob Stradling <[email-masked]>
Date: Fri, 26 Oct 2012 09:24:37 +0100

On 26/10/12 00:58, Rick Andrews wrote:
<snip>
> AFAICT, for CT to really work it will require participation from every CA whose roots are in browsers. I think you're underestimating how hard it will be to achieve that.

Rick,

Ultimately, assuming the RFC5878 TLS extension gains widespread support 
in server and client software, CT won't _require_ participation from any 
CA.  Each certificate holder will be able to configure their server to 
send their certificate's CT proof to each client.

But with participation from the CAs, it should be possible to realize 
the CT dream far sooner.  And (even in a future world where RFC5878 is 
supported everywhere) if the CA takes care of CT proof distribution, 
then that makes life easier for the certificate holder.

> Further, no one has yet brought up the privacy issue. CAs sell a lot of certificates to companies for their internal use. Some of them may object to publishing all their internal domain names.

This has been a concern for Comodo too, so I spoke to AGL about it a few 
weeks ago.  AIUI, the plan is that CT clients will have a 
user-configurable whitelist (empty by default) of domain names for which 
CT proofs will not be required.  Participating CAs should allow 
customers to opt-out from having their certs automatically logged with CT.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 26 Oct 2012 09:50:55 +0100

On 26 October 2012 09:24, Rob Stradling <[email-masked]> wrote:
>> AFAICT, for CT to really work it will require participation from every CA
>> whose roots are in browsers. I think you're underestimating how hard it will
>> be to achieve that.
>
>
> Rick,
>
> Ultimately, assuming the RFC5878 TLS extension gains widespread support in
> server and client software, CT won't _require_ participation from any CA.
> Each certificate holder will be able to configure their server to send their
> certificate's CT proof to each client.
>
> But with participation from the CAs, it should be possible to realize the CT
> dream far sooner.  And (even in a future world where RFC5878 is supported
> everywhere) if the CA takes care of CT proof distribution, then that makes
> life easier for the certificate holder.
>
>
>> Further, no one has yet brought up the privacy issue. CAs sell a lot of
>> certificates to companies for their internal use. Some of them may object to
>> publishing all their internal domain names.
>
>
> weeks ago.  AIUI, the plan is that CT clients will have a user-configurable
> whitelist (empty by default) of domain names for which CT proofs will not be
> required.  Participating CAs should allow customers to opt-out from having
> their certs automatically logged with CT.

I think there are at least three options

1. As you say, users (or admins might be a little safer) configure
domains to be opted-out.

2. Private certs are issued by private CAs (I mean the CA certificate,
of course) which are marked "do not log". This option will not be
available for default CAs.

3. Private certs are issued under a name-constrained intermediate
which is logged.

BTW, Rick, this has come up before, I thought on public lists, but
perhaps I am misremembering. I prefer 3, BTW, because it is not a
mechanism which users can be conned into invoking.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 26 Oct 2012 09:56:52 +0100

> CT is *a* solution, but by no means the only possible solution. Is there another solution that might be less expensive and intrusive to implement? CAA might get us 80% of the way there for a fracti…

I think the answer is that, no, there isn't another solution that is
easier. Getting 80% of the way might as well be getting none of the
way - unless _all_ CAs (or other issuers) are constrained, the problem
is not solved. DANE and CAA, even if they were deployable, still leave
you open to trusted third parties, and we've seen how that's gone.

Pinning has its own issues - and in any case is available now and has
not fixed the problem.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 26 Oct 2012 16:10:16 +0100

> Greetings again. The certrans BoF is scheduled for Tuesday after lunch at the IETF meeting; see <https://datatracker.ietf.org/meeting/85/agenda.html>. We have two hours, and we may not need all tha…

Correction: Adam Langley, and probably Stephen McHenry, from the
Certificate Transparency team at Google will be representing us at the
BoF.

---

From: Rick Andrews <[email-masked]>
Date: Fri, 26 Oct 2012 14:31:18 -0700

> From: Ben Laurie [mailto:[email-masked]]
> Sent: Friday, October 26, 2012 1:51 AM
> To: Rob Stradling
> Cc: Rick Andrews; [email-masked]; Paul Hoffman
> Subject: Re: [therightkey] Other solutions to the problem
> 

I see, so the certificate holder can submit their newly-minted certificate to a log server to get a CT proof. Instead of requiring the participation of every CA, you now require the participation of every certificate holder. You might say that not every certificate holder will need or want CT, but I would guess that the number that would want the protection would be far greater than the number of CAs.

> the CT

I believe in your plan each browser will be a CT client. Aside from the fact that the white list is an attractive target for hackers, I don't see how the average user is going to know how to configure this white list. I'm reminded of Adam's arguments against Convergence (http://www.imperialviolet.org/2011/09/07/convergence.html).

---

From: Leif Johansson <[email-masked]>
Date: Sat, 27 Oct 2012 12:55:50 +0200

> 
> The problem is that any CA can issue a certificate for a given domain name and all browsers will trust it. CT allows Paypal (just an example) to detect that some unexpected CA issued a cert for one of their domains. If CAA is used by the CA being hacked, their system should refuse to issue the cert to Paypal's domain. DANE or cert

When a CA is hacked I think we can safely assume that the 'system' can be tricked into doing whatever the attacker wants it to do. Including overriding CAA policy.

          Leif

---

From: Ben Laurie <[email-masked]>
Date: Mon, 29 Oct 2012 10:10:18 +0000

On 26 October 2012 22:31, Rick Andrews <[email-masked]> wrote:
> I see, so the certificate holder can submit their newly-minted certificate to a log server to get a CT proof. Instead of requiring the participation of every CA, you now require the participation of every certificate holder.

No, it is an option.

>You might say that not every certificate holder will need or want CT, but I would guess that the number that would want the protection would be far greater than the number of CAs.

Given that the plan is browsers will refuse non-CTed certs, I imagine
most holder of certificates used by the public will want CT.

> I believe in your plan each browser will be a CT client. Aside from the fact that the white list is an attractive target for hackers, I don't see how the average user is going to know how to config…

This is why I think the best solution is to issue private certs
through a name constrained intermediate which is logged.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 29 Oct 2012 10:13:00 +0000

> through a name constrained intermediate which is logged.

Or, as I mentioned above, through a private CA which is marked as "do
not log". I would not expect users to configure this, rather the
sysadmins of their corp machines.

BTW, a domain whitelist seems like a terrible idea: then attackers
could freely forge certificates in that whitelist, even if it was
configured correctly.

---

From: Rick Andrews <[email-masked]>
Date: Wed, 31 Oct 2012 16:57:38 -0700

> Sent: Monday, October 29, 2012 3:10 AM
> To: Rick Andrews
> Cc: Rob Stradling; [email-masked]; Paul Hoffman
> >> >> whose roots are in browsers. I think you're underestimating how
> hard
> >> it will
> >> >> be to achieve that.
> >> >
> >> >
> >> > Rick,
> >> >
> >> > server and client software, CT won't _require_ participation from
> any
> >> CA.
> > I see, so the certificate holder can submit their newly-minted
> certificate to a log server to get a CT proof. Instead of requiring the
> participation of every CA, you now require the participation of every
> certificate holder.
> 
> No, it is an option.

I understand that. I was trying to point out that for CT to be effective, you either need all CAs to participate, or for every CA that doesn't participate, their customers who want protection have to participate directly. I feel that's a pretty high bar to surmount.

> >You might say that not every certificate holder will need or want CT,
> but I would guess that the number that would want the protection would
> be far greater than the number of CAs.
> 

Do you have agreements with the major browser vendors to do this? It's possible that not all of them will be on board.

> >> > everywhere) if the CA takes care of CT proof distribution, then
> that
> >> makes
> >> >> Further, no one has yet brought up the privacy issue. CAs sell a
> lot
> >> of
> >> >> certificates to companies for their internal use. Some of them
> may
> >> object to
> >> > This has been a concern for Comodo too, so I spoke to AGL about it
> a
> >> few
> >> > whitelist (empty by default) of domain names for which CT proofs
> will
> >> not be
> >> > required.  Participating CAs should allow customers to opt-out
> from
> >> having
> > I believe in your plan each browser will be a CT client. Aside from
> the fact that the white list is an attractive target for hackers, I
> don't see how the average user is going to know how to configure this
> white list. I'm reminded of Adam's arguments against Convergence
> (http://www.imperialviolet.org/2011/09/07/convergence.html).
> 

I agree.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 01 Nov 2012 00:06:33 +0000

Just on this point:

> Do you have agreements with the major browser vendors to do this? It's possible that not all of them will be on board.

We're discussing a draft submitted for a BoF that might
or might not become a WG or get AD sponsored eventually
producing a proposed standard RFC.

None of that requires guaranteed ubiquitous deployment.
Nothing even near that is required in fact.

The IETF might be justifiably criticised for being slow
in doing stuff, but we ought also note that part of the
reason for that could be the extreme targets we set out
for ourselves.

Cheers,
S.