Re: X509v3 extensions (repost)
in X509 and RFC3280 Critical means that if you don't know how to handle an entension, you can ignore it. if you know how to handle it, you treat it X independantly of critical or not. I was mildly shaked to wake up : Obviously, I missed the half sentence at 'X': if critical is not set. Or: - You know and extension == treat it - else, (you don't know it) and critical is NOT set, ignore it - else fail. In a previous version of X509 and of PKIX you had - If you don't know an extension and critical is not set, ignore - else if you don't know and crticila is set, fail; - else (you know) and critical == treatment A - else you know and non critical == treatmant B. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: X509v3 extensions (repost)
Rich Salz wrote: Critical means if you don't know what this means, you cannot process the cert. or am i suffering from too many late nights hacking? You are right. This is the reason why setting the CRITICAL bit could lead to some interoperability issues, therefore you should think twice before setting it :-D -- C'you, Massimiliano Pala --o Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED] Tel.: +39 (0)59 270 094 http://www.openca.org Fax:+39 178 270 2077 http://openca.sourceforge.net Mobile: +39 (0)347 7222 365 University of Modena and Reggio Emilia Certification Authority Informations: Authority Access Point http://pki.unimo.it Authority's Certificate:http://pki.unimo.it/ca/issuers.html Certificate Revocation List: http://pki.unimo.it/crl/cacrl.crl --o smime.p7s Description: S/MIME Cryptographic Signature
Re: X509v3 extensions (repost)
On Sun, 8 Feb 2004, Richard Levitte - VMS Whacker wrote: dave.roberts The Extended Key Usage flag is not marked as a critical dave.roberts extension, so in theory it should pass OK. This is a fairly common misunderstanding. IF an extension is understood and supported by the application or library, it MUST be processed regardless of the critical flag. IF an extension is NOT understood and supported by the application or library, it can be ignored ONLY IF the critical flag is not set, otherwise the verification path is invalidated. I guess I should have double checked the RFC. Thanks for the correction. I suppose there's a little confusion as RFC 3280, Section 4.2 only talks about extensions not recognised :-) ... but the confusion was mine. dave.roberts Firstly, within the function x509v3_cache_extensions() dave.roberts in x509v3/v3_purp.c, the last bit of code checks for all dave.roberts extensions, looking for any that are critical. dave.roberts Strangely it looks to me like only extensions that are dave.roberts critical and not supported triggers the setting of the dave.roberts flags to include EXFLAG_CRITICAL. Should that 'not' be dave.roberts in there? No. EXFLAG_CRITICAL means it has found a critical extension that is not supported by OpenSSL, and that the verification should therefore fail. That makes much more sense with what I'm seeing. - DR __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #821] Patch for bn_div_words on x86_64
Hi! Actually, this function was called: I've got exception in gnomemeeting program (which uses TLS functionality). This bug existed only when compiled with asm optimizations and for x86_64. On Saturday 07 February 2004 13:06, Andy Polyakov via RT wrote: Fixed, thank you. For reference. The bug survived so far, because function in question is never called [divq instruction is inlined in bn_div.c]. A. !DSPAM:4024b898458561637815124! __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
