All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Vitaly Chikunov <vt@altlinux.org>
Cc: dhowells@redhat.com, Stephan Mueller <smueller@chronox.de>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Mimi Zohar <zohar@linux.vnet.ibm.com>,
	Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	linux-integrity@vger.kernel.org, keyrings@vger.kernel.org,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 4/4] crypto: Add EC-RDSA algorithm
Date: Wed, 16 Jan 2019 16:15:20 +0000	[thread overview]
Message-ID: <21602.1547655320@warthog.procyon.org.uk> (raw)
In-Reply-To: <20190107090449.d364ii24zervlsfq@sole.flsd.net>

Vitaly Chikunov <vt@altlinux.org> wrote:

> > Regarding your comment (2), I am not sure I understand. Why do you say that 
> > the DER format cannot be parsed by the kernel's ASN.1 parser? For example, 
> 
> It can, but DER is stricter than BER. For example, in DER 'OCTET STRING'
> length field should be encoded in just one byte if it's smaller than
> 128, in BER it could be encoded in multiple encodings. This does not
> seem like a big deal, though. With BER decoder an improperly DER-encoded
> certificate could be successfully parsed.

Whilst that is true, I don't think it's that big a deal.  DER is a subset of
BER, so a BER decoder ought to be able to parse it.  Note that X.509 is
supposed to be DER, but we use a BER decoder for that too.

David

  parent reply	other threads:[~2019-01-16 16:15 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-06 13:36 [RFC PATCH 0/4] crypto: Add EC-RDSA algorithm Vitaly Chikunov
2019-01-06 13:36 ` Vitaly Chikunov
2019-01-06 13:36 ` [RFC PATCH 1/4] X.509: Parse public key parameters from x509 for akcipher Vitaly Chikunov
2019-01-06 13:36   ` Vitaly Chikunov
2019-02-09 21:42   ` Vitaly Chikunov
2019-02-09 21:42     ` Vitaly Chikunov
2019-02-10 18:46     ` Vitaly Chikunov
2019-02-10 18:46       ` Vitaly Chikunov
2019-02-19  4:37       ` Herbert Xu
2019-02-19  4:37         ` Herbert Xu
2019-02-24  6:48         ` Vitaly Chikunov
2019-02-24  6:48           ` Vitaly Chikunov
2019-02-28  6:14           ` Herbert Xu
2019-02-28  6:14             ` Herbert Xu
2019-02-28  7:04             ` Vitaly Chikunov
2019-02-28  7:04               ` Vitaly Chikunov
2019-02-28  7:11               ` Vitaly Chikunov
2019-02-28  7:11                 ` Vitaly Chikunov
2019-02-28  7:51               ` Herbert Xu
2019-02-28  7:51                 ` Herbert Xu
2019-02-28  8:28                 ` Vitaly Chikunov
2019-02-28  8:28                   ` Vitaly Chikunov
2019-02-28  9:01                   ` Herbert Xu
2019-02-28  9:01                     ` Herbert Xu
2019-02-28 10:33                     ` Vitaly Chikunov
2019-02-28 10:33                       ` Vitaly Chikunov
2019-02-28 10:37                       ` Herbert Xu
2019-02-28 10:37                         ` Herbert Xu
2019-03-01 16:06                         ` Vitaly Chikunov
2019-03-01 16:06                           ` Vitaly Chikunov
2019-01-06 13:36 ` [RFC PATCH 2/4] akcipher: Introduce verify2 for public key algorithms Vitaly Chikunov
2019-01-06 13:36   ` Vitaly Chikunov
2019-01-06 13:36 ` [RFC PATCH 3/4] KEYS: set correct flags for keyctl if encrypt is not supported Vitaly Chikunov
2019-01-06 13:36   ` Vitaly Chikunov
2019-01-06 13:36 ` [RFC PATCH 4/4] crypto: Add EC-RDSA algorithm Vitaly Chikunov
2019-01-06 13:36   ` Vitaly Chikunov
2019-01-06 18:11   ` Stephan Müller
2019-01-06 18:11     ` Stephan Müller
2019-01-07  8:07     ` Vitaly Chikunov
2019-01-07  8:07       ` Vitaly Chikunov
2019-01-07  8:31       ` Stephan Mueller
2019-01-07  8:31         ` Stephan Mueller
2019-01-07  9:04         ` Vitaly Chikunov
2019-01-07  9:04           ` Vitaly Chikunov
2019-01-16 16:15         ` David Howells [this message]
2019-01-16 16:19 ` [RFC PATCH 2/4] akcipher: Introduce verify2 for public key algorithms David Howells

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=21602.1547655320@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=smueller@chronox.de \
    --cc=vt@altlinux.org \
    --cc=zohar@linux.vnet.ibm.com \
    /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.