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

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 Jan 2013 11:30:36 +0000

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]

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

> of CAs issuing fake certificates instead of "misissued" certificates?

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