Subject: Re: Last Call: <draft-laurie-pki-sunlight-05.txt> (Certificate Transparency) to Experimental RFC

From: SM <[email-masked]>
Date: Thu, 10 Jan 2013 09:10:32 -0800

At 11:33 20-12-2012, The IESG wrote:
>The IESG has received a request from an individual submitter to consider
>the following document:
>- 'Certificate Transparency'
>   <draft-laurie-pki-sunlight-05.txt> as Experimental RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2013-01-24. Exceptionally, comments may be

In Section 1:

   "Certificate Transparency aims to mitigate the problem of misissued
    certificates by providing publicly auditable, append-only, untrusted
    logs of all issued certificates."

It seems that CAs are having trust issues.  ETSI TS 102 042 audits 
looks like paperwork instead of assessing what could go wrong 
[1].  Isn't Certificate Transparency trying to mitigate the problem 
of CAs issuing fake certificates instead of "misissued" certificates?

In Section 3:

   "Logs MUST NOT impose any conditions on copying data retrieved from
    the log."

I am reading the above as meaning that the data retrieved is in the 
public domain.  Is that correct?  The wording could be improved as 
logs do not have any consciousness.

In Section 3.1:

  "In order to enable attribution of each logged certificate to its
   issuer, the log SHALL publish a list of acceptable root certificates
   (this list might usefully be the union of root certificates trusted
   by major browser vendors)."

Why is this a "SHALL" instead of a "MUST"?  I suggest a better 
wording for "log" in the above as "log" is defined as "a single, 
ever-growing, append-only Merkle Tree of such certificates".  There 
are other occurrences of "log" in the draft that should be reviewed.

In Section 4:

   "Messages are sent as HTTPS GET or POST requests.  Parameters for
    POSTs and all responses are encoded as JSON objects.

I suggest adding a reference for JSON objects.

   "It must map one-to-one to a known public key (how this
    mapping is distributed is out of scope for this document)."

This looks like a requirement.

   "A compliant v1 implementation MUST NOT expect this to
    be 0 (i.e. v1)."

What happens if the v1 implementation gets a zero?

In Section 7.3:

   "Violation of the append-only property is detected by global gossiping,
    i.e., everyone auditing logs comparing their versions of the latest
    signed tree heads."

In my humble opinion that's a practical approach.

Section 7 is about security and privacy considerations.  I didn't see 
any privacy considerations in Section 7.  I don't think that it is 
really needed as the document is about publicly auditable logs.  If 
there is any concern about information disclosure it could be 
mentioned that Certificate Transparency is for public end-entities.

Regards,
-sm

1. Confirm that there are automatic blocks in place for high-profile 
domain names (including those targeted in the DigiNotar and Comodo 
attacks in 2011)

---

From: Ben Laurie <[email-masked]>
Date: Mon, 14 Jan 2013 14:38:17 +0000

On 14 January 2013 11:30, Stephen Farrell <[email-masked]> wrote:
>
> FYI. Some comments sent just to the IETF list. Please
> respond there.
>
> Thanks,
> S.
>
>
> -------- Original Message --------
> Subject: Re: Last Call: <draft-laurie-pki-sunlight-05.txt> (Certificate
> Transparency) to Experimental RFC
> Date: Thu, 10 Jan 2013 09:10:32 -0800
> From: SM <[email-masked]>
> To: [email-masked]
>

Is there a difference, when you get down to it?

> public domain.  Is that correct?

Yes. This is necessary for auditing/monitoring.

>  The wording could be improved as

I have changed it to "Log operators..."

> Why is this a "SHALL" instead of a "MUST"?

MUST and SHALL are equivalent.

>  I suggest a better

What wording do you suggest that would be better?

> I suggest adding a reference for JSON objects.

There will be in the next version.

> This looks like a requirement.

If it were a requirement it would say MUST - but in any case, it is
gone in the next version.

> What happens if the v1 implementation gets a zero?

I don't understand the question.

> any privacy considerations in Section 7.

Good point, I have renamed it.

>  I don't think that it is
> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey

---

From: [email-masked] (Martin Rex)
Date: Mon, 14 Jan 2013 22:24:22 +0100 (CET)

SM wrote:
> The IESG wrote:

More appropriately, RPs are having trust issues with public CAs,
and domain owners have found themselves more than once faced with
the unexpected fraudulent issuance of certs allegedly authorized
for their domains.

Certificate Transparency (CT), the ways I understand it, is basically
a public certificate issuance log for public CAs (those you find in
the CABrowser forum, who have their their (Root)CA certs distributed
as pre-trusted in common Web Browsers).

Such a public cert issuance log can be used by domain owners to detect
cert issuance for their domains that they didn't actually authorize
or ask for (so which are likely fraudulent) *much* earlier after cert
issuance.  So far, this would often only become apparent if the CA
detected the fraudulent issuance itself, or when an attacked RP
would realize that it is being attacked with a perfectly valid(!!)
server certificate.  The latter typically happens only with RPs
that perform cert pinning and where the user that is alerted about
an unexpected server cert change is sufficiently knowledgable to
distinguish a likely misissued server cert from a mere roll-over
server cert change.

X.509/PKIX has a serious design/birth defect in certificate revocation,
by lacking the means to convey the information whether a certificate
was properly issued and is properly visible to CA audits and
desaster recovery procedures.  For CRLs that design flaw can not be
fixed within the protocol itself, because CRLs are a pure blacklisting
mechanism that blindly assumes that the absence of a revocation
implies that a certificate has been properly issued.  An assumption
that has been proven to be a flawed in the real world several times by now.

When complementing CRL checking with CT, this X.509 CRL design flaw
can be mitigated.

There currently are proposals for fixing a slightly different (but
related) problem for OCSP in PKIX, but there are some X.509 fanciers
that appear enfuriated by the idea of admitting that X.509 CRLs and
rfc2560-OCSP contain a shortcoming that needs fixing, so progress
in PKIX is slow.

The scope of CT is different than whatever PKIX might deliver
(even when rough consensus can be obtained within PKIX to improve OCSP),
because CT allows domain owners to monitor/determine issuance of certs
for their domain from public records.

-Martin

---

From: SM <[email-masked]>
Date: Mon, 14 Jan 2013 14:04:55 -0800

Hi Ben,

As a FYI, Eliot Lear posted a review at 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg08649.html

>Is there a difference, when you get down to it?

If I am talking to a non-English speaker it might be clearer when I 
say "fake Gucci handbag" instead of "misissued Gucci handbag".

I don't have a strong opinion about this.

>Yes. This is necessary for auditing/monitoring.

Ok.

>I have changed it to "Log operators..."

Ok.

>MUST and SHALL are equivalent.

Yes.

>What wording do you suggest that would be better?

I'll take this off-list.

>I don't understand the question.

If I guarantee that I won't use a zero the code doesn't expect 
it.  If the code gets a zero it might not handle it gracefully.  It's 
safer to tell the receiver to ignore a zero than to tell the sender 
not to send a zero.

Regards,
-sm