Subject: [Trans] Some comments on draft-ietf-trans-rfc6962-bis-16

From: Andrew Ayer <[email-masked]>
Date: Tue, 14 Jun 2016 20:31:19 -0700

Section 6.6 (get-all-by-hash): It's not clear whether the inclusion
proof is to the requested STH or to the returned STH.  I'm pretty sure
it's supposed to be the returned STH, but this wording suggests it's
the requested STH:

        tree_size:  The tree_size of the tree on which to base the
        proofs, in decimal

In this wording, it's unclear what "selected STH" refers to:

        inclusion:  A base64 encoded "TransItem" of type
        "inclusion_proof_v2" whose "inclusion_path" array of Merkle
        Tree nodes proves the inclusion of the chosen certificate in
        the selected STH.

Section 10.1 (metadata): Is the Final STH specified as a TransItem of
type signed_tree_head_v2 or as a tree_size integer?

Section 10.2.2 (Reconstructing the TBSCertificate): It's also necessary
to remove the Transparency Information extension, but this step is
omitted.

Sections 10.2.5 - 10.2.7 (compliance): It's unclear what role the TLS
Feature extension plays.

10.2.5 says that compliance means "accompanied by at least one valid
SCT."

10.2.6 says that if transparency_info is present in the TLS
Feature extension, then "CT compliance ... is required" and that "TLS
clients MUST treat certificates which fail this requirement as
non-compliant."  In other words, non-compliance must be treated as
non-compliant, which isn't saying anything.

10.2.7 says that if the certificate chain is non-compliant, the "TLS
client MUST refuse the connection," which renders the TLS feature
extension unnecessary.

I assume the intent is that if transparency_info is in the TLS Feature
extension, then TLS clients MUST refuse connections using non-compliant
chains.  Otherwise, they MAY refuse connections using non-compliant
chains, depending on the client's policy.

---

From: Eran Messeri <[email-masked]>
Date: Wed, 15 Jun 2016 15:56:59 +0100

I'll send a pull request to address the comments, I've replied to some
in-line.

>         Tree nodes proves the inclusion of the chosen certificate in
I've changed the description to say 'returned STH' rather than 'selected
STH' for more clarity. I didn't change the tree_size description as it
seems obvious to me this is what the client requests, but text to clarify
that this may not be what the client gets is welcome.

> type signed_tree_head_v2 or as a tree_size integer?
It doesn't have to be specified, but I've added a recommendation to provide
it as a TransItem.

> to remove the Transparency Information extension, but this step is
Good point, added.

> chains, depending on the client's policy.
What changes do you suggest here? That section 10.2.6 explicitly state that
a TLS client must refuse the connection in case of non-compliance?

>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Andrew Ayer <[email-masked]>
Date: Wed, 15 Jun 2016 12:26:15 -0700

On Wed, 15 Jun 2016 15:56:59 +0100
Eran Messeri <[email-masked]> wrote:

> > proof is to the requested STH or to the returned STH.  I'm pretty
> > sure it's supposed to be the returned STH, but this wording
> > suggests it's the requested STH:
> >
> I've changed the description to say 'returned STH' rather than
> 'selected STH' for more clarity. I didn't change the tree_size
> description as it seems obvious to me this is what the client
> requests, but text to clarify that this may not be what the client
> gets is welcome.

I'll think about it.  Changing "Selected STH" to "Returned STH" is
probably good enough.

> > Sections 10.2.5 - 10.2.7 (compliance): It's unclear what role the
> > TLS Feature extension plays.
> >
> 
> > Feature extension, then "CT compliance ... is required" and that
> > "TLS clients MUST treat certificates which fail this requirement as
> > I assume the intent is that if transparency_info is in the TLS
> > Feature extension, then TLS clients MUST refuse connections using
> > non-compliant chains.  Otherwise, they MAY refuse connections using
> > non-compliant chains, depending on the client's policy.
> >
> What changes do you suggest here? That section 10.2.6 explicitly
> state that a TLS client must refuse the connection in case of
> non-compliance?

I've opened a pull request on GitHub for my suggested changes:

https://github.com/google/certificate-transparency-rfcs/pull/173

Regards,
Andrew