Re: [openssl-dev] OpenSSL and certain PEM formats

2014-12-21 Thread Kurt Roeckx
On Sat, Dec 20, 2014 at 02:29:44PM +, Dr. Stephen Henson wrote:
 On Fri, Dec 19, 2014, Sean Leonard wrote:
 
  
  On Dec 19, 2014, at 11:35 AM, Kurt Roeckx k...@roeckx.be wrote:
  
   On Fri, Dec 19, 2014 at 03:05:32PM +, Viktor Dukhovni wrote:
   On Fri, Dec 19, 2014 at 08:47:55AM -0500, Daniel Kahn Gillmor wrote:
   
   Does OpenSSL have documented someplace exactly what it means to have a
   TRUSTED CERTIFICATE?
   
   It is a certificate + auxiliary data which specifies a friendly name
   plus a set of EKUs.
   
   Mozilla provides a list of root certificates and that includes at
   least the trust settings for that certificate.  
  
  What exactly is the Mozilla (NSS) format? How does it differ from the 
  OpenSSL format?
  
 
 The last time I checked NSS stored the trust data in a database (Berkeley DB)
 and the trust attributes could be accessed via PKCS#11. I'm not aware of any
 way to export the certificates to a file which retains the trust settings.
 
 I'm not aware of any standard for trust settings. There certainly wasn't
 one when this was added to OpenSSL.

The source is actually a text file you can see here:
https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/ckfw/builtins/certdata.txt

As far as I know they turn the file into a database, not the other
way around.


Kurt

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev


Re: [openssl-dev] OpenSSL and certain PEM formats

2014-12-19 Thread Sean Leonard

On 12/18/2014 4:41 AM, Salz, Rich wrote:

Are you trying to be proscriptive (say what people should use) or descriptive 
(document what is in use)?

Yes, PKCS8-based PRIVATE KEY is better.  But RSA PRIVATE KEY is in (wide) use 
and should be described.


I am trying to be proscriptively descriptive about what is in use and 
will lead to (continued) interoperability.


In the case of the * PRIVATE KEY labels, not a lot of crypto software 
supports it. The two biggest ones that I know of are OpenSSL and 
PolarSSL. (To my knowledge PolarSSL only supports RSA PRIVATE KEY and 
EC PRIVATE KEY--all others need to be in PRIVATE KEY PKCS #8 
format.) These two OSS implementations may in fact dominate the market 
but only a certain market segment (namely web servers, and by extension, 
the web interfaces to web servers by web hosting companies). If you want 
to import a private key into Mac OS X, Mozilla NSS, Microsoft CryptoAPI, 
or the Java VM, you need to package it up (typically with a certificate) 
in a PKCS #12 file.


PKCS #1 is an IETF (adopted) standard but PKCS #1 doesn't prescribe the 
RSA PRIVATE KEY label; it only defines the ASN.1 (BER/DER) 
representation. And PKCS #1 is no more or less a standard than the other 
IETF documents for the other key types, like Diffie-Hellman, ECC, etc.


Anyway, the document was approved so it should be published with *minor* 
changes as an RFC soon. I am loathe to add new labels/formats; I am not 
convinced the threshold is met here.


Cheers,

Sean

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev


Re: [openssl-dev] OpenSSL and certain PEM formats

2014-12-19 Thread Dave Thompson
 From: openssl-dev On Behalf Of Salz, Rich
 Sent: Thursday, December 18, 2014 07:42

 Are you trying to be proscriptive (say what people should use) or
descriptive
 (document what is in use)?
 
 Yes, PKCS8-based PRIVATE KEY is better.  But RSA PRIVATE KEY is in (wide)
 use and should be described.
 
E.g. Wireshark uses -- or did when I looked a few versions ago -- only the 
legacy RSA PRIVATE KEY form or PKCS12 not the PKCS8 PRIVATE KEY form.

(PEM_read_*PrivateKey silently handles either legacy or PKCS8, but 
Wireshark doesn't use OpenSSL it uses GnuTLS.)

There are also legacy DSA PRIVATE KEY and EC PRIVATE KEY.
On the whole these algorithms and keys were not used as much as RSA 
in the past (EC is now rising) but they were used and may still exist.

Technically there are legacy formats and IMPLEMENT_PEM routines for 
specific RSA,DSA,EC PUBLIC KEY. But PUBKEY (SPKI) has been default 
for at least 10 years, so these are probably very very little used.


___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev


Re: [openssl-dev] OpenSSL and certain PEM formats

2014-12-19 Thread Viktor Dukhovni
On Fri, Dec 19, 2014 at 08:47:55AM -0500, Daniel Kahn Gillmor wrote:

 Does OpenSSL have documented someplace exactly what it means to have a
 TRUSTED CERTIFICATE?

It is a certificate + auxiliary data which specifies a friendly name
plus a set of EKUs.

 For example, say we're talking about a certificate that i am willing to
 accept for the peer foo.example.  If i mark it TRUSTED and it has
 another SubjectAltName of bar.example, will OpenSSL subsequently accept
 it for bar.example as well?

http://marc.info/?l=openssl-devm=115218769327835w=2

There is no explicit association with a particular peer, it is up
to the application to add corresponding trusted certificates to
the store when validating particular peers for which such certificates
have been configured.  If such a certificate is added to the default
store, then it will apply to all cases with a matching EKU.

-- 
Viktor.
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev


Re: [openssl-dev] OpenSSL and certain PEM formats

2014-12-19 Thread Viktor Dukhovni
On Fri, Dec 19, 2014 at 07:02:29AM -0800, Sean Leonard wrote:

 There is also a TRUSTED CERTIFICATE label that OpenSSL uses...I believe
 this is a vendor-specific extension but now that I am spelunking through the
 source code I see that it could be abused. Relevant source code/comments
 say:
 https://www.openssl.org/docs/apps/x509.html

What is this abuse you speak of.  No remote actor injects trusted
certificates into the verifier's list of trust anchors.  Trusted
certificates are actually less trusted certificates, in that
their set of EKUs is potentially constrained.

-- 
Viktor.
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev


Re: [openssl-dev] OpenSSL and certain PEM formats

2014-12-19 Thread Kurt Roeckx
On Fri, Dec 19, 2014 at 03:05:32PM +, Viktor Dukhovni wrote:
 On Fri, Dec 19, 2014 at 08:47:55AM -0500, Daniel Kahn Gillmor wrote:
 
  Does OpenSSL have documented someplace exactly what it means to have a
  TRUSTED CERTIFICATE?
 
 It is a certificate + auxiliary data which specifies a friendly name
 plus a set of EKUs.

Mozilla provides a list of root certificates and that includes at
least the trust settings for that certificate.  In Debian we then
extract the certificates from that so that it can be used by
applications that need to have a list of trusted CAs.  However
those trust settings are removed because not everything that wants
to use those certificates understands the trusted certificate.  It
would be useful to have a standardised format.


Kurt

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev


Re: [openssl-dev] OpenSSL and certain PEM formats

2014-12-19 Thread Sean Leonard

On Dec 19, 2014, at 11:35 AM, Kurt Roeckx k...@roeckx.be wrote:

 On Fri, Dec 19, 2014 at 03:05:32PM +, Viktor Dukhovni wrote:
 On Fri, Dec 19, 2014 at 08:47:55AM -0500, Daniel Kahn Gillmor wrote:
 
 Does OpenSSL have documented someplace exactly what it means to have a
 TRUSTED CERTIFICATE?
 
 It is a certificate + auxiliary data which specifies a friendly name
 plus a set of EKUs.
 
 Mozilla provides a list of root certificates and that includes at
 least the trust settings for that certificate.  

What exactly is the Mozilla (NSS) format? How does it differ from the OpenSSL 
format?

Sean
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev


Re: [openssl-dev] OpenSSL and certain PEM formats

2014-12-18 Thread Kurt Roeckx
On Wed, Dec 17, 2014 at 08:34:52PM +0100, Erwann Abalea wrote:
 Le 17/12/2014 20:17, Viktor Dukhovni a écrit :
 On Wed, Dec 17, 2014 at 10:56:34AM -0800, Sean Leonard wrote:
 
 For reference for the group (in case you didn't take a look at the draft),
 the draft documents the following labels:
 
 CERTIFICATE
 ...
 Perhaps also TRUSTED CERTIFICATE?
 
  crypto/pem/pem.h:#define PEM_STRING_X509_TRUSTEDTRUSTED 
  CERTIFICATE
 
 It's specific to OpenSSL.

And it would be useful if it wasn't.


Kurt

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev


Re: [openssl-dev] OpenSSL and certain PEM formats

2014-12-18 Thread Salz, Rich
Are you trying to be proscriptive (say what people should use) or descriptive 
(document what is in use)?

Yes, PKCS8-based PRIVATE KEY is better.  But RSA PRIVATE KEY is in (wide) use 
and should be described.


___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev


[openssl-dev] OpenSSL and certain PEM formats

2014-12-17 Thread Sean Leonard

Hi OpenSSL devs:

I am putting the finishing touches on an Internet-Draft for textual 
encodings of security structures 
http://tools.ietf.org/html/draft-josefsson-pkix-textual-09, which 
OpenSSL refers to as the PEM format.


While reviewing OpenSSL's behavior, I noticed a few esoteric labels (see 
pem.h):

#define PEM_STRING_X509_PAIRCERTIFICATE PAIR
  (note, this is supposed to encapsulate a CertificatePair structure 
from X.509)

#define PEM_STRING_SSL_SESSIONSSL SESSION PARAMETERS
#define PEM_STRING_PARAMETERSPARAMETERS
  (note, this label does not have any algorithms in it, so I presume it 
refers to some kind of generic parameter structure)


Do these labels have practical use? I have not seen them in the wild. 
Why are they in OpenSSL? Are they ever used for interchange with other 
implementations, or are they specific to OpenSSL's own purposes?


Thanks,

Sean
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev


Re: [openssl-dev] OpenSSL and certain PEM formats

2014-12-17 Thread Kurt Roeckx
On Wed, Dec 17, 2014 at 02:37:08AM -0800, Sean Leonard wrote:
 Hi OpenSSL devs:
 
 I am putting the finishing touches on an Internet-Draft for textual
 encodings of security structures
 http://tools.ietf.org/html/draft-josefsson-pkix-textual-09, which OpenSSL
 refers to as the PEM format.
 
 While reviewing OpenSSL's behavior, I noticed a few esoteric labels (see
 pem.h):
 #define PEM_STRING_X509_PAIRCERTIFICATE PAIR
   (note, this is supposed to encapsulate a CertificatePair structure from
 X.509)
 #define PEM_STRING_SSL_SESSIONSSL SESSION PARAMETERS
 #define PEM_STRING_PARAMETERSPARAMETERS
   (note, this label does not have any algorithms in it, so I presume it
 refers to some kind of generic parameter structure)
 
 Do these labels have practical use? I have not seen them in the wild. Why
 are they in OpenSSL? Are they ever used for interchange with other
 implementations, or are they specific to OpenSSL's own purposes?

I know that the ssl session parameters can be read and written by
s_client and sess_id.  It can be used to resume a session.
applications can store the session information in a database or
something like that to later be able to resume the session.  But I
don't think anything uses it without openssl.  It's stored in an
SSL_SESSION_ASN1 which is an internal only structure that can
changed between versions.  Only the version that has written that
should be able to read it.


Kurt

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev


Re: [openssl-dev] OpenSSL and certain PEM formats

2014-12-17 Thread Salz, Rich
  I am putting the finishing touches on an Internet-Draft for textual
  encodings of security structures
  http://tools.ietf.org/html/draft-josefsson-pkix-textual-09, which
  OpenSSL refers to as the PEM format.

Cool.  You know why it's called PEM format, right?  (RFC 1115 et al)

  #define PEM_STRING_X509_PAIRCERTIFICATE PAIR
(note, this is supposed to encapsulate a CertificatePair structure
  from X.509)

This is not used anywhere in openssl.  I just removed it and did a build :)  
The fact that the fields are named forward and backward, makes me think it was 
intended for SSL/TLS use.  But as I said it's not used and I'll remove it soon.

  #define PEM_STRING_SSL_SESSIONSSL SESSION PARAMETERS

As Kurt said, this is for internal use only, no guarantee it works across any 
two revisions.

  #define PEM_STRING_PARAMETERSPARAMETERS
(note, this label does not have any algorithms in it, so I presume
  it refers to some kind of generic parameter structure)

It's used to encode arbitrary parameters for ENGINE, which is OpenSSL's 
crypto-hardware abstraction. 

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev


Re: [openssl-dev] OpenSSL and certain PEM formats

2014-12-17 Thread Erwann Abalea

Le 17/12/2014 17:34, Salz, Rich a écrit :

#define PEM_STRING_X509_PAIRCERTIFICATE PAIR
   (note, this is supposed to encapsulate a CertificatePair structure
from X.509)

This is not used anywhere in openssl.  I just removed it and did a build :)  
The fact that the fields are named forward and backward, makes me think it was 
intended for SSL/TLS use.  But as I said it's not used and I'll remove it soon.


It's an object type defined in X.509 to support cross-certification. It 
can be used as an LDAP attribute (see RFC4523, section 2.3, 
CertificatePair).


I haven't seen it used, and it doesn't need to have a PEM representation 
(LDAP requires a binary transmission).


___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev


Re: [openssl-dev] OpenSSL and certain PEM formats

2014-12-17 Thread Sean Leonard

On 12/17/2014 10:00 AM, Dr. Stephen Henson wrote:

On Wed, Dec 17, 2014, Sean Leonard wrote:


#define PEM_STRING_PARAMETERSPARAMETERS
   (note, this label does not have any algorithms in it, so I presume
it refers to some kind of generic parameter structure)


It's used internally to indicate to the PEM routines that it should accept any
kind of algorithm parameters and set up an EVP_PKEY structure appropriately.


Okay--so this one also sounds like it is not meant for interchange. I 
can cross this one off the list as well. Thanks!


For reference for the group (in case you didn't take a look at the 
draft), the draft documents the following labels:


CERTIFICATE
X509 CRL
CERTIFICATE REQUEST
PKCS7
CMS
PRIVATE KEY
ENCRYPTED PRIVATE KEY
ATTRIBUTE CERTIFICATE
PUBLIC KEY


as well as some other labels like NEW CERTIFICATE REQUEST for 
compatibility.


Sean
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev


Re: [openssl-dev] OpenSSL and certain PEM formats

2014-12-17 Thread Viktor Dukhovni
On Wed, Dec 17, 2014 at 10:56:34AM -0800, Sean Leonard wrote:

 For reference for the group (in case you didn't take a look at the draft),
 the draft documents the following labels:
 
 CERTIFICATE
 ...

Perhaps also TRUSTED CERTIFICATE?

crypto/pem/pem.h:#define PEM_STRING_X509_TRUSTEDTRUSTED 
CERTIFICATE

-- 
Viktor.
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev


Re: [openssl-dev] OpenSSL and certain PEM formats

2014-12-17 Thread Sean Leonard

On 12/17/2014 11:04 AM, Salz, Rich wrote:

Probably also worth documenting the legacy RSA PRIVATE KEY defined by openssl 
and used mainly in legacy pre-pkcs8 support


There is a paragraph on algorithm agility; the legacy labels (like RSA 
PRIVATE KEY) are not mentioned because for interchange, PKCS #8 is 
perfectly reasonable and is algorithm-agile.


IIRC, there are some implementations out there (by that I mean certain 
well-known certification authorities that I will not name) that 
specifically look for RSA PRIVATE KEY, and measure key strength by 
looking at the length of the blob. This method prevents other algorithms 
(e.g., ECC) from being used, and when other algorithms (e.g., ECC) are 
used, the key gets rejected for no other reason than because the key 
appears to be too small and therefore weak.


Sean

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev