Subject: [therightkey] Fwd: New Version Notification for draft-laurie-pki-sunlight-00.txt

From: Ben Laurie <[email-masked]>
Date: Wed, 12 Sep 2012 14:45:40 +0100

---------- Forwarded message ----------
From:  <[email-masked]>
Date: 12 September 2012 14:24
Subject: New Version Notification for draft-laurie-pki-sunlight-00.txt
To: [email-masked]
Cc: [email-masked], [email-masked]

A new version of I-D, draft-laurie-pki-sunlight-00.txt
has been successfully submitted by Ben Laurie and posted to the
IETF repository.

Filename:        draft-laurie-pki-sunlight
Revision:        00
Title:           Certificate Transparency
Creation date:   2012-09-12
WG ID:           Individual Submission
Number of pages: 16
URL:
http://www.ietf.org/internet-drafts/draft-laurie-pki-sunlight-00.txt
Status:          http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight
Htmlized:        http://tools.ietf.org/html/draft-laurie-pki-sunlight-00

Abstract:
   The aim of Certificate Transparency is to have every public end-
   entity TLS certificate issued by a known Certificate Authority
   recorded in one or more certificate logs.  In order to detect mis-
   issuance of certificates, all logs are publicly auditable.  In
   particular, domain owners will be able to monitor logs for
   certificates issued on their own domain.

   In order to protect clients from unlogged mis-issued certificates,
   logs sign all recorded certificates, and clients can choose not to
   trust certificates that are not accompanied by an appropriate log
   signature.  For privacy and performance reasons log signatures are
   embedded in the TLS handshake via the TLS authorization extension
   [RFC5878], or in the certificate itself via an X.509v3 certificate
   extension [RFC5280].

   In order to ensure a globally consistent view of the log, logs also
   provide a global signature over the entire log.  Any inconsistency of
   logs can be detected through cross-checks on the global signature.

   Logs are only expected to certify that they have seen a certificate
   and thus, we do not specify any revocation mechanism for log
   signatures in this document.  Logs will be append-only, and log
   signatures will be valid indefinitely.

The IETF Secretariat

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 18 Sep 2012 10:27:38 -0400

Ben,

One of the things the transparency depends on is the domain owners and auditors monitoring the logs.  Given the size, if things are not verified, mis-issued certificates can fall through the cracks.  I have some minor suggestions that may strengthen the transparency I-D further.  You are welcome to consider some or all of these below:

1.  Discuss this dependency explicitly in the Security Considerations Section.

2.  Since the SCT extension has the certification path used by the log, discuss that the relying party optionally can match that with their path albeit the paths could be different in some instances.

3.  Include a flag or indication in the SCT extension if the Log has matched one of the CAs in the path authoritative for the domain name if the domain has registered such a CA using out of band means.  (I have not fully thought out what the relying party will do if flag says no, but would think that if the Log knows CAs for a domain and the certificate is not a descendant of one of the CAs, log will not automatically include the certificate in the log)

4.  Given the structure of SCT, the determination that a CA speaks for domain can be made by Log, Auditor or the relying party if they have a visibility into authorized CAs for the domain.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Laurie
Sent: Wednesday, September 12, 2012 9:46 AM
To: [email-masked]
Subject: [therightkey] Fwd: New Version Notification for draft-laurie-pki-sunlight-00.txt

---------- Forwarded message ----------
From:  <[email-masked]>
Date: 12 September 2012 14:24
Subject: New Version Notification for draft-laurie-pki-sunlight-00.txt
To: [email-masked]
Cc: [email-masked], [email-masked]

A new version of I-D, draft-laurie-pki-sunlight-00.txt has been successfully submitted by Ben Laurie and posted to the IETF repository.

Abstract:

The IETF Secretariat
_______________________________________________
therightkey mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/therightkey

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 Sep 2012 10:55:15 +0100

> 1.  Discuss this dependency explicitly in the Security Considerations Section.

I'm about to push a revised version, but I'll add something about this.

> 2.  Since the SCT extension has the certification path used by the log, discuss that the relying party optionally can match that with their path albeit the paths could be different in some instance…

The SCT does not contain the certification path for exactly this reason.

> 3.  Include a flag or indication in the SCT extension if the Log has matched one of the CAs in the path authoritative for the domain name if the domain has registered such a CA using out of band me…

I presume you're referring to the use of DANE or CAA or something of
that nature? In any case, the log's purpose is not to judge the
correctness or otherwise of any particular certificate, but to make a
public record so that others can judge.

That said, the log could include a flag that said "at the time of
issuance, the issuing CA was allowed to issue for the domain, by
virtue of a CAA record". The log would presumably have to also include
a DNSSEC chain showing that this was so. I'm not sure if DNSSEC chains
can be effectively timestamped, though, so it would be hard to prevent
the log from lying about this.

Finally, we have been considering defining an extension mechanism for
the log, and this kind of thing seems like it would fit right in. Does
anyone have views on this?

> 4.  Given the structure of SCT, the determination that a CA speaks for domain can be made by Log, Auditor or the relying party if they have a visibility into authorized CAs for the domain.

Surely this determination is independent of the log? The log could say
in the SCT what things looked like at time of submission, but as I say
above, the log's function is to record, not judge.