[cabfpub] Fwd: Re: [cabfquest] Draft Ballot 186 - Limiting the Reuse of Validation Information
jimmy at it.auth.gr
Mon Feb 6 06:11:10 UTC 2017
Re-porting for Jürgen
-------- Forwarded Message --------
Subject: Re: [cabfquest] Draft Ballot 186 - Limiting the Reuse of
Date: Fri, 3 Feb 2017 17:35:12 +0100
From: Jürgen Brauckmann <brauckmann at dfn-cert.de>
Reply-To: questions at cabforum.org
Organization: DFN-CERT Services GmbH
To: Ryan Sleevi <sleevi at google.com>, CABFPub <questions at cabforum.org>
Ryan Sleevi schrieb:
> On Wed, Feb 1, 2017 at 10:49 AM, Ryan Sleevi <sleevi at google.com> wrote:
>> Reposing on behalf of Jürgen Brauckmann <brauckmann at dfn-cert.de>
>> Ryan Sleevi via Public schrieb:
>>> 4. The CA has not revoked any certificates which contain certificate
>>> information verified using the document or data.
>> Your goal is to kill OV?
> And why does OV require revocation? OV totally remains valid, so long as
> you're not revoking those certs.
Vetting for OV certificates is expensive and time consuming. Being
forced to do that every time a certificate is revoked will make it
nearly impossible to maintain that class of certs. Hence my inital comment.
But the discussion progressed substantially to limit "the damage" to
certain revoke reasons:
> As mentioned in my other message just now, beyond keyCompromise, what other
> reasons would you revoke a cert? Surely if you revoke a cert because of
> "affiliationChanged", you should very well be revalidating the affiliation
> before issuing a new cert
Well, there is no revoke reason "domain affiliaton changed" or "server
admin affiliation changed" or "organization affiliation changed".
So, by using X.509 revoke reasons to express policy, we are very coarse.
[may be reposted to public, thanks]
Questions mailing list
Questions at cabforum.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public