Subject: [Trans] Draft agenda

From: Melinda Shore <[email-masked]>
Date: Thu, 20 Feb 2014 08:06:08 -0900

I've uploaded a first crack at an agenda to
http://www.ietf.org/proceedings/89/agenda/agenda-89-trans.
Please let me know if anything is missing, or if you'd like
to request some time on the agenda.

I'll be starting discussions on some of these items over
the next few days.

Also, note that one of the things you can do to help move
work forward in the IETF is to volunteer to take minutes
or act as a Jabber scribe during the session.  If anybody
would like to volunteer now, we'd be grateful.

Melinda

---

From: Eran Messeri <[email-masked]>
Date: Mon, 24 Feb 2014 16:35:48 +0000

I'll be happy to scribe half the session.

As for the agenda, I'd like to suggest discussing handling of private
subdomains<https://code.google.com/p/certificate-transparency/issues/detail?id=20>
.
IMHO while the suggestion in the issue makes sense , it'd benefit from
another review to make sure it would work as intended and covers all cases
CAs are concerned about.

Eran

On Thu, Feb 20, 2014 at 5:06 PM, Melinda Shore <[email-masked]>wrote:

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Rob Stradling <[email-masked]>
Date: Mon, 24 Feb 2014 16:46:04 +0000

On 24/02/14 16:35, Eran Messeri wrote:
<snip>
> subdomains
> <https://code.google.com/p/certificate-transparency/issues/detail?id=20>.
> another review to make sure it would work as intended and covers all
> cases CAs are concerned about.

+1

> Eran
>
>
> On Thu, Feb 20, 2014 at 5:06 PM, Melinda Shore <[email-masked]
> <mailto:[email-masked]>> wrote:
>

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

---

From: Melinda Shore <[email-masked]>
Date: Mon, 24 Feb 2014 08:52:54 -0900

> I'll be happy to scribe half the session.

Excellent - thank you.

> cases CAs are concerned about.

That one looks to me like a hairball.  Right now it's a MUST
in 5280 that a serial number be unique for each certificate
issued by a CA.

Melinda

---

From: Ben Laurie <[email-masked]>
Date: Mon, 24 Feb 2014 18:21:25 +0000

> in 5280 that a serial number be unique for each certificate

Precertificates already share serial numbers with certificates. The
intent of 5280 is not violated by this practice, but perhaps needs
amending to permit it.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 24 Feb 2014 09:58:54 -0900

> intent of 5280 is not violated by this practice, but perhaps needs

If it turns out that there's agreement with this proposal
we'll need to make sure that this is highlighted somewhere
in our documents and that it's run past pkix.

Melinda

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 24 Feb 2014 14:17:46 -0500

What exactly is a 'precertificate'. Either something is a cert or it is not.

If it parses as an X.509v3 certificate then it is an X.509v3 certificate
and thats an end to it.

If it is not then it is probably a CSR which would seem to be the existing
PKIX structure that fits its purpose.

On Mon, Feb 24, 2014 at 1:21 PM, Ben Laurie <[email-masked]> wrote:

> >> <https://code.google.com/p/certificate-transparency/issues/detail?id=20
> >.

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

---

From: Eran Messeri <[email-masked]>
Date: Mon, 24 Feb 2014 20:42:09 +0000

The part I proposed to put on the agenda was the general approach to
avoiding logging private subdomains.
Of the two proposed solutions in issue #20, only the 2nd option refers to
precertificates. We could still discuss the 1st one without discussing
precertificates at all.

There's the separate matter of precertificates and serial numbers. Given
the vibrant discussions around it on the list, it might as well be added to
the agenda.

On Mon, Feb 24, 2014 at 7:17 PM, Phillip Hallam-Baker <[email-masked]>wrote:

>> >> <
>> https://code.google.com/p/certificate-transparency/issues/detail?id=20>.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 24 Feb 2014 16:00:43 -0500

> to request some time on the agenda.

Thanks for organizing, Melinda!  I'd like to try to make a bit of time
in the agenda to talk about the use of CT in the SMTP+STARTTLS
environment.

Given the current opportunistic mode that TLS is used for in SMTP, we
may decide that there is no reasonable intersection at all today, but i
think it would be worth putting the issue on people's radar with a brief
discussion.

For example, brief discussion of any of these questions might be useful:

 * Should submission (SMTP+STARTTLS on port 587, with some form of
   client authentication) servers enroll their certificates in the log?

 * Should submission clients (MUAs like Thunderbird or Outlook) verify
   SCTs?  If so, what would be a reasonable action for MUAs to take if
   an SCT is missing or does not validate?  Does this change if the MUA
   has a history of having seen a valid SCT for the submission server?
   Should MUA configuration indicate to the user whether a server's
   certificate is in the log or not?

 * Should submission servers that use client-side certs to authenticate
   their clients look for SCTs in their client's certs?  If so, how
   should they behave if a client's SCT is missing or does not validate?
 
 * Should regular (port 25, not submission) SMTP+STARTTLS clients verify
   the SCTs passed by the peer?  What should be done if an SCT is absent
   or doesn't verify?  What if there is a history of having seen a
   logged cert for that peer?

 * Should regular (port 25, not submission) SMTP+STARTTLS servers with
   client-cert-authenticated peers verify the SCTs passed by the peer?
   What should be done if an SCT is absent or doesn't verify?

 * Should certificates for submission or SMTP+STARTTLS contain any
   reference to the domains they accept e-mail for (or send e-mail
   from?), or should their certificates be limited to the hostname only?

 * What sort of log monitoring should an SMTP+STARTTLS or submission
   service operator do to avoid misissuance?  Does it differ in any way
   from the log monitoring that an HTTPS operator should do?

Regards,

    --dkg

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 24 Feb 2014 16:12:59 -0500

> For example, brief discussion of any of these questions might be useful:

What these all come down to is the question of using the CT log
infrastructure as a potential source for authoritative security policy.

It is a completely valid approach and one that I am looking at but in the
context of SMTP with S/MIME and PGP.

Whether or not these is time at the meeting, I suggest this is a discussion
we continue on therightkey because I have a feeling that Melinda is going
to kick us out pretty quick if we get into discussion of approaches. I
would kick me out.

This is why I think it is important to distinguish between keeping notary
logs for issue of certificates by CAs separate from the issue of how
notarize the notary logs. The way I see it we will end up eventually with
some collection of 'meta-notaries' which cross notarize at regular
intervals making defection or failure of a meta-notary of little concern.
Every meta-notary will cross notatrize every other within a 24hour period
so they are interchangable from a trust point of view.

I would see CT logs of SSL cert issue to be one input to the meta notaries,
CT logs of S/MIME certs another, PGP key signings another, security policy
statements another and so on.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 24 Feb 2014 12:25:55 -0900

On 2/24/14 12:12 PM, Phillip Hallam-Baker wrote:
> Whether or not these is time at the meeting, I suggest this is a
> discussion we continue on therightkey because I have a feeling that
> Melinda is going to kick us out pretty quick if we get into discussion
> of approaches. I would kick me out.

We have a very short session scheduled in London, and I feel
pretty strongly about IETF meetings as working meetings.

As for relevance, right now therightkey is the best place
for discussion of other approaches to fixing PKI, while trans
is specifically for discussion of certificate transparency.
The only thing that's in our charter at the moment is 6962bis.
That doesn't mean that other applications of CT are out-of-
scope, but that we'd need to recharter to take them on
as work items.  It's a bit early for that.  Probably the
best way to keep these proposals alive is to get internet
drafts posted.  I'd like to stay focused on getting 6962bis
done, but won't stomp on discussion of other CT applications
unless they take over the mailing list.  And otherwise I am
completely agnostic on the question of whether those discussions
happen here or on therightkey.

Melinda

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 24 Feb 2014 16:43:02 -0500

On 02/24/2014 04:25 PM, Melinda Shore wrote:

> as work items.

I think you're saying you want the slot in London to focus on getting
the mechanism right, and not trying to propose policy, which is
completely reasonable.  I'm happy to stay focused.

There's nothing in RFC 6962 (and i hope there won't be in 6962bis) that
is HTTPS-specific, though; it's defined as a mechanism for logging X.509
certificates for use in TLS, regardless of the application layer traffic
within the TLS session.

So i hope that the use of CT in SMTP+STARTTLS isn't seen as an "other
application" -- it's still TLS.  If we suspect that CT is somehow valid
only for X.509 certs used by HTTPS servers, we should make that more
explicit in the draft (but i hope we don't!)

Regards,

	--dkg

---

From: Ben Laurie <[email-masked]>
Date: Tue, 25 Feb 2014 07:19:30 +0000

> in our documents and that it's run past pkix.

By the way, CT does offer a 5280 compliant route (use a sub-CA for the
precertificate) but that doesn't actually provide any useful function
except ritual adherence to the RFC.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 25 Feb 2014 07:23:34 +0000

On 24 February 2014 19:17, Phillip Hallam-Baker <[email-masked]> wrote:
> If it parses as an X.509v3 certificate then it is an X.509v3 certificate and
> thats an end to it.

Indeed, and a precertificate is a certificate. RFC 6962 defines what
exactly it is.

Not sure where you're going with this.

> PKIX structure that fits its purpose.

Not really - a precertificate needs to be signed.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 25 Feb 2014 07:28:46 +0000

> explicit in the draft (but i hope we don't!)

I agree. One observation: CT as applied to HTTPS uses the CA signature
as a spam limitation mechanism.

I believe most SMTP certs are not CA issued, so the question arises:
how would you propose to limit spam?

I am open, by the way, to running CT logs at Google with alternate
spam limitation mechanisms to allow this kind of usage. I think that
not having a spam limitation mechanism is dangerous.

---

From: Rob Stradling <[email-masked]>
Date: Tue, 25 Feb 2014 10:09:17 +0000

> Not really - a precertificate needs to be signed.

CSRs are signed.  Self-signed, usually.

I think Phill is suggesting that a Precertificate could be a CSR, 
generated and signed by the CA (rather than self-signed by the 
certificate applicant).  The problem I see with this is that the CSR 
format doesn't contain some of the essential fields that MUST be present 
in a Precertificate: Serial Number, Issuer Name, etc.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 25 Feb 2014 07:36:23 -0500

On Tue, Feb 25, 2014 at 2:23 AM, Ben Laurie <[email-masked]> wrote:

> and

Ritual compliance with the existing PKIX spec.

Having two end entity certs with the same serial number is going to be a
problem.

> Not really - a precertificate needs to be signed.

CSRs are signed.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Feb 2014 09:01:56 -0800

Sorry for using a valid subject line. :-)

> how would you propose to limit spam?

At the earlier CT meeting, I think someone proposed that there could be a check that the cert was in actual use at the place it said it was.

> not having a spam limitation mechanism is dangerous.

Spam limitation is needed for both attacks on CT to weaken it and accidental misconfiguration that could look a lot like an attack.

--Paul Hoffman

---

From: Ben Laurie <[email-masked]>
Date: Tue, 25 Feb 2014 17:36:16 +0000

> At the earlier CT meeting, I think someone proposed that there could be a check that the cert was in actual use at the place it said it was.

That does not seem effective to me.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Feb 2014 09:53:35 -0800

> That does not seem effective to me.

It is more effective than doing nothing; it may not be effective enough to prevent overwhelm by spam. I was just pointing it out as something that was proposed, not well-thought-out.

--Paul Hoffman

---

From: Trevor Freeman <[email-masked]>
Date: Tue, 25 Feb 2014 19:47:31 +0000

I don't see the relevance of CT to opportunistic STARTTLS.

Opportunistic STARTTLS is a feature of the sender whereby the sender picks STARTTLS if offered, but otherwise will send the email.  If the alternative was send unprotected over plain TCP, you may as well negotiate TLS if offered.  Moreover, if TLS negotiation fails for whatever reason, the send remembers the fact and done not attempt to negotiate next time. 

The sender does have a list of SMTP domains where it requires TLS authentication, but that is mandatory  STARTTLS. 

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Tuesday, February 25, 2014 9:54 AM
To: Ben Laurie
Cc: [email-masked]; Daniel Kahn Gillmor
Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 25 Feb 2014 16:48:15 -0500

The idea seems to be that there is an append only log server that clients
are gong to be checking. So we can use that to stuff security policy
information into the system.

The problem is that the client only checks the CT logs in the normal case
after it has decided to use TLS.

So there is certainly a value in using an append only log to publish
security policy data and in fact I do this in PPE. But it is only a
solution to the downgrade attack problem with a lot of extra
infrastructure. For example an Omnibroker scanning the CT log and using
that to build the connection profile.

On Tue, Feb 25, 2014 at 2:47 PM, Trevor Freeman <
[email-masked]> wrote:

> Opportunistic STARTTLS is a feature of the sender whereby the sender picks
> STARTTLS if offered, but otherwise will send the email.  If the alternative
> was send unprotected over plain TCP, you may as well negotiate TLS if
> offered.  Moreover, if TLS negotiation fails for whatever reason, the send
> remembers the fact and done not attempt to negotiate next time.
>
> The sender does have a list of SMTP domains where it requires TLS
> authentication, but that is mandatory  STARTTLS.
>
> >> At the earlier CT meeting, I think someone proposed that there could be
> a check that the cert was in actual use at the place it said it was.
> >
> It is more effective than doing nothing; it may not be effective enough to
> prevent overwhelm by spam. I was just pointing it out as something that was
> proposed, not well-thought-out.
>
> --Paul Hoffman

---

From: Trevor Freeman <[email-masked]>
Date: Tue, 25 Feb 2014 22:13:12 +0000

The point with opportunistic TLS is its OPPORTUNISTIC, if there is any failure it will fall back to send without TLS. In opportunistic TLS the sender does no checks whatsoever on the certificate so why would it care about CT?

Besides the whole STARTTLS negation is already subject to downgrade attacks. Some firewalls actively block the STARTTLS negotiation.

From: Phillip Hallam-Baker [mailto:[email-masked]]
Sent: Tuesday, February 25, 2014 1:48 PM
To: Trevor Freeman
Cc: Paul Hoffman; Ben Laurie; [email-masked]; Daniel Kahn Gillmor
Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP

The idea seems to be that there is an append only log server that clients are gong to be checking. So we can use that to stuff security policy information into the system.

The problem is that the client only checks the CT logs in the normal case after it has decided to use TLS.

So there is certainly a value in using an append only log to publish security policy data and in fact I do this in PPE. But it is only a solution to the downgrade attack problem with a lot of extra infrastructure. For example an Omnibroker scanning the CT log and using that to build the connection profile.

On Tue, Feb 25, 2014 at 2:47 PM, Trevor Freeman <[email-masked]<mailto:[email-masked]>> wrote:
I don't see the relevance of CT to opportunistic STARTTLS.

-----Original Message-----
From: Trans [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Paul Hoffman
Sent: Tuesday, February 25, 2014 9:54 AM
To: Ben Laurie
Cc: [email-masked]<mailto:[email-masked]>; Daniel Kahn Gillmor
Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP

--Paul Hoffman
_______________________________________________
Trans mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/trans

_______________________________________________
Trans mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/trans

---

From: Ben Laurie <[email-masked]>
Date: Wed, 26 Feb 2014 11:13:08 +0000

On 25 February 2014 22:13, Trevor Freeman
<[email-masked]> wrote:
> The point with opportunistic TLS is its OPPORTUNISTIC, if there is any
> failure it will fall back to send without TLS. In opportunistic TLS the
> sender does no checks whatsoever on the certificate so why would it care
> about CT?

Then perhaps the word "opportunistic" should be removed from the
question. What is the relevance of CT to SMTP+STARTTLS?

>
>
>
> Besides the whole STARTTLS negation is already subject to downgrade attacks.
> Some firewalls actively block the STARTTLS negotiation.
>
>
>
> security policy data and in fact I do this in PPE. But it is only a solution
> to the downgrade attack problem with a lot of extra infrastructure. For
> example an Omnibroker scanning the CT log and using that to build the
> connection profile.
>
>
>
>
>
>
>
>
>
> On Tue, Feb 25, 2014 at 2:47 PM, Trevor Freeman
> <[email-masked]> wrote:
>
>>> At the earlier CT meeting, I think someone proposed that there could be a
>>> check that the cert was in actual use at the place it said it was.
>>

---

From: Ben Laurie <[email-masked]>
Date: Wed, 26 Feb 2014 11:28:59 +0000

> Having two end entity certs with the same serial number is going to be a

Not for ritual compliance. Same serial number _and issuer_ is a
problem. CT does not require this.

>> Not really - a precertificate needs to be signed.

But not by the right key - i.e. a change of spec would be required. I
think you might be able to cram the missing fields into attributes in
PKCS#10, though (which would also require additional spec).

---

From: Rob Stradling <[email-masked]>
Date: Wed, 26 Feb 2014 11:57:48 +0000

> problem. CT does not require this.

That's true, but CT does _permit_ same serial number and issuer.

I think Phill is saying that he wants ritual compliance to be the only 
option available.

>>>> If it is not then it is probably a CSR which would seem to be the
>>>> existing PKIX structure that fits its purpose.

Actually, I disagree with that.  A Precertificate is not a certificate 
signing _request_.  It's a certificate signing _promise_.

> PKCS#10, though (which would also require additional spec).

That would involve reinventing several wheels and making the whole thing 
far more complicated.  All just to achieve ritual compliance.

But if we must have ritual compliance with 5280, then my preferred 
solution is to "poison" the Issuer Name in the Precertificate.

For example...
Certificate Issuer Name: C=GB, O=My CA Ltd., CN=My CA
Precertificate Issuer Name: 1.2.3.4=CT, C=GB, O=My CA Ltd., CN=My CA

Sign both the Precertificate and the Certificate with the same CA 
private key.  Use the same serial number for both.

It wouldn't matter whether or not there exists a CA Certificate with the 
Subject Name "1.2.3.4=CT, C=GB, O=My CA Ltd., CN=My CA".

---

From: Ben Laurie <[email-masked]>
Date: Wed, 26 Feb 2014 12:27:29 +0000

On 26 February 2014 11:57, Rob Stradling <[email-masked]> wrote:
> That would involve reinventing several wheels and making the whole thing far
> more complicated.  All just to achieve ritual compliance.
>
> But if we must have ritual compliance with 5280, then my preferred solution
> is to "poison" the Issuer Name in the Precertificate.
>
> For example...
> Sign both the Precertificate and the Certificate with the same CA private
> key.  Use the same serial number for both.
>

Ah. I like that idea. Rather less than I like the idea of fixing the
need for ritual compliance, though.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 26 Feb 2014 12:35:09 +0000

<snip>

+1

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 Feb 2014 12:43:34 +0000

I'm not that keen on the phrase ritual compliance.

There is a lot of PKI code in the world that assumes
that issuer/serial is a unique identifier for a good
X.509 certificate.

It'd be best to not break such code by invalidating
that assumption.

If there's a good enough reason to do it, that might
be ok, but I figure the burden to demonstrate that
that is in fact ok should be on those arguing for such
a change.

S.

PS: No hats, just a comment:-)

---

From: Carl Wallace <[email-masked]>
Date: Wed, 26 Feb 2014 07:45:31 -0500

On 2/26/14, 7:35 AM, "Rob Stradling" <[email-masked]> wrote:

>>>solution
>>>private

While I agree that lack of a CA certificate with the matching naming
really doesn¹t matter, breaking name chaining seems like an odd way to
maintain ³ritual compliance".  Why not bump the version number instead?
v4 could be defined as a pre-certificate containing a poison extension and
a serial number that matches its v3 counterpart.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 26 Feb 2014 12:47:19 +0000

> I'm not that keen on the phrase ritual compliance.

I think it captures the essence quite nicely. What would you prefer?

> It'd be best to not break such code by invalidating

CT does not break that assumption: the second cert is effectively the
same cert, only lacking an SCT. It is also not a "good" certificate
(it has a critical extension no-one understands). Revocation of either
certificate implies revocation of the other. There's really only one
cert, conceptually.

> that is in fact ok should be on those arguing for such

This has been extensively discussed, and so far no reason has been
found to care other than ritual compliance.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 Feb 2014 13:03:46 +0000

> found to care other than ritual compliance.

Can you remind me where? I don't recall it but then maybe
I'm just forgetting

Ta,
S.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 26 Feb 2014 13:15:41 +0000

> Can you remind me where? I don't recall it but then maybe

On the CA/BForum lists.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 26 Feb 2014 13:28:36 +0000

> a serial number that matches its v3 counterpart.

Hi Carl.  I briefly discussed the idea of changing the version number 
with Ben a few months ago...

Rob: "More wacky idea...
I wonder if we could get away with putting 0x4354 in the certificate's 
Version field.  That might be enough to place it out-of-scope of 
RFC5280, and therefore out-of-scope of the duplicate serial number rule. 
  Probably more likely to break something though."

Ben: "I imagine it'd be hard to coerce most s/w to do this."

Also, I don't suppose IETF has the authority to define new X.509 
versions anyway.

---

From: Carl Wallace <[email-masked]>
Date: Wed, 26 Feb 2014 08:33:39 -0500

>with Ben a few months ago...

Sorry for the rehash.  There are occasions where I miss an email in this
list:-)

>Ben: "I imagine it'd be hard to coerce most s/w to do this."

The same probably applies to name chaining.

>Also, I don't suppose IETF has the authority to define new X.509

It’d certainly be cleaner to bump a version.  You could also do something
like define the pre-certificate to be an X.509 certificate as defined in
the RFC wrapped in a ContentInfo and forget about mucking with names or
version numbers.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 Feb 2014 13:37:07 +0000

>> Can you remind me where? I don't recall it but then maybe

Will I be the first to say "doesn't count"? :-)

But I was reminded offlist of the poison extension which
I'd forgotten. And I think that probably does solve the
problem and was discussed (though not extensively maybe)
in the process of doing 6962.

But absent that extension this would be about more
than ritual compliance I figure.

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 26 Feb 2014 08:41:45 -0500

> question. What is the relevance of CT to SMTP+STARTTLS?

The work factor for getting a bogus certificate is fixed in time. Without
CT the cost of getting a bogus certificate is $X. With CT the cost is still
$X but only up to the point where the certificate is notarized at which
point the cost of forging that certificate has gone to breaking the
cryptography (assumed to be infinity).

If we presume the existence of a common CT infrastructure such that it is
possible to query all the logs at one point then we have a mechanism for
requesting all the certificate information on a domain.

We can extend that approach in several ways:

* More types of certificate: S/MIME certs and PGP endorsements.
* Policy statements signed under a notarized certificate.

I am not sure that it makes a lot of sense to consider them in the same pot
though because email has very different protocol requirements and
constraints. It is asynchronous which means that we don't really care about
latency much, certainly not at the sub second level. But that also means we
can't pass credentials in-band as in SSL.

What I am looking to do in PPE is that when keys are generated, a
self-signed certificate is posted to a Cryptographic Advisor (CA for short)
which can interface to whatever next gen PKI emerges. When sending a
message the sender can pull information from their CA. Both groups are
using the Omnibroker protocol for this which is simply a JSON version of a
generalized XKMS, the question being 'how does X connect to Y to do Z'

So an Omnibroker answer could be 'encrypt the message under S/MIME using
this cert and force the use of STARTTLS for the transport.'

The question I haven't addressed yet in code is where those statements come
from. My belief is that this will involve the user signing a policy
statement to say what their end-to-end security statement is. It seems to
make sense for the site to also make a signed policy statement to say that
they always offer SSL on SMTP (and possible make the statement for some
other protocols like http). But this is not that difficult to specify. The
only real choice is ASN.1 or JSON and I think the preference is clear.

So at the very least I expect any S/MIME / PGP / Policy notary
infrastructure to feed into the same metanotary infrastructure as CT. It is
also quite possibly the incentive that would cause browsers besides Google
Chrome to consider implementing CT. Except for the case in which an
attacker knows that the target only uses IE or Firefox or Safari any bogus
cert is going to be detected in the Chrome CT client side check.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 26 Feb 2014 13:46:28 +0000

> Sorry for the rehash.  There are occasions where I miss an email in this

No need to apologize.  It was an off-list discussion.  :-)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 26 Feb 2014 08:46:34 -0500

+1

A key ceremony is after all a ritual. And one of the social functions of
rituals is to ensure that process is followed correctly. So saying 'mere
ritual' is like saying 'mere semantics' when these are meaning.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 26 Feb 2014 13:46:41 +0000

On 26 February 2014 13:41, Phillip Hallam-Baker <[email-masked]> wrote:
> The work factor for getting a bogus certificate is fixed in time. Without CT
> the cost of getting a bogus certificate is $X. With CT the cost is still $X
> but only up to the point where the certificate is notarized at which point
> the cost of forging that certificate has gone to breaking the cryptography
> (assumed to be infinity).
>
>
> latency much, certainly not at the sub second level.

Exactly, so it would be entirely possible to check with the log(s)
before proceeding with the connection. This is nice because we could
(I think!) even not require the SCT to appear in the TLS connection at
all - the client could look up the cert by hash...

> But that also means we

I'm not sure what you mean by this? Credentials pertaining to the
sender/recipient? Clearly server credentials can be sent in-band.

> which can interface to whatever next gen PKI emerges. When sending a message
> the sender can pull information from their CA. Both groups are using the
> Omnibroker protocol for this which is simply a JSON version of a generalized
> XKMS, the question being 'how does X connect to Y to do Z'
>
>
> Chrome to consider implementing CT. Except for the case in which an attacker
> knows that the target only uses IE or Firefox or Safari any bogus cert is
> going to be detected in the Chrome CT client side check.
>
>
>
> --

---

From: Ben Laurie <[email-masked]>
Date: Wed, 26 Feb 2014 13:49:08 +0000

> than ritual compliance I figure.

Maybe, but that point is moot :-)

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 26 Feb 2014 06:13:51 -0800

Did anyone consider using RFC4211 CRMF requests as "pre-certificates"?
CRMF has both issuer and serialNumber, as well as extensions. The
CertTemplate of RFC4211 is basically a TBSCertificate.

Cheers,
Tomas

PS: time to change subject of the thread?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 26 Feb 2014 10:29:04 -0500

> all - the client could look up the cert by hash...

Yes, CT might be applicable but it is designed to meet constraints that
probably don't apply.

> sender/recipient? Clearly server credentials can be sent in-band.

PPE is mostly focused on end-to-end encryption.

We can pass certs for SSL in-band. But right now CA issued certs are only
required for email clients doing SUBMIT and the implementations are weak.
OK so it turned out that Apple's wasn't meant to ignore the server cert
like I assumed. But I have an attack that negates the CA cert checking on
at least one other platform.

So adding CT to STARTTLS as is makes no sense unless the scope of CT is
wider than CA issued SSL certs. It means we either have to do security
policy or end-to-end encryption with client certs.

I do have a plan to do both but each requires more moving pieces and they
each require the same additional pieces. So there if we are going to invest
for one we might as well do both.

---

From: Trevor Freeman <[email-masked]>
Date: Thu, 27 Feb 2014 04:18:45 +0000

SMTP servers for large organizations and public email services do have performance considerations so I would not totally dismiss this issue. There likely is some tolerance of delays bit not a lot.

Typical case for TLS client auth with SMTP is server to server submission not client submission. The majority of email servers have self signed certificates for SMTP. However where organizations want TLS auth to work for SMTP they use CA issued SSL like certificates for the email servers.  The main difference with pure SSL certificates is typically an SMTP server support multiple SMTP domain so has multiple domain names in the certificates.

TLS server auth is also different for client and server submission. Again, both would be more tolerant of some delays.

________________________________
From: Phillip Hallam-Baker <[email-masked]>
Sent: 26 February 2014 07:29
To: Ben Laurie
Cc: Trevor Freeman; [email-masked]; Paul Hoffman; Daniel Kahn Gillmor
Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP

Yes, CT might be applicable but it is designed to meet constraints that probably don't apply.

We can pass certs for SSL in-band. But right now CA issued certs are only required for email clients doing SUBMIT and the implementations are weak. OK so it turned out that Apple's wasn't meant to ignore the server cert like I assumed. But I have an attack that negates the CA cert checking on at least one other platform.

So adding CT to STARTTLS as is makes no sense unless the scope of CT is wider than CA issued SSL certs. It means we either have to do security policy or end-to-end encryption with client certs.

I do have a plan to do both but each requires more moving pieces and they each require the same additional pieces. So there if we are going to invest for one we might as well do both.