Rob,
6962-bis notes that:
"Those who are concerned about misissue can monitor the logs, asking
them regularly for all new entries, and can thus check whether
domains they are responsible for have had certificates issued that
they did not expect."
If you act as a monitor yourself, you can be sure that the logs you're
monitoring aren't misbehaving. You don't have to trust the logs.
I'm not sure I follow your argument above. If I act as my own monitor, I
will see the cert
issued to me, I can verify that it has one or more SCTs, and I could go
to each log for which
there is an SCT, to verify that the entry in in the log. But, how do I
know that the logs
that I contact are not misbehaving? They could show me entries other
than ones that might
conflict with my name space. Detection of that behavior is the job of
the audit function,
not a Monitor, right?
However, if you use the services of a third-party monitor instead
(which I expect most domain owners would prefer to do), then you have
to trust that that third-party monitor isn't hiding any certs from you.
agreed, but that's not the same as log misbehavior; it's Monitor
misbehavior.
Therefore, ISTM that some domain owners might want to be able to use
the services of multiple independent monitors simultaneously.
sure.
To facilitate this, it would be useful to define a standard API for
querying a monitor. This API would allow callers to search for certs
issued to a particular domain name/space, setup notifications of
(mis-)issuance, etc.
I'm always in favor of interface standards, but this is not the sort of
API I would have imagined.
I've thought that one might want a standard way for a client of a
Monitor to submit the info needed
for the Monitor to "protect" the client: a set Subject names/SANs, a set
of public keys associated
with each Subject/SAN, and a way to inform the client when a cert is
logged that does not match
the supplied info. One also should be able to include an indication of
what cert profile these
certs are supposed to match, e.g., DV, EV, SMIME, IPsec, ...
Consider this my contribution to your draft.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
