All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: ell@lists.01.org
Subject: Re: [PATCH v2 4/6] unit: Generate and use PKCS8 version of server key for TLS tests
Date: Mon, 08 Aug 2016 18:30:48 -0500	[thread overview]
Message-ID: <57A91628.7030401@gmail.com> (raw)
In-Reply-To: <alpine.OSX.2.20.1608081408210.4540@mjmartin-mac01.local>

[-- Attachment #1: Type: text/plain, Size: 1558 bytes --]

Hi Mat,

 >
> RSA private keys are a pending addition to the kernel key subsystem in
> the keys-next branch. Only a PKCS#8 private key parser was added to the
> asymmetric key type. Additional parsers can be added, it will try each
> registered parser until one succeeds.
>
> The PKCS#1 key data is stored as an octet string inside the PKCS#8 format.
>
> My impression is that the kernel uses the PKCS#8 format because it only
> accepts DER-encoded keys. PKCS#8 retains both a crypto algorithm
> identifier and a key encryption identifier when private key data is
> converted from PEM to DER (binary), so it the kernel can deduce the
> correct crypto algorithm and decrypt the key. With the OpenSSL-style
> PKCS#1 keys we used before, all the kernel can do is assume that an
> ASN.1 sequence of 9 integers is, in fact, an RSA private key.
>
> Since it's trivial to convert private key files to PKCS#8 with openssl,
> I think it makes sense to stick to PKCS#8 in the ELL key API.

The problem is that the WPA-Enterprise certificate is usually generated 
by the sysadmin or network admin.  So we can't really control what we 
get.  My impression is that PKCS1 format is much more common than #8, 
and converting on the fly isn't really an option.

>
> Do you want me to change the filenames so that cert-client-key.pem and
> cert-server-key.pem are PKCS#8 format? That way there aren't two copies
> of the private key around. I think that would be transparent to the iwd
> unit tests.

No, don't do that.

Regards,
-Denis


  reply	other threads:[~2016-08-08 23:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-08 17:25 [PATCH v2 1/6] key: Add NULL check to l_key_get_info Mat Martineau
2016-08-08 17:25 ` [PATCH v2 2/6] tls: Convert encrypt and verify to l_key crypto Mat Martineau
2016-08-09 16:17   ` Denis Kenzior
2016-08-09 18:36     ` Mat Martineau
2016-08-08 17:25 ` [PATCH v2 3/6] tls: Use l_key crypto for decrypt and sign Mat Martineau
2016-08-09 16:26   ` Denis Kenzior
2016-08-09 18:40     ` Mat Martineau
2016-08-08 17:25 ` [PATCH v2 4/6] unit: Generate and use PKCS8 version of server key for TLS tests Mat Martineau
2016-08-08 17:42   ` Denis Kenzior
2016-08-08 17:53     ` Mat Martineau
2016-08-08 19:58       ` Denis Kenzior
2016-08-08 22:27         ` Mat Martineau
2016-08-08 23:30           ` Denis Kenzior [this message]
2016-08-08 17:25 ` [PATCH v2 5/6] unit: Check return value of l_tls_set_auth_data Mat Martineau
2016-08-08 17:25 ` [PATCH v2 6/6] examples: " Mat Martineau
2016-08-08 17:39 ` [PATCH v2 1/6] key: Add NULL check to l_key_get_info Denis Kenzior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57A91628.7030401@gmail.com \
    --to=denkenz@gmail.com \
    --cc=ell@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.