[vwnc] X509.Certificate issue

I haven't been following X.509 developments in a while, but the specs used to be fairly adamant about requiring CA certificates to have BasicConstraints. Here's the relevant bit on BasicConstraints from RFC#5280 which seems to be the latest:
------
 Conforming CAs MUST include this extension in all CA certificates
   that contain public keys used to validate digital signatures on
   certificates and MUST mark the extension as critical in such
   certificates.  
-------
BC is the primary attribute that distinguishes certificates that are allowed to issue other certificates from the rest. This distinction is critical from the security point of view. Without it a CA has no way to prevent its subjects from issuing fraudulent certificates. For example if ACME-CA issues a certificate to John Doe, and John Doe then turns around and issues a certificate for Bank Of America for his phishing web server, a web browser has no way of distinguishing it from other valid certificates issued by ACME-CA. Not unless it can determine that John Doe has no right to issue other certificates. That's what BC is for.

KeyUsage has a flag that is relevant (keyCertSign). It seems that the new versions of the spec are more strict about requiring inclusion of this extension as well (for CAs), but it doesn't allow using it instead of BC.

------
        ...
           Conforming CAs MUST include this extension in certificates that
   contain public keys that are used to validate digital signatures on
   other public key certificates or CRLs.  When present, conforming CAs
   SHOULD mark this extension as critical.
       
        ...

      The keyCertSign bit is asserted when the subject public key is
      used for verifying signatures on public key certificates.  If the
      keyCertSign bit is asserted, then the cA bit in the basic
      constraints extension (Section 4.2.1.9) MUST also be asserted.

-------

So I'd say that the new CA certificate is quite suspicious, failing fairly fundamental criteria of the spec.
That's why the framework complains about it.

As far as work-arounds go, that should be fairly easy. This warning, as all the other X.509 Warnings, is resumable. So I'd suggest to use a handler with a big, fat comment explaining why you're forced to ignore a serious security warning, making sure that the certificate in question (parameter of the exception) is the one that you're willing to tolerate in your application, and if so then resume the exception. Otherwise pass it on.

HTH,

Martin

"Mark Petersen"<[hidden email]> wrote:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Thanks for the information, Martin.  Yes, I was able to proceed and load.
I forwarded your comments to the owner of the certificate.  He says he got
it from GeoTrust, who uses VeriSign as their root cert signer.  Seems odd
they would ignore Basic Constraints.

Thanks,


                                                                           
 Mark K. Petersen        (Embedded image moved to    Home Office: (319)    
 Semiconductor Research  file: pic12852.jpg)         406-4165 Cell: (845)  
 and Development Center                              235-4360              
 IBM Global Engineering                              Internet email:      
 Solutions                                           [hidden email]  
                                                     DMACS Wiki            
                                                     DMACS Forum          
                                                                           








                                                                                                                         
  From:       [hidden email]                                                                                        
                                                                                                                         
  To:         Mark Petersen/Fishkill/IBM@IBMUS                                                                          
                                                                                                                         
  Cc:         <[hidden email]>                                                                                        
                                                                                                                         
  Date:       11/23/2009 04:18 PM                                                                                        
                                                                                                                         
  Subject:    [vwnc] X509.Certificate issue                                                                              
                                                                                                                         





I haven't been following X.509 developments in a while, but the specs used
to be fairly adamant about requiring CA certificates to have
BasicConstraints. Here's the relevant bit on BasicConstraints from RFC#5280
which seems to be the latest:
------
 Conforming CAs MUST include this extension in all CA certificates
   that contain public keys used to validate digital signatures on
   certificates and MUST mark the extension as critical in such
   certificates.
-------
BC is the primary attribute that distinguishes certificates that are
allowed to issue other certificates from the rest. This distinction is
critical from the security point of view. Without it a CA has no way to
prevent its subjects from issuing fraudulent certificates. For example if
ACME-CA issues a certificate to John Doe, and John Doe then turns around
and issues a certificate for Bank Of America for his phishing web server, a
web browser has no way of distinguishing it from other valid certificates
issued by ACME-CA. Not unless it can determine that John Doe has no right
to issue other certificates. That's what BC is for.

KeyUsage has a flag that is relevant (keyCertSign). It seems that the new
versions of the spec are more strict about requiring inclusion of this
extension as well (for CAs), but it doesn't allow using it instead of BC.

------
             ...
                Conforming CAs MUST include this extension in certificates
that
   contain public keys that are used to validate digital signatures on
   other public key certificates or CRLs.  When present, conforming CAs
   SHOULD mark this extension as critical.

             ...

      The keyCertSign bit is asserted when the subject public key is
      used for verifying signatures on public key certificates.  If the
      keyCertSign bit is asserted, then the cA bit in the basic
      constraints extension (Section 4.2.1.9) MUST also be asserted.

-------

So I'd say that the new CA certificate is quite suspicious, failing fairly
fundamental criteria of the spec.
That's why the framework complains about it.

As far as work-arounds go, that should be fairly easy. This warning, as all
the other X.509 Warnings, is resumable. So I'd suggest to use a handler
with a big, fat comment explaining why you're forced to ignore a serious
security warning, making sure that the certificate in question (parameter
of the exception) is the one that you're willing to tolerate in your
application, and if so then resume the exception. Otherwise pass it on.

HTH,

Martin

"Mark Petersen"<[hidden email]> wrote:
>               5d:a9:04:b5:98:b8:06:22:81

>               Exponent: 65537 (0x10001)

>               X509v3 extensions:

>               X509v3 Key Usage: critical

>               Digital Signature, Non Repudiation, Key Encipherment,
Encryption
>               SubjectKeyIdentifier:

>               2.5.29.31:

>               2.5.29.35:

>               2.5.29.37: Signature Algorithm: sha-1WithRSAEncryption

>               43:b5:d5:a2:80:5f:7f:ad:51:20:ca:69:29:bb:1b:65:d2:1e:

>

>
>
>
> Indeed, I don't see a Basic Constraints stanza in the new certificate.
Is
> Basic Constraints: now Key Usage:?  Any ideas why this would be?  Is
there
> a work-around or fix?
>
> Thanks,
>
>
>

>  Mark K. Petersen        (Embedded image moved to    Home Office: (319)

>  Semiconductor Research  file: pic20898.jpg)         406-4165 Cell: (845)

>  and Development Center                              235-4360

>  IBM Global Engineering                              Internet email:

>  Solutions                                           [hidden email]

>                                                      DMACS Wiki

>                                                      DMACS Forum

>


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc