Melinda Shore | 21 Jul 17:09 2014
Picon

Slides!?

If you're going to be showing slides during the trans
working group session on Friday, please send them to
Paul and me by noon Thursday, EDT.

Thanks,

Melinda
Melinda Shore | 21 Jul 15:30 2014
Picon

Meetecho available during trans session

For those unable to be physically present during the
trans session on Friday, we've requested Meetecho
coverage.  The link will be: http://www.meetecho.com/ietf90/trans
once the session is underway.

Melinda
Rick Andrews | 18 Jul 20:11 2014

List of Roots Accepted by Log Servers

I finally got around to reading the list of roots accepted by the pilot and aviator log servers (using the get-roots command). I see a number of our roots that seem inappropriate to me, meaning that we have never issued SSL certs (EV or non-EV) from those roots, and never intend to. It seems to me that Google cast a wide net to add all relevant roots to kickstart the log servers (perhaps bootstrapped from Mozilla’s root list?), but at some point (before CT is “live”) I would like to see the list trimmed.
 
My thinking is that if I somehow issue an SSL cert from a root that I did not intend to use for SSL, I would prefer to catch that as quickly as possible; ideally, when the log server refuses to give me an SCT. Is Google willing to remove roots from pilot and aviator?
 
I think we need a somewhat formal way for CAs to provide log server operators their list of roots, and update that over time. For example, we have a few new roots that we expect to be using in the next few months, and I need to make sure they’re added to log servers before I start using them. If log server operators provide an service level agreement (SLA) for such changes, that would be great.
 
Comments?
 
-Rick
 
 
_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
Internet-Drafts | 10 Jul 18:53 2014
Picon

I-D ACTION:draft-ietf-trans-rfc6962-bis-04.txt

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public Notary Transparency  Working Group of the IETF.

    Title         : Certificate Transparency
    Author(s)     : B. Laurie, et al
    Filename      : draft-ietf-trans-rfc6962-bis
    Pages         : 31 
    Date          : 2014-07-10 

   This document describes a protocol for publicly logging the existence
   of Transport Layer Security (TLS) certificates as they are issued or
   observed, in a manner that allows anyone to audit certificate
   authority (CA) activity and notice the issuance of suspect
   certificates as well as to audit the certificate logs themselves.
   The intent is that eventually clients would refuse to honor
   certificates that do not appear in a log, effectively forcing CAs to
   add all issued certificates to the logs.

   Logs are network services that implement the protocol operations for
   submissions and queries that are defined in this document.

A URL for this Internet-Draft is:
https://www.ietf.org/internet-drafts/draft-ietf-trans-rfc6962-bis-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment (draft-ietf-trans-rfc6962-bis): message/external-body, 70 bytes
_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
Melinda Shore | 9 Jul 19:33 2014
Picon

Meeting agenda uploaded

I've uploaded a first cut at a meeting agenda for IETF 90.
Please let Paul and I know of any changes or additional requests.
Also, if you've got a slot on the agenda please get slides to
us by Wednesday before the session; it's a big help for remote
participants and non-native English speakers to have those
available reasonably well in advance.

Melinda
Melinda Shore | 9 Jul 04:21 2014
Picon

Walking through the issue tracker: Ticket #10

I see that Rob's taken ownership of this one (on precertificate
SCTs and OCSP) - it looks like there was agreement about how
to handle it, but is there text?

Thanks,

Melinda
Melinda Shore | 4 Jul 01:18 2014
Picon

Toronto planning

We've got a 2.5-hour slot on Friday, and based on discussions with Paul
and Ben, here's what we think is going to be on the agenda:

1) 6962bis status, updates, issues.  This will include discussion
   of issues raised on the mailing list, issue tracker tickets against
   the document, and so on

2) Gossip protocols, or rather a gossip protocol proposal.  I do not
   believe there is a write-up of this anywhere yet, so this should be
   seen as the start of that discussion

3) Other applications.  We've had some discussion both here and offline
   of dnssec logging, and there's been some interest in logging
   signatures of executables/binaries

4) any other work that needs to be done.  At the last meeting we had
   a brief discussion of whether or not a client behavior document
   should be separated out of the bis document; without a volunteer to
   do it the question is moot.

What are we omitting or have we forgotten?  We'll get a firmer agenda
out towards the end of next week, based on this list and any additional
feedback.

Melinda
Melinda Shore | 3 Jul 21:57 2014
Picon

Walking through the issue tracker: Ticket #8

This ticket asks about a mechanism for looking up Merkle proofs for a
batch of certificates around the SCT timestamp.

It looks as if there's an agreement to provide a DNS-based mechanism.
It may be worth pointing out that it's occasionally difficult to get
agreement to move data into the DNS and that we'll need to be prepared
to answer questions about that in order to get the document through the
process.  So, if you're not familiar with RFC 6950 ("Architectural
Considerations on Application Features in the DNS") it may be worth
giving it a read.

Should this ticket be closed?

Melinda
Melinda Shore | 3 Jul 21:47 2014
Picon

Walking through the issue tracker: Ticket #4

Hey, all:

We have 10 open issues in the trans issue tracker
(http://trac.tools.ietf.org/wg/trans/trac/report/1)
and I'd like to walk through them and see where things
stand, what can be closed, etc.  I'm going to take the
liberty of assuming that the list is not comprehensive, as
nothing's been added in the last two months and nothing
from Steve's recent comments have been added.  And that's
okay - if the issue tracker isn't useful we don't need to
use it.

So, on to actual content: Ticket #4 asks whether signatures
should be treated consistently across certificates and
precertificates - i.e. should the TBS be signed in both
cases, rather than the entire certificate as is currently
specified for certificates.

Melinda
Stephen Kent | 3 Jul 20:39 2014
Picon

comments on Sections 7 + 9 (the last set of comments before Toronto)

Section 7

 

The Security Considerations include some statements that worry me.  It says “If a server presents a valid signed timestamp for a certificate, then the client knows that the certificate has been published in a log.” This is not quite true, since the certificate may be published later, or never at all. Please try to be more precise here.

 

It also says “…the client knows that the subject of the certificate has had some time to notice the misissue and take some action, such as asking a CA to revoke a misissued certificate.”  Since the client doesn’t know, with certainty, that the Subject is monitoring for mis-issuance, the client can’t know how long it may be before the mis-issuance may be remedied. The statement here needs to note that a client cannot assume how long it may be before mis-issuance problems are detected and remedied. The last sentence of the first paragraph of this section does a good job of noting these limitations, but its message is diluted by the preceding statements.

 

The final paragraph is good, although “transparency” may be too much of a euphemism! The lack of a discussion of various scenarios with respect to how mis-issuance may occur (see my comments on the Introduction) makes it harder for a reader to understand the ways that CT is intended to address the problem of certificate mis-issuance. It  might be appropriate to compare CT to key pinning (draft-ietf-websec-key-pinning-17.txt) , for example, since both mechanisms attempt to deal with some of the same attacks.

 

Section 7.1 provides a good explanation of how MMD fits into the CT scheme. But it begins with an absolute statement about TLS clients rejecting certificates w/o an SCT. Absent a discussion of how to address partial deployment, the first sentence does not seem reasonable.

 

Section 7.3 seems to offer a warning that some examples of redacted names could be dangerous, but it provides only a couple of examples. Without a more precise definition of what constitutes a dangerously “overly redacted” precertificate, the warning here is not adequate. The statement “TLS clients MAY reject a certificate whose corresponding precertificate would be overly redacted.” seems impossible to implement, based on the level of specification presented here. (If a certificate is dangerously over-redacted, and we define what that means, maybe a SHOULD is more appropriate.) This subsection needs work, and may be indicative of a serious problem with respect to the security afforded by redacted precertificates.

 

Section 7.4 describes how two forms of log misbehavior can be detected. The first type of misbehavior is a violation of the MMD. This description is a bit worrisome as it specifies relying on a “trusted auditor” (a new term) if a client does not want to reveal what certificate is of interest. The alternative approach suggested (for a client that does not want to reveal what certificates are of interest) is to request proofs for a batch of certificates. A more algorithmic description of the suggested behavior should be provided, either here or in Section 5.4 (which probably needs to be re-written anyway), along with a definition for a “trusted auditor” (or just delete the term “trusted”). The second type of misbehavior, characterized as violating the append-only property, is detected by “global gossiping.” This is not a reasonable explanation of a countermeasure, given the lack of any detailed description of how such gossiping is to take place.

 

 

Section 9 raises an important topic, i.e., key rollover. But saying that this topic needs to be addressed in the future is worrisome. The WG needs to decide if it’s OK to postpone this critical aspect of the design to a future document.

<!-- /* Font Definitions */ <at> font-face {font-family:"&#65325;&#65331; &#26126;&#26397;"; panose-1:0 0 0 0 0 0 0 0 0 0; mso-font-alt:"Optima ExtraBlack"; mso-font-charset:128; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:fixed; mso-font-signature:1 134676480 16 0 131072 0;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:-536870145 1107305727 0 0 415 0;} <at> font-face {font-family:Cambria; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:-536870145 1073743103 0 0 415 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} <at> page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} -->
_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
Stephen Kent | 3 Jul 18:01 2014
Picon

Comments on Section 5

Section 5

 

This section discusses the different types of clients in the CT ecosystem. Saying that this section describes “typical” clients is rather open-ended, illustrative vs. normative. I suggest this section say that it enumerates the current set of clients that CT was designed to support, and note that other types of clients may be defined in the future.

 

The admonition that “All clients should gossip with each other, exchanging STHs at least;” is not suitable for a standard. First, since TLS Clients are an example of clients, this suggestion implies that every browser should “gossip” with every other browser. Do you really mean that? Also, since no protocol for “gossiping” is defined, this is not useful guidance. I suggest all references to “gossiping” be removed until the “separate document” mentioned here is written.

 

 

Section 5.1

 

The description of “Submitters” should list CAs and Web PKI certificate Subjects as the primary examples.

 

 

Section 5.2

 

This section says that “TLS clients are not directly clients of the log …” This seems to contradict the statement in 5.4 that says an Auditor might be part of a TLS client. Do you really want to exclude TLS clients? If so, then there needs to be an explanation of how TLS clients, who are the ultimate beneficiaries of CT, become aware of bad certificates and reject them in the future. Or, does CT assume that bad PR will always deter a CA fro m issuing a bad certificate?

 

This section states “In addition to normal validation of the certificate and its chain, they should validate the SCT by computing the signature input from the SCT data as well as the certificate and verifying the signature, using the corresponding log's public key." Ought the “should” be “SHOULD”? More importantly, I don’t recall seeing an algorithmic description of how a client matches a received end-entity certificate against an SCT(L). Given the variations allowed for SCT data (based on an end-entity certificate, end-entity pre-certificate, or name-constrained CA certificate) this really needs to be explained, in detail. You don’t need to provide the algorithm details here; putting the details in a normative appendix might be fine.

 

The text also says “Note that this document does not describe how clients obtain the logs' public keys." I think the document does need to posit how the public key for a log is obtained, in a secure fashion, and how key changes for logs are managed.

 

 

Section 5.3

 

The introduction for this subsection says that a monitor “watches for certificates of interest” but provides no details of how this is effected. Is each certificate of interest defined by a DNS name and associated CA, for example? Since this function is not described as a MAY, it merits as detailed a description as the correctness checking function for which the algorithm is provided.

 

 

Section 5.4

 

This section defines Auditors as taking “…partial information about a log as input and verify[ing] that this information is consistent with other partial information they have.” This description seems too vague to be in a standard. A higher level description of what an Auditor does is needed, plus a description of what inputs it operates on, and what algorithms it uses (at a minimum) to do its job. <!-- /* Font Definitions */ <at> font-face {font-family:"&#65325;&#65331; &#26126;&#26397;"; panose-1:0 0 0 0 0 0 0 0 0 0; mso-font-alt:"Optima ExtraBlack"; mso-font-charset:128; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:fixed; mso-font-signature:1 134676480 16 0 131072 0;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:-536870145 1107305727 0 0 415 0;} <at> font-face {font-family:Cambria; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:-536870145 1073743103 0 0 415 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"&#65325;&#65331; &#26126;&#26397;"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} <at> page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} -->
_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans

Gmane