> In the example you gave the signature and signatureAlgorithm fields in the > certificate don't match.
Well, technically you’re correct - but from semantic point of view, how different is an empty list, and a list presented as ASN.1 NULL? Don’t we have an empty list in both cases? And aren’t these two the only two ways to represent an empty list (so there’s little chance of somebody utilizing this difference to craft an attack)? > OpenSSL tolerated this before but the fix for CVE-2014-8275 now rejects this > case. Yes I checked http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8275. I don’t think the intent of the above fix was to deal with this specific “ empty list" case that I’m bringing up. I think they were addressing real mismatches rather than the two possible representations of "nothing". > How did you generate this certificate? Certificates I’m bringing in that demonstrate the problem are generated by Apple software, Certificate Assistant. Please note that I provided two certificates - and the one for CA (RabbitMQ_Test_CA.pem) appears to pass even the current openssl-1.0.1k acceptance, despite having the same difference in encoding. Please check ASN.1 dump offsets 20 and 628 - and enjoy the difference between “empty” and “ASN.1 NULL”. > Do you have any pubic CA examples which do this? Unfortunately, I don’t have enough of public CA samples to find other “offenders”. Those few that I checked, seem to always encode empty list as 0x05 0x00 (ASN.1 NULL). But regardless, isn’t it obvious that semantically the two can (and IMHO should) be treated the same? And even if it is a bug in Apple code, what harm would come from following the IETF motto of “being liberal in what you receive and conservative in what you send”? A need to blacklist two fingerprints instead of one in the very worst case? Thanks! -- Uri Blumenthal u...@mit.edu<mailto:u...@mit.edu> _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
