Subject: Re: [Trans] [ct-policy] Re: Certificate Transparency Newsletter - August 2015

From: Rob Stradling <[email-masked]>
Date: Wed, 4 Nov 2015 12:28:10 +0000

Tom,

I just raised http://trac.tools.ietf.org/wg/trans/trac/ticket/113 to 
track this.

How do you envisage that we let "a site owner dictate that CT should 
always be enabled for their domain"?
Some sort of HTTP header (a la HSTS and HPKP), perhaps?
Do you think this is something that the TRANS WG should specify (in 
6962-bis or some other document)?  Or should we punt it to WEBSEC or 
some other place?

Thanks.

On 19/10/15 17:29, Tom Ritter wrote:
> On 19 October 2015 at 09:05, Rob Stradling <[email-masked]> wrote:
>> Perhaps 6962-bis should prohibit or recommend against using TLS Feature for
>> the CT TLS extension then.  Or...
>>
>> Actually, I can't find any explicit requirement in RFC7633 that says words
>> to the effect of "The TLS server MUST send TLS extension X".  The actual
>> requirements are expressed more vaguely than that.  e.g.
>>    "A server offering an end-entity certificate with a TLS feature
>>     extension MUST satisfy a client request for the specified feature"
>>    "If these features are requested by the client in its ClientHello
>>     message, then the server MUST return a ServerHello message that
>>     satisfies this request."
>>
>> So, perhaps 6962-bis could specify that, if a TLS client sends the CT TLS
>> extension and the TLS server's cert contains the TLS Feature cert extension
>> with the CT TLS extension identifier, then the TLS server MUST "satisfy the
>> request" by sending SCTs via any of the three supported mechanisms (CT TLS
>> extension, cert extension, stapled OCSP response extension).
>
> So... you could. But it wouldn't solve the generic problem of letting
> a site owner dictate that CT should always be enabled for their
> domain.  The reason I'm critical of 7633 is that it only applies to a
> single certificate[0].  If I want to 'enforce' CT for a single
> certificate, via a x509 extension... I could just put the CT x509
> extension in the certificate.
>
> I'm opposed to the idea of a x509 extension seen on one certificate,
> once, applying a policy for the entire domain. For one thing it's
> weird, and for another thing it has no way to indicate how long the
> policy should apply for. (And it couldn't work for wildcard certs.)
>
> [0] Now technically where 7633 really comes into play and is very
> useful is when it's included in intermediates or (my pounding heart be
> still) - root certs.  In *that* case it would work great for requiring
> CT... but not for site owners, for certificate authorities.  A CA is
> assured that all the certs it issues will be publicly logged, and it
> can use this as a check against misissuance.  I think that's great...
> but it still doesn't help site owners. =)
>
> -tom
>

-- 
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: Jeremy Rowley <[email-masked]>
Date: Wed, 4 Nov 2015 12:40:32 +0000

I was thinking it should be similar to mustStaple. Makes sense as it serves a similar purpose. Not sure which WG it belongs in though. 

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Rob Stradling
Sent: Wednesday, November 4, 2015 5:28 AM
To: Tom Ritter; certificate-transparency
Cc: [email-masked]; [email-masked]
Subject: Re: [Trans] [ct-policy] Re: Certificate Transparency Newsletter - August 2015

Tom,

I just raised http://trac.tools.ietf.org/wg/trans/trac/ticket/113 to track this.

How do you envisage that we let "a site owner dictate that CT should always be enabled for their domain"?
Some sort of HTTP header (a la HSTS and HPKP), perhaps?
Do you think this is something that the TRANS WG should specify (in 6962-bis or some other document)?  Or should we punt it to WEBSEC or some other place?

Thanks.

On 19/10/15 17:29, Tom Ritter wrote:
>> Perhaps 6962-bis should prohibit or recommend against using TLS 
>> Feature for the CT TLS extension then.  Or...
>>
>> Actually, I can't find any explicit requirement in RFC7633 that says 
>> words to the effect of "The TLS server MUST send TLS extension X".  
>> The actual requirements are expressed more vaguely than that.  e.g.
>> So, perhaps 6962-bis could specify that, if a TLS client sends the CT 
>> TLS extension and the TLS server's cert contains the TLS Feature cert 
>> extension with the CT TLS extension identifier, then the TLS server 
>> MUST "satisfy the request" by sending SCTs via any of the three 
>> supported mechanisms (CT TLS extension, cert extension, stapled OCSP response extension).
>

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.

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

---

From: Jeremy Rowley <[email-masked]>
Date: Wed, 4 Nov 2015 12:41:27 +0000

Sorry that wouldn't work of course. It'd have to be a header. 

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Rob Stradling
Sent: Wednesday, November 4, 2015 5:28 AM
To: Tom Ritter; certificate-transparency
Cc: [email-masked]; [email-masked]
Subject: Re: [Trans] [ct-policy] Re: Certificate Transparency Newsletter - August 2015

Tom,

Thanks.

---

From: Tom Ritter <[email-masked]>
Date: Wed, 4 Nov 2015 09:26:30 -0600

> Some sort of HTTP header (a la HSTS and HPKP), perhaps?

Yea, probably.

> Do you think this is something that the TRANS WG should specify (in 6962-bis
> or some other document)?  Or should we punt it to WEBSEC or some other
> place?

A process question for the chairs I'd say. Probably websec? I've
volunteered to do this draft before, and it still stands.  Now that
Firefox is working on implementing the x509 version, they may be open
to implementing a header version as well - before the feedback seemed
to be "Yea, maybe, but will anyone implement in a timely fashion?"

-tom

---

From: Melinda Shore <[email-masked]>
Date: Thu, 5 Nov 2015 09:50:38 +0900

On 11/5/15 12:26 AM, Tom Ritter wrote:
> A process question for the chairs I'd say. Probably websec?

I haven't discussed this with Paul but my personal feeling is
that this wouldn't belong in the trans working group for two
reasons: 1) we are focused on specifying actual CT mechanisms,
and 2) the people who would understand the broader implications
of doing this typically have not been involved with trans.
I'm not sure what the right forum would be but we can certainly
raise it with websec and see how that goes.

Thanks,

Melinda