Re: Reg. type of certificate - CA / EE based on X509_check_ca().

2014-07-08 Thread Sanjaya Joshi
Thanks for the reply Tom and Kyle H.

Now i have below 2 questions:

(1) Based on application's need, can we assume return codes 2, 3 and 4 as
non-CA ?
(2) If we get return code 4 basicConstraints absent but keyUsage present
and keyCertSign asserted for a certificate, is this a valid certificate ?
Because RFC 3280 says:

The keyCertSign bit is asserted when the subject public key is

  used for verifying a signature on public key certificates.  If the

  keyCertSign bit is asserted, then the cA bit in the basic
  constraints extension (section 4.2.1.10) MUST also be asserted.


Regards,
Sanjaya



On Tue, Jul 8, 2014 at 2:16 AM, Kyle Hamilton aerow...@gmail.com wrote:


 On 7/7/2014 2:40 AM, Sanjaya Joshi wrote:
  Hello,
My application uses openssl 1.0.0, and it uses X509_check_ca() to
  find out if an X509 certificate is a CA certificate, or an End-entity
  (EE) certificate.
 
  The below are the possible return codes.
 
  /* return codes of X509_check_ca():
  * 0 not a CA
  * 1 is a CA
  * 2 basicConstraints absent so maybe a CA
  * 3 basicConstraints absent but self signed V1.
  * 4 basicConstraints absent but keyUsage present and
  keyCertSign asserted.
  */
 
  My question here is, if we get return code as 4, should we consider
  this as a CA certificate or an EE certificate ?
 
  Any quick support in this regard is much appreciated.
  Regards,
  Sanjaya

 This depends on your environment, and the types of certificates that the
 CAs used issue.

 The reason the codes are differentiated is because the authors of the
 library can't make a blanket determination for the library's clients. :P

 -Kyle H




Re: Reg. type of certificate - CA / EE based on X509_check_ca().

2014-07-08 Thread Kyle Hamilton
This is unfortunately something that you need to figure out for yourself.

The controlling standard is not RFC 3280, or in fact any of the RFCs. 
It is X.509, available from http://www.itu.int/.  (You can get the
latest ratified edition for no cost.)

However:

2 should probably not be considered a CA if you are expecting RFC3280
compliance.
3 is usually considered a CA, because self-signed V1 CAs were kept in
legacy production in many circumstances.  This technically violates
RFC3280, but there at least used to be many examples of things that
expected it anyway.
4 should probably not be considered a CA if you are expecting RFC3280
compliance.

-Kyle H

On 7/8/2014 1:13 AM, Sanjaya Joshi wrote:
 Thanks for the reply Tom and Kyle H.

 Now i have below 2 questions:

 (1) Based on application's need, can we assume return codes 2, 3 and 4
 as non-CA ?
 (2) If we get return code 4 basicConstraints absent but keyUsage
 present and keyCertSign asserted for a certificate, is this a valid
 certificate ? Because RFC 3280 says:

 The keyCertSign bit is asserted when the subject public key is

   used for verifying a signature on public key certificates.  If the

   keyCertSign bit is asserted, then the cA bit in the basic

   constraints extension (section 4.2.1.10) MUST also be asserted.


 Regards,
 Sanjaya



 On Tue, Jul 8, 2014 at 2:16 AM, Kyle Hamilton aerow...@gmail.com
 mailto:aerow...@gmail.com wrote:


 On 7/7/2014 2:40 AM, Sanjaya Joshi wrote:
  Hello,
My application uses openssl 1.0.0, and it uses X509_check_ca() to
  find out if an X509 certificate is a CA certificate, or an
 End-entity
  (EE) certificate.
 
  The below are the possible return codes.
 
  /* return codes of X509_check_ca():
  * 0 not a CA
  * 1 is a CA
  * 2 basicConstraints absent so maybe a CA
  * 3 basicConstraints absent but self signed V1.
  * 4 basicConstraints absent but keyUsage present and
  keyCertSign asserted.
  */
 
  My question here is, if we get return code as 4, should we consider
  this as a CA certificate or an EE certificate ?
 
  Any quick support in this regard is much appreciated.
  Regards,
  Sanjaya

 This depends on your environment, and the types of certificates
 that the
 CAs used issue.

 The reason the codes are differentiated is because the authors of the
 library can't make a blanket determination for the library's
 clients. :P

 -Kyle H





smime.p7s
Description: S/MIME Cryptographic Signature


Re: Reg. type of certificate - CA / EE based on X509_check_ca().

2014-07-08 Thread Jeffrey Walton
 The controlling standard is not RFC 3280, or in fact any of the RFCs.  It is
 X.509, available from http://www.itu.int/.  (You can get the latest ratified
 edition for no cost.)
If its a server certificate issued by a CA intended to be consumed by
browsers (or other related services), then the CA likely issued under
the CA/Browser Forums Baseline Requirements and EV Guide; not RFCs
like 5280 and 6125.

You can find them at
http://cabforum.org/baseline-requirements-documents/ and
http://cabforum.org/extended-validation-2/.

Jeff
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: Reg. type of certificate - CA / EE based on X509_check_ca().

2014-07-07 Thread Tom Francis

On Jul 7, 2014, at 5:40 AM, Sanjaya Joshi joshi.sanj...@gmail.com wrote:

 Hello,
   My application uses openssl 1.0.0, and it uses X509_check_ca() to find out 
 if an X509 certificate is a CA certificate, or an End-entity (EE) certificate.
 
 The below are the possible return codes.
 
 /* return codes of X509_check_ca():
 * 0 not a CA
 * 1 is a CA
 * 2 basicConstraints absent so maybe a CA
 * 3 basicConstraints absent but self signed V1.
 * 4 basicConstraints absent but keyUsage present and keyCertSign 
 asserted.
 */
 
 My question here is, if we get return code as 4, should we consider this as a 
 CA certificate or an EE certificate ?

It really depends on your use case, I think.  For example, one application I 
worked on had to “import” certificates to aid another process in locating 
certificates and building certificate chains (this goes back a _long_ time 
ago).  For that one, it made more sense to treat such a cert as a CA 
certificate, since it was not uncommon for certificates that had their version 
set to V3 to be missing basicConstraints, and V1 certificates were still quite 
popular.  The app needed to be able to import such certificates into locations 
for most efficient access (and putting a cert that should be used in building a 
chain into a location that wasn’t considered for building the chain would be 
really bad).  If your use case is significantly different, you could go either 
way, or maybe even reject such certificates entirely.

TOM

 Any quick support in this regard is much appreciated.
 Regards,
 Sanjaya

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: Reg. type of certificate - CA / EE based on X509_check_ca().

2014-07-07 Thread Kyle Hamilton

On 7/7/2014 2:40 AM, Sanjaya Joshi wrote:
 Hello,
   My application uses openssl 1.0.0, and it uses X509_check_ca() to
 find out if an X509 certificate is a CA certificate, or an End-entity
 (EE) certificate.

 The below are the possible return codes.

 /* return codes of X509_check_ca():
 * 0 not a CA
 * 1 is a CA
 * 2 basicConstraints absent so maybe a CA
 * 3 basicConstraints absent but self signed V1.
 * 4 basicConstraints absent but keyUsage present and
 keyCertSign asserted.
 */

 My question here is, if we get return code as 4, should we consider
 this as a CA certificate or an EE certificate ?

 Any quick support in this regard is much appreciated.
 Regards,
 Sanjaya

This depends on your environment, and the types of certificates that the
CAs used issue.

The reason the codes are differentiated is because the authors of the
library can't make a blanket determination for the library's clients. :P

-Kyle H



smime.p7s
Description: S/MIME Cryptographic Signature