Ben,
...
To restate our position
first issue: does "our" = Google or just the authors of this document?
on this: we don't know what clients will do in
response to failure to comply with CT, and nor are we in a position to
mandate it.
I agree with the last part of this statement, irrespective of the identity
of the "our" above.
We feel it is helpful to provide a mechanism by which the
issuance of certificates can be made open to public scrutiny.
that is clearly the premise of CT, yet absent a detailed analysis of how
transparency improves security, the premise is unsubstantiated.
Clearly
adoption of this mechanism does ultimately require that clients behave
somehow differently for certificates that do not conform, but we can't
dictate what that behaviour is.
maybe, maybe not. I'll await your comments on the new intro for the
attack model. In that text I make some observations about the importance of
browser behavior in the CT system.
For example, right now, the only client I know of that reacts to CT is
Chrome/Chromium, and the behaviour it (at least for Chrome - Chromium
comes in multiple flavours) currently exhibits is that text in some
dialogues is changed depending on whether CT is present and meets
Chrome's policies or not, and in the display/non-display of the EV
indicators for EV certificates. This behaviour has already been
through several versions and policy changes, and will continue to
evolve - and is not arrived at by IETF consensus, nor will it ever be.
nice of you to reaffirm that Google doesn't care about IETF standards
in this context.
So, I don't see how it can be a part of the I-D.
I agree that client responses to the presence or absence of an SCT
ought not be part of your document. Your document is really a spec for
CT log behavior and it should be retitled as such.
A CT architecture doc is needed, consistent with what has been done for
many IETF security area systems of this scale. The attack model I've been
working on is also a common element of an RFC suite for a security system
with this many moving parts. Descriptions of how a Monitor works, including
its relationship to logs and to Subjects, is needed. The audit function
needs
to be defined precisely if there is to be claim that CT can detect
misbehavior
by logs. Finally, the behavior of clients, in terms of what checks they
perform
on certs accompanied by SCTs, and whether they discriminate against
certs w/o SCTs.
also seems to be an essential element of a complete system description.
You argue that CT "... does ultimately require that clients behave
somehow differently
for certificates that do not conform." Yet you note that Google has not
yet figured
out what thus discriminatory behavior should be. Maybe this means that
the CT design
is not yet adequately mature, and thus it ought not move from
experimental, yet.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
