* Lutz Jaenicke wrote on Tue, Apr 22, 2008 at 09:59 +0200: > > This rule is independent of current time. e.g. If the validity dates > > of the parent certificate is 2008/04/18~2009/04/18 and the ones of > > child certificate is 2008/06/18~2009/06/18 or 2008/03/18~2009/03/18, > > the certificate chain should be invalid. The validity dates of child > > certificate should be between the ones of parent(2008/04/18~2009/04/18). > Ok, so we are facing a violation of policies at the CA. At the date of > certificate verification we are however checking whether all components > of the certificate chain are valid at this day.
> Even though the overlapping dates are a violation of the standard the > question is whether we actually should actually enforce this inside the > library. Yes, maybe then a new CA certificate will be presented (with new expiry dates), why not. BTW, what is the idea/logic behind? I don't understand why this should be independent of current time. Maybe before the CA certificate expires, a new CA certificate will be presented without overlapping validity. Also, if the child certificate would be trusted if valid till 2009/04/18 on 2009/04/17, I don't see why it should not be trusted at the same day (2009/04/17) if valid till 2009/04/19. I understand that in the second case the CA certificate is not trusted anymore, but this surely does depend on current time. I've already read the idea that a CA should not certify for longer than a certificate that is valid for the signing key - but never understood why. Is this some standard requiring that or is it just a matter of policy (and style maybe)? Where can I read/learn more? Beside useless and expensive, wouldn't it be allowed (correct) if the CA every day creates a new one-day-valid CA certificate? Can it really be concluded from the expiry date of some certificate whether the CA is authorised to certify or not? What if the CA is authorised to certify for four years with a maximum certificate duration of 30 days? (or whatever some policy requires). If it is just against the policy of some CAs and other reaonable policies could be imagined, I think it should not be checked by the library. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
