Ben,
On 11 January 2016 at 17:31, Karen Seo <[email protected]
<mailto:[email protected]>> wrote:
Folks,
I agree with the approach discussed on the list of simplifying
6962-bis to focus only on specifications for the CT log by moving
the detailed specifications for other components of the CT system
to other documents. This is in line with a message from Melinda on
July 2 re: client behavior, and a message from Rich Saltz on July
6 re: the Auditor function. To facilitate moving requirements for
the CA/Subject part of the system, I propose that we make the
changes below with regard to statements about CT requirements for
CA and Subject behavior. These changes will also help to address
some of the concerns that have been cited elsewhere aboutthe text
of 6962-bis (e.g., issues 139, 140, 144).
The tag "client behaviour" is an unfortunate choice, because it mixes
up various different concerns. The particular concern that was
intended to be separated was what clients do UI-wise in response to
the presence of lack of transparency information.
I agree that the phrase "client behavior" is too broad. But, I also
think that not all of what
a client does in the lack of valid CT info is strictly a UI issue. For
example, Eran noted that the architecture doc distinguishes between what
a client does in the absence of an SCT vs. what
it does if there is an SCT but the sig fails. This, IMHO, is a
legitimate protocol issue that the
WG has not addressed. David took a position on this in his browser
spec, but that's just an
initial proposal that needs to be reviewed and discussed by the WG.
However, at least the issue is
clearly stated in that doc and thus provides a basis for discussion.
Other client behaviour, such as following the protocol, is _not_ out
of scope for 6962-bis. Indeed, it seems counter-productive to remove
it, since that's the document implementers have to actually read in
order to implement CT. It makes no sense to define one side of a
protocol in one document and the other in another.
The text in 6269-bis is still rather odd in discussing client behavior
in the protocol context.
It makes comments (not using standards language) about clients requiring
all connections to
be accompanied by SCTs:
TLS clients can thus require that all certificates they accept as
valid are accompanied
by signed timestamps.
If I were implementing a client this would sound like a requirement,
especially in the absence
of any RFC that purports to be a client spec. The text above is an
example of why I feel we
need an separate client spec that is clear about requirements.
Similarly vague text appears elsewhere, e.g.,
Since certificates may not be accepted by TLS clients unless logged, ...
The question of whether a (TLS) client is expected to contact a log
directly to acquire an STH is also
not clearly described with text like:
When a client requests a log's latest STH ...
Since the next sentence refers to "marking clients" a reader may infer
that TLS clients
are required to acquire STHs. This is a more subtle issue than
suggested by this text.
In general, 6962-bis uses the term "client" to refer to all log clients,
but usage is
sometimes inconsistent, leading to ambiguity wrt TLS client (aka bowser)
requirements.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
