3 messages??Options?
Ken Smith Reply?|?Threaded?|?More????? Mar 17, 2013; 2:22am
Shouldn't CSRs automatically add default version?
3 posts
(I originally sent this to openssl-users but it is a question about? the implementation of OpenSSL more than the usage so I'm reposting? here.)?
I'm programmatically generating CSRs per the example in 10.3.1 of? Network Programming with OpenSSL. This CSR is fine according to the? openssl command line tool and to Bouncy Castle's .NET PKCS#10 handling? code. The Windows Crypto API function, CryptDecodeObjectEx refuses to? parse the CSR claiming that it is corrupted ASN.1. Here's an example.?
OpenSSL's command line asn1parse tool reads this just fine. Peter? Gutmann's dumpasn1 (www.cs.auckland.ac.nz/~pgut001/dumpasn1.c) claims? that there are two ASN.1 errors in this CSR.?
and added a call to X509_REQ_set_version(req, 0). Now Windows Crypto? API will accept CSRs I generate.?
Section 4.1 of RFC 2986 says, "Certification request information shall? have...CertificationRequestInfo ::= SEQUENCE { version INTEGER { v1(0)? } (v1,...),". Shouldn't OpenSSL be adding a version with a default? value of 0 even when X509_REQ_set_version is not called??
That CSR is clearly invalid, because one of its objects isn't properly? DER encoded.? The INTEGER encoding its version has a length equal to zero, and this? isn't permitted by X.690 (BER/DER/CER encoding):? "8.3.1 The encoding of an integer value shall be primitive. The contents? octets shall consist of one or more octets."?
OpenSSL could set the version to 0 by default when creating the X509_REQ? object (this is done when you call the X509_to_X509_REQ() function).? But the version field is not declared as "INTEGER DEFAULT v1", so it? could be acceptable to consider that explicitely setting the version is? the responsibility of the application creating the request.?
--? Erwann ABALEA?
Le 16/03/2013 19:22, Ken Smith a écrit : > -----BEGIN CERTIFICATE REQUEST-----? > MIICbzCCAVcCADArMSkwJwYDVQQDEyBiYjA2NGU1MDIwMTcwOTE4MTY0ZTlmMDY2? > [...]? > 0s8Z? > -----END CERTIFICATE REQUEST-----? > [...]? > Section 4.1 of RFC 2986 says, "Certification request information shall? > have...CertificationRequestInfo ::= SEQUENCE { version INTEGER { v1(0)? > } (v1,...),". Shouldn't OpenSSL be adding a version with a default? > value of 0 even when X509_REQ_set_version is not called? ...?[show rest of quote] ______________________________________________________________________? OpenSSL Project ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??http://www.openssl.org Development Mailing List ? ? ? ? ? ? ? ? ? ? ??[hidden email]? Automated List Manager ? ? ? ? ? ? ? ? ? ? ? ? ??[hidden email]?
Ken Smith Reply?|?Threaded?|?More????? Mar 19, 2013; 4:12am
On Mon, Mar 18, 2013 at 5:42 AM, Erwann Abalea? <[hidden email]> wrote:? > That CSR is clearly invalid, because one of its objects isn't properly DER? > encoded.?
This is precisely my point. All of the OpenSSL calls I make succeed? including PEM_write_X509_REQ. Either,?
?- the call to PEM_write_X509_REQ should fail indicating that it can't? construct valid ASN.1 because the structure lacks a version? ?- or the X509_REQ should encode a default version of 0 in the event? the user failed to specify.?
As it stands, it is possible to sail through successful calls to the? OpenSSL API and end up with something invalid. This violates the the? principle of least surprise.?