[cabfpub] Pre-Ballot - Short-Life Certificates

Eddy Nigg eddy_nigg at startcom.org
Wed Oct 29 15:12:04 MST 2014


On 10/29/2014 08:50 PM, kirk_hall at trendmicro.com wrote:
> I agree that browsers and apps will make their own judgments about 
> when a case of BR non-compliance is serious enough to warrant a UI 
> warning, and when it can be ignored.  I would just offer my opinion 
> that lack of CDP and AIA data in a cert (whether or not Chrome wants 
> to check that information in the client) is a fundamental certificate 
> flaw that renders the cert inherently untrustworthy, and it should 
> automatically be rejected by applications (just as expired certs, etc. 
> are now automatically rejected).  But that's just my opinion.

Considering that CAs were required to modify the OCSP responders to 
include Good, Revoked and *Unknown* upon request of the browsers mostly 
(I believe Google was a strong supporter of that), it's rather confusing 
to know that browsers entirely ignore it if the certificates have no 
OCSP (and CRL) pointers, not speaking about checking this information 
when available.

So what does it matter if Diginotar knew or didn't knew which 
certificates were issued if this information wouldn't be used anyway?

-- 
Regards
Signer: 	Eddy Nigg, COO/CTO
	StartCom Ltd. <http://www.startcom.org>
XMPP: 	startcom at startcom.org <xmpp:startcom at startcom.org>
Blog: 	Join the Revolution! <http://blog.startcom.org>
Twitter: 	Follow Me <http://twitter.com/eddy_nigg>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141030/c349c2bd/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4313 bytes
Desc: S/MIME Cryptographic Signature
Url : https://cabforum.org/pipermail/public/attachments/20141030/c349c2bd/attachment.bin 


More information about the Public mailing list