Re: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt
David Benjamin <davidben@chromium.org> Wed, 10 May 2017 22:47 UTC
Return-Path: <davidben@google.com>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B96128B51 for <curdle@ietfa.amsl.com>; Wed, 10 May 2017 15:47:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYcBzLDEAI3R for <curdle@ietfa.amsl.com>; Wed, 10 May 2017 15:47:51 -0700 (PDT)
Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFD981270FC for <curdle@ietf.org>; Wed, 10 May 2017 15:47:50 -0700 (PDT)
Received: by mail-pg0-x22a.google.com with SMTP id 64so4660510pgb.3 for <curdle@ietf.org>; Wed, 10 May 2017 15:47:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/49lU8BjAcP5YwmJWlVFiInTngigFd4lvl9wM7yyDso=; b=kGqQjTU0QP5GIxjPXY8KpjMTAf5TnYrjN5zS2nMdvIrGIGeWjfWPruUkjK+K+IQVVE OX717aOaL0MTtbzYwk+ilM8rnKQ3zYLKSxdVBNkqmJGXDu8QL9abViHhnpjjr/7Q4EGR apchmwhSMCodRLjfDAYx/NmVmRhoKI/QZu8dE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/49lU8BjAcP5YwmJWlVFiInTngigFd4lvl9wM7yyDso=; b=rbNs9W5g4hH4/F+Goa3k+gPDlyBrraONoE7TA95OyEDG+Us+MvG+8mez7mMwKIySxk lK6PtQUAH9XvrEwmEVq10ri9z65BLTYxYvn4WQdN+scO8Ke4FtLNOkk/C8+mk3xlk6Ko JdJRWagtoD443ocih3w5zyZ/VktDMgs+IPpNYm7NCpbqjoKz+mgSyj7nLM7pXrOxxm4j bSu+/SZG3qX/FNNH/E7GBg0rhmrlMqs5VtOVc8DNv2TtzHqzI0DL94czphF9v7WUCnQU NYtOC4YQgczaSSdwu1aJSfP5c+XM5p6PZ1yUd9On+AjuPALn6YFkvMX78oB3twqG9KHU 1smQ==
X-Gm-Message-State: AODbwcBUJHdUrokrVRuJOulqW/PATZ6YnoM1xL7tGt8EDloEPCrdbP5Y Q0/cJaBPjKzXkBX+68LFJ9IYOEGOJyS4
X-Received: by 10.99.154.18 with SMTP id o18mr8892197pge.59.1494456470340; Wed, 10 May 2017 15:47:50 -0700 (PDT)
MIME-Version: 1.0
References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <CAFewVt6-0WSqmwD7xVvKWDg3P9vNpFZDqB-n61hiU9qQp1c2cw@mail.gmail.com> <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> <CAFewVt7iuyzY-VkQn7V7PjEOWyk0k7-KLsmpEGjhSdTh7JW2Og@mail.gmail.com> <CAFewVt5v_bqQMo7ZpnnUWa2c41Xy-SkUWw63sh8Yn-UWskKdmw@mail.gmail.com> <CAFewVt4dv0Q2C_N+Cn2or6D+_CdZCDwfoe-g1sOTJqNSJON_nw@mail.gmail.com> <CAFewVt4sJE9+sdPAjtQKL0L+RqkgS9AXaa5ytGOK80Bcgua8sA@mail.gmail.com> <001c01d2c998$ba1f6f80$2e5e4e80$@augustcellars.com> <CAFewVt5nDnSLga7ZpyY8sZO2TNpn4cOC0oAhapKSkWV64cavDQ@mail.gmail.com>
In-Reply-To: <CAFewVt5nDnSLga7ZpyY8sZO2TNpn4cOC0oAhapKSkWV64cavDQ@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Wed, 10 May 2017 22:47:38 +0000
Message-ID: <CAF8qwaByALNz1=LSTtCg0PrqrDe7mN2da5gFqAp2dHA9Cjxbtg@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>, Jim Schaad <ietf@augustcellars.com>
Cc: curdle <curdle@ietf.org>
Content-Type: multipart/alternative; boundary="f403045e2c0a0c7db7054f334348"
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/jmnNDtxnsxoQZw3iK1hX5h6-gso>
Subject: Re: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 May 2017 22:47:55 -0000
On Wed, May 10, 2017 at 6:23 PM Brian Smith <brian@briansmith.org> wrote: > Jim Schaad <ietf@augustcellars.com> wrote: > > I have not yet gotten to the point of validating the edge cases, > although the number seems to be getting to the point of a test suite which > I would prefer to handle in a different manner. > > I would prefer the test suite to be incorporated into the RFC, and for > it to be considered normative. > > > Public keys - I think that it makes sense to talk about saying that > checks needs to be done on public keys. For the set of checks I can just > reference the two drafts, I do not think that I need to re-state them in > this draft. > > It would be good to see the text that will be used. I personally agree > that consistency of the private and public key MUST/SHOULD be checked, > but others may disagree. > > More importantly, there should be a requirement that the v2 form (with > the public key) must be accepted. > I think requiring the consistency check here is excessive. You're now requiring everyone compute it, which means there was no point in including it to begin with. Yes, it provides a corruption check, but a rather convoluted one, as this thread demonstrates. You've got problems with high bits being set, etc. I think folks who care about detecting corruption should add an external checksum to wherever they're getting their keys from. That is simpler, works uniformly for all key types, and avoids raising questions like "why aren't you doing a consistency check on the attributes?". If an application needs both corruption detection *and* is incapable of adding it to the layer above, this is so specific a use case that requiring everyone do it does not make sense. If we really believed this should be universal to private key transport, we would have defined every private key format in the world to be K || hash(K). Instead, I would recommend serving that use case by defining a checksum attribute type in a separate document and getting it standardized. I don't especially object to requiring the v2 form be accepted or fixing BoringSSL to accept it, but if the only use is a mandatory convoluted checksum check, then I would rather we throw v2 away and stick with the simple thing. > > Private keys - There is a slightly interesting trade-off that may need > to be considered at this point. One can either have the keys in the > correct format, or one can require that the correct masking be applied > during the import step. The reason for requiring the latter is that it > removes some of the fixed structure of the private key. This has a (very > small) advantage as a totally random item is harder to make guesses at. It > is true however that there is other structure in the text that is encrypted > so this would be a very small advantage. When I wrote my code, I did the > import and then the masking step as the masking needs to be done in a lot > of cases when operations are done. Do people have opinions on this? > > Every possible 32-byte private key should be accepted, and the > implementation should mask the input after parsing the privateKey > value and before doing the pairwise consistency check (if any) and > before doing any operation using the private key. See my other reply > where I provide test vectors for this. > > Cheers, > Brian > -- > https://briansmith.org/ > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle >
- Re: [Curdle] FW: New Version Notification for dra… Mehner, Carl
- Re: [Curdle] FW: New Version Notification for dra… Russ Housley
- [Curdle] FW: New Version Notification for draft-i… Jim Schaad
- Re: [Curdle] FW: New Version Notification for dra… Daniel Migault
- Re: [Curdle] New Version Notification for draft-i… David Schinazi
- Re: [Curdle] New Version Notification for draft-i… Tommy Pauly
- Re: [Curdle] FW: New Version Notification for dra… Brian Smith
- Re: [Curdle] FW: New Version Notification for dra… Jim Schaad
- Re: [Curdle] FW: New Version Notification for dra… Brian Smith
- Re: [Curdle] FW: New Version Notification for dra… David Benjamin
- Re: [Curdle] FW: New Version Notification for dra… Brian Smith
- Re: [Curdle] FW: New Version Notification for dra… Brian Smith
- Re: [Curdle] FW: New Version Notification for dra… Brian Smith
- Re: [Curdle] FW: New Version Notification for dra… Brian Smith
- Re: [Curdle] FW: New Version Notification for dra… Ilari Liusvaara
- Re: [Curdle] FW: New Version Notification for dra… Jim Schaad
- Re: [Curdle] FW: New Version Notification for dra… David Benjamin
- Re: [Curdle] FW: New Version Notification for dra… Brian Smith
- Re: [Curdle] FW: New Version Notification for dra… Brian Smith
- Re: [Curdle] FW: New Version Notification for dra… David Benjamin
- Re: [Curdle] FW: New Version Notification for dra… Brian Smith
- Re: [Curdle] FW: New Version Notification for dra… Jim Schaad
- Re: [Curdle] New Version Notification for draft-i… Russ Housley
- Re: [Curdle] FW: New Version Notification for dra… Brian Smith
- Re: [Curdle] FW: New Version Notification for dra… Brian Smith
- Re: [Curdle] FW: New Version Notification for dra… David Benjamin
- Re: [Curdle] FW: New Version Notification for dra… Jim Schaad
- Re: [Curdle] FW: New Version Notification for dra… Brian Smith