On Mon, Oct 20, 2014 at 11:33:51PM +0200, Linus Nordberg wrote:
> Paul Wouters <[email protected]> wrote
> Mon, 20 Oct 2014 13:44:57 -0400 (EDT):
>
> | On Mon, 20 Oct 2014, Linus Nordberg wrote:
> |
> | as individual without chair hat...
> |
> | > Logs MUST verify that the submitted end-entity certificate or
> |
> | > My intention was to make the specification less restrictive by changing
> | >
> | > Logs MAY accept certificates that have
> | > expired, are not yet valid, have been revoked, or are otherwise not
> | > fully valid according to X.509 verification rules in order to
> | > accommodate quirks of CA certificate-issuing software.
> |
> | That seems to bring up the topic a bit too broadly I think? How about:
>
> The text above is the current text in 6962bis-4.
>
>
> | Logs MUST protect themselves against spam. They MAY require a
> | fully validated X.509 certification chain to one of their configured
> | trusted root CA's.
>
> This may be OK for the spam issue but certainly not for attribution.
Is attribution critical for the core functionality of CT? (I know this goes
back to the "purpose of CT" thread that Stephen's done a lot of work
defining, and I've got to get around to participating in that thread) While
I agree that the remediation mechanisms available increase if you know which
root CA to hassle to get a cert revoked, knowledge that a cert was issued
still has *some* value, even if there's no clear indication of who issued it
(in a fanciful future of infinite storage, where self-signed certs were
accepted in logs).
- Matt
--
Java. The elegant simplicity of C++. The blazing speed of Smalltalk.
-- From http://c2.com/cgi/wiki?SmalltalkMinusMinus
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
