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: X509v3 extensions (repost)
I've come across an issue with extensions. I have a S/MIME signed message, where the signing cert has signing + encrypting Key Usage flags, and SSL server Extended Key Usage flags. Because there is a Ext. Key Usage flags set, but not the S/MIME one then the cert validation procedure fails, hence the signature verification fails. The Extended Key Usage flag is not marked as a critical extension, so in theory it should pass OK. There are a number of reasons for this as far as I can tell. Firstly, within the function x509v3_cache_extensions() in x509v3/v3_purp.c, the last bit of code checks for all extensions, looking for any that are critical. Strangely it looks to me like only extensions that are critical and not supported triggers the setting of the flags to include EXFLAG_CRITICAL. Should that 'not' be in there? 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 independantly of critical or not. there was a defect report in X509 to have this interpretation changed, in older versions of 509 and PKIX there was indee a three state logic. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
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 independantly of critical or not. hunh? 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? /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
X509v3 extensions (repost)
Repost as I didn't see this make it too the list. Typos corrected :) -- Forwarded message -- Date: Wed, 4 Feb 2004 14:16:03 + (GMT) To: [EMAIL PROTECTED] Subject: X509v3 extensions I've come across an issue with extensions. I have a S/MIME signed message, where the signing cert has signing + encrypting Key Usage flags, and SSL server Extended Key Usage flags. Because there is a Ext. Key Usage flags set, but not the S/MIME one then the cert validation procedure fails, hence the signature verification fails. The Extended Key Usage flag is not marked as a critical extension, so in theory it should pass OK. There are a number of reasons for this as far as I can tell. Firstly, within the function x509v3_cache_extensions() in x509v3/v3_purp.c, the last bit of code checks for all extensions, looking for any that are critical. Strangely it looks to me like only extensions that are critical and not supported triggers the setting of the flags to include EXFLAG_CRITICAL. Should that 'not' be in there? Secondly, assuming the reverse logic of the above, there is only one flag to indicate that extensions are critical, therefore if any are critical, then all would be treated as so. However, the only place that criticality is checked is in x509/x509_vfy.c function check_chain_purpose() at the top where it checks to see if critical extensions should be ignored, but are set. Steve: is this part of the area that you told me needed working on? :) As for fixing... should/could the caching function have 3 seperate critical flags, one each for KeyUsage, ExKeyUsage and NsCertType. These could then be checked when a lookup is made on a specific extension. Would reversing the logic for setting the flags break anything else? Is anyone else already working in this area? - DR __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
