The answers from CAs we typically see in this group are more along the lines of 
not thinking it necessary to revoke at all than needing more time, I'd say. So 
I don't really see what this idea that 24 hours would be too short is based on. 
I think relaxing the revocation time limit may in fact be a solution for a 
problem that doesn't exist (much). After all quite a few of these misissued 
certificates will not even work properly.

What I don't like is that the answers of CAs hardly ever explain what happened, 
how it was possible that it happened and what has/will be done to prevent is 
from happening again. It looks like they have no real incentive to do things 

Yes, in some cases the bad certificates will be in use and the revocation may 
cause problems (not too much I understand as revocation mostly does not work 
;-) for CA-customers and their website visitors. But having to deal with that 
when they are doing it wrong is the only motivation a CA has for doing things 
right. As things are this doesn't seem to motivate them very much. ;-)

And customers will have to learn to choose CAs that don't cause this kind of 
problems. Or suffer them... that is up to them.

On to other hand customers also have little motivation to do things right. To 
most of them HTTPS is something they are forced into by the recent HTTPS-only 
drive by the browsers.

All in all I appreciate how CT is pulling all this garbage into broad daylight. 
We should be simply aiming to get it cleared away. And if there is stuff in 
there that is not worth revoking promptly then it would be better to remove 
theses issuance requirements than to relax the revocation requirement.

CU Hans
dev-security-policy mailing list
              • ... Matt Palmer via dev-security-policy
              • ... Jakob Bohm via dev-security-policy
              • ... Matthew Hardeman via dev-security-policy
              • ... Peter Gutmann via dev-security-policy
              • ... Ryan Sleevi via dev-security-policy
              • ... Ryan Sleevi via dev-security-policy
      • Re: Certificates ... Jakob Bohm via dev-security-policy
      • Re: Certificates ... Ryan Sleevi via dev-security-policy
      • Re: Certificates ... Matthew Hardeman via dev-security-policy
  • Re: Certificates with inva... okaphone.elektronika--- via dev-security-policy

Reply via email to