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.

-----BEGIN CERTIFICATE REQUEST----- 
MIICbzCCAVcCADArMSkwJwYDVQQDEyBiYjA2NGU1MDIwMTcwOTE4MTY0ZTlmMDY2 
MWMyNmVhMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMWfPXnVtnMj 
e2WvpNuBQW7lg3cxztBbPPyis+KoWysslWjA2Z2JpKN3GY25ncpZoJWbCMetIFPA 
Ue/cqOM0IWlck9tjPOFby+Zjftz5icdaJ1+xGryX9NizyCuAFlxWlKwToH8d22sG 
xYnKK/ioRKXjZb14tyME0tA3MOXO3JN+2+KK6A0BC54GO03ce72PYpbx0FYkt9VF 
bAgc42Xq9wiNJfzH/gbyk/avFvMHNL+5pJ1oBWjbbGUiPCHqONuVmKFsGP81lNJG 
HUrK7J1cKfyfV2YR7RJZLKDXBf6UKh0Qntrpm5f5lYIgNekt/AY2DDHBoyBItjIk 
/pUWfnvXTcsCAwEAAaAAMA0GCSqGSIb3DQEBCwUAA4IBAQBse8alivTZxKF2Uw2f 
3xM84buzbrvTsMAVDpGGgkuOd54lcShMvhIMpHDmuQgDrJgRuhbLhKpcXJIpQxj9 
zZbvlZnKPuvqOQX0+4rTgl4QTq42dCOnRxSLrmuh1kZoB40bp7iICKQq3zXsz89v 
HNPC54Pnwxv1sp0J2C2EG6c3WdBJ9Z8F8yhUPdJWQla91i5rLVSrZClDm80bCpPf 
WYmmGRhyCwZ6XeD0FkvcUTxXpJkyhzYlyG7KndW0EScazJdBens8ox2YdUtpw2BT 
OYy6Bu/cFhgqdYKUxd0iVQ9lP4xrLzKYl3x0Np2Qay8n59rDhsAfgk0bSc0Lxok3 
0s8Z 
-----END CERTIFICATE REQUEST-----

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.

0 623: SEQUENCE { 
  4 343:   SEQUENCE { 
  8   0:     INTEGER 
       :       Error: Object has zero length. 
 10  43:     SEQUENCE { 
... 
349   0:     [0] 
       :       Error: Object has zero length. 
       :     } 
351  13:   SEQUENCE { 
353   9:     OBJECT IDENTIFIER '1 2 840 113549 1 1 11' 
364   0:     NULL 
       :     }

This could be an error with Mr. Gutmann's tool but the fact that 
Windows Crypto API doesn't like the CSR is curious. I followed this 
advice

http://stackoverflow.com/questions/15294964/windows-2008r2-ca-openssl-csr-error-parsing-csr-asn1-bad-value-met

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?

Kind regards, 
   Ken Smith 
   :{> 
______________________________________________________________________ 
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email] 
Automated List Manager                           [hidden email]

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 :

______________________________________________________________________ 
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email] 
Automated List Manager                           [hidden email]

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.

:{> 
______________________________________________________________________ 
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email] 
Automated List Manager                           [hidden email]