On 21/09/11 03:05, Alex Rousskov wrote:
On 09/20/2011 05:46 AM, Fabian Hugelshofer wrote:
On 09/16/2011 04:35 PM, Alex Rousskov wrote:
On 09/16/2011 12:55 AM, Fabian Hugelshofer wrote:
What would you use to identify the certificates?
- Serial number?
- Serial number and common name?
- Serial number and issuer?
- Fingerprint (might not be available in each case)?
I hope somebody already answered these important questions in general
CRL context!
CRLs use the serial number in combination with the issuer.
The issuer name and the serial are probably not sufficient as there can
be multiple CAs with the same name (certificates with different
validity, different trust chains, ...).
If we implement a custom black list, we can be flexible and support all
of the above. To start with, I guess we should block all certificates
with DigiNotar in the chain.
What are the next steps, would you like me to open a Squid Bug?
I believe the rule is that new features should be documented on wiki,
but opening a "feature request" bug report would not hurt, I guess.
Can you summarize the minimum number of new ACL types that you think we
should support to make this work? I know we want issuer name and serial
number. Do we want notBefore and notAfter matching? Anything else?
Do we need to be able to test a match against a certificate at Nth
position in the chain? Or can we always test all certificates in the chain?
If this is to be worth using we definitely need to block any chains
containing a blacklisted certificate at any level. Allowing sites to
add/remove a link of chain and avoid the blacklist voids the utility of
this feature.
It would be nice to hear from others regarding this issue to make sure
we are not missing something important.
For my part I'm not versed enough in the details to have a strong
opinion either way. I thought the CRL infrastructure performed this task
sufficiently.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.15
Beta testers wanted for 3.2.0.12
