(no subject)

On Wed, Oct 21, 2009, Adam Rosenstein wrote:

I'm assuming you are using OpenSSL 1.0.0 otherwise this isn't supported at
all.

Have you set the flags to X509_V_FLAG_EXTENDED_CRL_SUPPORT?

What other flags have you set?

What other extensions are present in the CRL and CRL signer?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

I'm using v1.0.0 Beta 3.


My code is perl xs glue but it looks something like this:

  purpose    = X509_PURPOSE_MIN - 1;
  cert_store = X509_STORE_new();
  revokes    = crl_stack;
  X509_STORE_set_flags(cert_store, 0);
  vpm        = X509_VERIFY_PARAM_new();
 
  X509_VERIFY_PARAM_set_flags(vpm,X509_V_FLAG_X509_STRICT);
  if ( revokes ) {
    // .
    // . perl xs stuff here
    // .
    if ( num_crls >= 0) {
#if (OPENSSL_VERSION_NUMBER >= 0x10000003L)
      X509_VERIFY_PARAM_set_flags(vpm,X509_V_FLAG_EXTENDED_CRL_SUPPORT);
#endif
      // if you pass in one crl it is assumed to be the crl to check
      // for the cert being verified only
      X509_VERIFY_PARAM_set_flags(vpm,X509_V_FLAG_CRL_CHECK);
      if ( num_crls >= 1 ) {
        // if you pass in > 1 crl then it is assumed you have
        // passed in one crl for every ca in the chain
               
        // (2do: use an explicit argument for this now that we will
        // have one iCRL for all)
               
        X509_VERIFY_PARAM_set_flags(vpm,X509_V_FLAG_CRL_CHECK_ALL);
      }
    }
  }
   
  if (purpose > X509_PURPOSE_MIN) {
    X509_VERIFY_PARAM_set_purpose(vpm, purpose);
  }
  X509_STORE_set1_param(cert_store, vpm);

  trusted = sk_X509_new_null();
  sk_X509_push(trusted,root);
   
  //
  // The UNTRUSTED STACK (as CAs come in...)
  //
   
  untrusted = sk_X509_new_null();
   
  for (ca_idx = 0 ; ca_idx <= num_cas; ca_idx++) {
    // .
    // . perl xs stuff
    // .
    sk_X509_push(untrusted,(X509 *)ca_cert);
  }
   
  //
  // The CRL STACK
  //
   
  for (crl_idx = 0 ; crl_idx <= num_crls; crl_idx++) {
    // .
    // . perl xs stuff
    // .
    sk_X509_CRL_push(crls,(X509_CRL *)crl);
  }
   
  // The certificate store verification context and actual verification
   
  cs_ctx = X509_STORE_CTX_new();
  if (!cs_ctx) {
    error="malloc error";
    goto CERTIFICATE_VERIFY_FAILURE;
  }
  if(! X509_STORE_CTX_init(cs_ctx,cert_store,cert,untrusted)) {
    error="error initializing cs_ctx";
    goto CERTIFICATE_VERIFY_FAILURE;
  }
  X509_STORE_CTX_trusted_stack(cs_ctx, trusted);
   
  if (purpose) X509_STORE_CTX_set_purpose(cs_ctx, purpose);
  if (crls) X509_STORE_CTX_set0_crls(cs_ctx,crls);
  verifyResult = X509_verify_cert(cs_ctx);


ROOT (CA0) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: O=Red Condor, OU=PKI, CN=CA0
Validity
    Not Before: Oct 11 19:36:01 2009 GMT
    Not After : Oct 21 19:36:01 2010 GMT
Subject: O=Red Condor, OU=PKI, CN=CA0
X509v3 extensions:
    X509v3 Basic Constraints: critical
        CA:TRUE, pathlen:8
    X509v3 Subject Key Identifier:
        A0:A0:7A:71:6C:23:26:E4:00:9A:EA:17:B9:B4:A8:7F:1D:0C:65:DE
    X509v3 Authority Key Identifier:
        keyid:A0:A0:7A:71:6C:23:26:E4:00:9A:EA:17:B9:B4:A8:7F:1D:0C:65:DE
    X509v3 Key Usage: critical
        Certificate Sign, CRL Sign

-----BEGIN CERTIFICATE-----
MIIBuTCCAWOgAwIBAgIBATANBgkqhkiG9w0BAQUFADAxMRMwEQYDVQQKEwpSZWQg
Q29uZG9yMQwwCgYDVQQLEwNQS0kxDDAKBgNVBAMTA0NBMDAeFw0wOTEwMTExOTM2
MDFaFw0xMDEwMjExOTM2MDFaMDExEzARBgNVBAoTClJlZCBDb25kb3IxDDAKBgNV
BAsTA1BLSTEMMAoGA1UEAxMDQ0EwMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAPxS
gTKr9MTRGhh8OYyNfEB0kuSpPJJOH+U9BncIQO3Ff+DMtaM2DyBlUn7TY9Xb2+5i
Yz7go/XN9QRvnhO4mp8CAwEAAaNmMGQwEgYDVR0TAQH/BAgwBgEB/wIBCDAdBgNV
HQ4EFgQUoKB6cWwjJuQAmuoXubSofx0MZd4wHwYDVR0jBBgwFoAUoKB6cWwjJuQA
muoXubSofx0MZd4wDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA0EAH3bu
6vB/XW7IBYpwqUs1sihHrTsvibg5660Ry2pD2+QUDRVvOZofOoY0T3iWETItnjM2
KcZrYtj1cYXrW9T5Dw==
-----END CERTIFICATE-----

Indirect CRL Signer (CA0iCRL) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: sha1WithRSAEncryption
Issuer: O=Red Condor, OU=PKI, CN=CA0
Validity
    Not Before: Oct 11 19:37:10 2009 GMT
    Not After : Oct 21 19:37:10 2010 GMT
Subject: O=Red Condor, OU=PKI, CN=CA0iCRL
X509v3 extensions:
    X509v3 Basic Constraints: critical
        CA:TRUE, pathlen:8
    X509v3 Subject Key Identifier:
        0E:8C:C9:D3:F4:2C:B8:6D:81:71:69:B4:2E:99:FA:08:AD:CF:A9:8F
    X509v3 Authority Key Identifier:
        keyid:E1:C1:46:BC:E5:6F:03:27:7A:23:C4:0B:A2:BF:F9:0F:03:BC:F8:83
    X509v3 Key Usage: critical
        Certificate Sign, CRL Sign
-----BEGIN CERTIFICATE-----
MIIBvTCCAWegAwIBAgIBAjANBgkqhkiG9w0BAQUFADAxMRMwEQYDVQQKEwpSZWQg
Q29uZG9yMQwwCgYDVQQLEwNQS0kxDDAKBgNVBAMTA0NBMDAeFw0wOTEwMTExOTM3
MTBaFw0xMDEwMjExOTM3MTBaMDUxEzARBgNVBAoTClJlZCBDb25kb3IxDDAKBgNV
BAsTA1BLSTEQMA4GA1UEAxMHQ0EwaUNSTDBcMA0GCSqGSIb3DQEBAQUAA0sAMEgC
QQCWgKj+xxLStKZW1ydA9w4RZee56acEqpZHRXsuwLXXUOlzI3XWPlOzcbYnGW72
leoOQ36Qi9lBOow0yct/p4X5AgMBAAGjZjBkMBIGA1UdEwEB/wQIMAYBAf8CAQgw
HQYDVR0OBBYEFA6MydP0LLhtgXFptC6Z+gitz6mPMB8GA1UdIwQYMBaAFOHBRrzl
bwMneiPEC6K/+Q8DvPiDMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQUFAANB
AMhSoa8Ut9/eRQiJnOsPajUcgHQiimm41u3kC9zL6SjCcVlrbfyzZiSfX2g+XFma
N6xmAhQjUEXCAOSz2WmoWuM=
-----END CERTIFICATE-----

End Entity (AdamRosenstein) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Version: 3 (0x2)
Serial Number: 3 (0x3)
Signature Algorithm: sha1WithRSAEncryption
Issuer: O=Red Condor, OU=PKI, CN=CA0
Validity
    Not Before: Oct 11 19:37:10 2009 GMT
    Not After : Oct 21 19:37:10 2010 GMT
Subject: O=Red Condor, OU=PKI, CN=AdamRosenstein
X509v3 extensions:
    X509v3 Basic Constraints: critical
        CA:FALSE
    X509v3 Subject Key Identifier:
        BE:21:0B:DF:87:07:84:81:FC:82:4A:74:07:C4:23:F4:7F:3A:6E:56
    X509v3 Authority Key Identifier:
        keyid:E1:C1:46:BC:E5:6F:03:27:7A:23:C4:0B:A2:BF:F9:0F:03:BC:F8:83
    X509v3 Key Usage: critical
        Digital Signature, Key Encipherment
    X509v3 CRL Distribution Points:
        Full Name:
          URI:http://pki.redcondor.net/CA0-indirect.crl
        CRL Issuer:
          DirName: O = Red Condor, OU = PKI, CN = CA0iCRL
-----BEGIN CERTIFICATE-----
MIICNzCCAeGgAwIBAgIBAzANBgkqhkiG9w0BAQUFADAxMRMwEQYDVQQKEwpSZWQg
Q29uZG9yMQwwCgYDVQQLEwNQS0kxDDAKBgNVBAMTA0NBMDAeFw0wOTEwMTExOTM3
MTBaFw0xMDEwMjExOTM3MTBaMDwxEzARBgNVBAoTClJlZCBDb25kb3IxDDAKBgNV
BAsTA1BLSTEXMBUGA1UEAxMOQWRhbVJvc2Vuc3RlaW4wXDANBgkqhkiG9w0BAQEF
AANLADBIAkEApfAUsD6T8qVwX6iC4RRwhM41cwR+ndkZQ8ov8ot8eRH+3gV9NzFF
0sZFfHtzhC6zovonvkujYNCihHsIvbe12wIDAQABo4HYMIHVMAwGA1UdEwEB/wQC
MAAwHQYDVR0OBBYEFL4hC9+HB4SB/IJKdAfEI/R/Om5WMB8GA1UdIwQYMBaAFOHB
RrzlbwMneiPEC6K/+Q8DvPiDMA4GA1UdDwEB/wQEAwIFoDB1BgNVHR8EbjBsMGqg
LaArhilodHRwOi8vcGtpLnJlZGNvbmRvci5uZXQvQ0EwLWluZGlyZWN0LmNybKI5
pDcwNTETMBEGA1UEChMKUmVkIENvbmRvcjEMMAoGA1UECxMDUEtJMRAwDgYDVQQD
EwdDQTBpQ1JMMA0GCSqGSIb3DQEBBQUAA0EAiziI4gGkpZRsw+o20tAOyD1yZJsA
Dq5jgehNI2lEVzrf3b0xuR4CIk/bC/uZZ+KoLcBcp8afsXBkS9WJdLxEyg==
-----END CERTIFICATE-----

CRL <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Version 2 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: /O=Red Condor/OU=PKI/CN=CA0iCRL
Last Update: Oct 20 19:37:10 2009 GMT
Next Update: Aug 17 19:37:10 2010 GMT
CRL extensions:
    X509v3 Issuing Distrubution Point: critical
        Full Name:
          URI:http://pki.redcondor.net/CA0-indirect.crl
        Indirect CRL
    X509v3 Authority Key Identifier:
        keyid:0E:8C:C9:D3:F4:2C:B8:6D:81:71:69:B4:2E:99:FA:08:AD:CF:A9:8F
    X509v3 CRL Number:
        10
Revoked Certificates:
    Serial Number: 03
        Revocation Date: Oct 21 19:37:10 2009 GMT
        CRL entry extensions:
            X509v3 Certificate Issuer: critical
                DirName:/O=Red Condor/OU=PKI/CN=CA0
-----BEGIN X509 CRL-----
MIIBiTCCATMCAQEwDQYJKoZIhvcNAQEFBQAwNTETMBEGA1UEChMKUmVkIENvbmRv
cjEMMAoGA1UECxMDUEtJMRAwDgYDVQQDEwdDQTBpQ1JMFw0wOTEwMjAxOTM3MTBa
Fw0xMDA4MTcxOTM3MTBaMFkwVwIBAxcNMDkxMDIxMTkzNzEwWjBDMEEGA1UdHQEB
/wQ3MDWkMzAxMRMwEQYDVQQKEwpSZWQgQ29uZG9yMQwwCgYDVQQLEwNQS0kxDDAK
BgNVBAMTA0NBMKBvMG0wPgYDVR0cAQH/BDQwMqAtoCuGKWh0dHA6Ly9wa2kucmVk
Y29uZG9yLm5ldC9DQTAtaW5kaXJlY3QuY3JshAH/MB8GA1UdIwQYMBaAFA6MydP0
LLhtgXFptC6Z+gitz6mPMAoGA1UdFAQDAgEKMA0GCSqGSIb3DQEBBQUAA0EAiPvZ
NnPv6wh5rMiR9b4f5H2KkZiwZ8H2HDE/d/vOTQOiffnqKpQTL3b5IKK8OQhFSgIL
IiVT5d9CUhFlGmFUsw==
-----END X509 CRL-----


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

On Wed, Oct 21, 2009, Adam Rosenstein wrote:

> I'm using v1.0.0 Beta 3.
>
>

Hmm... there seems to be an SKID/AKID issue here:

You message doesn't include any CA certificate with an SKID matching the EE
AKID. Is there an extra intermediate CA missing?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

On Fri, Oct 23, 2009, Dr. Stephen Henson wrote:

> On Wed, Oct 21, 2009, Adam Rosenstein wrote:
>
> > I'm using v1.0.0 Beta 3.
> >
> >
>
> Hmm... there seems to be an SKID/AKID issue here:
>

There is also a bug in the verification code which means it was expecting to
find a CRL for the CRL signing certificate too even if not configured to check
the whole chain.

Please try the next snapshot.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

You are correct, I made a paste error in the mail.  The certs were correct at the time I tested however (my test script just regenerates things each time and I pasted an old ee with a new root ca).

I just tried openssl-SNAP-20091026.tar.gz and still get Different CRL Scope.  Here is the EE, ROOT CA, Indirect CRL signer, and Indirect CRL in a P7.

-----BEGIN PKCS7-----
MIIHfgYJKoZIhvcNAQcCoIIHbzCCB2sCAQExADALBgkqhkiG9w0BBwGgggW5MIIC
NzCCAeGgAwIBAgIBAzANBgkqhkiG9w0BAQUFADAxMRMwEQYDVQQKEwpSZWQgQ29u
ZG9yMQwwCgYDVQQLEwNQS0kxDDAKBgNVBAMTA0NBMDAeFw0wOTEwMTYyMDI4MDVa
Fw0xMDEwMjYyMDI4MDVaMDwxEzARBgNVBAoTClJlZCBDb25kb3IxDDAKBgNVBAsT
A1BLSTEXMBUGA1UEAxMOQWRhbVJvc2Vuc3RlaW4wXDANBgkqhkiG9w0BAQEFAANL
ADBIAkEAxOqxSY6OYvLnSoA5dPAbWsApx6N6cBn6qYeFeNovkr+JnoBaPuSMDSAN
fkmwktZCcumfX6czyV6qQjKlB1e0CwIDAQABo4HYMIHVMAwGA1UdEwEB/wQCMAAw
HQYDVR0OBBYEFERl5bIuRASGgLLjYaIMI5DNfO/lMB8GA1UdIwQYMBaAFCRhPk/D
NEBzZOufd0Bguya9GhSiMA4GA1UdDwEB/wQEAwIFoDB1BgNVHR8EbjBsMGqgLaAr
hilodHRwOi8vcGtpLnJlZGNvbmRvci5uZXQvQ0EwLWluZGlyZWN0LmNybKI5pDcw
NTETMBEGA1UEChMKUmVkIENvbmRvcjEMMAoGA1UECxMDUEtJMRAwDgYDVQQDEwdD
QTBpQ1JMMA0GCSqGSIb3DQEBBQUAA0EAsteORZ/QTZv3RVhxDkmY1p3dH7DB6ZMm
sXzkhA+GN3v4GXdb7EhNSTAQ+EuRhZhQBRDKE3Y63pF6CsrU93rP8jCCAb0wggFn
oAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwMTETMBEGA1UEChMKUmVkIENvbmRvcjEM
MAoGA1UECxMDUEtJMQwwCgYDVQQDEwNDQTAwHhcNMDkxMDE2MjAyODA0WhcNMTAx
MDI2MjAyODA0WjA1MRMwEQYDVQQKEwpSZWQgQ29uZG9yMQwwCgYDVQQLEwNQS0kx
EDAOBgNVBAMTB0NBMGlDUkwwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAo3ObrwsI
K1KcZ0KwAFbQAmSJ3DWwc9nRGhFUmakGY84fCs3viULbGdsNkSfa3oXBw88W+Ppd
IrD8hsi9ZcZmFwIDAQABo2YwZDASBgNVHRMBAf8ECDAGAQH/AgEIMB0GA1UdDgQW
BBQQqbRAIlIdYffeBpkKUh2R50rfVTAfBgNVHSMEGDAWgBQkYT5PwzRAc2Trn3dA
YLsmvRoUojAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADQQA7DJqmDpWh
7MNQuZ/TLSa7clVmgkJQCbuJrGQ59zWA+QTaeQ886RECSGybXV+rQ94jsbgQIa0b
KXRsJSDaNiihMIIBuTCCAWOgAwIBAgIBATANBgkqhkiG9w0BAQUFADAxMRMwEQYD
VQQKEwpSZWQgQ29uZG9yMQwwCgYDVQQLEwNQS0kxDDAKBgNVBAMTA0NBMDAeFw0w
OTEwMTYyMDI4MDRaFw0xMDEwMjYyMDI4MDRaMDExEzARBgNVBAoTClJlZCBDb25k
b3IxDDAKBgNVBAsTA1BLSTEMMAoGA1UEAxMDQ0EwMFwwDQYJKoZIhvcNAQEBBQAD
SwAwSAJBALoQF/Jo7vqH0+fNc2vBstWDBYay+EEaGPWJAIsn2F1C86JXFWOjRdu+
Fxz7JV5suaMpXcR8j/22LBOHYoxKXgUCAwEAAaNmMGQwEgYDVR0TAQH/BAgwBgEB
/wIBCDAdBgNVHQ4EFgQUJGE+T8M0QHNk6593QGC7Jr0aFKIwHwYDVR0jBBgwFoAU
JGE+T8M0QHNk6593QGC7Jr0aFKIwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEB
BQUAA0EACWYfa92zpMJcXwvD09fcn3CA6umXjVqbEDdbkjASWYRgo2dHMyV6NGoo
xHpXt/5zgnMyyhuqpzr9K6XY2XQTYqGCAZYwggGSMIIBPAIBATANBgkqhkiG9w0B
AQUFADA1MRMwEQYDVQQKEwpSZWQgQ29uZG9yMQwwCgYDVQQLEwNQS0kxEDAOBgNV
BAMTB0NBMGlDUkwXDTA5MTAyNTIwMjgwNloXDTEwMDgyMjIwMjgwNlowWTBXAgED
Fw0wOTEwMjYyMDI4MDZaMEMwQQYDVR0dAQH/BDcwNaQzMDExEzARBgNVBAoTClJl
ZCBDb25kb3IxDDAKBgNVBAsTA1BLSTEMMAoGA1UEAxMDQ0EwoHgwdjBHBgNVHRwB
Af8EPTA7oC2gK4YpaHR0cDovL3BraS5yZWRjb25kb3IubmV0L0NBMC1pbmRpcmVj
dC5jcmyBAQCCAQCEAf+FAQAwHwYDVR0jBBgwFoAUEKm0QCJSHWH33gaZClIdkedK
31UwCgYDVR0UBAMCAQowDQYJKoZIhvcNAQEFBQADQQBRIY2yeJ+519ZH/nfzLsq3
rSmKMW43QSRSdKV93K4qPtuWhVcc/3Z9jKkO/p9WD9pVA1RALWc8XyLEGvbRPyA2
MQA=
-----END PKCS7-----

-----Original Message-----
From: owner-openssl-users@... [mailto:owner-openssl-users@...] On Behalf Of Dr. Stephen Henson
Sent: Friday, October 23, 2009 5:09 PM
To: openssl-users@...
Subject: Re: your mail

On Fri, Oct 23, 2009, Dr. Stephen Henson wrote:

> On Wed, Oct 21, 2009, Adam Rosenstein wrote:
>
> > I'm using v1.0.0 Beta 3.
> >
> >
>
> Hmm... there seems to be an SKID/AKID issue here:
>

There is also a bug in the verification code which means it was expecting to
find a CRL for the CRL signing certificate too even if not configured to check
the whole chain.

Please try the next snapshot.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

On Mon, Oct 26, 2009, Adam Rosenstein wrote:

> You are correct, I made a paste error in the mail.  The certs were correct
> at the time I tested however (my test script just regenerates things each
> time and I pasted an old ee with a new root ca).
>
> I just tried openssl-SNAP-20091026.tar.gz and still get Different CRL Scope.
> Here is the EE, ROOT CA, Indirect CRL signer, and Indirect CRL in a P7.
>

Hmm... I now get the message "certificate revoked" when I verify that chain.
That is using a (not yet committed) change to the verify utility to input CRLs
to the verification context. Due to a limitation in the current CRL lookup
code indirect CRLs don't work when placed in a store.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

Ahh, that explains it.  Thanks for looking into it.

My code only uses a store for verification.  It is Perl glue developed in-house.  Perhaps we would be willing to donate it to contrib.  It is a more complete set of bindings to libcrypto than other modules on CPAN.

The documentation on iCRLs was a little cryptic to me.  It said that no lookup methods were used (?).  Now you say the store is also not used.  How do I get the iCRL into the verification process?  Also, does the current 1.0.0 icrl code enforce the "same trust-anchor" method of tying iCRL issuer to the CA it is revoking for?

I'd be happy to help continue testing indirect CRLs, as they are a feature we would like.  We have root and first-level intermediate CA's on smartcards "offline" (in a safe) because they are infrequently used.  We would like to have a single indirect CRL issuer (issued by root) so we can require full chain CRL checking AND enforce timely updates to the CRL's while keeping our infrequently used private keys out of normal circulation.

Also, I can confirm that name-constraints are working beautifully.

Adam Rosenstein
Red Condor

-----Original Message-----
From: owner-openssl-users@... [mailto:owner-openssl-users@...] On Behalf Of Dr. Stephen Henson
Sent: Thursday, October 29, 2009 3:42 PM
To: openssl-users@...
Subject: Re: your mail

On Mon, Oct 26, 2009, Adam Rosenstein wrote:

> You are correct, I made a paste error in the mail.  The certs were correct
> at the time I tested however (my test script just regenerates things each
> time and I pasted an old ee with a new root ca).
>
> I just tried openssl-SNAP-20091026.tar.gz and still get Different CRL Scope.
> Here is the EE, ROOT CA, Indirect CRL signer, and Indirect CRL in a P7.
>

Hmm... I now get the message "certificate revoked" when I verify that chain.
That is using a (not yet committed) change to the verify utility to input CRLs
to the verification context. Due to a limitation in the current CRL lookup
code indirect CRLs don't work when placed in a store.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

On Fri, Oct 30, 2009, Adam Rosenstein wrote:

> Ahh, that explains it.  Thanks for looking into it.
>
> The documentation on iCRLs was a little cryptic to me.  It said that no
> lookup methods were used (?).  Now you say the store is also not used.  How
> do I get the iCRL into the verification process?  Also, does the current
> 1.0.0 icrl code enforce the "same trust-anchor" method of tying iCRL issuer
> to the CA it is revoking for?
>

You can get CRLs into the process using X509_STORE_CTX_set0_crls(). As
indicated in the docs, some protocols (PKCS#7 and CMS) do this automatically.

At some point indirect CRL lookup using stores will be included too. The
indirect CRL code though is very new and (apart from the PKITS tests)
untested.

Yes it does include the same trust anchor requirement of RFC5280. Some
security concerns have been raise on the PKIX mailing lists about the
possibilities of unathorised CRLs being accepted in some scenarios which is
why the indirect CRL checking is disabled by default.

> I'd be happy to help continue testing indirect CRLs, as they are a feature
> we would like.  We have root and first-level intermediate CA's on smartcards
> "offline" (in a safe) because they are infrequently used.  We would like to
> have a single indirect CRL issuer (issued by root) so we can require full
> chain CRL checking AND enforce timely updates to the CRL's while keeping our
> infrequently used private keys out of normal circulation.
>
>

Having a single CRL might cause problems with circular dependencies. There was
a PKITS test that included this but it was later marked as not being required.

It's a case of how you issue a CRL for the indirect CRL issuer. If
it issues a CRL covering itself then it is effectively indicating its own
validity. In the case of the indirect CRL issuer private key being compromised
that is of course not trustworthy.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

Hmmm... my code does that but I get 'Different CRL Scope' on the SNAP from the 26th.

> indicated in the docs, some protocols (PKCS#7 and CMS) do this
> automatically.
>

A pkcs7 with crls in the container will automatically use them?  Cool.  How do you tell the p7 verify function when you want to require crl checking for each cert in the chain (X509_V_FLAG_CRL_CHECK_ALL) and when you just want EE checking.  Also, this raises another question.  I was using P7's without data as nice 'identity chain containers' (.p7c files) rather than concatenated PEM files.  Of course I have to unpack them to verify the identity.  The docs make the p7 verify function seem to be basically about the data:

    The type of p7 must be signedData. There must be at least one signature
    on the data and if the content is detached indata cannot be NULL.

If I call p7 verify with PKCS7_NOSIGS can I verify an "empty" p7 that has only certs and crls?

> At some point indirect CRL lookup using stores will be included too. The
> indirect CRL code though is very new and (apart from the PKITS tests)
> untested.
>
> Yes it does include the same trust anchor requirement of RFC5280. Some
> security concerns have been raise on the PKIX mailing lists about the
> possibilities of unathorised CRLs being accepted in some scenarios which
> is
> why the indirect CRL checking is disabled by default.

Yes, I'd been following that conversation, which is why I asked.  With Name Constraints in any CA outside our direct control I think that would not be an issue.
 
I'd considered this too.  It is tricky.  I think our solution will be something like this:  Have your iCRL crldp=root. Pre-generate a year's worth of daily empty crls for root, keep them fairly secure.  You dole them out to the directory/web server on a daily basis, unless there is a compromise of the one lynchpin key (iCRL issuer's key).  That warrants a trip to the safe....

Of course, if you think that level 1 CA compromises (root is level 0) are equally rare as iCRL key compromises, then I guess you could say this method obviates the need for an indirect crl issuer for the L1 CA's.....

 
> Steve.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

On Fri, Oct 30, 2009, Adam Rosenstein wrote:

I've just committed my changes, they don't touch the verify code just adds an
option to the verify utility.

This is what I now get from your certs:

openssl verify -verbose -crl_check -extended_crl -CRLfile crls
 -untrusted certs -CAfile root.pem ee.pem

 ee.pem: O = Red Condor, OU = PKI, CN = AdamRosenstein
 error 23 at 0 depth lookup:certificate revoked

> > indicated in the docs, some protocols (PKCS#7 and CMS) do this
> > automatically.
> >
>
> A pkcs7 with crls in the container will automatically use them?  Cool.  How
> do you tell the p7 verify function when you want to require crl checking for
> each cert in the chain (X509_V_FLAG_CRL_CHECK_ALL) and when you just want EE
> checking.

You set up verification parameters as usual and then call:

X509_STORE_set1_param(store, param);

Then when you call PKCS7_verify() (or preferably CMS_verify() ) any CRLs in
the PKCS#7 structure are automatically used. This works on any API that takes
an X509_STORE parameter.

No because the code needs to know which certificate(s) to verify. It does that
by locating the signer(s) certificates and using any certificates or CRLs
present as well. So you need a signature with the EE certificate on it for
this to work.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

I definitely get better results with the latest snapshot.  However I still don't get my "0 depth lookup:certificate revoked" but instead get a
"0 depth lookup:CRL path validation error"

Looking at the differences between my application logic and verify.c, I see that the command line uses an X509 Lookup with a file source for -CAFile, where as I simply pass in a trusted chain in my verify call, which I can achieve in the verify app using the -trusted command line switch instead.

/opt/openssl_1_0_0/bin/openssl verify -x509_strict -verbose -crl_check -extended_crl -CRLfile /tmp/ind.crl  -untrusted /tmp/CA0iCRL.pem -trusted /tmp/CA0.pem /tmp/AdamRosenstein.pem
/tmp/AdamRosenstein.pem: O = Red Condor, OU = PKI, CN = CA0iCRL
[CRL path]error 20 at 0 depth lookup:unable to get local issuer certificate
O = Red Condor, OU = PKI, CN = AdamRosenstein
error 54 at 0 depth lookup:CRL path validation error

Am I misunderstanding the intention of the trusted stack?  Does openssl provide an in-memory x509 lookup method (from a stack of X509 *'s) or do I have to roll my own?

Thanks for all of your answers Dr Henson,

Adam Rosenstein


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...

On Tue, Nov 03, 2009, Adam Rosenstein wrote:

Ah that must be a problem with the trusted stack stuff. I'll check that. You
can get an in-memory store by doing:

store = X509_STORE_new();
/* Do this for each cert */
X509_STORE_add_cert(store, cert);

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@...
Automated List Manager                           majordomo@...