Subject: [Trans] [trans] #117 (rfc6962-bis): log description as "untrusted"

From: "trans issue tracker" <[email-masked]>
Date: Fri, 13 Nov 2015 18:42:37 -0000

#117: log description as "untrusted"

 The introduction stills refers to logs as “untrusted” yet this is a
 potentially confusing term for readers. Logs are nominally trusted, but
 subject to independent Monitoring and Auditing.  Remember the Regan-era
 slogan "trust but verify" :-)

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-trans-
  [email-masked]           |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  minor        |  Milestone:
Component:  rfc6962-bis  |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/117>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Fri, 13 Nov 2015 23:55:19 -0000

Comment (by [email-masked]):

 FWIW, I really like the term "untrusted".

 Remember the “I don’t trust used car salesmen as far as I could throw
 them.” idea -- the whole point is to not _have_ _to_ trust the logs,
 aight?

 Severity:  -            |  Resolution:
 Keywords:               |

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/117#comment:1>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 16 Nov 2015 11:00:24 -0000

Comment (by [email-masked]):

 Steve, Linus,

 Would this rework of the first two sentences work for both of you?

 "Certificate transparency aims to mitigate the problem of misissued
 certificates
 by providing append-only logs of all issued certificates. The logs do not
 need
 to be trusted because they are publicly auditable. Anyone may verify the
 correctness of each log and monitor when new certificates are added to
 it."

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/117#comment:2>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 16 Nov 2015 11:17:22 -0000

Works for me. Thanks.

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/117#comment:3>
trans <http://tools.ietf.org/trans/>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 16 Nov 2015 11:15:17 -0500

If logs were not trusted, then nobody would rely on them. It seems
more accurate to say that a log is trusted by its clients (CAs, TLS clients,
  and Monitors) until it is detected misbehaving. An essential aspect of CT
is that it tries  to provide mechanisms to enable third parties to 
detect such mis-behavior.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 16 Nov 2015 11:23:01 -0500

Rob,

that text is much better.

how about "all issued certificates" -> "all certificates submitted by
CAs, certificate Subjects, or others."

Steve

---

From: Rob Stradling <[email-masked]>
Date: Mon, 16 Nov 2015 21:29:48 +0000

Steve,

I would say that "...all issued certificates" does summarize the "aim" 
of the CT ecosystem pretty well: in the long run, we expect TLS clients 
to require CT compliance for all publicly trusted certs, meaning that 
interested parties have a strong incentive for all certs to be logged.

I'm not as keen on your proposed text, TBH.

However, I realize that the "all" in "all issued certificates" is a bit 
misleading when you consider the options for logging precertificates 
and/or name constrained intermediates in place of actual end-entity 
certs.  For that reason I'd be happy to drop the word "all" from my 
proposed rework of the first sentence...

"Certificate transparency aims to mitigate the problem of misissued 
certificates by providing append-only logs of issued certificates."

BTW, is there a reason why we're now having this discussion only on the 
mailing list, rather than continuing it where it started (i.e. on the 
issue tracker, which automatically copies each message to the mailing 
list) ?

On 16/11/15 16:23, Stephen Kent wrote:
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

-- 
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: Stephen Kent <[email-masked]>
Date: Mon, 16 Nov 2015 17:05:06 -0500

Rob,

> of the CT ecosystem pretty well: in the long run, we expect TLS 
> clients to require CT compliance for all publicly trusted certs, 
> meaning that interested parties have a strong incentive for all certs 
> to be logged.
yes, but this RFC should focus on a more narrow, accurate 
characterization, rather
than using the future optimistic tense (as it does whenever it talks 
about TLS clients
rejecting certs w/o SCTs).
> However, I realize that the "all" in "all issued certificates" is a 
> bit misleading when you consider the options for logging 
> precertificates and/or name constrained intermediates in place of 
> actual end-entity certs.  For that reason I'd be happy to drop the 
> word "all" from my proposed rework of the first sentence...
thanks.
> certificates by providing append-only logs of issued certificates."
WFM.
> BTW, is there a reason why we're now having this discussion only on 
> the mailing list, rather than continuing it where it started (i.e. on 
> the issue tracker, which automatically copies each message to the 
> mailing list) ?
no, not intentional.

Steve