From nobody Thu Sep 1 17:22:24 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4913712D7A9 for ; Thu, 1 Sep 2016 17:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TCbNbq6dp-37 for ; Thu, 1 Sep 2016 17:22:20 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 24A3412D7A2 for ; Thu, 1 Sep 2016 17:22:20 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id v123so102893043qkh.2 for ; Thu, 01 Sep 2016 17:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=rBBc3Zu7Cg5sy07HLsSX50YYuko4hf/UZPC8GK41oL8=; b=cq1D58vZOU/yL/4spnEm7f58GfKikONQXYHuHDUpSa8yXbHpYIR7CYi44RjnjQt/Wp wiR37sVcq2/CMhpbUSjVQAY5vs8AIQe4O8FNam4V339dISA2OskVJLCUWq1DBk04+eKs FBFnf/edRo/YYZXn1H+ZmajV/Gq7UcPt6HUDzo9++EQE5l2TqC5nWIuxd7fLidlQZgtu Dsf3v28jtABqY0gDsf+Uqe0FID3VIixuoq06Qsu+J2rj9etvtyfkIh1QBvElsBQHDi6C qMixTMJhsckBjBFvZea9m80RCNGvz0neAh9UEFL+IFbTqrI9VWzKjeKkze2L4twvXRJv uMGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=rBBc3Zu7Cg5sy07HLsSX50YYuko4hf/UZPC8GK41oL8=; b=AlBPQ3Mxo2zDSXgESpmPM/jP3TAih4fA3rU8sEYdc9Cf0N3caD48Ya9ux9BvenW2yB bmYBEpAXZ1LgRjq6D+L3zkud2OPAm0Jf4mmKvskdSqAG0oaYDIgfvlROnZGz98ZCOgco y5GNvoSw58UvyYs/yuCadoPBjqvt58hT56HzWyPKraX11SviUNCIvOkkGpnseuUcRFBL GY/qrKQTdR5Xxp4ze/koMJupk80gESjfYjNCML+wnBS0DWpFsIBgYwpld2X5qdWfwl+9 od1Ty8nAIwokfxDpy2yyn4nYYHAM6lkLHo+Fclx9e9Z0Iky6bHPPlDh8TeqxrAMNZ5aq cGaw== X-Gm-Message-State: AE9vXwPu+U/dhg/Nu0Go7mlqxlcAAL3yGYSk2Rq3zPmKdmtr4Q7v+QJfKEAu8WXrA2uu7Zn0iTlyYGp1MOljvQ== X-Received: by 10.55.18.148 with SMTP id 20mr7534131qks.210.1472775739023; Thu, 01 Sep 2016 17:22:19 -0700 (PDT) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.200.36.199 with HTTP; Thu, 1 Sep 2016 17:22:18 -0700 (PDT) From: Adam Langley Date: Thu, 1 Sep 2016 17:22:18 -0700 X-Google-Sender-Auth: U8Vo11iHrLR9fhAtKjd2R-v9Tdg Message-ID: To: spasm@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Spasm] Chunking ciphertexts X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 00:22:23 -0000 Since the WG is currently considering changes to S/MIME, I'd like to mention the benefits of chunking ciphertexts. (Or, rather, the problems with not chunking them.) As I understand it, S/MIME and associated standards typically encrypt payloads as a single ciphertext (i.e. RFC 5084). Since the plaintexts might be quite large, this encourages implementations to decrypt these ciphertexts in a "streaming" fashion, i.e. they return plaintext before it's authenticated. Encouraging APIs that return unauthenticated plaintext is an ecosystem cost since such APIs are dangerous. One similarity is with the MAC-then-encrypt constructions used in TLS, which caused many problems by processing unauthenticated ciphertext. At a higher level, it's not hard to find people on the internet suggesting things like: gpg -d your_archive.tgz.gpg | tar xz because the gpg command also provides a "streaming" interface. (http://askubuntu.com/questions/95920/encrypt-tar-gz-file-on-create) With constructions like AES-GCM it's, of course, very easy to manipulate the plaintext at will if the application doesn't authenticate it before processing. Even if the application is careful not to "release" plaintext to the UI until the authenticity has been established, a streaming design exposes more program attack surface. By normalising large ciphertexts and thus streaming APIs, the next protocol that comes along is more likely to use them without realising the issues and thus the problem persists. Preferably, plaintext inputs would be chunked into reasonably large parts (say 16KiB) and encrypted separately. The chunks only need to be large enough that the overhead from the additional authenticators is negligible. With such a design, large messages can be incrementally processed without having to deal with unauthenticated plaintext, and AEAD APIs can be safer. (Not to mention that larger messages can be processed since AES-GCM, for one, has a ~64GiB limit for a single plaintext.) Some thought is needed to ensure that the chunks are in the correct order (i.e. by counting nonces), that the first chunk should be first (i.e. by starting the nonce at zero) and that the last chunk should be last (i.e. by appending an empty, terminator chunk with special additional data). But that's not hard. Even with such a design it's still the case that an attacker can cause the message to be detectably truncated. If you want to aim higher, an all-or-nothing transform can be used, although that requires two passes over the input and I understand if it's sufficiently problematic that you don't want to do that. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Fri Sep 2 09:56:24 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E6B12D0BB for ; Fri, 2 Sep 2016 09:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 9BY45OOsK5Cb for ; Fri, 2 Sep 2016 09:56:19 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 9911F12D0A0 for ; Fri, 2 Sep 2016 09:56:19 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id p186so134527957oia.2 for ; Fri, 02 Sep 2016 09:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p3zLOjFhzg5xA45PolmNn/jLy76ruBv5Si4A9m8XHbk=; b=BngKz8JkFAOzWuCulEk0N/LUIeJNlKnCdTPpOC+19Mp5iy++VRr59cvWz+pKjpUlwp wuJ429TfkhZ58EGOv60zlbm1Lr71Y1mt559C0rtzmoNc/wp2G3TQnUfMXLL6bRHznFIg aDFr/uMrDe4aX5KHqKFMl3tTkXk2/YvvCQrQE41Im/+6TDA2C5IyDEW7TBJqmcsv/MhI QshYkyFFyWbid+1oTgajqWTX0x107Fp24LQLBW2HAr0+LqKiw2BpyWN8dPfYqlCAB3Q5 PvU6jVUZexYKtmALpJaq2vK/vhIPR5sSqwlOcXDyh9DdaTziCA/+jfTAJAGCP+UST/w1 qW2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p3zLOjFhzg5xA45PolmNn/jLy76ruBv5Si4A9m8XHbk=; b=JWbyUySj8WDvl/K1Ctdgs3iQ8/WgIKknCM3CAbhDeZ7KmUpeMZgJTw6nOdxs0jvMcw 7cm1s7W39KHs51GibROio93vLbtOz1yX3npLSz++byxCwZiG8YmuOyCnth+oAqKkXsOQ tAGLk4rAv/CrxWGcLlwZVvMJVg7IxokgPM4jrHsjS+q9OZJUtldJay+CxTM7EmvD6AQG 6sEotQ8f03zbZbnUdwwg5rnFjEirRHldO+CZUxbZzrPpS+IBbXxzxHVx2+DuYx2z0669 VLn1fjz6Pl1IZWKBQns6hlgtutYOnaa5xQQWqM/p65FUsyH6BH1jEidFQGfeCLO8E5oh 74zA== X-Gm-Message-State: AE9vXwOjJ9JBnk/NkeHlNjrFWoQ0ZR61/P6q3kGwsBuFn5cP68YY9veYfJ70lR2pSJqLyr+JCwN8U4RXLc0hTB+8 X-Received: by 10.157.57.134 with SMTP id y6mr22350147otb.94.1472835378735; Fri, 02 Sep 2016 09:56:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.41.71 with HTTP; Fri, 2 Sep 2016 09:56:17 -0700 (PDT) In-Reply-To: References: From: Wei Chuang Date: Fri, 2 Sep 2016 09:56:17 -0700 Message-ID: To: Adam Langley Content-Type: multipart/alternative; boundary=001a1141a31890279e053b8935a3 Archived-At: Cc: SPASM , curdle@ietf.org Subject: Re: [Spasm] Chunking ciphertexts X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 16:56:22 -0000 --001a1141a31890279e053b8935a3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cross posting to Curdle as I think this is more of a general problem than just S/MIME. Support for chunking could be done at CMS, and would require updating RFC5652. I also wanted to point out that there was a similar discussion in the cfrg earlier on this topic though I don't know what the outcome was. -Wei On Thu, Sep 1, 2016 at 5:22 PM, Adam Langley wrote: > Since the WG is currently considering changes to S/MIME, I'd like to > mention the benefits of chunking ciphertexts. (Or, rather, the > problems with not chunking them.) > > As I understand it, S/MIME and associated standards typically encrypt > payloads as a single ciphertext (i.e. RFC 5084). Since the plaintexts > might be quite large, this encourages implementations to decrypt these > ciphertexts in a "streaming" fashion, i.e. they return plaintext > before it's authenticated. > > Encouraging APIs that return unauthenticated plaintext is an ecosystem > cost since such APIs are dangerous. One similarity is with the > MAC-then-encrypt constructions used in TLS, which caused many problems > by processing unauthenticated ciphertext. At a higher level, it's not > hard to find people on the internet suggesting things like: > > gpg -d your_archive.tgz.gpg | tar xz > > because the gpg command also provides a "streaming" interface. > (http://askubuntu.com/questions/95920/encrypt-tar-gz-file-on-create) > > With constructions like AES-GCM it's, of course, very easy to > manipulate the plaintext at will if the application doesn't > authenticate it before processing. Even if the application is careful > not to "release" plaintext to the UI until the authenticity has been > established, a streaming design exposes more program attack surface. > > By normalising large ciphertexts and thus streaming APIs, the next > protocol that comes along is more likely to use them without realising > the issues and thus the problem persists. > > > Preferably, plaintext inputs would be chunked into reasonably large > parts (say 16KiB) and encrypted separately. The chunks only need to be > large enough that the overhead from the additional authenticators is > negligible. With such a design, large messages can be incrementally > processed without having to deal with unauthenticated plaintext, and > AEAD APIs can be safer. (Not to mention that larger messages can be > processed since AES-GCM, for one, has a ~64GiB limit for a single > plaintext.) > > Some thought is needed to ensure that the chunks are in the correct > order (i.e. by counting nonces), that the first chunk should be first > (i.e. by starting the nonce at zero) and that the last chunk should be > last (i.e. by appending an empty, terminator chunk with special > additional data). But that's not hard. > > > Even with such a design it's still the case that an attacker can cause > the message to be detectably truncated. If you want to aim higher, an > all-or-nothing transform can be used, although that requires two > passes over the input and I understand if it's sufficiently > problematic that you don't want to do that. > > > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --001a1141a31890279e053b8935a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Cross posting to Curdle as I think this is more of a general problem than just S/MIME.  

Support for chunking could be done at CMS, and would require updating RFC5652.

I also wanted to point out that there was a similar discussion in the cfrg earlier on this topic though I don't know what the outcome was.

-Wei


On Thu, Sep 1, 2016 at 5:22 PM, Adam Langley <agl@imperialviolet.org> wrote:
Since the WG is currently considering changes to S/MIME, I'd like to
mention the benefits of chunking ciphertexts. (Or, rather, the
problems with not chunking them.)

As I understand it, S/MIME and associated standards typically encrypt
payloads as a single ciphertext (i.e. RFC 5084). Since the plaintexts
might be quite large, this encourages implementations to decrypt these
ciphertexts in a "streaming" fashion, i.e. they return plaintext
before it's authenticated.

Encouraging APIs that return unauthenticated plaintext is an ecosystem
cost since such APIs are dangerous. One similarity is with the
MAC-then-encrypt constructions used in TLS, which caused many problems
by processing unauthenticated ciphertext. At a higher level, it's not
hard to find people on the internet suggesting things like:

gpg -d your_archive.tgz.gpg | tar xz

because the gpg command also provides a "streaming" interface.
(http://askubuntu.com/questions/95920/encrypt-tar-gz-file-on-create)

With constructions like AES-GCM it's, of course, very easy to
manipulate the plaintext at will if the application doesn't
authenticate it before processing. Even if the application is careful
not to "release" plaintext to the UI until the authenticity has been
established, a streaming design exposes more program attack surface.

By normalising large ciphertexts and thus streaming APIs, the next
protocol that comes along is more likely to use them without realising
the issues and thus the problem persists.


Preferably, plaintext inputs would be chunked into reasonably large
parts (say 16KiB) and encrypted separately. The chunks only need to be
large enough that the overhead from the additional authenticators is
negligible. With such a design, large messages can be incrementally
processed without having to deal with unauthenticated plaintext, and
AEAD APIs can be safer. (Not to mention that larger messages can be
processed since AES-GCM, for one, has a ~64GiB limit for a single
plaintext.)

Some thought is needed to ensure that the chunks are in the correct
order (i.e. by counting nonces), that the first chunk should be first
(i.e. by starting the nonce at zero) and that the last chunk should be
last (i.e. by appending an empty, terminator chunk with special
additional data). But that's not hard.


Even with such a design it's still the case that an attacker can cause
the message to be detectably truncated. If you want to aim higher, an
all-or-nothing transform can be used, although that requires two
passes over the input and I understand if it's sufficiently
problematic that you don't want to do that.


Cheers

AGL

--
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--001a1141a31890279e053b8935a3-- From nobody Fri Sep 2 10:15:11 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B546512D6A1 for ; Fri, 2 Sep 2016 10:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 VRbY9LgjusXl for ; Fri, 2 Sep 2016 10:15:07 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 AE6F212D1A3 for ; Fri, 2 Sep 2016 10:15:07 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id c15so170747140oig.0 for ; Fri, 02 Sep 2016 10:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M+SgS+BiZJQ/3HNESkchUZHTQlbC1HdIQvIvbpn6EuE=; b=QYR9Duai2Vqj57/sqe/g3FJLQYpx6KuyM0WnROGzATK3u0iiPoiVzwKLWgqfHZQLOu xwLH5Xvvmu/dLTSygR5yA/GgY8M/360b3pVJ2FR3anGuVjzA9l2xV+rCTGHw4M7sj4pg OETowX/lfRfhLE9MPiuOizlJvWqo8BK6EGn1/z2SWFxrYQL6GV155rKeNTvEVBowS5eD gDFEaowxZMfRQf2g2qeRaChuLzuBDbS5uYvPywTX4k2VN1xWYHxpOO318YYR1EV6Df1Q SCu5MhhwhHctEYxVBONdqNgZ9sEsFN20NrX6XeVJT3se3WHi6BKjBQx6OEs2ZaWm9rJH 7bnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M+SgS+BiZJQ/3HNESkchUZHTQlbC1HdIQvIvbpn6EuE=; b=iQi82Zv/wx7ieU+WYQzc7vFh2XBt2qM03DfEGRTt7nqcBdTmd5uZXVQDO6/lujq7kF tDrtZOGWypj7mwPuMcoUHJ438oaHbSnGe0k2irSCUMnE9aH38Ehoyexd53V8c/kUg34W m/v+JAvHKizmwiFcppr+EX5zpL7QClL6It/HS4j6tKJRAIZA7VR+44jLogFCB3sFtXXh Uy0m1qY0ynUoFQSuN9o0V5ps9wYmzQH7VNMh0brL4HH7wCq9fwE999xvDygd81QUeCPG D/BqlFLF4JnRrXVy94gFSSCC9zZV8B53tMjRBgNMee98ehwpkM+5eRpRb/YF0QFq/moB HuZg== X-Gm-Message-State: AE9vXwO/+UOWSru3Rcyns6yqKgrZOUFgJaiAA38b99OkQYQ7HiEuqx+7+EbFkDmJp1LsN5H+B8+EpZai+47hd1Lz X-Received: by 10.202.62.195 with SMTP id l186mr20018757oia.129.1472836506973; Fri, 02 Sep 2016 10:15:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.41.71 with HTTP; Fri, 2 Sep 2016 10:15:05 -0700 (PDT) In-Reply-To: References: <147252989540.19045.14451060202052338375.idtracker@ietfa.amsl.com> From: Wei Chuang Date: Fri, 2 Sep 2016 10:15:05 -0700 Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=001a113ccf1ecfc66f053b89789a Archived-At: Cc: SPASM Subject: Re: [Spasm] I-D Action: draft-ietf-lamps-rfc5751-bis-01.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 17:15:10 -0000 --001a113ccf1ecfc66f053b89789a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Also many thanks for the update. I asked for feedback internally. Two things from that: 1. The AES-GCM IV length should not use the default RFC5084 12 byte length, and instead should use 16 bytes. This is from Quan Nguyen who recently posted an errata that has more background (S/MIME list). Perhaps this could be added to the security section in the draft? 2. Consideration for chunking of the ciphertext. There's a related post on the Spasm list by Adam Langley. Otherwise it sounds positive. -Wei On Mon, Aug 29, 2016 at 9:29 PM, Russ Housley wrote: > I did a very quick skim of the -01 version. Thanks. > > I expected Section 2.3 to include ECDH and X25519. If they are added, > some related guidance will be needed in Sections 4.4 and 4.5. > > Section 4 offers guidance about RSA, RSASSA-PSS, RSAES-OAEP, and DH > algorithms. It used to contain some guidance about DSA. Is there any > reason to remove DSA guidance from 4.2 and 4.3? I think we need to add > guidance in Sections 4.2 and 4.3 for ECDSA and EdDSA. > > Russ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --001a113ccf1ecfc66f053b89789a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Also many thanks for the update.

I asked for feedback internally.  Two things from that:
1. The AES-GCM IV length should not use the default RFC5084 12 byte length, and instead should use 16 bytes.  This is from Quan Nguyen who recently posted an errata that has more background (S/MIME list). Perhaps this could be added to the security section in the draft?  
2. Consideration for chunking of the ciphertext.  There's a related post on the Spasm list by Adam Langley.
Otherwise it sounds positive.

-Wei



On Mon, Aug 29, 2016 at 9:29 PM, Russ Housley <housley@vigilsec.com> wrote:
I did a very quick skim of the -01 version.  Thanks.

I expected Section 2.3 to include ECDH and X25519.  If they are added, some related guidance will be needed in Sections 4.4 and 4.5.

Section 4 offers guidance about RSA, RSASSA-PSS, RSAES-OAEP, and DH algorithms.  It used to contain some guidance about DSA.  Is there any reason to remove DSA guidance from 4.2 and 4.3?  I think we need to add guidance in Sections 4.2 and 4.3 for ECDSA and EdDSA.

Russ

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--001a113ccf1ecfc66f053b89789a-- From nobody Fri Sep 2 11:37:59 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B7C12B04A for ; Fri, 2 Sep 2016 11:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 nVbXNe9LSZPX for ; Fri, 2 Sep 2016 11:37:55 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FCBF126B6D for ; Fri, 2 Sep 2016 11:37:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CF56B3005D0 for ; Fri, 2 Sep 2016 14:37:52 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8v8xplpC-EP2 for ; Fri, 2 Sep 2016 14:37:51 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 2A3CF3004B7; Fri, 2 Sep 2016 14:37:51 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Fri, 2 Sep 2016 14:37:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5819BEE2-C679-4A39-8736-5D10850D78A3@vigilsec.com> References: To: Adam Langley X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: spasm@ietf.org Subject: Re: [Spasm] Chunking ciphertexts X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 18:37:57 -0000 Adam: I agree that returning yet-to-be-authenticated plaintext is very = harmful. All of the AEAD ciphers that I know explicitly say not to do = so. In thinking about the problem that you raise, I think that a chafe would = be needed at the CMS layer, which could then be used at the S/MIME = layer. RFC 5083 defines AuthEnvelopedData: AuthEnvelopedData ::=3D SEQUENCE { version CMSVersion, originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, recipientInfos RecipientInfos, authEncryptedContentInfo EncryptedContentInfo, authAttrs [1] IMPLICIT AuthAttributes OPTIONAL, mac MessageAuthenticationCode, unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL } The authEncryptedContentInfo would need to be replaced with a SEQUENCE = of encrypted chunks, where each chunk would need an integrity-protected = sequence number and ciphertext. I think this is beyond the scope of the current LAMPS WG charter, but if = people would really implement it, I am willing to do the CMS layer work. Russ On Sep 1, 2016, at 8:22 PM, Adam Langley wrote: > Since the WG is currently considering changes to S/MIME, I'd like to > mention the benefits of chunking ciphertexts. (Or, rather, the > problems with not chunking them.) >=20 > As I understand it, S/MIME and associated standards typically encrypt > payloads as a single ciphertext (i.e. RFC 5084). Since the plaintexts > might be quite large, this encourages implementations to decrypt these > ciphertexts in a "streaming" fashion, i.e. they return plaintext > before it's authenticated. >=20 > Encouraging APIs that return unauthenticated plaintext is an ecosystem > cost since such APIs are dangerous. One similarity is with the > MAC-then-encrypt constructions used in TLS, which caused many problems > by processing unauthenticated ciphertext. At a higher level, it's not > hard to find people on the internet suggesting things like: >=20 > gpg -d your_archive.tgz.gpg | tar xz >=20 > because the gpg command also provides a "streaming" interface. > (http://askubuntu.com/questions/95920/encrypt-tar-gz-file-on-create) >=20 > With constructions like AES-GCM it's, of course, very easy to > manipulate the plaintext at will if the application doesn't > authenticate it before processing. Even if the application is careful > not to "release" plaintext to the UI until the authenticity has been > established, a streaming design exposes more program attack surface. >=20 > By normalising large ciphertexts and thus streaming APIs, the next > protocol that comes along is more likely to use them without realising > the issues and thus the problem persists. >=20 >=20 > Preferably, plaintext inputs would be chunked into reasonably large > parts (say 16KiB) and encrypted separately. The chunks only need to be > large enough that the overhead from the additional authenticators is > negligible. With such a design, large messages can be incrementally > processed without having to deal with unauthenticated plaintext, and > AEAD APIs can be safer. (Not to mention that larger messages can be > processed since AES-GCM, for one, has a ~64GiB limit for a single > plaintext.) >=20 > Some thought is needed to ensure that the chunks are in the correct > order (i.e. by counting nonces), that the first chunk should be first > (i.e. by starting the nonce at zero) and that the last chunk should be > last (i.e. by appending an empty, terminator chunk with special > additional data). But that's not hard. >=20 >=20 > Even with such a design it's still the case that an attacker can cause > the message to be detectably truncated. If you want to aim higher, an > all-or-nothing transform can be used, although that requires two > passes over the input and I understand if it's sufficiently > problematic that you don't want to do that. >=20 >=20 > Cheers >=20 > AGL >=20 > --=20 > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Fri Sep 2 11:41:04 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E46126B6D for ; Fri, 2 Sep 2016 11:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 JBF-Vdz1JNi9 for ; Fri, 2 Sep 2016 11:41:00 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25BBF1288B8 for ; Fri, 2 Sep 2016 11:41:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 350A8300639 for ; Fri, 2 Sep 2016 14:40:58 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7aoZ6M5hs5zS for ; Fri, 2 Sep 2016 14:40:55 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 633CC30041E; Fri, 2 Sep 2016 14:40:55 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_DD30583F-D93C-4C6B-A1C1-6D6786D1238A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Fri, 2 Sep 2016 14:40:56 -0400 Message-Id: <29CA40B0-90E2-4755-9DED-C20C42B3CDB7@vigilsec.com> References: To: Wei Chuang X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Adam Langley , SPASM , curdle@ietf.org Subject: Re: [Spasm] [Curdle] Chunking ciphertexts X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 18:41:02 -0000 --Apple-Mail=_DD30583F-D93C-4C6B-A1C1-6D6786D1238A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As I just said on the SPASM mail list: In thinking about the problem = that you raise, I think that a chunking would be needed at the CMS = layer, which could then be used at the S/MIME layer. This problem is not one that belongs in the CURDLE WG because it = involves much more than new algorithms. Russ On Sep 2, 2016, at 12:56 PM, Wei Chuang wrote: > Cross posting to Curdle as I think this is more of a general problem = than just S/MIME. =20 >=20 > Support for chunking could be done at CMS, and would require updating = RFC5652. >=20 > I also wanted to point out that there was a similar discussion in the = cfrg earlier on this topic though I don't know what the outcome was. >=20 > -Wei >=20 >=20 > On Thu, Sep 1, 2016 at 5:22 PM, Adam Langley = wrote: > Since the WG is currently considering changes to S/MIME, I'd like to > mention the benefits of chunking ciphertexts. (Or, rather, the > problems with not chunking them.) >=20 > As I understand it, S/MIME and associated standards typically encrypt > payloads as a single ciphertext (i.e. RFC 5084). Since the plaintexts > might be quite large, this encourages implementations to decrypt these > ciphertexts in a "streaming" fashion, i.e. they return plaintext > before it's authenticated. >=20 > Encouraging APIs that return unauthenticated plaintext is an ecosystem > cost since such APIs are dangerous. One similarity is with the > MAC-then-encrypt constructions used in TLS, which caused many problems > by processing unauthenticated ciphertext. At a higher level, it's not > hard to find people on the internet suggesting things like: >=20 > gpg -d your_archive.tgz.gpg | tar xz >=20 > because the gpg command also provides a "streaming" interface. > (http://askubuntu.com/questions/95920/encrypt-tar-gz-file-on-create) >=20 > With constructions like AES-GCM it's, of course, very easy to > manipulate the plaintext at will if the application doesn't > authenticate it before processing. Even if the application is careful > not to "release" plaintext to the UI until the authenticity has been > established, a streaming design exposes more program attack surface. >=20 > By normalising large ciphertexts and thus streaming APIs, the next > protocol that comes along is more likely to use them without realising > the issues and thus the problem persists. >=20 >=20 > Preferably, plaintext inputs would be chunked into reasonably large > parts (say 16KiB) and encrypted separately. The chunks only need to be > large enough that the overhead from the additional authenticators is > negligible. With such a design, large messages can be incrementally > processed without having to deal with unauthenticated plaintext, and > AEAD APIs can be safer. (Not to mention that larger messages can be > processed since AES-GCM, for one, has a ~64GiB limit for a single > plaintext.) >=20 > Some thought is needed to ensure that the chunks are in the correct > order (i.e. by counting nonces), that the first chunk should be first > (i.e. by starting the nonce at zero) and that the last chunk should be > last (i.e. by appending an empty, terminator chunk with special > additional data). But that's not hard. >=20 >=20 > Even with such a design it's still the case that an attacker can cause > the message to be detectably truncated. If you want to aim higher, an > all-or-nothing transform can be used, although that requires two > passes over the input and I understand if it's sufficiently > problematic that you don't want to do that. >=20 >=20 > Cheers >=20 > AGL >=20 > -- > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --Apple-Mail=_DD30583F-D93C-4C6B-A1C1-6D6786D1238A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii As I = just said on the SPASM mail list: In thinking about the problem = that you raise, I think that a chunking would be needed at the CMS = layer, which could then be used at the S/MIME = layer.

This problem is not one that belongs in the = CURDLE WG because it involves much more than new = algorithms.

Russ


On Sep 2, 2016, at 12:56 PM, Wei Chuang <weihaw@google.com> = wrote:

Cross posting to Curdle as I think this = is more of a general problem than just S/MIME. =  

Support for chunking could be done at CMS, and = would require updating RFC5652.

I also wanted = to point out that there was a similar discussion in the = cfrg earlier on this topic though I don't know what the outcome = was.

-Wei


On Thu, Sep 1, 2016 = at 5:22 PM, Adam Langley <agl@imperialviolet.org> = wrote:
Since the WG is = currently considering changes to S/MIME, I'd like to
mention the benefits of chunking ciphertexts. (Or, rather, the
problems with not chunking them.)

As I understand it, S/MIME and associated standards typically = encrypt
payloads as a single ciphertext (i.e. RFC 5084). Since the = plaintexts
might be quite large, this encourages implementations to decrypt = these
ciphertexts in a "streaming" fashion, i.e. they return plaintext
before it's authenticated.

Encouraging APIs that return unauthenticated plaintext is an = ecosystem
cost since such APIs are dangerous. One similarity is with the
MAC-then-encrypt constructions used in TLS, which caused many = problems
by processing unauthenticated ciphertext. At a higher level, it's = not
hard to find people on the internet suggesting things like:

gpg -d your_archive.tgz.gpg | tar xz

because the gpg command also provides a "streaming" interface.
(http://askubuntu.com/questions/95920/encrypt-tar-gz-file-on-create)

With constructions like AES-GCM it's, of course, very easy to
manipulate the plaintext at will if the application doesn't
authenticate it before processing. Even if the application is = careful
not to "release" plaintext to the UI until the authenticity has been
established, a streaming design exposes more program attack surface.

By normalising large ciphertexts and thus streaming APIs, the next
protocol that comes along is more likely to use them without = realising
the issues and thus the problem persists.


Preferably, plaintext inputs would be chunked into reasonably large
parts (say 16KiB) and encrypted separately. The chunks only need to = be
large enough that the overhead from the additional authenticators is
negligible. With such a design, large messages can be incrementally
processed without having to deal with unauthenticated plaintext, and
AEAD APIs can be safer. (Not to mention that larger messages can be
processed since AES-GCM, for one, has a ~64GiB limit for a single
plaintext.)

Some thought is needed to ensure that the chunks are in the correct
order (i.e. by counting nonces), that the first chunk should be = first
(i.e. by starting the nonce at zero) and that the last chunk should = be
last (i.e. by appending an empty, terminator chunk with special
additional data). But that's not hard.


Even with such a design it's still the case that an attacker can = cause
the message to be detectably truncated. If you want to aim higher, = an
all-or-nothing transform can be used, although that requires two
passes over the input and I understand if it's sufficiently
problematic that you don't want to do that.


Cheers

AGL

--
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
=

_______________________________________________
Curdle mailing = list
Curdle@ietf.org
https://www.ietf.or= g/mailman/listinfo/curdle

= --Apple-Mail=_DD30583F-D93C-4C6B-A1C1-6D6786D1238A-- From nobody Fri Sep 2 11:45:31 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7F812B071 for ; Fri, 2 Sep 2016 11:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 1mj-47KOWFfc for ; Fri, 2 Sep 2016 11:45:28 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2641E126B6D for ; Fri, 2 Sep 2016 11:45:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3448C300572 for ; Fri, 2 Sep 2016 14:45:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LpQxJ6AV85vc for ; Fri, 2 Sep 2016 14:45:25 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 1596630041E; Fri, 2 Sep 2016 14:45:25 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3BC1BBF1-CDA0-4218-884D-4F0739019164" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Fri, 2 Sep 2016 14:45:25 -0400 Message-Id: References: <147252989540.19045.14451060202052338375.idtracker@ietfa.amsl.com> To: Wei Chuang X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: SPASM Subject: Re: [Spasm] I-D Action: draft-ietf-lamps-rfc5751-bis-01.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 18:45:30 -0000 --Apple-Mail=_3BC1BBF1-CDA0-4218-884D-4F0739019164 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > I asked for feedback internally. Two things from that: > 1. The AES-GCM IV length should not use the default RFC5084 12 byte = length, and instead should use 16 bytes. This is from Quan Nguyen who = recently posted an errata that has more background (S/MIME list). = Perhaps this could be added to the security section in the draft? =20 I have no objection to the 16 octets, but the attack raised has no = relevance to CMS AuthEnvelopedData where a fresh key is used for every = encryption. > 2. Consideration for chunking of the ciphertext. There's a related = post on the Spasm list by Adam Langley. > Otherwise it sounds positive. As I said in response to Adam=92s message, I am in favor of preventing = yet-to-be-authenticated plaintext from being returned, but this is not = just a matter of making a small change to this document. Russ --Apple-Mail=_3BC1BBF1-CDA0-4218-884D-4F0739019164 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I= asked for feedback internally.  Two things from that:
1. = The AES-GCM IV length should not use the default RFC5084 12 byte length, = and instead should use 16 bytes.  This is from Quan Nguyen who = recently posted an errata that has more background (S/MIME list). Perhaps = this could be added to the security section in the draft? =  

I have no objection to the = 16 octets, but the attack raised has no relevance to CMS = AuthEnvelopedData where a fresh key is used for every = encryption.

2. Consideration for chunking of the ciphertext.  = There's a related post on the Spasm list by Adam Langley.
Otherwise it = sounds positive.

As I said in = response to Adam=92s message, I am in favor of preventing = yet-to-be-authenticated plaintext from being returned, but this is not = just a matter of making a small change to this = document.

Russ

= --Apple-Mail=_3BC1BBF1-CDA0-4218-884D-4F0739019164-- From nobody Fri Sep 2 12:46:42 2016 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B525C12D169 for ; Fri, 2 Sep 2016 12:46:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147284560173.24825.7686449303209130110.idtracker@ietfa.amsl.com> Date: Fri, 02 Sep 2016 12:46:41 -0700 From: IETF Secretariat Archived-At: Subject: [Spasm] Milestones changed for lamps WG X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 19:46:42 -0000 Changed milestone "WG adoption of a draft to specify the way to use authenticated encryption in S/MIME", resolved as "Done", added draft-ietf-lamps-rfc5750-bis, draft-ietf-lamps-rfc5751-bis to milestone. URL: https://datatracker.ietf.org/wg/lamps/charter/ From nobody Fri Sep 2 12:47:18 2016 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 882CD12D169 for ; Fri, 2 Sep 2016 12:47:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147284563655.24837.2659043206329565234.idtracker@ietfa.amsl.com> Date: Fri, 02 Sep 2016 12:47:16 -0700 From: IETF Secretariat Archived-At: Subject: [Spasm] Milestones changed for lamps WG X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 19:47:16 -0000 Changed milestone "WG adoption of a draft to specify the way to include an i18n email address as a subject alternative name and an issuer alternative name", resolved as "Done", added draft-ietf-lamps-eai-addresses to milestone. URL: https://datatracker.ietf.org/wg/lamps/charter/ From nobody Fri Sep 2 14:31:54 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D216712D0BD for ; Fri, 2 Sep 2016 14:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 xT0jYXqOtzN6 for ; Fri, 2 Sep 2016 14:31:50 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62FDF12B03D for ; Fri, 2 Sep 2016 14:31:50 -0700 (PDT) Received: from hebrews (50.193.221.102) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 2 Sep 2016 14:44:12 -0700 From: Jim Schaad To: 'Adam Langley' , References: In-Reply-To: Date: Fri, 2 Sep 2016 14:31:08 -0700 Message-ID: <099d01d20561$53a67470$faf35d50$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLsHj5jydAzwEphcKAPGiflM6aGzJ4yg0qw Content-Language: en-us X-Originating-IP: [50.193.221.102] Archived-At: Subject: Re: [Spasm] Chunking ciphertexts X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 21:31:53 -0000 Adam, I have some problems with doing chunked encryption algorithms because I am never sure what is being attempted with them. The version that is being proposed for HTTP (http://httpwg.org/http-extensions/draft-ietf-httpbis-encryption-encoding.ht ml) is being done because it allows for random access decryption so that it can be done by multiple streams. You are suggesting that another reason is so that one can have even larger encrypted objects than is currently permitted by some algorithms. The block size suggested below is much larger than that suggested for HTTP. I know that I have had discussions with people at various points about not supplying a streaming interface to crypto APIs as being an issue that "should be fixed" because it is what they are used to having. This was raised several times when doing the W3C WebCrypto interfaces. One of the problems that I have is that you need to do a couple of different things that I am never sure are properly covered: 1. You need to make sure that blocks cannot be moved. 2. You need to make sure that a block cannot be substituted for. 3. You need to make sure that each block is integrity checked before release. 4. If you allow for random access, should all prior blocks be somehow integrity checked first? If you are using stream APIs, what do you do if the first ten blocks are fine, but then the eleventh block is messed up? This fact then needs to be propagated down the stream in some fashion so that correct responses can be executed. The last think you want is to execute gpg -d your_archive.tgz.gpg > archive.tar and have the file left on the disk even though it is not complete. jim > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Adam Langley > Sent: Thursday, September 01, 2016 5:22 PM > To: spasm@ietf.org > Subject: [Spasm] Chunking ciphertexts > > Since the WG is currently considering changes to S/MIME, I'd like to mention the > benefits of chunking ciphertexts. (Or, rather, the problems with not chunking > them.) > > As I understand it, S/MIME and associated standards typically encrypt payloads > as a single ciphertext (i.e. RFC 5084). Since the plaintexts might be quite large, > this encourages implementations to decrypt these ciphertexts in a "streaming" > fashion, i.e. they return plaintext before it's authenticated. > > Encouraging APIs that return unauthenticated plaintext is an ecosystem cost > since such APIs are dangerous. One similarity is with the MAC-then-encrypt > constructions used in TLS, which caused many problems by processing > unauthenticated ciphertext. At a higher level, it's not hard to find people on the > internet suggesting things like: > > gpg -d your_archive.tgz.gpg | tar xz > > because the gpg command also provides a "streaming" interface. > (http://askubuntu.com/questions/95920/encrypt-tar-gz-file-on-create) > > With constructions like AES-GCM it's, of course, very easy to manipulate the > plaintext at will if the application doesn't authenticate it before processing. Even > if the application is careful not to "release" plaintext to the UI until the > authenticity has been established, a streaming design exposes more program > attack surface. > > By normalising large ciphertexts and thus streaming APIs, the next protocol that > comes along is more likely to use them without realising the issues and thus the > problem persists. > > > Preferably, plaintext inputs would be chunked into reasonably large parts (say > 16KiB) and encrypted separately. The chunks only need to be large enough that > the overhead from the additional authenticators is negligible. With such a > design, large messages can be incrementally processed without having to deal > with unauthenticated plaintext, and AEAD APIs can be safer. (Not to mention > that larger messages can be processed since AES-GCM, for one, has a ~64GiB > limit for a single > plaintext.) > > Some thought is needed to ensure that the chunks are in the correct order (i.e. > by counting nonces), that the first chunk should be first (i.e. by starting the > nonce at zero) and that the last chunk should be last (i.e. by appending an > empty, terminator chunk with special additional data). But that's not hard. > > > Even with such a design it's still the case that an attacker can cause the message > to be detectably truncated. If you want to aim higher, an all-or-nothing > transform can be used, although that requires two passes over the input and I > understand if it's sufficiently problematic that you don't want to do that. > > > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Fri Sep 2 14:55:04 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B829112D589 for ; Fri, 2 Sep 2016 14:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RIl7N03t-_Rx for ; Fri, 2 Sep 2016 14:55:00 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 70410127735 for ; Fri, 2 Sep 2016 14:55:00 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id v123so134220999qkh.2 for ; Fri, 02 Sep 2016 14:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0Kw1lj3D1RT7YBgq+ukn8GZFs5WD/jwkkfGFteHLK/0=; b=UMUUlrNCBrYGgstR3mWfjcH+OS1gnTb2ArWKKlR/W2Z+nBlY5hvI8Oi1oa129psfD5 NtXq9yrP0/mchDlLHgHwOexI3FgHpPD0eAYhodsuJ8FRwjksxspylM+dr48d4O6tmkG4 ZIC6bOR5/Ak3rGHeISWq9mMYgwRL8mNXCncn2veHNfnlrFBeMeMP1BxqwwshL2aVVhUI Qaz5G/PfBvp8qdGxazrwGECbqL1zLqo53YEGjBaIEJRSH1LIDbJA6efjZUmDIUzMp/gR 6LmOb8+ew4zr8MdTiCPS71So2cte75owpGXMkPZEu8LrrvLUL6naJd+tjs8BYwVpDVVc 3pug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0Kw1lj3D1RT7YBgq+ukn8GZFs5WD/jwkkfGFteHLK/0=; b=P7qw17mGmN2RolT3dKBlyK3lv+52iQhBUe0d9r/VT/moiYkie8+zRHj3ZsofvZsdvB NsdB/1gDLZprPcNyuG/8ZqV2sUw5ycBKe5DjsDPwQKxTdfsrHdBVIBWkqUiIM/S9b/q8 74ZJgQUrG+A4WoPDd/LsQcCmvre6LjUygKZ+Izv7FwbWYIXuQsuHALCDQj7AAdluG7gf qJ2EB5O8KL1DZoHPcx18ji/gXU73DJlmRyk+GPIDTmckCMrYWx+aE6Z9BBIQaCF6xYwM TQlbR3Wt5KQ1tNlwas5Wg84RGF5XrV0ciTxn4LJ/YAND9Iq3nD+FfdUM3sgMcrx6VraL PFpA== X-Gm-Message-State: AE9vXwP5jgObmEl/tbtk6nMsslJznrRmsaPVkiIkSS3s1+As5eYur7NyAWGlLU4LGHNGCVSG8QMSBm72UZb7kg== X-Received: by 10.55.101.10 with SMTP id z10mr26207971qkb.186.1472853299609; Fri, 02 Sep 2016 14:54:59 -0700 (PDT) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.200.50.142 with HTTP; Fri, 2 Sep 2016 14:54:59 -0700 (PDT) In-Reply-To: <099d01d20561$53a67470$faf35d50$@augustcellars.com> References: <099d01d20561$53a67470$faf35d50$@augustcellars.com> From: Adam Langley Date: Fri, 2 Sep 2016 14:54:59 -0700 X-Google-Sender-Auth: h2R4JONviecnTE5-ehT9wsELf7g Message-ID: To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: spasm@ietf.org Subject: Re: [Spasm] Chunking ciphertexts X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 21:55:03 -0000 On Fri, Sep 2, 2016 at 2:31 PM, Jim Schaad wrote: > I have some problems with doing chunked encryption algorithms because I am > never sure what is being attempted with them. > > The version that is being proposed for HTTP > (http://httpwg.org/http-extensions/draft-ietf-httpbis-encryption-encoding.ht > ml) is being done because it allows for random access decryption so that it > can be done by multiple streams. You are suggesting that another reason is > so that one can have even larger encrypted objects than is currently > permitted by some algorithms. The block size suggested below is much larger > than that suggested for HTTP. Allowing very large messages is one, minor advantage. A much bigger one is that large ciphertexts present a dilemma: either an implementation can buffer the whole ciphertext/plaintext in memory and process it all at once, or else it can decrypt it in a "streaming" fashion. The former is unappetising because messages may be larger than available memory. The latter is dangerous because it encourages the implementation of APIs that return unauthenticated plaintext and generally makes things more fragile. Chunking ciphertexts solves both of these issues. > One of the problems that I have is that you need to do a couple of different > things that I am never sure are properly covered: > > 1. You need to make sure that blocks cannot be moved. > 2. You need to make sure that a block cannot be substituted for. > 3. You need to make sure that each block is integrity checked before > release. > 4. If you allow for random access, should all prior blocks be somehow > integrity checked first? That's all correct and I mentioned a solution that used nonces from zero upwards and the AD to distinguish an EOF chunk. That's not the only design but, if you have random, per-message keys then it's probably the most basic. > If you are using stream APIs, what do you do if the first ten blocks are > fine, but then the eleventh block is messed up? This fact then needs to be > propagated down the stream in some fashion so that correct responses can be > executed. The last think you want is to execute > > gpg -d your_archive.tgz.gpg > archive.tar > > and have the file left on the disk even though it is not complete. That's the truncation issue that I mentioned at the end of my message. The /last/ thing I want is for archive.tar to contain attacker-controlled data, which a "streaming" interface allows. Truncation is less bad than that. Truncation can only be solved with two passes over the input I believe (although I'd be happy to be proven wrong). If that's viable (and perhaps, in CMS, it is?) then please let me know and I'm sure I can get back to you with a solid proposal. But I find that needing two passes often puts people off. Thus I was only aiming to hit what I see as the most pressing issue at this point: unauthenticated plaintext. Cheers AGL From nobody Fri Sep 2 16:35:17 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0910812D552 for ; Fri, 2 Sep 2016 16:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 VJQ3WiIZOTe3 for ; Fri, 2 Sep 2016 16:35:14 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D7ED12D58A for ; Fri, 2 Sep 2016 16:35:13 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 2 Sep 2016 16:47:45 -0700 From: Jim Schaad To: 'Adam Langley' References: <099d01d20561$53a67470$faf35d50$@augustcellars.com> In-Reply-To: Date: Fri, 2 Sep 2016 16:34:41 -0700 Message-ID: <09ae01d20572$95f2be90$c1d83bb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLsHj5jydAzwEphcKAPGiflM6aGzAJd9ApDAUqQn4WeFWPrsA== Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Cc: spasm@ietf.org Subject: Re: [Spasm] Chunking ciphertexts X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 23:35:16 -0000 > -----Original Message----- > From: alangley@gmail.com [mailto:alangley@gmail.com] On Behalf Of Adam > Langley > Sent: Friday, September 02, 2016 2:55 PM > To: Jim Schaad > Cc: spasm@ietf.org > Subject: Re: [Spasm] Chunking ciphertexts >=20 > On Fri, Sep 2, 2016 at 2:31 PM, Jim Schaad = wrote: > > I have some problems with doing chunked encryption algorithms = because > > I am never sure what is being attempted with them. > > > > The version that is being proposed for HTTP > > = (http://httpwg.org/http-extensions/draft-ietf-httpbis-encryption-encod > > ing.ht > > ml) is being done because it allows for random access decryption so > > that it can be done by multiple streams. You are suggesting that > > another reason is so that one can have even larger encrypted objects > > than is currently permitted by some algorithms. The block size > > suggested below is much larger than that suggested for HTTP. >=20 > Allowing very large messages is one, minor advantage. A much bigger = one is that > large ciphertexts present a dilemma: either an implementation can = buffer the > whole ciphertext/plaintext in memory and process it all at once, or = else it can > decrypt it in a "streaming" > fashion. >=20 > The former is unappetising because messages may be larger than = available > memory. >=20 > The latter is dangerous because it encourages the implementation of = APIs that > return unauthenticated plaintext and generally makes things more = fragile. >=20 > Chunking ciphertexts solves both of these issues. >=20 > > One of the problems that I have is that you need to do a couple of > > different things that I am never sure are properly covered: > > > > 1. You need to make sure that blocks cannot be moved. > > 2. You need to make sure that a block cannot be substituted for. > > 3. You need to make sure that each block is integrity checked = before > > release. > > 4. If you allow for random access, should all prior blocks be = somehow > > integrity checked first? >=20 > That's all correct and I mentioned a solution that used nonces from = zero > upwards and the AD to distinguish an EOF chunk. That's not the only = design but, > if you have random, per-message keys then it's probably the most = basic. >=20 > > If you are using stream APIs, what do you do if the first ten blocks > > are fine, but then the eleventh block is messed up? This fact then > > needs to be propagated down the stream in some fashion so that = correct > > responses can be executed. The last think you want is to execute > > > > gpg -d your_archive.tgz.gpg > archive.tar > > > > and have the file left on the disk even though it is not complete. >=20 > That's the truncation issue that I mentioned at the end of my message. >=20 > The /last/ thing I want is for archive.tar to contain = attacker-controlled data, > which a "streaming" interface allows. > Truncation is less bad than that. >=20 > Truncation can only be solved with two passes over the input I believe = (although > I'd be happy to be proven wrong). If that's viable (and perhaps, in = CMS, it is?) > then please let me know and I'm sure I can get back to you with a = solid proposal. If you do two passes then you have killed the benefit that you listed, = that you do not have the keep the entire message in memory. Once you = have the entire message in memory you can always do a decrypt in place = so you at least do not to have two copies of it. But doing two passes = means that the entire message needs to be there at some point. This is also going to be the same problem that non-CMS implementations = are going to have with doing EdDSA in pure mode. CMS already does a = hash and sign so that problem does not exist. Jim >=20 > But I find that needing two passes often puts people off. Thus I was = only aiming > to hit what I see as the most pressing issue at this > point: unauthenticated plaintext. >=20 >=20 > Cheers >=20 > AGL From nobody Fri Sep 2 16:41:54 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC1B12D552 for ; Fri, 2 Sep 2016 16:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 nA-h3WK8ka6N for ; Fri, 2 Sep 2016 16:41:51 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 CCC8E12B034 for ; Fri, 2 Sep 2016 16:41:50 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id 11so55260463qtc.0 for ; Fri, 02 Sep 2016 16:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=J8qdcTl61TW7BIeNZEShOWz2D36F14wcUft3z/92Zhc=; b=Tsax2W2viEwTSx28vLoS1ZCYEDGRKp+1wEczqZLUEF9MUBvgXLdb2R9nLUsIQ2xAYW zMaTt5newz5c1xBpeQ/phV7f1k1WLFfid3fftDOZJYQCTOgLrEKVRg+WA8VrRS/IjW4W e39ObSnWN9kwWvzACNZTrxg2E+TiRA9FdLZAzOUTWk9G5oUdfgo+Mq4eNJM501YFhOIr FrYhvStlelry9STI/ohmS/o+/V+7p7wnyBNrt5of4aSSI89Q+XfU+XXkZI1rkbT8WiAg gunJIttN/UanYnCdHn2+YkPvWM0pV6o3rugg3wTnZmzqOO666MDxc/ycTDpZBExDvH9O GMyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=J8qdcTl61TW7BIeNZEShOWz2D36F14wcUft3z/92Zhc=; b=Gd2OBeDSTAVEq/CxCbsOmZLD5jBUsFj3fjVUI8n0ENLBhISj0AwDBzCWqa1/lfd5Ha XBcjLYKVncJOlPHDEbDpdzKndnp+CO4T2hdT9M4MD4755kX3jIjziUTjhL4JTzBmRXU+ L8L9SWGjm2Dw58Hn13NcPhkyFJsNRA4BK4vGibsaY48EQ5n+MB5HruibuK+JIE8X+KZZ O6ZwDvv9KWpJ4yXkmcqMWjnbft5XvbB4Bpueulf9Tm2fiONGfqHTUqEp0KTTkHUvrePA c7+fBEKcBfRuwFn9MkPj2/kLIYHhckJjK2CGhChwl/Jjo1NF/p8rqqnVZggNdezaq20p Taaw== X-Gm-Message-State: AE9vXwOruohnBEwnSCk2UMFjBgx0gh5qD5qQ9/y77ZhkKxXKtluVBJGnorHzdN0lurrMzF2Z1A+sIoSqBJyS2Q== X-Received: by 10.200.47.253 with SMTP id m58mr27645636qta.60.1472859710016; Fri, 02 Sep 2016 16:41:50 -0700 (PDT) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.200.50.142 with HTTP; Fri, 2 Sep 2016 16:41:49 -0700 (PDT) In-Reply-To: <09ae01d20572$95f2be90$c1d83bb0$@augustcellars.com> References: <099d01d20561$53a67470$faf35d50$@augustcellars.com> <09ae01d20572$95f2be90$c1d83bb0$@augustcellars.com> From: Adam Langley Date: Fri, 2 Sep 2016 16:41:49 -0700 X-Google-Sender-Auth: BUsWfzQ9hik2cOUhPz56NPTBBzk Message-ID: To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: spasm@ietf.org Subject: Re: [Spasm] Chunking ciphertexts X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 23:41:53 -0000 On Fri, Sep 2, 2016 at 4:34 PM, Jim Schaad wrote: > If you do two passes then you have killed the benefit that you listed, that you do not have the keep the entire message in memory. The whole message has to pass /though/ memory twice, but it doesn't all have to be in memory at the same time. It's possible to do two passes by reading it from the disk twice. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Sun Sep 4 16:40:25 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FD812B0E9 for ; Sun, 4 Sep 2016 16:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 8nHBJfSmzEpT for ; Sun, 4 Sep 2016 16:40:22 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A2612B00D for ; Sun, 4 Sep 2016 16:40:22 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 4 Sep 2016 16:53:24 -0700 From: Jim Schaad To: Date: Sun, 4 Sep 2016 16:40:09 -0700 Message-ID: <0ac801d20705$adf15170$09d3f450$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdIHA7D6LdPrxcuiTySXxs6xYTSmlQ== Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Subject: [Spasm] What is the version number X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2016 23:40:24 -0000 We will be changing the version number for S/MIME with this set of documents. The question has been raised - what should the version number be. What I think are reasonable options are: 3.2 - Hey - that just the next number in the sequence. 3.5 - This is a "bigger" number to signify that we have made some significant changes with the addition of AEAD algorithms. 4.0 - This is a "marketing bigger" number that says we really did some big changes in this version of the specification. The current document is currently set at 3.5 because I remembered this as being what Sean said it should be, however more recent mail from him seems to indicate differently. Jim From nobody Sun Sep 4 19:20:15 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D73712B14D for ; Sun, 4 Sep 2016 19:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KPZI-Cn5qEKo for ; Sun, 4 Sep 2016 19:20:12 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 7E63512B11D for ; Sun, 4 Sep 2016 19:20:12 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id w2so101859106wmd.0 for ; Sun, 04 Sep 2016 19:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1moiyM/VlFA4xoWivKP8IOdtkRYZ6+V3IrB3rnBuyVE=; b=qta6RDR2fhFnYPXFn/QItRGQye0iMozMJ4hRyctUqRmEK/MlXk6sUlZoOAUIn4gvjV RhmiSVWuU7TdzeRI1v0jAMSFMOGqWMdQXJ2lKHztoN5JGi/FTlginG5MRBjhvJCO9ETT s37rjrJzDl+QthBoo3EBxPWgdZwhln6lG9+1+4yjfbKVy4B9bM229Mc1m44sgirsPz4l gNGXvQLdFwitBHwFWAfxirjct/B57H9IFcITWRcM2dtWiarQZaw/hkBVerotzJAcl8wY p53gw7dOWS3lniyEgsgqQwhxqhaSF8wYqxD1eb8G27kO1LI4Uw6h88cch+FfW+jJRZsN fuVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1moiyM/VlFA4xoWivKP8IOdtkRYZ6+V3IrB3rnBuyVE=; b=dtRsoXLynzhxdoUqxrRqxjylBOnDHrCZrgh1F9mGILF84iP6U53FnICqGsjnxRV9RG XheYYj+2p7DlRfH4bnUZcp5LTEcijha0OPMXc3+tmtEpPrSn0yNR7h/ObOXxweLagQPT UoFOa0nBfiW4ojqzrlW13HCi0/fa9WhSYtxG2JwZDPztPtN5NSsoOoayMSF9niuFERky Q8EBvwKt7EHzxBa1GCs30/GGWyJNjKdePFuHbXH3rCByFldk+W2SBuG20+xUIJRz8Ujv sNTN1nxUOlItciJ4nhrh26EN4qxa9cB812Ur0M59Azh22r6nrdhdnwsM17fKv6E4ksM5 vQiw== X-Gm-Message-State: AE9vXwME8R2h1kxgZ4y2eowANy3rG/yfNXemcNq947u/vH7cWCa6T9BDSpfrHYT/rYlbTD8GWpGgOB3rbAv1VA== X-Received: by 10.194.135.147 with SMTP id ps19mr28678323wjb.6.1473042010998; Sun, 04 Sep 2016 19:20:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.145.231 with HTTP; Sun, 4 Sep 2016 19:20:10 -0700 (PDT) In-Reply-To: <0ac801d20705$adf15170$09d3f450$@augustcellars.com> References: <0ac801d20705$adf15170$09d3f450$@augustcellars.com> From: Blake Ramsdell Date: Sun, 4 Sep 2016 19:20:10 -0700 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=20cf305e1f25ce0ca1053bb9512b Archived-At: Cc: "spasm@ietf.org" Subject: Re: [Spasm] What is the version number X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 02:20:14 -0000 --20cf305e1f25ce0ca1053bb9512b Content-Type: text/plain; charset=UTF-8 Does RFC 5751 remove the possibility for numbering this effort "3.2"? On Sunday, September 4, 2016, Jim Schaad wrote: > We will be changing the version number for S/MIME with this set of > documents. The question has been raised - what should the version number > be. What I think are reasonable options are: > > 3.2 - Hey - that just the next number in the sequence. > > 3.5 - This is a "bigger" number to signify that we have made some > significant changes with the addition of AEAD algorithms. > > 4.0 - This is a "marketing bigger" number that says we really did some big > changes in this version of the specification. > > The current document is currently set at 3.5 because I remembered this as > being what Sean said it should be, however more recent mail from him seems > to indicate differently. > > Jim > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --20cf305e1f25ce0ca1053bb9512b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Does RFC 5751 remove the possibility for numbering this effort "3.2&qu= ot;?

On Sunday, September 4, 2016, Jim Schaad <ietf@augustcellars.com> wrote:
We will be changing the version number for S/MIME with= this set of
documents.=C2=A0 The question has been raised - what should the version num= ber
be.=C2=A0 What I think are reasonable options are:

3.2 - Hey - that just the next number in the sequence.

3.5 - This is a "bigger" number to signify that we have made some=
significant changes with the addition of AEAD algorithms.

4.0 - This is a "marketing bigger" number that says we really did= some big
changes in this version of the specification.

The current document is currently set at 3.5 because I remembered this as being what Sean said it should be, however more recent mail from him seems<= br> to indicate differently.

Jim


_______________________________________________
Spasm mailing list
Spasm@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/spasm
--20cf305e1f25ce0ca1053bb9512b-- From nobody Sun Sep 4 20:01:22 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B85B12B15A for ; Sun, 4 Sep 2016 20:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 T83azvQN7bHq for ; Sun, 4 Sep 2016 20:01:19 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E1C12B137 for ; Sun, 4 Sep 2016 20:01:18 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 4 Sep 2016 20:14:00 -0700 From: Jim Schaad To: 'Blake Ramsdell' References: <0ac801d20705$adf15170$09d3f450$@augustcellars.com> In-Reply-To: Date: Sun, 4 Sep 2016 20:00:43 -0700 Message-ID: <0adf01d20721$b37fd460$1a7f7d20$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0AE0_01D206E7.07236D60" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHuqCtG6owLonQWcrlR3RUPPc5MggHKMpcAoCKhZlA= Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Cc: spasm@ietf.org Subject: Re: [Spasm] What is the version number X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 03:01:20 -0000 ------=_NextPart_000_0AE0_01D206E7.07236D60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable You are right, it should have been 3.3 not 3.2 =20 Jim =20 =20 From: Blake Ramsdell [mailto:blaker@gmail.com]=20 Sent: Sunday, September 04, 2016 7:20 PM To: Jim Schaad Cc: spasm@ietf.org Subject: Re: [Spasm] What is the version number =20 Does RFC 5751 remove the possibility for numbering this effort "3.2"? On Sunday, September 4, 2016, Jim Schaad > wrote: We will be changing the version number for S/MIME with this set of documents. The question has been raised - what should the version = number be. What I think are reasonable options are: 3.2 - Hey - that just the next number in the sequence. 3.5 - This is a "bigger" number to signify that we have made some significant changes with the addition of AEAD algorithms. 4.0 - This is a "marketing bigger" number that says we really did some = big changes in this version of the specification. The current document is currently set at 3.5 because I remembered this = as being what Sean said it should be, however more recent mail from him = seems to indicate differently. Jim _______________________________________________ Spasm mailing list Spasm@ietf.org =20 https://www.ietf.org/mailman/listinfo/spasm ------=_NextPart_000_0AE0_01D206E7.07236D60 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

You are = right, it should have been 3.3 not 3.2

 

Jim

 

 

From:<= /b> = Blake Ramsdell [mailto:blaker@gmail.com]
Sent: Sunday, = September 04, 2016 7:20 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = spasm@ietf.org
Subject: Re: [Spasm] What is the version = number

 

Does RFC = 5751 remove the possibility for numbering this effort = "3.2"?

On Sunday, September 4, 2016, Jim Schaad <ietf@augustcellars.com> = wrote:

We will = be changing the version number for S/MIME with this set = of
documents.  The question has been raised - what should the = version number
be.  What I think are reasonable options = are:

3.2 - Hey - that just the next number in the = sequence.

3.5 - This is a "bigger" number to signify = that we have made some
significant changes with the addition of AEAD = algorithms.

4.0 - This is a "marketing bigger" number = that says we really did some big
changes in this version of the = specification.

The current document is currently set at 3.5 = because I remembered this as
being what Sean said it should be, = however more recent mail from him seems
to indicate = differently.

Jim


______________________________________= _________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

------=_NextPart_000_0AE0_01D206E7.07236D60-- From nobody Mon Sep 5 20:15:00 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C6712B103 for ; Mon, 5 Sep 2016 20:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 8KDtRqGW3YD5 for ; Mon, 5 Sep 2016 20:14:57 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 AFB7912B0FE for ; Mon, 5 Sep 2016 20:14:57 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id l2so205782091qkf.3 for ; Mon, 05 Sep 2016 20:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pnaepIVmfpGJkumaa1eaCl/5KyCeIFLHt5NUKm2sies=; b=Tqd/bfzjtKOnnKWGgDnY82G5r5PpC0fV5Ht0VlIvMI4wVHHX0fH9T2e/Na4aVvRNRW VVmQHwTnWZKkNRBO0WZEFC+mcfj7bhcfnhIagbGi9o+ErqlFYZpsMuX84hTXpodoU5XN lUTo1tI7c2aMKaQTVymUwYHsj10ccVlsHxoyc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pnaepIVmfpGJkumaa1eaCl/5KyCeIFLHt5NUKm2sies=; b=ev5dkkwCyiOvOqH9w00ZcPHzbG2hWPE4kcjdksNkA8xU0JOSDl0q+HuxrCb2N0tsLw Oi+VSp9cuKtWGKzbSOnh5IwD6YZ3N9uqZ4QTyxhMS54PM/i9Dv0uIw1OVn43HjByo4oe AA2+Viy9Qe8f3MGo5sJC2mAF59Fy1EKZMG1a2638tZVLowbfTsw875ldcbt8Nzd3Gvvt bUjXnMfiayxcjWLnLKMG5+94zxFHR7J9qSeJrolVOjPjlzWHeGhV1LPdIfmA2AyJtV0U kzm1WEzTGnBGhWzIH8FrJksrqpWSOeTvn7JU/7Obj25SE4fF9sdE7/K/yqG6hxrV8pLb 3ZWQ== X-Gm-Message-State: AE9vXwNGFTi8A8PCbY2FX7QCUGQ5vm0gp6Ai14O5atXjY2/adngTpHI/cYhJSD6EFw2X5A== X-Received: by 10.55.132.71 with SMTP id g68mr44715593qkd.50.1473131696805; Mon, 05 Sep 2016 20:14:56 -0700 (PDT) Received: from [172.16.0.112] ([96.231.228.70]) by smtp.gmail.com with ESMTPSA id s23sm16576032qka.10.2016.09.05.20.14.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 05 Sep 2016 20:14:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <0ac801d20705$adf15170$09d3f450$@augustcellars.com> Date: Mon, 5 Sep 2016 23:14:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <024F9083-FB4C-401E-B497-0B1B591E7C40@sn3rd.com> References: <0ac801d20705$adf15170$09d3f450$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3124) Archived-At: Cc: spasm@ietf.org Subject: Re: [Spasm] What is the version number X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 03:14:59 -0000 I favor 4.0, but I=E2=80=99m certainly not going to die on that hill. spt > On Sep 04, 2016, at 19:40, Jim Schaad wrote: >=20 > We will be changing the version number for S/MIME with this set of > documents. The question has been raised - what should the version = number > be. What I think are reasonable options are: >=20 > 3.2 - Hey - that just the next number in the sequence. >=20 > 3.5 - This is a "bigger" number to signify that we have made some > significant changes with the addition of AEAD algorithms. >=20 > 4.0 - This is a "marketing bigger" number that says we really did some = big > changes in this version of the specification. >=20 > The current document is currently set at 3.5 because I remembered this = as > being what Sean said it should be, however more recent mail from him = seems > to indicate differently. >=20 > Jim >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Sep 6 08:09:41 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B2012B563 for ; Tue, 6 Sep 2016 08:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 22q7qU226Ntj for ; Tue, 6 Sep 2016 08:09:35 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AA0D12B4C2 for ; Tue, 6 Sep 2016 08:07:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E9D5A300639 for ; Tue, 6 Sep 2016 11:07:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3hXCcMx7-H66 for ; Tue, 6 Sep 2016 11:07:55 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id AF7A0300443; Tue, 6 Sep 2016 11:07:55 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <0ac801d20705$adf15170$09d3f450$@augustcellars.com> Date: Tue, 6 Sep 2016 11:07:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0ac801d20705$adf15170$09d3f450$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: spasm@ietf.org Subject: Re: [Spasm] What is the version number X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 15:09:39 -0000 Right now, the message document and the certificate document are = different. I can live with any of these numbers, but we need to pick = one! Russ On Sep 4, 2016, at 7:40 PM, Jim Schaad wrote: > We will be changing the version number for S/MIME with this set of > documents. The question has been raised - what should the version = number > be. What I think are reasonable options are: >=20 > 3.2 - Hey - that just the next number in the sequence. >=20 > 3.5 - This is a "bigger" number to signify that we have made some > significant changes with the addition of AEAD algorithms. >=20 > 4.0 - This is a "marketing bigger" number that says we really did some = big > changes in this version of the specification. >=20 > The current document is currently set at 3.5 because I remembered this = as > being what Sean said it should be, however more recent mail from him = seems > to indicate differently. >=20 > Jim >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Sun Sep 18 18:26:49 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8A112B126 for ; Sun, 18 Sep 2016 18:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 MDUbk1h5w47h for ; Sun, 18 Sep 2016 18:26:45 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 7B23A12B0CB for ; Sun, 18 Sep 2016 18:26:42 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id w204so133431072qka.0 for ; Sun, 18 Sep 2016 18:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=+McC+9955KsceSRD1xzQCI4us+FJeirmeXpv1glRSHA=; b=tgXptSOJBfnugSWiw0r3vOvcZKOwFbuBs45uCnfQ35zE/Cko/Y/9xnaKzqXPRtvXFD hcQZk8HGKntb4/U8ExcZKmwlFUa2SMdGoL5qjX8Ak7vyqC3/BQ96byizWsdkIP5baUr8 rP1oav0NfqbF/9uY5ffV7+6aZx3+EBAravqM6jiRE4zVt3USjF+8xW+QBR3yg5t+oMTt kR4SGJIc6Z8H7wvBdBQiJ0m5iFP+Mk+LWvVPm52zI6PI8r954O7jkLu8LEl1FYIY+z3w GlnpKYfJmrw9mBETaJqhvZmWmWbj9nBokOaLi5aB6MTj32VQSgYt4wty0YVOhCGtqOgi tZ6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=+McC+9955KsceSRD1xzQCI4us+FJeirmeXpv1glRSHA=; b=ex/rvxk4cvGzxYBwuBLNlILccRvAZKKWlepyS46tOJLu7mrsSYJb1XOgTuDSW4HH3Y TbZXWUmDqEeCifmGMRx8WkVJWGEGzRfJx5ZL0xMaXJ7hyS1LXKrVjYU9UvkTtoFIoUF3 pgs3JqC/vm0z53NYNDIsH6epuhTqHEsj/wHwOPU6FIGMQPR97hULxy35RF9a5EVaA3E8 aDhwwk+/y9N3p/FRyY5egCls6oMJLIGwG7GDSorrjQHqTWhj47vcDrCgVp62vnWbiG3e 4XrBmDSRZg4mnGe3T0H8ZUJVoOZJopHqznz3r0TmBgjZxwjua23Gb66Y7lKEl2fjhD4B Fl6w== X-Gm-Message-State: AE9vXwMYGXyIP0LkbeKAqQtJ+3Marw7gRwgnV/0FuGBIoRzzH+IE+ExS1DvyqZwvT4a6xDtgmDtuVEyivbWFYw== X-Received: by 10.55.103.197 with SMTP id b188mr26896802qkc.108.1474248401528; Sun, 18 Sep 2016 18:26:41 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.209.87 with HTTP; Sun, 18 Sep 2016 18:26:41 -0700 (PDT) From: Phillip Hallam-Baker Date: Sun, 18 Sep 2016 21:26:41 -0400 X-Google-Sender-Auth: XVQKhd3OnKQmOQlxV9g8xdciosQ Message-ID: To: SPASM@ietf.org Content-Type: multipart/alternative; boundary=94eb2c05b77448af69053cd234b2 Archived-At: Subject: [Spasm] Towards OpenPGP / SMIME interoperability X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 01:26:48 -0000 --94eb2c05b77448af69053cd234b2 Content-Type: text/plain; charset=UTF-8 Wouldn't it be nice if we could get to the point where S/MIME and OpenPGP are just message formats and clients will allow the use of any trusted key to send a message regardless of which PKI it came from? One of the really useful features of OpenPGP is the ability to create direct trust links via fingerprints. Many S/MIME and PKIX clients use fingerprints to identify certificates. The OpenPGP group is currently looking at its v5 fingerprint format. I have designed a proposal that allows one fingerprint format to be used with multiple PKIs and key formats. The trick being to include some metadata describing the data being fingerprinted within the scope of the digest. Details of the generic scheme I have proposed are here: https://tools.ietf.org/html/draft-hallambaker-udf-03 So the question here are 1) Do we think a fingerprint scheme has value in the S/MIME world? 2) If so is the S/MIME world prepared to use a fingerprint format that is designed to enable use by multiple applications without cross semantics attacks (e.g. attacker crafts PKIX cert to look like an OpenPGP key packet with a different key). I think that fingerprints could be very very useful as a means of exchanging PKIX trust roots. So lets say I am hooking up my mail client to the enterprise servers. Today I click to 'require TLS' but this says nothing about which certs to accept. It seems to me that being able to enter the fingerprint of the enterprise intermediate root under which all the TLS certs are signed would allow security to be tightened up rather usefully. --94eb2c05b77448af69053cd234b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wouldn't it be nice if we could get to the po= int where S/MIME and OpenPGP are just message formats and clients will allo= w the use of any trusted key to send a message regardless of which PKI it c= ame from?

One of the really useful features of OpenPGP is the ability= to create direct trust links via fingerprints. Many S/MIME and PKIX client= s use fingerprints to identify certificates.=C2=A0

The OpenPGP group is currently looking at its v5 = fingerprint format. I have designed a proposal that allows one fingerprint = format to be used with multiple PKIs and key formats. The trick being to in= clude some metadata describing the data being fingerprinted within the scop= e of the digest.

Details = of the generic scheme I have proposed are here:

https://tools= .ietf.org/html/draft-hallambaker-udf-03


So the question here are

1) Do we think a fingerprint scheme has value in the S/MIME wo= rld?

=
2) If so is the S/MI= ME world prepared to use a fingerprint format that is designed to enable us= e by multiple applications without cross semantics attacks (e.g. attacker c= rafts PKIX cert to look like an OpenPGP key packet with a different key).


I think that fingerprints could be v= ery very useful as a means of exchanging PKIX trust roots. So lets say I am= hooking up my mail client to the enterprise servers. Today I click to '= ;require TLS' but this says nothing about which certs to accept. It see= ms to me that being able to enter the fingerprint of the enterprise interme= diate root under which all the TLS certs are signed would allow security to= be tightened up rather usefully.
--94eb2c05b77448af69053cd234b2-- From BATV+e4a5c8c88c3adab274df+4775+infradead.org+dwmw2@bombadil.srs.infradead.org Mon Sep 19 03:23:42 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A401312B2E0; Mon, 19 Sep 2016 03:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no 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 bQ4Gc9lMpyKX; Mon, 19 Sep 2016 03:23:36 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 7CB5E12B2C9; Mon, 19 Sep 2016 03:23:24 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1blvjP-00067V-Ju; Mon, 19 Sep 2016 10:23:23 +0000 Message-ID: <1474280601.144982.263.camel@infradead.org> From: David Woodhouse To: saag@ietf.org, spasm@ietf.org Date: Mon, 19 Sep 2016 11:23:21 +0100 Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-D4sUIoZYXYCq0P1yK9tm" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Subject: [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 10:26:45 -0000 --=-D4sUIoZYXYCq0P1yK9tm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (I hope the cross-post is acceptable; apologies if not.) Various applications will optionally make use of X.509 certificates for client authentication. Those certificates, and the associated private keys, may be found in files on the file system, in PKCS#11 tokens, or in another OS-specific form of certificate database. In my opinion, it would be nice to have some consistency between applications. If a user has a certificate in a certain form, it would be nice for that to Just Work=E2=84=A2 across all well-behaved applications= . In practice, nothing could be further from the truth. Applications *all* suck, and various certificates will spuriously fail to work in one application but not another. Or work if the application is build against crypto library $A but not when built against crypto library $B. Or for objects in PKCS#11 each application might require a *different* identifier string to locate the same object. If they support PKCS#11 at all. I'd like to fix that. I would like to achieve a consensus that a "well- behaved application" SHOULD accept certificates and keys in various (TBD) file formats and also accept PKCS#11 URIs according to RFC7512. I have slowly been working on this. I have encouraged the Fedora distribution of Linux to amend their packaging guidelines to state that software packaged for Fedora SHOULD accept a PKCS#11 URI wherever it would accept a filename. And that software SHOULD load the PKCS#11 tokens which are indicated by the system configuration. We have already fixed various applications to comply with these requirements, and I even mentored a Google Summer of Code project which added RFC7512 support to NSS=C2=B2. I believe the Fedora packaging guidelines have been a success, and I would like to expand the scope. There's no *reason* this should be Fedora-specific, or even specific to Linux or POSIX operating systems. So I'm looking for a forum in which to reach a consensus on what should be accepted, and to publish those guidelines. I'd be very interested in hearing suggestions. Simultaneously, I'm also looking at expanding the technical scope. For my own project, the OpenConnect VPN client, I have started to collect a torture test suite=C2=B3 of RSA, DSA and EC keys in various PKCS#1, PKCS#8 and PKCS#12 forms =E2=80=94 both unencrypted, and encrypted = with various algorithms. I have yet to embark of the joy of files with non- ASCII passphrases, especially in non-UTF8 locales =E2=80=94 but I have a bo= ttle of vodka ready to help me do so. My test suite also includes PKCS#11 tests including private keys where the token doesn't expose the public component (which made OpenSSL crash until yesterday, yay!) and certificates with the CKA_PRIVATE attribute set, so some software will fail to *find* them. I am thinking of splitting my torture test out from OpenConnect itself, and making it available as a project in its own right. I can, of course, lobby to expand the Fedora guidelines to state that all software packaged for Fedora SHOULD pass the torture test suite, but I think it makes sense to aim for a wider consensus than that. Opinions welcome... does it make sense to attempt to publish an informational RFC outlining such "expectations"? Or should it take some other form? Or should I just not bother, and continue to push it from the Fedora angle, since it's getting into a lot of upstream software already? I also expect some heckling at my specific test cases =E2=80=94 do we *real= ly* expect everyone to support DSA keys still? And PEM files encrypted the old OpenSSL way? And PKCS#12 files encrypted with MD5-DES? (I can accept 'no' answers to the latter two only if expressed in a form which lets me file bugs against ancient "enterprise" software to stop *creating* them that way...) --=20 dwmw2 =C2=B9 https://fedoraproject.org/wiki/Packaging:SSLCertificateHandling =C2=B2 https://bugzil.la/1162897 =C2=B3 http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/test= s/Makefile.am --=-D4sUIoZYXYCq0P1yK9tm Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTE5MTAyMzIxWjAvBgkqhkiG9w0BCQQxIgQgLQ7nkMZwxo8HmMkbSxFaGkVXPrivTKrzNJ8J PAbDyLAwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICADwo qNvdEERNUXHfDagCLkb3sCjBqRhCbn+vWijyyjEW5QeOn4A0Bb3OAK4n3h88sxEvzdIGV3R7w1ca fLftiQnWDOWcIKJmj8idmbWrB25EPW5OZEk+/xNygqtEFVFl6xES9WPi6jjSSmXhom4cOjIU43Dp 4eVBm0WIKWVacQ9/eaWWzSrpdDwXyh4cZ7unWxoHaDl+mzAUthB5XHtA664fWayzLQivqh0tuyNj X9hcEiI5APCf/OhIlDua34zuP3hg94K3nPyuzSLDFwe8iPxT41L8XvGlXR+dz6UDJyt/Itr0NcKI L3V/+IzXgrQkgAhHYoYUGmYtZaCcdTNaWe7NzF+8yNhsqMMUsZ8Rsb+sP/uHyQjFQTpJCf6bVN7G 8TqkfiKC0yOrZLhFlzL4BsUyhGkmtxUOb5gJbroaKxITG7VLD/5Eva3AJfmo61vBo7ch/ULoY94j /O11Kp6Gk7R07oN8EKoTtlpJLti+p7jxtH9Zedi9wCgE3DKPGHZVrNn7BEKm7Zb2NVtLzl/atiJs vfaUtwWkHT4EdQKfOt4xglP8QzBRRD+JMcqBTGP7qNZNqC0g7d5lLRioLQGsAk1u/Z7nad0Q/pzP zrb6o0qeoEcBLGZQEHucC5ZDn8vMdkMF9KGYBzYRXT/TNlH5TUA9W42xZA9XyfSwf7+Ogw9oAAAA AAAA --=-D4sUIoZYXYCq0P1yK9tm-- From nobody Mon Sep 19 04:27:05 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CD012B039 for ; Mon, 19 Sep 2016 04:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 AvTmXcMU6C51 for ; Mon, 19 Sep 2016 04:26:58 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 7894012B34A for ; Mon, 19 Sep 2016 04:26:57 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id g62so104164589lfe.3 for ; Mon, 19 Sep 2016 04:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZRO4dTK4jHWvRsEkdBBteCNnYLA41DbXtpTDxDlI3IY=; b=YcUJPC3oGKAwaDGXMw8l9eubSLtqBe5ERn2rApbuHadjLacK+HKnaakVAtt8ZrZAw9 gc3gQ+BcLsLM7wBhhdNpDnqiB6/AwTV9/a7crb7ingsihFg+2U8c2ARa5PvDfzF5ZU6j iAEHV97BbhAsN0IitLUCUWU3s0/e9wJ8tW2kBQclryY1GiBHHJOENgTxrdzp+n6IxXwx 1SgfpV4zjVNK6uvX39AiBOU1dEScf7XWYrNwp+mHtCX2xnf51zLNGkGTaQnLbXa11mFS E43jvC+jyWSUq62Z0+I3pJxiyIKwetR8Bo26yRS+XlUPovRIOYjE7HZa09qg4EIbyHtx rBJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZRO4dTK4jHWvRsEkdBBteCNnYLA41DbXtpTDxDlI3IY=; b=i4pcOVfjigqD81pmuvcJ1NXgpcEZ02sAVeSdoOV9MSD47i/Jidt74htqQdXtpxl2O4 4wbnfeQITO/6Di7UoCvHQjSJDTnU7RUhN0dqhdRatP7ZiASpycUJtVdG7GL8y2YT3f8C ImmjyGUs+9xpEqq6FCrt87DgQ8o6iz8SVsd56Cl5Wbs7/AErktOeTUXcfoGZymQM4TZp gsu2kTzCD4QBg4gTy4zJaeF8Ni3olXZlOREuvEBGuH5N59X+4oXE8bf96gFq4hemGKsz 2a5o6ZxqzlQBIjOMMbbL0xmf+suKrYaztNkr3aova/tnJ1NrWjy4rxbGf7EARm9xLH1Y 5zNg== X-Gm-Message-State: AE9vXwOLt2QGiFRh9gUqpJgur56pD7Ijbru6zVaGG3TzFkqluH6QR14DNA4beBcG7zz15IN6AF+ZPWq4saMkRg== X-Received: by 10.25.76.136 with SMTP id z130mr1110893lfa.126.1474284415481; Mon, 19 Sep 2016 04:26:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Mon, 19 Sep 2016 04:26:14 -0700 (PDT) In-Reply-To: <1474280601.144982.263.camel@infradead.org> References: <1474280601.144982.263.camel@infradead.org> From: Ted Lemon Date: Mon, 19 Sep 2016 07:26:14 -0400 Message-ID: To: David Woodhouse Content-Type: multipart/alternative; boundary=001a114b1738e20a56053cda9689 Archived-At: Cc: spasm@ietf.org, Security Area Advisory Group Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 11:27:01 -0000 --001a114b1738e20a56053cda9689 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The effort is certainly worth doing. I've encountered the same problem, and also find it frustrating. It might be worth writing an informational doc; the challenge would be socializing it to the people who need to read it. On Mon, Sep 19, 2016 at 6:23 AM, David Woodhouse wrote: > (I hope the cross-post is acceptable; apologies if not.) > > Various applications will optionally make use of X.509 certificates for > client authentication. > > Those certificates, and the associated private keys, may be found in > files on the file system, in PKCS#11 tokens, or in another > OS-specific form of certificate database. > > In my opinion, it would be nice to have some consistency between > applications. If a user has a certificate in a certain form, it would > be nice for that to Just Work=E2=84=A2 across all well-behaved applicatio= ns. > > In practice, nothing could be further from the truth. > > Applications *all* suck, and various certificates will spuriously fail > to work in one application but not another. Or work if the application > is build against crypto library $A but not when built against crypto > library $B. Or for objects in PKCS#11 each application might require a > *different* identifier string to locate the same object. If they > support PKCS#11 at all. > > I'd like to fix that. I would like to achieve a consensus that a "well- > behaved application" SHOULD accept certificates and keys in various > (TBD) file formats and also accept PKCS#11 URIs according to RFC7512. > > I have slowly been working on this. I have encouraged the Fedora > distribution of Linux to amend their packaging guidelines to state that > software packaged for Fedora SHOULD accept a PKCS#11 URI wherever it > would accept a filename. And that software SHOULD load the PKCS#11 > tokens which are indicated by the system configuration. > > We have already fixed various applications to comply with these > requirements, and I even mentored a Google Summer of Code project which > added RFC7512 support to NSS=C2=B2. > > I believe the Fedora packaging guidelines have been a success, and I > would like to expand the scope. There's no *reason* this should be > Fedora-specific, or even specific to Linux or POSIX operating systems. > So I'm looking for a forum in which to reach a consensus on what should > be accepted, and to publish those guidelines. I'd be very interested in > hearing suggestions. > > > Simultaneously, I'm also looking at expanding the technical scope. > For my own project, the OpenConnect VPN client, I have started to > collect a torture test suite=C2=B3 of RSA, DSA and EC keys in various > PKCS#1, PKCS#8 and PKCS#12 forms =E2=80=94 both unencrypted, and encrypte= d with > various algorithms. I have yet to embark of the joy of files with non- > ASCII passphrases, especially in non-UTF8 locales =E2=80=94 but I have a = bottle > of vodka ready to help me do so. > > My test suite also includes PKCS#11 tests including private keys where > the token doesn't expose the public component (which made OpenSSL crash > until yesterday, yay!) and certificates with the CKA_PRIVATE attribute > set, so some software will fail to *find* them. > > I am thinking of splitting my torture test out from OpenConnect itself, > and making it available as a project in its own right. > > I can, of course, lobby to expand the Fedora guidelines to state that > all software packaged for Fedora SHOULD pass the torture test suite, > but I think it makes sense to aim for a wider consensus than that. > > Opinions welcome... does it make sense to attempt to publish an > informational RFC outlining such "expectations"? Or should it take some > other form? Or should I just not bother, and continue to push it from > the Fedora angle, since it's getting into a lot of upstream software > already? > > I also expect some heckling at my specific test cases =E2=80=94 do we *re= ally* > expect everyone to support DSA keys still? And PEM files encrypted the > old OpenSSL way? And PKCS#12 files encrypted with MD5-DES? > > (I can accept 'no' answers to the latter two only if expressed in a > form which lets me file bugs against ancient "enterprise" software to > stop *creating* them that way...) > > -- > dwmw2 > > =C2=B9 https://fedoraproject.org/wiki/Packaging:SSLCertificateHandling > =C2=B2 https://bugzil.la/1162897 > =C2=B3 http://git.infradead.org/users/dwmw2/openconnect.git/ > blob/HEAD:/tests/Makefile.am > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > --001a114b1738e20a56053cda9689 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The effort is certainly worth doing. =C2=A0 I've encou= ntered the same problem, and also find it frustrating. =C2=A0 It might be w= orth writing an informational doc; the challenge would be socializing it to= the people who need to read it.

On Mon, Sep 19, 2016 at 6:23 AM, David Woodhouse <d= wmw2@infradead.org> wrote:
= (I hope the cross-post is acceptable; apologies if not.)

Various applications will optionally make use of X.509 certificates for
client authentication.

Those certificates, and the associated private keys, may be found in
files on the file system, in PKCS#11 tokens, or in another
OS-specific form of certificate database.

In my opinion, it would be nice to have some consistency between
applications. If a user has a certificate in a certain form, it would
be nice for that to Just Work=E2=84=A2 across all well-behaved applications= .

In practice, nothing could be further from the truth.

Applications *all* suck, and various certificates will spuriously fail
to work in one application but not another. Or work if the application
is build against crypto library $A but not when built against crypto
library $B. Or for objects in PKCS#11 each application might require a
*different* identifier string to locate the same object. If they
support PKCS#11 at all.

I'd like to fix that. I would like to achieve a consensus that a "= well-
behaved application" SHOULD accept certificates and keys in various (TBD) file formats and also accept PKCS#11 URIs according to RFC7512.

I have slowly been working on this. I have encouraged the Fedora
distribution of Linux to amend their packaging guidelines to state that
software packaged for Fedora SHOULD accept a PKCS#11 URI wherever it
would accept a filename. And that software SHOULD load the PKCS#11
tokens which are indicated by the system configuration.

We have already fixed various applications to comply with these
requirements, and I even mentored a Google Summer of Code project which
added RFC7512 support to NSS=C2=B2.

I believe the Fedora packaging guidelines have been a success, and I
would like to expand the scope. There's no *reason* this should be
Fedora-specific, or even specific to Linux or POSIX operating systems.
So I'm looking for a forum in which to reach a consensus on what should=
be accepted, and to publish those guidelines. I'd be very interested in=
hearing suggestions.


Simultaneously, I'm also looking at expanding the technical scope.
For my own project, the OpenConnect VPN client, I have started to
collect a torture test suite=C2=B3 of RSA, DSA and EC keys in various
PKCS#1, PKCS#8 and PKCS#12 forms =E2=80=94 both unencrypted, and encrypted = with
various algorithms. I have yet to embark of the joy of files with non-
ASCII passphrases, especially in non-UTF8 locales =E2=80=94 but I have a bo= ttle
of vodka ready to help me do so.

My test suite also includes PKCS#11 tests including private keys where
the token doesn't expose the public component (which made OpenSSL crash=
until yesterday, yay!) and certificates with the CKA_PRIVATE attribute
set, so some software will fail to *find* them.

I am thinking of splitting my torture test out from OpenConnect itself,
and making it available as a project in its own right.

I can, of course, lobby to expand the Fedora guidelines to state that
all software packaged for Fedora SHOULD pass the torture test suite,
but I think it makes sense to aim for a wider consensus than that.

Opinions welcome... does it make sense to attempt to publish an
informational RFC outlining such "expectations"? Or should it tak= e some
other form? Or should I just not bother, and continue to push it from
the Fedora angle, since it's getting into a lot of upstream software already?

I also expect some heckling at my specific test cases =E2=80=94 do we *real= ly*
expect everyone to support DSA keys still? And PEM files encrypted the
old OpenSSL way? And PKCS#12 files encrypted with MD5-DES?

(I can accept 'no' answers to the latter two only if expressed in a=
form which lets me file bugs against ancient "enterprise" softwar= e to
stop *creating* them that way...)

--
dwmw2

=C2=B9 https://fedoraproject.org/wiki/Packaging:SSLCertificateHandling
=C2=B2 https://bugzil.la/1162897
=C2=B3 http://git.i= nfradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefil= e.am

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag


--001a114b1738e20a56053cda9689-- From nobody Mon Sep 19 09:36:30 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1CB12B451 for ; Mon, 19 Sep 2016 09:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_MIME_MALF=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fUAwPKJH5gX8 for ; Mon, 19 Sep 2016 09:36:28 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 0FEF312B470 for ; Mon, 19 Sep 2016 09:35:09 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id n185so15460431qke.1 for ; Mon, 19 Sep 2016 09:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:cc; bh=v8vHgXwfJic8+tfqFWsLWy6Y2imItRCdK/4fWMfFZiI=; b=Y7YisCEW244pW6M+s6jX4i5XeeCRv2a9L0kxyA6i2MsDSZnha/4BSRDtT84CyGvRwQ JiIZtvKJXbxA4/U8CqramdCphjIJbDuZ8bIrFJr86tVmXk4T7PKEQ/4tDUklpsx8VMp3 rsijbvddFwzkstZ0024Lr1wR+e7b0KPQrAP/md7kgTuLCKHN0kkYOfXsqax1IBbclskH OdAHU60qbSdGeLO2pfulEHj12z0+xu866xj92TT95Gjhvqitl+Zx3YlQhIGqn48YA6RS VBYXfqv0LRGrXRINya6oOI7kFnh3DYBO8+xoNPZ5adpjvr7WMWm6s6KTzNWPyZvw4DND 17sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:cc; bh=v8vHgXwfJic8+tfqFWsLWy6Y2imItRCdK/4fWMfFZiI=; b=aLWENFPs1nm8Ed/oM9UxcyclzoJior4OjrjK5lGecD9fAcGGgH1Bdb+ZgpcekEGbMs N55MEIA63HYu5XwuFgu8S60nEU2JIrQJv8HVFvjxPRDcVKThHrELc7qV3vsOCB5LlWr5 ZYmKOCIOUuMdQ4pFQxSgrVEh03kOVmNPGmawIBjqp1/tg/vrlDY0E97Dqv6dON84w17x fsx58lf1L2nb4UJs2QPUAIgjdhuReKTxjtLFRUCf0FrPoJItbkTKSH8XLI+kpiMqhT7F rQV/3LTItFHrsSwH5UnFMQwXzQETbJWc5HohSd3gKoeXR/QQMnQBPgqx+dgFIgUX8ISN 8GXg== X-Gm-Message-State: AE9vXwMJ0X6En7Rv5jhXhp5EdSHqYcOgTYxJi/lsO22JM7uLpWd/cHdHZvMgZstVDRdpTdSmDnj4ozLuN5VzRQ== X-Received: by 10.55.160.145 with SMTP id j139mt32127056qke.167.1474302908230; Mon, 19 Sep 2016 09:35:08 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.209.87 with HTTP; Mon, 19 Sep 2016 09:35:07 -0700 (PDT) In-Reply-To: <1474280601.144982.263.camel@infradead.org> References: <1474280601.144982.263.camel@infradead.org> From: Phillip Hallam-Baker Date: Mon, 19 Sep 2016 12:35:07 -0400 X-Google-Sender-Auth: 2SBL5OEcofPE64Cw0PDcERGhQdg Message-ID: Content-Type: multipart/alternative; boundary=94eb2c076206230c50053cdee55d Archived-At: Cc: spasm@ietf.org, "saag@ietf.org" Subject: Re: [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 16:36:29 -0000 --94eb2c076206230c50053cdee55d Content-Type: text/plain; charset=UTF-8 This is a very common problem and one that I encounter on an hourly basis as I write code for the Mesh. There are three separate formats used for public keys in SSH and four for private. This is all stuff that has dropped off the table as far as the standards groups are concerned because 'it isn't protocol that goes on the wire'. Except of course it does. The way I think we have to approach a solution is to use a container of some type whether that is MIME or JSON that has a slot for metadata describing the content type to follow: Content-Type: application/pkix-certificate Content-Encoding: BASE64 3ljkrf3kjrkj3hrfkjh3fjkh3jkfh34fkjh== It isn't too difficult to allow a choice of MIME or JSON for the container as the JSON will always start with a { and the MIME never will. I use JSON-B which is simply JSON with an added code point that lets me drop specified length binary encoded data into a JSON document at a particular point. But that is because some of my files are rather large. --94eb2c076206230c50053cdee55d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thi= s is a very common problem and one that I encounter on an hourly basis as I= write code for the Mesh. There are three separate formats used for public = keys in SSH and four for private.

This is all stuff that has dropped off the table as far as the s= tandards groups are concerned because 'it isn't protocol that goes = on the wire'. Except of course it does.

The way I think we have to approach a solution is to u= se a container of some type whether that is MIME or JSON that has a slot fo= r metadata describing the content type to follow:

Content-Type: application/pkix-certificate
Content-Encoding: BASE= 64

3ljkrf3kjrkj3hrfkjh3fj= kh3jkfh34fkjh=3D=3D

It is= n't too difficult to allow a choice of MIME or JSON for the container a= s the JSON will always start with a { and the MIME never will.=C2=A0
<= div class=3D"gmail_default" style=3D"font-size:small">
I use JSON-B which is simply J= SON with an added code point that lets me drop specified length binary enco= ded data into a JSON document at a particular point. But that is because so= me of my files are rather large.


--94eb2c076206230c50053cdee55d-- From nobody Mon Sep 19 11:54:31 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0192512B4E6; Mon, 19 Sep 2016 11:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 VOuRSQP-WT4x; Mon, 19 Sep 2016 11:54:28 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 6284C12B4B3; Mon, 19 Sep 2016 11:54:28 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id o139so5784143vka.1; Mon, 19 Sep 2016 11:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JhRGZvApYryGgCIQkMt8usoF/Sb5lPdO2+g/GtH86Tw=; b=CIvdoVtsMlpZSq29Qm42FviG3uxazk0HW3PMPA7ab3s1XZmlF6NoWMUlBqYqW9vQoR Yz4Hmlq5KFCy5ahssNx5ZF2eRh4Es+OjDeQkOqppC4n6no5vjwjiVErriz3WLHL0Uak0 sP36WVfThdec6Lh5t5oxs7PHhxTEoFP6ZBrd9j+byfV2tn3OvnvRm6OkVV00kKG6NltK QxJW7x89SHv0gks0ehli4Jgtfv7UuWKISWPOU7r5+/oaPyKuI6s81CnAF53KY8TsnCcd 0rngpA+QGnVjp30+YHhVDjbSGBgSpix4R2zluYuc3XtHAuRFX5meZWhS3DV/B5xr6+7/ BL7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JhRGZvApYryGgCIQkMt8usoF/Sb5lPdO2+g/GtH86Tw=; b=jVRzilkikFOFBqQjSKhz1aAiDDC7oUWTH04S+TrbCxdIssOMKo1Ry8nReiFtTT7X0v LqeXq6FSOCjWFs6AI2iW5N7Saz62ryRnc+uPHwF9zmSwqnsI6JMJiLm5ZKyuZ+/ZxsPk EqFYJaXu27Lw4Uw5UGWOU83B+Uca4AjYHlBSJWiBOIkbRs1H+eQfVIkYxhPOu+a7JTDF 8+sHQv3GEpSNyFQG4Ss/L9bxpjdV+quyKx5IKH/4oFqfxXmGKgQKrDvV+I2Skt0Yuhmc r156Dnp7OnehqD9zNBvXqjpB/xBfoyGC1nEhBK/bO83jNXHFIdwGSn+CsEZw0t1O+143 slMA== X-Gm-Message-State: AE9vXwPNaE6PU+0x9a6HOG0HZ8AKlQHLHte7jScXzdMqfbaTvgM9gcZAlEmdfVWKw9T03xviDKvJtLW3HNatcQ== X-Received: by 10.31.158.1 with SMTP id h1mr503977vke.44.1474311267371; Mon, 19 Sep 2016 11:54:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.102 with HTTP; Mon, 19 Sep 2016 11:54:26 -0700 (PDT) Received: by 10.176.4.102 with HTTP; Mon, 19 Sep 2016 11:54:26 -0700 (PDT) In-Reply-To: References: <1474280601.144982.263.camel@infradead.org> From: Watson Ladd Date: Mon, 19 Sep 2016 11:54:26 -0700 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11425eec6151c1053ce0d75a Archived-At: Cc: spasm@ietf.org, David Woodhouse , Security Area Advisory Group Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 18:54:31 -0000 --001a11425eec6151c1053ce0d75a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 19, 2016 at 4:26 AM, Ted Lemon wrote: > The effort is certainly worth doing. I've encountered the same problem, > and also find it frustrating. It might be worth writing an informational > doc; the challenge would be socializing it to the people who need to read > it. The first problem is that there isn't an easy library to integrate that will handle this. If it's a five minute fix that's very different from a long development process. And no, adding better support to NSS doesn't count: NSS has no documentation, as well as missing some important security features. (NSS diffie-hellman ephemeral keys don't rotate for instance). If you want applications to use tokens you need to make doing so a solution, not a problem. Standards can help, but they have also massively hurt. > > On Mon, Sep 19, 2016 at 6:23 AM, David Woodhouse > wrote: >> >> (I hope the cross-post is acceptable; apologies if not.) >> >> Various applications will optionally make use of X.509 certificates for >> client authentication. >> >> Those certificates, and the associated private keys, may be found in >> files on the file system, in PKCS#11 tokens, or in another >> OS-specific form of certificate database. >> >> In my opinion, it would be nice to have some consistency between >> applications. If a user has a certificate in a certain form, it would >> be nice for that to Just Work=E2=84=A2 across all well-behaved applicati= ons. >> >> In practice, nothing could be further from the truth. >> >> Applications *all* suck, and various certificates will spuriously fail >> to work in one application but not another. Or work if the application >> is build against crypto library $A but not when built against crypto >> library $B. Or for objects in PKCS#11 each application might require a >> *different* identifier string to locate the same object. If they >> support PKCS#11 at all. >> >> I'd like to fix that. I would like to achieve a consensus that a "well- >> behaved application" SHOULD accept certificates and keys in various >> (TBD) file formats and also accept PKCS#11 URIs according to RFC7512. >> >> I have slowly been working on this. I have encouraged the Fedora >> distribution of Linux to amend their packaging guidelines to state that >> software packaged for Fedora SHOULD accept a PKCS#11 URI wherever it >> would accept a filename. And that software SHOULD load the PKCS#11 >> tokens which are indicated by the system configuration. >> >> We have already fixed various applications to comply with these >> requirements, and I even mentored a Google Summer of Code project which >> added RFC7512 support to NSS=C2=B2. >> >> I believe the Fedora packaging guidelines have been a success, and I >> would like to expand the scope. There's no *reason* this should be >> Fedora-specific, or even specific to Linux or POSIX operating systems. >> So I'm looking for a forum in which to reach a consensus on what should >> be accepted, and to publish those guidelines. I'd be very interested in >> hearing suggestions. >> >> >> Simultaneously, I'm also looking at expanding the technical scope. >> For my own project, the OpenConnect VPN client, I have started to >> collect a torture test suite=C2=B3 of RSA, DSA and EC keys in various >> PKCS#1, PKCS#8 and PKCS#12 forms =E2=80=94 both unencrypted, and encrypt= ed with >> various algorithms. I have yet to embark of the joy of files with non- >> ASCII passphrases, especially in non-UTF8 locales =E2=80=94 but I have a= bottle >> of vodka ready to help me do so. >> >> My test suite also includes PKCS#11 tests including private keys where >> the token doesn't expose the public component (which made OpenSSL crash >> until yesterday, yay!) and certificates with the CKA_PRIVATE attribute >> set, so some software will fail to *find* them. >> >> I am thinking of splitting my torture test out from OpenConnect itself, >> and making it available as a project in its own right. >> >> I can, of course, lobby to expand the Fedora guidelines to state that >> all software packaged for Fedora SHOULD pass the torture test suite, >> but I think it makes sense to aim for a wider consensus than that. >> >> Opinions welcome... does it make sense to attempt to publish an >> informational RFC outlining such "expectations"? Or should it take some >> other form? Or should I just not bother, and continue to push it from >> the Fedora angle, since it's getting into a lot of upstream software >> already? >> >> I also expect some heckling at my specific test cases =E2=80=94 do we *r= eally* >> expect everyone to support DSA keys still? And PEM files encrypted the >> old OpenSSL way? And PKCS#12 files encrypted with MD5-DES? >> >> (I can accept 'no' answers to the latter two only if expressed in a >> form which lets me file bugs against ancient "enterprise" software to >> stop *creating* them that way...) >> >> -- >> dwmw2 >> >> =C2=B9 https://fedoraproject.org/wiki/Packaging:SSLCertificateHandling >> =C2=B2 https://bugzil.la/1162897 >> =C2=B3 >> http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makef= ile.am >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. --001a11425eec6151c1053ce0d75a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Sep 19, 2016 at 4:26 AM, Ted Lemon <mellon@fugue.com> wrote:
> The effort is certainly worth doing. I've encountered the same pro= blem,
> and also find it frustrating. It might be worth writing an information= al
> doc; the challenge would be socializing it to the people who need to r= ead
> it.

The first problem is that there isn't an easy library to= integrate that will handle this. If it's a five minute fix that's = very different from a long development process. And no, adding better suppo= rt to NSS doesn't count: NSS has no documentation, as well as missing s= ome important security features. (NSS diffie-hellman ephemeral keys don'= ;t rotate for instance).

If you want applications to use tokens you need to make doin= g so a solution, not a problem. Standards can help, but they have also mass= ively hurt.

>
> On Mon, Sep 19, 2016 at 6:23 AM, David Woodhouse <dwmw2@infradead.org>
> wrote:
>>
>> (I hope the cross-post is acceptable; apologies if not.)
>>
>> Various applications will optionally make use of X.509 certificate= s for
>> client authentication.
>>
>> Those certificates, and the associated private keys, may be found = in
>> files on the file system, in PKCS#11 tokens, or in another
>> OS-specific form of certificate database.
>>
>> In my opinion, it would be nice to have some consistency between >> applications. If a user has a certificate in a certain form, it wo= uld
>> be nice for that to Just Work=E2=84=A2 across all well-behaved app= lications.
>>
>> In practice, nothing could be further from the truth.
>>
>> Applications *all* suck, and various certificates will spuriously = fail
>> to work in one application but not another. Or work if the applica= tion
>> is build against crypto library $A but not when built against cryp= to
>> library $B. Or for objects in PKCS#11 each application might requi= re a
>> *different* identifier string to locate the same object. If they >> support PKCS#11 at all.
>>
>> I'd like to fix that. I would like to achieve a consensus that= a "well-
>> behaved application" SHOULD accept certificates and keys in v= arious
>> (TBD) file formats and also accept PKCS#11 URIs according to RFC75= 12.
>>
>> I have slowly been working on this. I have encouraged the Fedora >> distribution of Linux to amend their packaging guidelines to state= that
>> software packaged for Fedora SHOULD accept a PKCS#11 URI wherever = it
>> would accept a filename. And that software SHOULD load the PKCS#11=
>> tokens which are indicated by the system configuration.
>>
>> We have already fixed various applications to comply with these >> requirements, and I even mentored a Google Summer of Code project = which
>> added RFC7512 support to NSS=C2=B2.
>>
>> I believe the Fedora packaging guidelines have been a success, and= I
>> would like to expand the scope. There's no *reason* this shoul= d be
>> Fedora-specific, or even specific to Linux or POSIX operating syst= ems.
>> So I'm looking for a forum in which to reach a consensus on wh= at should
>> be accepted, and to publish those guidelines. I'd be very inte= rested in
>> hearing suggestions.
>>
>>
>> Simultaneously, I'm also looking at expanding the technical sc= ope.
>> For my own project, the OpenConnect VPN client, I have started to<= br> >> collect a torture test suite=C2=B3 of RSA, DSA and EC keys in vari= ous
>> PKCS#1, PKCS#8 and PKCS#12 forms =E2=80=94 both unencrypted, and e= ncrypted with
>> various algorithms. I have yet to embark of the joy of files with = non-
>> ASCII passphrases, especially in non-UTF8 locales =E2=80=94 but I = have a bottle
>> of vodka ready to help me do so.
>>
>> My test suite also includes PKCS#11 tests including private keys w= here
>> the token doesn't expose the public component (which made Open= SSL crash
>> until yesterday, yay!) and certificates with the CKA_PRIVATE attri= bute
>> set, so some software will fail to *find* them.
>>
>> I am thinking of splitting my torture test out from OpenConnect it= self,
>> and making it available as a project in its own right.
>>
>> I can, of course, lobby to expand the Fedora guidelines to state t= hat
>> all software packaged for Fedora SHOULD pass the torture test suit= e,
>> but I think it makes sense to aim for a wider consensus than that.=
>>
>> Opinions welcome... does it make sense to attempt to publish an >> informational RFC outlining such "expectations"? Or shou= ld it take some
>> other form? Or should I just not bother, and continue to push it f= rom
>> the Fedora angle, since it's getting into a lot of upstream so= ftware
>> already?
>>
>> I also expect some heckling at my specific test cases =E2=80=94 do= we *really*
>> expect everyone to support DSA keys still? And PEM files encrypted= the
>> old OpenSSL way? And PKCS#12 files encrypted with MD5-DES?
>>
>> (I can accept 'no' answers to the latter two only if expre= ssed in a
>> form which lets me file bugs against ancient "enterprise"= ; software to
>> stop *creating* them that way...)
>>
>> --
>> dwmw2
>>
>> =C2=B9 https://fedoraproject.org/wiki/Packaging:SSLCertificateHan= dling
>> =C2=B2 https://bugzil.la/116= 2897
>> =C2=B3
>> http://git.infradead.org/users/dwmw2/openconnec= t.git/blob/HEAD:/tests/Makefile.am
>>
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www= .ietf.org/mailman/listinfo/saag
>>
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.iet= f.org/mailman/listinfo/saag
>

--
"Man is born free, but everywhere he is in chains".
--Rousseau.

--001a11425eec6151c1053ce0d75a-- From nobody Mon Sep 19 12:28:14 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16DD12B0AF; Mon, 19 Sep 2016 12:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no 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 7OwiAqxLJa1X; Mon, 19 Sep 2016 12:28:08 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 B994812B04B; Mon, 19 Sep 2016 12:28:08 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bm4EZ-0006wF-Nd; Mon, 19 Sep 2016 19:28:08 +0000 Message-ID: <1474313284.144982.367.camel@infradead.org> From: David Woodhouse To: Phillip Hallam-Baker Date: Mon, 19 Sep 2016 20:28:04 +0100 In-Reply-To: References: <1474280601.144982.263.camel@infradead.org> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-l4imTMt6nNn2bR7NhCXb" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: spasm@ietf.org, "saag@ietf.org" Subject: Re: [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 19:28:11 -0000 --=-l4imTMt6nNn2bR7NhCXb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2016-09-19 at 12:35 -0400, Phillip Hallam-Baker wrote: > This is a very common problem and one that I encounter on an hourly > basis as I write code for the Mesh. There are three separate formats > used for public keys in SSH and four for private. >=20 > This is all stuff that has dropped off the table as far as the > standards groups are concerned because 'it isn't protocol that goes > on the wire'. Except of course it does. >=20 > The way I think we have to approach a solution=C2=A0is to use a container > of some type whether that is MIME or JSON that has a slot for > metadata describing the content type to follow: Hm... the problem is that there exists a plethora of different file formats, and applications are massively inconsistent about which ones they support. Your proposed solution is to add a new file format to the mix? That is... not entirely what I had in mind. :) I suppose it *would* improve consistency, in an unhelpful kind of a way... it would give a new format that all existing applications would *consistently* fail to support, --=20 dwmw2 --=-l4imTMt6nNn2bR7NhCXb Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTE5MTkyODA0WjAvBgkqhkiG9w0BCQQxIgQgj1CutSB8UpwB+wSg3ZKii7ENCZM+9mKdnumz M4CKzZ8wgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAD3P tfQ80lsAHlIY3Xvl5Poj9ESosINiU4e8juXrIl0kZxT1ks869aI2IIhvaWRLzP5cewgFU5ctHNkF Y3mhRJE9LiS6KUNqLobNCOlLH17zp6KoPDmEq7jqVM2lOSf4e3xu0+pi0cjf/StTyEWNfWwJW7XX Zm78jq1Stz93m65rDHXNOM5jSqx6WH2o0W82fQ/7Ny09sZdNhbhNMEb8qifgBGPD1AP4AmHvgysy BP+STsWWEvw+n0lufLGF87LfqzAkDTC+vxyhiKlAZZjMHs6AvX/tAMAMY7P/aPYSLNS7Nn3EfdNc BBY02a8uAsjyXv9oSVrM85aKoqSKcUoWAoa/U20eEf2waHEN7JwXn8K+8ivjqTAp1xYwarqugHiz nPhYLBmx5vnqLYrmfr5nE+7LSRMx+GEFWPVwfNQhg16jW1RBChejyEE3zvgdKGPsy6fxeCXzrPrH uzLC2nYsw2XXPt+V1U/Jh11KLzTmZ1mkBJ2AhgY795avGL6BIOwuQYT0+vf34HA4cWCyaXbn7agf yn58ZXFAzNfOiNCO4B18e6swVUx8/sBp5CVwAi5hWU7wB9X8WxpBapjPfhvhkj59xPIlXUaO6gJz qQMvSW8S4YxiCT3K2V1la2//Uj+VYSdSiX+gEbeXATQhG0q7OAazGBTItxx4cOBOr1Nj1jOpAAAA AAAA --=-l4imTMt6nNn2bR7NhCXb-- From nobody Mon Sep 19 12:56:51 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB78E12B532; Mon, 19 Sep 2016 12:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no 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 5tpLuDI99Wel; Mon, 19 Sep 2016 12:56:40 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 5109412B531; Mon, 19 Sep 2016 12:56:40 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bm4gA-0002Gh-Uj; Mon, 19 Sep 2016 19:56:39 +0000 Message-ID: <1474314996.144982.391.camel@infradead.org> From: David Woodhouse To: Watson Ladd , Ted Lemon Date: Mon, 19 Sep 2016 20:56:36 +0100 In-Reply-To: References: <1474280601.144982.263.camel@infradead.org> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-uhxd37pAYUpMOTWuI+ap" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: spasm@ietf.org, Security Area Advisory Group Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 19:56:46 -0000 --=-uhxd37pAYUpMOTWuI+ap Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2016-09-19 at 11:54 -0700, Watson Ladd wrote: > On Mon, Sep 19, 2016 at 4:26 AM, Ted Lemon wrote: > > The effort is certainly worth doing. I've encountered the same problem, > > and also find it frustrating. It might be worth writing an informationa= l > > doc; the challenge would be socializing it to the people who need to re= ad > > it. > > The first problem is that there isn't an easy library to integrate > that will handle this. If it's a five minute fix that's very > different from a long development process. I'll restate that differently: the problem is that *all* the crypto libraries go out of their way to make it *hard* for applications to do this correctly. I have *pondered* splitting out my file-handling code from OpenConnect into a BSD-licensed library. That does handle the task of working out what type of file it's dealing with, and tickling the crypto library (well, OpenSSL or GnuTLS) in precisely the right way to load it. On the whole though, I'd rather just fix the libraries so that the application doesn't *need* to do that kind of nonsense. > And no, adding better support to NSS doesn't count: NSS has no > documentation, as well as missing some important security features. > (NSS diffie-hellman ephemeral keys don't rotate for instance). Sure, there are *lots* of things to be fixed. Fixing NSS to use PKCS#11 URIs addresses only part of the problem. Using *files* from NSS is also a complete pain in the posterior. There exists nss-pem but it's baroque and supports only a tiny set of file formats. > If you want applications to use tokens you need to make doing so a > solution, not a problem. Standards can help, but they have also > massively hurt. When you say 'tokens' you're talking about PKCS#11? That part is actually relatively easy, at least for the crypto libraries I've been looking at. NSS is mostly resolved; there's the question of loading the system-configured PKCS#11 providers but we have a way forward and patches filed for that too:=C2=A0https://bugzil.la/1296263 GnuTLS has worked for as long as I can remember =E2=80=94 you just pass it = a PKCS#11 URI in place of a filename and it Just Works=E2=84=A2. And I've fix= ed up its file support in places too, for example by adding support for the OpenSSL encrypted PEM files. For OpenSSL there is engine_pkcs11, which I've recently fixed so it is loaded simply with ENGINE_by_id("pkcs11") and takes PKCS#11 URIs to load keys and certs. Longer-term, there are moves afoot to integrate PKCS#11 support directly into OpenSSL. Other crypto libraries exist, of course, but not so much on platforms where PKCS#11 is prevalent. But that's just me tilting at windmills on my own. The point of reaching out in this forum is to try to reach a consensus on what we should expect from applications, and maybe even get others to help :) --=20 David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation --=-uhxd37pAYUpMOTWuI+ap Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTE5MTk1NjM2WjAvBgkqhkiG9w0BCQQxIgQgs4v+NGkYRRrm7gw+LbOXKgohcp03eUqSyDd0 rd96W1wwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICALo5 UyAh9m83Ub35t4kMpQdWtBTZFrsIxEO10BjlNER47SzKJUdGB9/mQI/C3WwIEN5lgz4mQ60C2L02 D7dIDJApI1na79vvJFxEmPnyGBAnqNe5SomVfVQqx/uWlJDqYtZM+bsKNKCjekc/N6Lzy2uvfXhk phYM+3ksKSF5HZsIZD4fOMbKifYWhqtQhM6hz9XE/KShbXnrRKminL6wK16Ad0seOESVqDCZqu/F R7M4ks82OgkjRYIU7z/FiMbUxD04r8/KU+DY8ZfNmxw8e0TM9DX1lrsqrDfxrSYUa0WkKhDE1eqr i0whexLY6/FaqUplJm+W+va5o/3f4k5aQBgmyDRqIorFpxLft0ii2CdLCTsWEg2yYlU2ix/D/zKb +9BO5DbeafjEGclBHupRr3YYlpr4rxi6bAbtIrID+BIM5i5buAqDvLob7rOwvi74L3HLRI3I81ze 5qqVqEEW2EdMXe+/Pw5sDXBgKGlwUVV4FTd5DRPYmxZdwEbQEG1p1N0JbtgshNp0mi09YsXuAXNn 2XCeBqeoboJ5Gt4qUeTp7CNtqIdn2n0J8TnuUQmduv4V2oB/EWsITJTzmzKriycm/iA3mtF9gXX4 tJLHyMJngGhQwEz67Cat3XMlqbPIGcENedyfC+QkrPsXcViO83VuEGOZSjeKdtW13O4q1XboAAAA AAAA --=-uhxd37pAYUpMOTWuI+ap-- From nobody Tue Sep 20 08:11:01 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2528212B6DB; Tue, 20 Sep 2016 08:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 rjLCdw9YMDAR; Tue, 20 Sep 2016 08:10:47 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3843D12B3CE; Tue, 20 Sep 2016 07:49:32 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 373402009E; Tue, 20 Sep 2016 11:02:31 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 30B726392C; Tue, 20 Sep 2016 10:49:31 -0400 (EDT) From: Michael Richardson To: David Woodhouse In-Reply-To: <1474314996.144982.391.camel@infradead.org> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: spasm@ietf.org, Watson Ladd , Ted Lemon , Security Area Advisory Group Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 15:10:52 -0000 --=-=-= Content-Type: text/plain David Woodhouse wrote: >> And no, adding better support to NSS doesn't count: NSS has no >> documentation, as well as missing some important security features. >> (NSS diffie-hellman ephemeral keys don't rotate for instance). > Sure, there are *lots* of things to be fixed. > Fixing NSS to use PKCS#11 URIs addresses only part of the problem. > Using *files* from NSS is also a complete pain in the posterior. There > exists nss-pem but it's baroque and supports only a tiny set of file > formats. NSS seems hostile to having private keys loaded. It expects to manage all of that, and for partly good reasons: the private key may be in a module or something. But the result is that you basically can't write regression tests for NSS. At least that's my experience. > But that's just me tilting at windmills on my own. The point of > reaching out in this forum is to try to reach a consensus on what we > should expect from applications, and maybe even get others to help :) I expect applications to: a) be runable without a system resource. so: b) they can be tested without an install. so: c) I can run the executable from the source directory. It's great if applications, once installed, can be told about system wide keys and the like, and we can arrange to share things appropriately, but too often the system-wide stuff has gotten in the way of actually making things work. Frankly, it's why SSH took off in the 1990s, while ssltelnet and ktelnet failed: minimal to no infrastructure. Building scalable systems doesn't mean building them for 1,000,000 people, it means building them for a range, ideally down to 1. I think that the major problem with X.509 client certificates is that many applications and protocols don't know if 509 is being used as a container for a self-signed certificate, for poorly(privately) signed certificate, a corporate CA, or a webCA. That's where PHB's suggestion of a new meta-format would win. (It means that we could eventually not have the keys in X.509 format.) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV+FMd4CLcPvd0N1lAQKP0wf9FiyBzL1h1njdHio791Ng1pgQW6EM3Ckb QXrS01L8LBdYBRUnstsFFJeFAwmec0oG1cgW1GNV4jd+V4NL/+tqV02O73MTTjIb tx3zasQJHJBRBJmtpjIIDbPLlPpS84N8sp+CpaWJEZjA+PTYT1S8BkpCswgoyf/f YYD+rR071H1HX4EuxdXQG+3fJ3vhgxbHOX5FcW9H1jk3J+hKtEqXFYhQ1MWehC0D kQGnTO12JV6sRddPqmjNLG2z9L0gAxv8Y30otuQv/B4319O4RPVDfKFk7nkUTghk FmtjlUsY+v3aueWRp1Z3Wig1rTbwCJOSgq1BNHpxt1bHpshR6IxyMg== =4kWt -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 20 08:43:28 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F3512B348; Tue, 20 Sep 2016 08:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 hQylzhE45eLx; Tue, 20 Sep 2016 08:43:16 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 310C212B6DB; Tue, 20 Sep 2016 08:43:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 730CA1EF7; Tue, 20 Sep 2016 15:43:03 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJWr1W-QVSLK; Tue, 20 Sep 2016 15:43:03 +0000 (UTC) Received: from [192.168.100.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id CF2061B5B; Tue, 20 Sep 2016 15:43:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <22611.1474382971@obiwan.sandelman.ca> Date: Tue, 20 Sep 2016 11:43:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: spasm@ietf.org, David Woodhouse , Security Area Advisory Group Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 15:43:19 -0000 On Sep 20, 2016, at 10:49 AM, Michael Richardson = wrote: > I think that the major problem with X.509 client certificates is that = many > applications and protocols don't know if 509 is being used as a = container for > a self-signed certificate, for poorly(privately) signed certificate, a > corporate CA, or a webCA. >=20 > That's where PHB's suggestion of a new meta-format would win. > (It means that we could eventually not have the keys in X.509 format.) This proposal may be applicable: https://tools.ietf.org/html/draft-winter-opsec-netconfig-metadata-00 Alan DeKok. From BATV+228e0feef8add010b485+4776+infradead.org+dwmw2@bombadil.srs.infradead.org Tue Sep 20 08:57:54 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CC612B2A4; Tue, 20 Sep 2016 08:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no 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 3vXWFSzrt76q; Tue, 20 Sep 2016 08:57:52 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 1DA9112B108; Tue, 20 Sep 2016 08:57:52 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bmNQb-0007XA-5b; Tue, 20 Sep 2016 15:57:49 +0000 Message-ID: <1474387066.144982.443.camel@infradead.org> From: David Woodhouse To: Michael Richardson Date: Tue, 20 Sep 2016 16:57:46 +0100 In-Reply-To: <22611.1474382971@obiwan.sandelman.ca> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-RbuX5Hubs30PKsN5anTK" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: spasm@ietf.org, Watson Ladd , Ted Lemon , Security Area Advisory Group Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 16:07:02 -0000 --=-RbuX5Hubs30PKsN5anTK Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2016-09-20 at 10:49 -0400, Michael Richardson wrote: > I expect applications to: > a) be runable without a system resource. > so: > b) they can be tested without an install. > so: > c) I can run the executable from the source directory. Yes, all of these are good practice. They are orthogonal to what I'm trying to achieve, but certainly I wouldn't do anything to *discourage* the above. > It's great if applications, once installed, can be told about system wide > keys and the like, and we can arrange to share things appropriately, but = too > often the system-wide stuff has gotten in the way of actually making thin= gs > work. Frankly, it's why SSH took off in the 1990s, while ssltelnet and > ktelnet failed: minimal to no infrastructure. I think that's orthogonal to my purpose here too. You're talking about the infrastructure on the server side, used to determine which client keys to trust. What I'm talking about here is *clients* finding the keys to use. For X.509 certificates and keys, applications need to be able to support various file formats *and* should support using objects from a system-specific central store *if* such exists on the platform. Starting with just the files... take a look at the test cases in http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makef= ile.am There are various PKCS#1, PKCS#8, PKCS#12 files in various PEM and DER permutations with a selection of weak and strong encryption types (and lack of encryption). I know of NOT A SINGLE APPLICATION which will Just Work=E2=84=A2 for every = one of those test cases. And looking beyond files: if I go and purchase a hardware crypto device lik= e a Yubikey, and plug it into my system. I install the OpenSC package which= has a PKCS#11 provider module for it, and provision a key in it.... now, h= ow do I use it? The answer should be simple. I determine a RFC7512 identifier for the key I= want to use (e.g. 'pkcs11:manufacturer=3Dpiv_II;id=3D%01') and then every = application in the system SHOULD just accept that identifier in place of a = filename. That is the scope of what I'm trying to do here =E2=80=94 nothing more. Jus= t making client applications consistent in what forms of key they accept, a= nd how the user identifies them. Note that I don't need to *install* my client application for the system ce= rtificate support to work. I can run it from its build directory and using = "-c 'pkcs11:manufacturer=3Dpiv_II;id=3D%01'" should still work. My test cas= es jump through hoops to use a SoftHSM token for testing, with its storage = database actually kept in the git repository. But that's just for testing. --=C2=A0 dwmw2 --=-RbuX5Hubs30PKsN5anTK Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIwMTU1NzQ2WjAvBgkqhkiG9w0BCQQxIgQgt1EhhCjsh4O8B5KvWH5gwcS5OSy7UOreeFHp GfrDgtUwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAAC6 GFoNBPi4QL5R4hlCmyjIe/ed2UpDML26SIQeH+bjqZZIz021v8szfpzUOzsZm8w41LkBBzQfU4p2 05S3OVrTJ46IVkKe74Kc/Nd3yommbKtI7Nl24GAmMs2IUIkY7FTL+QYMnffaptw08CRSIY7uTrIU o2/9clzrv/BjQ3A4XmdOwNb7cZV7YmOFIEUPHFTSTktUH/V4rrHbhdFYDJ+89ZFcQFBSYdrdsqP0 BGOO65SYYNbCfFCbzncoDo1dQGTg7QUgrM70Ma1RoRmo1e+ZlHg9uWite+dCFLBws3VcrNKzVdsH +MJFOpfwXhktb1MS0OBDlTEM0g6X+kclvs0MnZFXaij8uply/fQaSSuTIsFj+RKCn10Ka20ZkN8M LLj5itZBwKtFfxuJGbglJAmkC49gQQHX/L4NnFSDzE72Eomkr1tZBfJlUy0SGD3YrK+L1CC1GRSG /oMFVpBxG2q5k3Q+ktwFBolqgaA+flnwVlVGx4yCA1uG45FVcD0xruXbehWoouQJvys4nOioC4DV sj4g2wo0WYk6klM3UsbCmqSw0kGE8Utq/8fz1/XPUZ2tzlPVXsWOoyj7zQ5We7w3nHNqN+tOb74y YVHYffrJRuNWprEmAObtwf2eQqoIGeLyJ6EfoF8EZ5hbfen4EQHTwmaLypB3OEormSx8iulkAAAA AAAA --=-RbuX5Hubs30PKsN5anTK-- From BATV+228e0feef8add010b485+4776+infradead.org+dwmw2@bombadil.srs.infradead.org Tue Sep 20 09:06:48 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E485D12B3BC; Tue, 20 Sep 2016 09:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no 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 j8x09RWKB-1E; Tue, 20 Sep 2016 09:06:44 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 74E4C12B377; Tue, 20 Sep 2016 09:06:44 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bmNZA-00043E-RF; Tue, 20 Sep 2016 16:06:41 +0000 Message-ID: <1474387598.144982.452.camel@infradead.org> From: David Woodhouse To: Alan DeKok , Michael Richardson Date: Tue, 20 Sep 2016 17:06:38 +0100 In-Reply-To: References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-YwJ/lnlnSFahAHrz2F0m" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: spasm@ietf.org, Security Area Advisory Group Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 16:08:08 -0000 --=-YwJ/lnlnSFahAHrz2F0m Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2016-09-20 at 11:43 -0400, Alan DeKok wrote: > On Sep 20, 2016, at 10:49 AM, Michael Richardson = wrote: > >=20 > > I think that the major problem with X.509 client certificates is that m= any > > applications and protocols don't know if 509 is being used as a contain= er for > > a self-signed certificate, for poorly(privately) signed certificate, a > > corporate CA, or a webCA. > >=20 > > That's where PHB's suggestion of a new meta-format would win. > > (It means that we could eventually not have the keys in X.509 format.) >=20 > This proposal may be applicable: >=20 > https://tools.ietf.org/html/draft-winter-opsec-netconfig-metadata-00 That looks like a layer above what I'm talking about. My goal is that we should be able to refer to certificates in a simple consistent way. If the certificate is in a system store then applications should allow it to be used by means of a consistent identifier string (which is defined by RFC7512 for PKCS#11, and may be different for OSX/Windows system certificate stores). If the certificate is in a file, obviously the identifier is the filename... but we need to fix applications so that they actually *accept* all types of files. Which as I said, none of them do at the moment. Looking at the proposal above, I see there is some attempt to handle certificate encodings =E2=80=94 it the CertEncodingEnum has values of PEM, = DER, and P12. This looks a lot like the problematic applications we need to fix... for PKCS#1 and PKCS#8 you have to manually specify whether it's PEM or DER file even though the software could work that out for itself. And for PKCS#12 you *don't* have to specify; it's going to assume DER. All very suboptimal. My assertion is that applications shouldn't *need* that nonsense, and should just take the filename and deal with the contents. Please don't entrench that horridness further. It also seems that the proposal you reference doesn't have any kind of support for using keys from hardware. If the key I want to use is identified by an RFC7512 PKCS#11 URI, how do I indicate *that* in this format? --=20 dwmw2 --=-YwJ/lnlnSFahAHrz2F0m Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIwMTYwNjM4WjAvBgkqhkiG9w0BCQQxIgQg2slSW4SZHYgpGahGEdoveEdVMimaHN9eziV7 q1XFG74wgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAID9 4QpxFM6aiVEq5bkC/Ifp5K3VrlepyyijbxTiHJ/xdOAeWHpUbASklC9xV6vxIqg+/upxlf9DNX+d A86ySGVIR5J2Z3dtm4AGYCy8kehuKpLw0dZI242LAR8+9gBgU7IYS2NUVR14kBcWKKRGhP03DRMa Esaz/sTSsqTjAawXxz8YUYGVCWR6VLu3ENmcbGlB++0YcCV7Zij2izJ7UBNiEi68SiInjbr80Evg sPoCAG4+U1WHTxS55bIGDzcDqPAdHXjVGE0Unu2NktWNLpHrfPDJJ9GucRePkNp2ul1bos9CXsCs QKTyNMr4H7QQqEPAigI0H62NxUzzjReh19FiCp2Jriq7XXcG5NoxocHH4g/HiBQdNfeFhcC92uO8 ZekZnglUua9a5uWG4N8a/dOHYKDj2iwOPVN5A4A218GLzhCmhO3v+zjP1+nOwu5KorpeaMCqn0Vw yib+6IO54POP11/CuquyML+HZfUSPpuTqPCklomTx4mCgohS+kJLf5UDPUnXOLLKV1YI3xACvtoR ouSvyUIBGC/sJaYzGJsa21aY/A9GzCCZaMbQQmy6Jmdx5BnR0cK2DM//TXYO3VnYnWNXA3WG8V9I 2/CI9QTuCTy9IDCXcOhlQ/yQtTpdeDETLl9MkGJX8yM6tEgq7LNfI3eskpMHgSGhtG9XYVkVAAAA AAAA --=-YwJ/lnlnSFahAHrz2F0m-- From nobody Tue Sep 20 09:36:08 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB5512B3A2; Tue, 20 Sep 2016 09:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 TUdPoaYH_Ope; Tue, 20 Sep 2016 09:36:01 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1D03012B0E9; Tue, 20 Sep 2016 09:36:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 70D341EF7; Tue, 20 Sep 2016 16:36:00 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOjVjW8pOs3z; Tue, 20 Sep 2016 16:36:00 +0000 (UTC) Received: from [192.168.100.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id BADC31704; Tue, 20 Sep 2016 16:35:59 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <1474387598.144982.452.camel@infradead.org> Date: Tue, 20 Sep 2016 12:36:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <11F16CFE-3554-4F07-811A-8F5D4BE3A6AE@deployingradius.com> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387598.144982.452.camel@infradead.org> To: David Woodhouse X-Mailer: Apple Mail (2.3124) Archived-At: Cc: spasm@ietf.org, Michael Richardson , Security Area Advisory Group , Winter Stefan Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 16:36:03 -0000 On Sep 20, 2016, at 12:06 PM, David Woodhouse = wrote: >> https://tools.ietf.org/html/draft-winter-opsec-netconfig-metadata-00 >=20 > That looks like a layer above what I'm talking about. My goal is that > we should be able to refer to certificates in a simple consistent way. >=20 > If the certificate is in a system store then applications should allow > it to be used by means of a consistent identifier string (which is > defined by RFC7512 for PKCS#11, and may be different for OSX/Windows > system certificate stores). I think that the two solutions complement each other. > Looking at the proposal above, I see there is some attempt to handle > certificate encodings =E2=80=94 it the CertEncodingEnum has values of = PEM, DER, > and P12. >=20 > This looks a lot like the problematic applications we need to fix... > for PKCS#1 and PKCS#8 you have to manually specify whether it's PEM or > DER file even though the software could work that out for itself. And > for PKCS#12 you *don't* have to specify; it's going to assume DER. All > very suboptimal. I agree. > My assertion is that applications shouldn't *need* that nonsense, and > should just take the filename and deal with the contents. Please don't > entrench that horridness further. I understand, but... that's easier than scanning the file to see if = it's one of N possible unknown formats. And likely more secure. > It also seems that the proposal you reference doesn't have any kind of > support for using keys from hardware. If the key I want to use is > identified by an RFC7512 PKCS#11 URI, how do I indicate *that* in this > format? The proposal would need updating to handle that. Alan DeKok. From nobody Tue Sep 20 10:08:53 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC59812B413; Tue, 20 Sep 2016 10:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no 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 lRcpXRitZv1R; Tue, 20 Sep 2016 10:08:49 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 A2EDC12B407; Tue, 20 Sep 2016 10:08:47 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bmOXF-0005zD-No; Tue, 20 Sep 2016 17:08:46 +0000 Message-ID: <1474391322.144982.459.camel@infradead.org> From: David Woodhouse To: Alan DeKok Date: Tue, 20 Sep 2016 18:08:42 +0100 In-Reply-To: <11F16CFE-3554-4F07-811A-8F5D4BE3A6AE@deployingradius.com> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387598.144982.452.camel@infradead.org> <11F16CFE-3554-4F07-811A-8F5D4BE3A6AE@deployingradius.com> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-ASIsEMorymqZWp83s9cR" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: spasm@ietf.org, Michael Richardson , Security Area Advisory Group , Winter Stefan Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 17:08:51 -0000 --=-ASIsEMorymqZWp83s9cR Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2016-09-20 at 12:36 -0400, Alan DeKok wrote: >=20 > > My assertion is that applications shouldn't *need* that nonsense, and > > should just take the filename and deal with the contents. Please don't > > entrench that horridness further. >=20 > =C2=A0 I understand, but... that's=C2=A0easier than scanning the file to = see if > it's one of N possible unknown formats.=C2=A0 And likely more secure. Easier for whom? Not for the user, certainly. Users should be able to ask applications just to use a certificate/key from a given file, without worrying about the minutiae of what's inside it. Besides, it's not like it's hard to tell the difference between PEM and DER files. And if you're already accepting "DER" as a filetype, that covers all manner of stuff including PKCS#8, PKCS#1 and the various unencrypted forms of DSA and EC keys. It's not like recognising PKCS#12 in that code path is particularly difficult *either*, if you were doing it properly. Which, as I noted, no application does. > > It also seems that the proposal you reference doesn't have any kind of > > support for using keys from hardware. If the key I want to use is > > identified by an RFC7512 PKCS#11 URI, how do I indicate *that* in this > > format? >=20 > =C2=A0 The proposal would need updating to handle that. Yes. Yes, it does :) --=20 dwmw2 --=-ASIsEMorymqZWp83s9cR Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIwMTcwODQyWjAvBgkqhkiG9w0BCQQxIgQg2anFHKINopEydtqh1K2d4OJXURP64i08sy90 bQu+xtwwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAJZv kfxvjSeMC9U2HysoMQ6CeH+uNf7mlr8n22zoAd5HkGH7CoI4B2Xf86xERUeartKPZ/so6jPYpVdv DsjDQVqaNphcUaw0dDJQunvSxiwCJy963YfGDYqKm2u/9p0etM/I4O7D1J8GpC0uLHo54CMjNI4N iyGEXTODdbLP10+xtK08srpxfa/aa7ZwPKSX0lcCW8xgXWyXFC9L9PcVhLQd153v5As+CQt2gZF4 y5gSPoIOjvAeVrbSEK5cfltLGC+wwgLA6OSCv+p8HNGQzWnEZui7m2Hu+VBimq2QWIlXd/tIX8/A S+CMnBosPffGp3ADHZ0fT2cTXxH3q2Yzr4w46AwmhC9uV6qSEti0548ZYjuT7GdYP1RdT5hoCwHI 41tFR1xOKWwUfevK8S5spQ23atq5EjvD358SfItudEIYBom1KNrbaEkR19ZEBQatPpdZKJ7oaIRT 7a4vCE1pxwdASbYsawcULSjb8KW70LE0KdYkwTirMyRG4P7lboa4elhH4bccoqjjL2OejAxy7cxp Zz04sMMqWBJnVYUZ7ryIYUB4AFiimnS7gjwdJHTPzt7bmAcZTk8BlvL/qT7s4sPYMwbwShPOouQq KgZR/fKxWO3EecgoCe2e/GIA0GNmbMoCoMfwCpBwHUKBA2p1iEHz7vmK72dp/y2o3oiFlK42AAAA AAAA --=-ASIsEMorymqZWp83s9cR-- From nobody Tue Sep 20 17:29:59 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C533012B4EE; Tue, 20 Sep 2016 17:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 hG8vFCB6PI8R; Tue, 20 Sep 2016 17:29:53 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E9B312B10D; Tue, 20 Sep 2016 17:29:53 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 46E36E1D3; Tue, 20 Sep 2016 20:42:53 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D5E036392C; Tue, 20 Sep 2016 20:29:51 -0400 (EDT) From: Michael Richardson To: David Woodhouse In-Reply-To: <1474387066.144982.443.camel@infradead.org> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: spasm@ietf.org, Watson Ladd , Ted Lemon , Security Area Advisory Group Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 00:29:55 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable David Woodhouse wrote: > And looking beyond files: if I go and purchase a hardware crypto devi= ce > like a Yubikey, and plug it into my system. I install the OpenSC > package which has a PKCS#11 provider module for it, and provision a k= ey > in it.... now, how do I use it? > The answer should be simple. I determine a RFC7512 identifier for the > key I want to use (e.g. 'pkcs11:manufacturer=3Dpiv_II;id=3D%01') and = then > every application in the system SHOULD just accept that identifier in > place of a filename. yes, that would be great. Maybe we need to register the pkcs11: URI, such that we can then say it's a URI, and file:// would also naturally work. > That is the scope of what I'm trying to do here =E2=80=94 nothing mor= e. Just > making client applications consistent in what forms of key they accep= t, > and how the user identifies them. +10. > Note that I don't need to *install* my client application for the > system certificate support to work. I can run it from its build > directory and using "-c 'pkcs11:manufacturer=3Dpiv_II;id=3D%01'" shou= ld > still work. My test cases jump through hoops to use a SoftHSM token f= or > testing, with its storage database actually kept in the git > repository. But that's just for testing. +100. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV+HUfYCLcPvd0N1lAQKcFwf7BdjeURrpTjzUjzJu7WMfUT4nBBaeLitr Roa2DuXQ+tgd1WjRPv8rioSTNuKTOMHdUxSSl7BiNA+sKhhdxQM/9nZBrfeD1qte ghAYMMgUFWsHp4Z4+EW9OKnVBCdTAsvc/HNEdQDD5j2NA8hTMPn2gx42+TPiXW26 Y/hUrOzGw2fjxaTNZ1V2xhbwx+sHICjYZPLcntIVDXuL9+5tH1eA8RYMHNXktbs4 2AIADfHS8O3fPlm8S6OLz1ZRgwsQ2IEZAK/TI70ey1WLyixfThcE5kf4/zG4ltvL rRm4HR+3/zfQT+eiiDrHtVL3hfSg6aWhK3w/k3A2QnbHuVB95IA2Sg== =A5V0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Sep 21 08:12:04 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B24A12B4C1; Wed, 21 Sep 2016 08:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 99tCdmuXvHYz; Wed, 21 Sep 2016 08:11:55 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1ABE12B4BB; Wed, 21 Sep 2016 08:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1474470715; x=1506006715; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FTBE47BOlfPivYs+3hye3ISPynq0xFFnhMc4SD/v4CE=; b=xSk/lT+YP17uMFaswzvuGsVDwPVSvn2H9HBuqhVnx+xGRGmPltOPgN9X b4T8xNmaXO4dGObINkdFgfj3qIg5DPhFcTLq+IumRTne/vtKVjoBn9flR gqJZ7+Q2SfMMrbyA/fnuo5mShJQkq2Zb71x8Aq+40oKKHilnYQpOObrUX z7qYIyXfRIr/Py8Lt2/Br6KplwKkhw0au+iK2J/YcbhvcXJcSwAsL+nVw DswlwumtNxCNiHGftplUii90eHj5pPzIM7MKTvTmYykbKI2S773wLTN8G St9JpJwxjCWaZK60dyxtyQC7+pE3shXIW5te5UP9ZRMh7TTQvUlAPLm6e A==; X-IronPort-AV: E=Sophos;i="5.30,374,1470657600"; d="scan'208";a="106850386" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from uxcn13-tdc-d.uoa.auckland.ac.nz ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 Sep 2016 03:11:49 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 22 Sep 2016 03:11:49 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Thu, 22 Sep 2016 03:11:49 +1200 From: Peter Gutmann To: David Woodhouse , Michael Richardson Thread-Topic: [saag] [Spasm] Best practices for applications using X.509 client certificates Thread-Index: AQHSEq/5nIMxm+cmykaH/hYw9B3r/6CBrdmAgAATEQCAAk6N/w== Date: Wed, 21 Sep 2016 15:11:49 +0000 Message-ID: <1474470703731.18547@cs.auckland.ac.nz> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>, <1474387066.144982.443.camel@infradead.org> In-Reply-To: <1474387066.144982.443.camel@infradead.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spasm@ietf.org" , Security Area Advisory Group Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 15:11:58 -0000 David Woodhouse writes:=0A= =0A= >There are various PKCS#1, PKCS#8, PKCS#12 files in various PEM and DER=0A= >permutations with a selection of weak and strong encryption types (and lac= k=0A= >of encryption).=0A= >=0A= >I know of NOT A SINGLE APPLICATION which will Just Work=99 for every one o= f=0A= >those test cases.=0A= =0A= That's not surprising, you've barely scratched the surface of the mess of= =0A= what's out there for storing private keys, some of it completely undocument= ed,=0A= and yet you want some magic piece of code or app to be able to work with al= l=0A= of them. Not just that, but you're saying that you want Internet Explorer = to=0A= be able to grab GPG keys and OpenSSL to be able to grab Apple account keys = and=0A= Flash Player to be able to grab OpenSSH keys. Is that really what you're= =0A= after?=0A= =0A= Peter.= From nobody Wed Sep 21 14:58:04 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F15D12B461; Wed, 21 Sep 2016 14:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no 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 bwHsCqpKbgj3; Wed, 21 Sep 2016 14:58:02 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 1E73112B154; Wed, 21 Sep 2016 14:58:02 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:f69] (helo=shinybook.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bmpWf-0007KR-BK; Wed, 21 Sep 2016 21:57:57 +0000 Message-ID: <1474495074.30494.21.camel@infradead.org> From: David Woodhouse To: Peter Gutmann , Michael Richardson Date: Wed, 21 Sep 2016 22:57:54 +0100 In-Reply-To: <1474470703731.18547@cs.auckland.ac.nz> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> , <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-PGZyFu4LE/NvdHG5s9ka" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: "spasm@ietf.org" , Security Area Advisory Group Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 21:58:03 -0000 --=-PGZyFu4LE/NvdHG5s9ka Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2016-09-21 at 15:11 +0000, Peter Gutmann wrote: > David Woodhouse writes: >=20 > >There are various PKCS#1, PKCS#8, PKCS#12 files in various PEM and DER > >permutations with a selection of weak and strong encryption types (and l= ack > >of encryption). > > > >I know of NOT A SINGLE APPLICATION which will Just Work=E2=84=A2 for eve= ry one of > >those test cases. >=20 > That's not surprising, you've barely scratched the surface of the mess of > what's out there for storing private keys, some of it completely undocume= nted, > and yet you want some magic piece of code or app to be able to work with = all > of them.=C2=A0 Not just that, but you're saying that you want Internet Ex= plorer to > be able to grab GPG keys and OpenSSL to be able to grab Apple account key= s and > Flash Player to be able to grab OpenSSH keys.=C2=A0 Is that really what y= ou're > after? No, the scope here is limited to X.509 certificates and the associated keys, and the *common* formats for those keys. Using GPG and OpenSSH private keys is definitely a long way outside that scope. So let's assume I have a key in a given PEM or DER format file as issued through my employer's PKI infrastructure (and associated client- side provisioning tools. I also have a variety of client applications on my system (openconnect, openvpn, curl, wpa_supplicant, etc.) which can use certificates from files. I just want those applications to work consistently. I don't want them to support different subsets of the common file formats depending on which crypto library they happen to be built against this week, and how much attention their author was paying to such matters. There are a variety of forms which have been the *default* output of tools like OpenSSL over the years, and I've recently been finding some of those which are not accepted by certain client applications (and libraries). That's not acceptable. I don't want *every* possible format to be supported; just the common ones which people are *likely* to encounter in real life. And for hardware tokens... if my employer provided me with a hardware crypto token such as a Yubikey, and the OpenSC driver is installed correctly in my system, then I *really* want to be able to pass the RFC7512 identifier "pkcs11:manufacturer=3Dpiv_II;id=3D%01" to any of those applications and expect them to Just Work=E2=84=A2. That's actually a very reasonable request, I think. --=C2=A0 dwmw2 --=-PGZyFu4LE/NvdHG5s9ka Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIxMjE1NzU0WjAvBgkqhkiG9w0BCQQxIgQgEUfvPPvTDnGHdabTkTgpsgHgQRHDGF7YRnUx nFw6FiMwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAFFU ijFNtN6/yFrEXF4i05727guKZRu/xxNR3gGM215rmA+bKUYDAcMI/vKTmE3Jyx/A/vrDQdXcZoAo tBxVvzUtRbJRY/ltmIk7NYW9WHUoPaaMpPdeytWJqU/Pd07KbBByWQwbHw1bYLgKz89GWTQZhOFa se557mIcOdqklBSOse4QOhMTu0xw9wFxJXAyMqXOJ0a1XGuaXB2FXeP03OYQIQ3J5QBg1fysJ6i1 E2hfY3hCgPlfiEudlKQUCigwRLcP1OHq/skoPXXE+S2iHiARcRy3QhBMD/yA8WgAywpRv+6vbzlQ scK9rWa4Idzax7cfMgSwMrhMKmm90BTFRcpnRcn9oLNizz9rVhlOp4JpOI4iNol5USFXfossTBfM AlfRRGUGVqQGQeA2AGKJwfgEzmQT6NOtDXEHf9G+VAi/05cFDf7ozfGumvUlP1IuSzb6ctg7mANq agGV7EF3ETNua0r8aAM1ckUM61qcB+WkXiTvPTkfL96X2q/dhO2fYdeszVglFNRzKsKPnHFY05s3 88q9PPlN+iOFQQOWlIXgUs6QeYnYE3dSeMOSxlnH3BKiat2s62D2JFUQTlYUy3tqRIQ1rM294Q0y L7ZDSb02Xyv/BeqTbP9Fqoz4xYOHjZNFJhtHdjyy/QXNO9ppIeEo+DnNbPHBhhEzQaIGk9+zAAAA AAAA --=-PGZyFu4LE/NvdHG5s9ka-- From nobody Wed Sep 21 22:04:38 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDDC12B799; Wed, 21 Sep 2016 22:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 feIvbB43a9Mt; Wed, 21 Sep 2016 22:04:35 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6509812B679; Wed, 21 Sep 2016 22:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1474520674; x=1506056674; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YqiutOFUQoErx7eztKowvBX0/0vIdT2S07Zwi8L/egY=; b=EnakGBreG75UO/k+L/aKl+Qu0hmPQ0tFq2C1/OZb3P2fGbhViYOxpYxH Qlo4xpRvG1wJhs0ol4loyFMVgeVyFX1lqppC+62jG2NKePtscaY7tgo5E gTl4IE6FIr9VhQVISG/C/qiDZIm5t2zmMGF2DNeghQK5CyJie1MHHudhz NllObA8sIoBblMki6Zo4jud5QxmRbHHk1Mm8gfx0B+aFdalbesdiQQ0yF CmNscpoWro31zW2P1N4R+ZX6mc747/p7J2c0V08XuWWZwQZ0Xy51LQsfW 5Knw6DssDaTsL0FHvVFC1TgW4waccsBV2cLqJT02R+bRyIAl3M3wye+OL Q==; X-IronPort-AV: E=Sophos;i="5.30,377,1470657600"; d="scan'208";a="106970680" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from uxcn13-tdc-d.uoa.auckland.ac.nz ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 Sep 2016 17:04:32 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.25) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 22 Sep 2016 17:04:32 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Thu, 22 Sep 2016 17:04:32 +1200 From: Peter Gutmann To: David Woodhouse , Michael Richardson Thread-Topic: [Spasm] [saag] Best practices for applications using X.509 client certificates Thread-Index: AQHSFFM8/XRSMCovG0SGBgcgJhzHQaCE9KsU Date: Thu, 22 Sep 2016 05:04:31 +0000 Message-ID: <1474520671777.43424@cs.auckland.ac.nz> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> , <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz>, <1474495074.30494.21.camel@infradead.org> In-Reply-To: <1474495074.30494.21.camel@infradead.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spasm@ietf.org" , Security Area Advisory Group Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 05:04:36 -0000 David Woodhouse writes:=0A= =0A= >That's actually a very reasonable request, I think.=0A= =0A= I don't know about reasonableness (hey, possibly it is), but it's highly=0A= unlikely it'll ever be addressed. This situation has been with us for=0A= twenty years without much, if any, progress being made (you can go back=0A= two decades and find people complaining about the same thing). You just ha= ve =0A= to work around it... that kinda sucks, but then lots of life in general doe= s.=0A= =0A= Peter.=0A= From BATV+66c94379fcb09c76a7b5+4778+infradead.org+dwmw2@bombadil.srs.infradead.org Thu Sep 22 03:27:28 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92AC12BF33; Thu, 22 Sep 2016 03:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no 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 iDR91IpOlifV; Thu, 22 Sep 2016 03:27:27 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 0277A12BF32; Thu, 22 Sep 2016 03:27:27 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bn1Du-0001mT-2Y; Thu, 22 Sep 2016 10:27:22 +0000 Message-ID: <1474540039.45169.62.camel@infradead.org> From: David Woodhouse To: Peter Gutmann , Michael Richardson Date: Thu, 22 Sep 2016 11:27:19 +0100 In-Reply-To: <1474520671777.43424@cs.auckland.ac.nz> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> , <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> ,<1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-9RJlX7kAi3/EPUg9EJ7Z" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: "spasm@ietf.org" , Security Area Advisory Group Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 11:37:55 -0000 --=-9RJlX7kAi3/EPUg9EJ7Z Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2016-09-22 at 05:04 +0000, Peter Gutmann wrote: > David Woodhouse writes: >=20 > >=20 > > That's actually a very reasonable request, I think. >=20 > I don't know about reasonableness (hey, possibly it is), but it's highly > unlikely it'll ever be addressed. This situation has been with us for > twenty years without much, if any, progress being made (you can go back > two decades and find people complaining about the same thing). You just = have=20 > to work around it... that kinda sucks, but then lots of life in general d= oes. Heh, that's a very defeatist attitude :) I'm happy to tilt at windmills, and writing out a clear set of guidelines for applications to follow will be an important step to pushing them in the right direction. Even without that, there *has* been progress on this front. Below is a non-exhaustive list of "crappiness" that users have experienced =E2=80=94 especially with a focus on Linux and similar operatin= g systems. Note that we have *already* fixed almost all of these, so I am not as pessimistic as you about it being "highly unlikely it'll ever be addressed". I think it makes a lot of sense to write up the recommended best practice, and fix the crypto libraries so they make it hard for applications *not* to follow the best practice, instead of making it hard for applications to get it *right*. Sure, it won't be a panacea, but a world where users have higher expectations and file bugs for "this application does not follow the documented best practice" *will* be a better place. Here's that list of mostly-already-fixed problems: "My distribution builds this application against GnuTLS but this PEM=20 file is in the non-standard OpenSSL encrypted form so it doesn't=20 work." "My token doesn't expose the EC public key so I can't authenticate to the VPN... unless I rebuild OpenConnect to use GnuTLS instead of=20 OpenSSL. But I'm on CentOS where GnuTLS is too old to support Cisco's broken pre-standard version of DTLS." "My distribution builds cURL against NSS so the standard form of the PKCS#11 URI doesn't work and I have to use a NSS-specific way to specify the cert instead." "Hm, my token is installed correctly and works everywhere. I can see=20 my cert in 'seahorse' and 'p11tool' and use it from OpenConnect=E2=80=A6 = but why doesn't it work in Firefox? Oh, because NSS doesn't actually=20 load the tokens listed in the system configuration." "OK, so I fixed that... but now why doesn't it show up in Chrome. That uses NSS too, right? Oh, I have to add it to a *different* configuration file, ffs." "Now openvpn doesn't support the standard URI form either, it uses libpkcs11-helper which has an entirely different format that I need to use to specify the certificate." "Ick, when wpa_supplicant is built against OpenSSL it needs all this=20 explicit "engine" configuration nonsense in *addition* to needing the cert to be specified in a non-standard form. Unlike when built with GnuTLS, when it does just accept a RFC7512 PKCS#11 URI in its 'certificate' option." "Argh, FFS. The OpenSSL engine doesn't load the tokens listed in the=20 system configuration *either*, and needs to be explicitly told which provider module to load. And my application doesn't even give me the=20 hook to do that." "Oh, 'openvpn --cert' takes PEM files according to its documentation=E2=80= =A6 but wait, *this* is a PEM file and it doesn't seem to work. Why?" "Hm, all this *used* to work but when I just renewed my certificate, it magically stopped working... oh, because the new cert was issued with OpenSSL 1.1 and that uses a SHA256 HMAC by default which this version of GnuTLS doesn't cope with. "Oh, my cert is marked with CKA_PRIVATE but libp11 doesn't return it from PKCS11_enumerate_certs() even *after* I log in, so the application can't find it." "Hm, I need to configure my VPN to use the cert in my token but the GUI configuration dialog only lets me choose from a file." --=20 David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation --=-9RJlX7kAi3/EPUg9EJ7Z Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIyMTAyNzE5WjAvBgkqhkiG9w0BCQQxIgQgkSdqLaZgEtRMjpU/kgnhCSnOna1FGX2AqsQJ T9ijmRcwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAIrA 3+1TRHC/7hxIg0vGHZofW9axRxnthAUYAJSbPedTb6CnAoHAojZxmmfdUsxq66GekTZQLR4wruRR 3CxV63OmikBYO44DylQrfIi0ockAnbitduVrH4wkjNSCMXnfBfnUyq/xnBekPGbIOq2Z0gSkMRws 6s01WHEyk3kwJl34Gbo01yOYGTO8hY6h4le2PBe7s+U38WI+Bw/7V1HXvs0XyEVGa/gchZwTcXi5 FzOimSyAKgdFDrlEMQlbqmS3e6t23OGITvArCmOhecgFhD2gmmQkgRRU8c6DTGKpNqE6E7L+tVer kNPclfkwhlpq2QIvnVfcnirAofYjVoXqZ6XFfl4bVyZAhlsEW6DDw8DAu3iAR9th9ScclmBT8GsS NnoVujvzYxareJlZChVkZcQGumNeMvgdIsOXNvdeMPaARQeU8IAjcGEckMI6gpiGW5Cv4KIetwpn yobOMqhPnFa/1JdZhDSzsKAueDxMeanf4DPGq588kfY+YTbqONDyQtWfymkJcXmzxI8tDOYUCi0Z ufYLuT41D8F17NLu7+CmQR+wEe1EIWA8KAEt/QbrYZjHlNrKmNQi3NGMhlS8qgW+hjfcy+A+k+Os 7Ojl4fNTTDAeIqLDMm1rJ6kQ1UKHMVgAEWT96JChxQS6yyreqiS+YEhZieHs7diIwxzeXETJAAAA AAAA --=-9RJlX7kAi3/EPUg9EJ7Z-- From nobody Thu Sep 22 07:37:44 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEDE12B21F; Thu, 22 Sep 2016 07:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 7FLAEDlK1aWR; Thu, 22 Sep 2016 07:37:36 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id BA84012B4F9; Thu, 22 Sep 2016 07:18:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id C426E1F0B; Thu, 22 Sep 2016 14:18:24 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UoGoaVAExUm; Thu, 22 Sep 2016 14:18:24 +0000 (UTC) Received: from [192.168.100.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 1770B1EA6; Thu, 22 Sep 2016 14:18:23 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <1474540039.45169.62.camel@infradead.org> Date: Thu, 22 Sep 2016 10:18:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> To: David Woodhouse X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "spasm@ietf.org" , Michael Richardson , Security Area Advisory Group , Peter Gutmann Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 14:37:39 -0000 On Sep 22, 2016, at 6:27 AM, David Woodhouse = wrote: > Below is a non-exhaustive list of "crappiness" that users have > experienced =E2=80=94 especially with a focus on Linux and similar = operating > systems. Note that we have *already* fixed almost all of these, so I = am > not as pessimistic as you about it being "highly unlikely it'll ever = be > addressed". I see many of those issues as: * not implementing the standards correctly * using application-specific solutions instead of pre-existing solutions = already in wide use * implementations which produce bad or non-existent log messages=20 In my experience, many critical network applications or "security" = applications produce wonderful messages like "failed". Or "byte 14 not = 6 in my_foo_function()". Nonsense like that degrades security. This problem isn't programming, it's psychology. The programmers have = a mental model in which administrators know everything the programmers = know. This mental model is wrong. Administrators (and end users) need = *different* information than what programmers typically produce. As a case in point, I tried to get client certs working with a = commonly-used application. I followed the docs, and everything looked = like it succeeded. Yet the application refused to use the client = certificate. Why? I have *no idea*. There were no log messages, error = messages, or *anything* which let me know what the application was = doing, and how I could fix the problem. I eventually gave up, and installed a competing product. Which worked = fine the first time. I would hope that any X.509 best practice document takes this into = account. i.e. recommend that the application have a "security log" = which describes WHERE it's looking for certs, WHAT it found, WHY it = worked (or didn't work). Recommending formats for log messages would be = a big plus. It would be good to walk through typical usage scenarios, = and explain which log message should be produced when. Both for "it = works" cases, and for "it doesn't work" cases. Simple messages like that go a *long* way to educating the end user. = Instead of clicking through warning pop-ups, the user has some insight = into what's going on, and why. This empowers the end user to make = better choices. Alan DeKok. From nobody Thu Sep 22 08:33:52 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71E912B3A9 for ; Thu, 22 Sep 2016 08:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 v2xFJTYLlCPF for ; Thu, 22 Sep 2016 08:33:48 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 7709012BC95 for ; Thu, 22 Sep 2016 08:33:01 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id g62so71373647lfe.3 for ; Thu, 22 Sep 2016 08:33:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b7bZG7FFn3kNTohc1W2rl/CUKqKo84N0tcI4ZexVsMY=; b=mS41uabSRsUhWE08TXSxVnyUVvBp6vMUfelkxaMW90AYi6Q4/fLmEmNrDnlRd/xu1G F3mNv+Xdwz2qJa9lvAKNejUz9HL+TuZDlV9tHDsvfgG9HuEsKLTeiusqkmmPFOG3egFv K1ndK10b36Om6q5UIUJWzoBQlqArNMBFky4zha/TsPWSZV0AyKXXX9xuorQUp8OhkVZx suK4Su9Mr0fTY4phUiDSMMcfew+61MT3EoMjTtgcxcbGA8+Vrr9ba/KCwnUe9/tbRfKh AhHnfYaQ9WjoLBSu/QpaQIF5nzZ5n0IDD12TENriNO9kksaKl+60KkExZfilh6ydaUhZ N/oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b7bZG7FFn3kNTohc1W2rl/CUKqKo84N0tcI4ZexVsMY=; b=VwU1tWZGc1tESDf9OHG4o1aO0uRkB7ZTCtgPXMCnRWq5Wt+JgFD9Ps3O3R7sK82X4M r5KDUcsyYHoz2RD1gR9kKJmzlGmWFpQu4jmWOWoeJBVFvsJUjWgAn/ycIieKoCmoiV0l P7+XYo6ni8E0QKUQ+6c0CI0+iRmWhhKHCxSY89iy3uKeC1ytHnPa0c/cLa9G1mL6AqnK m+uH8wHR9crVvNP8uWKqvjECGrr7kmHwYCsZgIiLdsDHo864rYCZ1VdgSWRfPFAIKKxt xPg2m75YJJPHQzRGxP/B7SMRKpXjjIuCJWAeubYhwi4PlXMU223EzClibLJrQ02MtOrb W/AQ== X-Gm-Message-State: AE9vXwPr3srNkuK0aF6JagQK09+YfQ43aFhMb7DEKOcg92gEpml+k7mIhe+dWv27Gmtio06+FOgHzFrzBvpI+A== X-Received: by 10.25.28.19 with SMTP id c19mr1252400lfc.56.1474558379357; Thu, 22 Sep 2016 08:32:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Thu, 22 Sep 2016 08:32:18 -0700 (PDT) In-Reply-To: <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> From: Ted Lemon Date: Thu, 22 Sep 2016 11:32:18 -0400 Message-ID: To: Alan DeKok Content-Type: multipart/alternative; boundary=001a11401be8671a3d053d1a6075 Archived-At: Cc: "spasm@ietf.org" , Michael Richardson , David Woodhouse , Security Area Advisory Group Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 15:33:51 -0000 --001a11401be8671a3d053d1a6075 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 22, 2016 at 10:18 AM, Alan DeKok wrote: > I would hope that any X.509 best practice document takes this into > account. i.e. recommend that the application have a "security log" which > describes WHERE it's looking for certs, WHAT it found, WHY it worked (or > didn't work). Recommending formats for log messages would be a big plus. > It would be good to walk through typical usage scenarios, and explain which > log message should be produced when. Both for "it works" cases, and for > "it doesn't work" cases. > > Simple messages like that go a *long* way to educating the end user. > Instead of clicking through warning pop-ups, the user has some insight into > what's going on, and why. This empowers the end user to make better > choices. > Yes, this! --001a11401be8671a3d053d1a6075 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 22, 2016 at 10:18 AM, Alan DeKok <aland@deployingradius.co= m> wrote:
=C2=A0I would hop= e that any X.509 best practice document takes this into account.=C2=A0 i.e.= recommend that the application have a "security log" which descr= ibes WHERE it's looking for certs, WHAT it found, WHY it worked (or did= n't work).=C2=A0 Recommending formats for log messages would be a big p= lus.=C2=A0 It would be good to walk through typical usage scenarios, and ex= plain which log message should be produced when.=C2=A0 Both for "it wo= rks" cases, and for "it doesn't work" cases.

=C2=A0 Simple messages like that go a *long* way to educating the end user.= =C2=A0 Instead of clicking through warning pop-ups, the user has some insig= ht into what's going on, and why.=C2=A0 This empowers the end user to m= ake better choices.

Yes, this!=C2=A0

--001a11401be8671a3d053d1a6075-- From nobody Thu Sep 22 09:08:23 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C290E12B1E9; Thu, 22 Sep 2016 09:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no 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 bODsfqLzGL3T; Thu, 22 Sep 2016 09:08:16 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 048AD12B5E5; Thu, 22 Sep 2016 09:08:16 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bn6Xg-00016h-KD; Thu, 22 Sep 2016 16:08:09 +0000 Message-ID: <1474560485.45169.92.camel@infradead.org> From: David Woodhouse To: Alan DeKok , Nikos Mavrogiannopoulos Date: Thu, 22 Sep 2016 17:08:05 +0100 In-Reply-To: <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-nNG2tgSKA7YUApXLKcF5" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: "spasm@ietf.org" , Michael Richardson , Security Area Advisory Group , Peter Gutmann Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 16:08:23 -0000 --=-nNG2tgSKA7YUApXLKcF5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2016-09-22 at 10:18 -0400, Alan DeKok wrote: > On Sep 22, 2016, at 6:27 AM, David Woodhouse wrote: > >=20 > > Below is a non-exhaustive list of "crappiness" that users have > > experienced =E2=80=94 especially with a focus on Linux and similar oper= ating > > systems. Note that we have *already* fixed almost all of these, so I am > > not as pessimistic as you about it being "highly unlikely it'll ever be > > addressed". >=20 > I see many of those issues as: >=20 > * not implementing the standards correctly >=20 > * using application-specific solutions instead of pre-existing solutions = already in wide use And partly the fact that there are TOO MANY standards; both de facto and de jure. Just look at the class of "stuff which OpenSSL has produced by default over the years for private keys", including the output of tools such as 'openssl req -new'. There's about a dozen different file formats with which applications should "Just Work", right there. We added HMAC-SHA256 support to GnuTLS PKCS#12 just a week or two back, because OpenSSL 1.1 does that by default. We added pbeWithMD5AndDES-CBC=20 support too, Turns out OpenSSL 1.0.2 is still producing *that* by default with 'openssl pkcs8 -topk8' :) > * implementations which produce bad or non-existent log messages=20 >=20 >=20 > =C2=A0 In my experience, many critical network applications or "security" > applications produce wonderful messages like "failed". Or "byte 14 > not 6 in my_foo_function()". Nonsense like that degrades security. I'd note that those are two very different classes of bad error message. The first is bad because it doesn't provide any information about what went wrong; merely that something did. This is the type of bad error message which is most common. The second is bad because it's giving the wrong information. But it's still better than the first, because at least I can go and read my_foo_function() and see what's going on. > =C2=A0 I would hope that any X.509 best practice document takes this into > account. i.e. recommend that the application have a "security log" > which describes WHERE it's looking for certs, WHAT it found, WHY it > worked (or didn't work). Recommending formats for log messages would > be a big plus. It would be good to walk through typical usage > scenarios, and explain which log message should be produced when.=20 > Both for "it works" cases, and for "it doesn't work" cases. Crappy error handling is a personal bugbear of mine... but I'd actually tried *not* to get too distracted by it in putting together the draft. It's not really specific to X.509 best practices at all. Nevertheless, some wording on it did slip into the draft that Nikos and I have started working on, because I just couldn't help myself. Here is a very early attempt at that draft. I have tried quite hard to limit the scope because as this discussion has showed, there are plenty of possibilities for "mission creep". http://david.woodhou.se/draft-woodhouse-cert-best-practice.html https://github.com/dwmw2/ietf-cert-best-practice I should point out that although I put Nikos's name on it and he has contributed many improvements, any egregious errors and stupidities in it should be blamed on me. Especially as I didn't actually double-check=20 with him before posting it here. :) --=C2=A0 dwmw2 --=-nNG2tgSKA7YUApXLKcF5 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIyMTYwODA1WjAvBgkqhkiG9w0BCQQxIgQgN6MXXpabIjGdvddFe8b5ZAIY+RHGkV4ZsTn6 HDBMqQowgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAH0I 640SKOGZgAX5pQnqEo7oQTIB2Qcpj1cGyaXMZpxBc8Z404CfTazy/L/d+E8wrq9KWwZ07dmomGgE lHkpqSrwIDr9I5NhQQP2LGic3OpNpXEaw+rd4LkDABdKoPqJk2EDIHaL51F+YufZRPnf+SYcjXgv mthbh28Vx/WBJwkP4ULESPIhkRXnIgFtY5E9zurFQmwl3F7tHkd6W9NXMZWRIXQLIav2D5mT/fNi 9ZnXI4i+0St7x3Nec7CJrmgwD0rd+X3ZEoK9aAgUe3XYmnUp0bUaY6b8tcQPiEjtS04dn3p0L6pD /7FCelKk7NV/3ryaQJZV3hW1NEvT6OtSzFzE/xbc1nodZFFF2qVp3ZeLTggjwfBgHACOjgpQNHJO FKMXIhdrAuXRmnpD6cejrIFhT195VtAqEpKB7Wf5uwsTGoJh1aVFF18z8lkxQcOLA1xuiUZavBm2 mgsrTCk7+lqiLvjdIZKVPS2NHNfYkJTqR6d+/tojpeAR4Feptwgc/nIeLwRRp8L72ubbYGbvEulf chXvxQPKNWJ247iDksM8sK/lSc5SuSNLocfFsMXSKe4Zj7odeMG6DQ2jTfvVq9T5bh9yqjJaIi7l sECOgjZGQpQVa1JGY4fE9osmPGClXvJS1Q2OCArk01ychd8BGrP1MDhAbvMGhvbZW4v6XjFSAAAA AAAA --=-nNG2tgSKA7YUApXLKcF5-- From nobody Thu Sep 22 11:24:59 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E30A12B17B for ; Thu, 22 Sep 2016 11:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 afQZR4LSpw6Q for ; Thu, 22 Sep 2016 11:24:53 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 DF48412B04F for ; Thu, 22 Sep 2016 11:24:52 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id l131so75802721lfl.2 for ; Thu, 22 Sep 2016 11:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pHSBjIs5cVU7g7tvJY/wTJfxp0ocpXbQ0Ohz+hF2tvk=; b=V/97N9tWnhUFj0HBoFdbw8+Nd3fVuNpJYcXFbu8V2ddsz90fhhLhKnu4X5w2hT40ig HoQR5qjO5A0tfwGvZY3v9fNDDJxxRXa3r9QmFUVbgkybWpfVqQHCMi7XPkqZFp3u+GKH GQT48pYxFVWujtWpITBKs7zrPh687ILnA+mckG8EbLHKYN0zCQqQ5L+27wvMi5JQFRwE 1QT+s/9htxhs+Jvsy6wmj6PRKAnV2zKc9O+53zV4GynL7LfJdYBHGAfnchXDX8v2A/ys R/pbyHrxRqATbVmTiEhPTDq4fnq8ILujR5WWG4YDMAVvp5ZNxtnYRCAece5l+9zNNDF9 eksg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pHSBjIs5cVU7g7tvJY/wTJfxp0ocpXbQ0Ohz+hF2tvk=; b=Qp7692GB7zZM58iH/XCuWNMGnwzSQLNz2WQXq1AmfDdS34rGacIMQgiNQ368KafgPw sXYK+dng18Fgv8Ck8FMNRwfMAGryqdVAXUS1EyB1vDgzkZDXyavieLubCHAPuZQyeknD xVLr4pJRWueFM9k76JB/cgWmAIeHDVFirfxAIGCN/7ZA63zeXu+5gkebm6axlYprE79K ooP4o2ytP7UIz5hMh2yPajW3aeh8gTDvvUhWn88O7rZDayn5di+3PgmjxPaOqXS3Hlc7 zoJx2DnodmRckAGFWkd6hte7Y/FVX+zlNQvpX/ggo40uwCT9hO/MTevLx7nuQmfYvEa/ 0SrA== X-Gm-Message-State: AE9vXwMuUhJ9R+px0rtN1oPJV6z0RloA66e6sWs5tb95O60l98n6h/GkH3o96QoovigtP9Wg8v1Z+Pldhfbd1w== X-Received: by 10.25.18.23 with SMTP id h23mr1505428lfi.5.1474568690909; Thu, 22 Sep 2016 11:24:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Thu, 22 Sep 2016 11:24:10 -0700 (PDT) In-Reply-To: <1474560485.45169.92.camel@infradead.org> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> From: Ted Lemon Date: Thu, 22 Sep 2016 14:24:10 -0400 Message-ID: To: David Woodhouse Content-Type: multipart/alternative; boundary=001a113fb46004de82053d1cc734 Archived-At: Cc: Nikos Mavrogiannopoulos , "spasm@ietf.org" , Michael Richardson , Security Area Advisory Group , Alan DeKok Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 18:24:57 -0000 --001a113fb46004de82053d1cc734 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This looks good generally. However, one concern I have about it is that we actually really don't want applications to have access to private keys. Well, anyway I don't. I want the private key to be in an engine where it can't be gotten out by the application, and I want the application to provide data for the engine to process: cleartext in, ciphertext out. This is a big ask, and I realize that, so I am not saying that this document is wrong. But I'm bringing it up because I wonder if you've thought about it, and possibly considered specifying this operational model as well. Not being a security expert myself, is what I am asking for technically unreasonable, or do you just think it doesn't need to be scoped in to this work? On Thu, Sep 22, 2016 at 12:08 PM, David Woodhouse wrote: > On Thu, 2016-09-22 at 10:18 -0400, Alan DeKok wrote: > > On Sep 22, 2016, at 6:27 AM, David Woodhouse > wrote: > > > > > > Below is a non-exhaustive list of "crappiness" that users have > > > experienced =E2=80=94 especially with a focus on Linux and similar op= erating > > > systems. Note that we have *already* fixed almost all of these, so I = am > > > not as pessimistic as you about it being "highly unlikely it'll ever = be > > > addressed". > > > > I see many of those issues as: > > > > * not implementing the standards correctly > > > > * using application-specific solutions instead of pre-existing solution= s > already in wide use > > And partly the fact that there are TOO MANY standards; both de facto > and de jure. > > Just look at the class of "stuff which OpenSSL has produced by default > over the years for private keys", including the output of tools such as > 'openssl req -new'. There's about a dozen different file formats with > which applications should "Just Work", right there. > > We added HMAC-SHA256 support to GnuTLS PKCS#12 just a week or two back, > because OpenSSL 1.1 does that by default. We added pbeWithMD5AndDES-CBC > support too, Turns out OpenSSL 1.0.2 is still producing *that* by > default with 'openssl pkcs8 -topk8' :) > > > * implementations which produce bad or non-existent log messages > > > > > > In my experience, many critical network applications or "security" > > applications produce wonderful messages like "failed". Or "byte 14 > > not 6 in my_foo_function()". Nonsense like that degrades security. > > I'd note that those are two very different classes of bad error message. > > The first is bad because it doesn't provide any information about what > went wrong; merely that something did. This is the type of bad error > message which is most common. > > The second is bad because it's giving the wrong information. But it's > still better than the first, because at least I can go and read > my_foo_function() and see what's going on. > > > I would hope that any X.509 best practice document takes this into > > account. i.e. recommend that the application have a "security log" > > which describes WHERE it's looking for certs, WHAT it found, WHY it > > worked (or didn't work). Recommending formats for log messages would > > be a big plus. It would be good to walk through typical usage > > scenarios, and explain which log message should be produced when. > > Both for "it works" cases, and for "it doesn't work" cases. > > Crappy error handling is a personal bugbear of mine... but I'd actually > tried *not* to get too distracted by it in putting together the draft. > It's not really specific to X.509 best practices at all. Nevertheless, > some wording on it did slip into the draft that Nikos and I have > started working on, because I just couldn't help myself. > > Here is a very early attempt at that draft. I have tried quite hard to > limit the scope because as this discussion has showed, there are plenty > of possibilities for "mission creep". > > http://david.woodhou.se/draft-woodhouse-cert-best-practice.html > https://github.com/dwmw2/ietf-cert-best-practice > > I should point out that although I put Nikos's name on it and he has > contributed many improvements, any egregious errors and stupidities in > it should be blamed on me. Especially as I didn't actually double-check > with him before posting it here. :) > > -- > dwmw2 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > --001a113fb46004de82053d1cc734 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This looks good generally. =C2=A0 However, one concern I h= ave about it is that we actually really don't want applications to have= access to private keys. =C2=A0 Well, anyway I don't. =C2=A0 I want the= private key to be in an engine where it can't be gotten out by the app= lication, and I want the application to provide data for the engine to proc= ess: cleartext in, ciphertext out. =C2=A0 This is a big ask, and I realize = that, so I am not saying that this document is wrong. =C2=A0 But I'm br= inging it up because I wonder if you've thought about it, and possibly = considered specifying this operational model as well. =C2=A0 Not being a se= curity expert myself, is what I am asking for technically unreasonable, or = do you just think it doesn't need to be scoped in to this work?

On Thu, Sep 22, 201= 6 at 12:08 PM, David Woodhouse <dwmw2@infradead.org> wrote= :
On Thu, 2016-09-22 at = 10:18 -0400, Alan DeKok wrote:
> On Sep 22, 2016, at 6:27 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> >
> > Below is a non-exhaustive list of "crappiness" that use= rs have
> > experienced =E2=80=94 especially with a focus on Linux and simila= r operating
> > systems. Note that we have *already* fixed almost all of these, s= o I am
> > not as pessimistic as you about it being "highly unlikely it= 'll ever be
> > addressed".
>
>=C2=A0 =C2=A0I see many of those issues as:
>
> * not implementing the standards correctly
>
> * using application-specific solutions instead of pre-existing solutio= ns already in wide use

And partly the fact that there are TOO MANY standards; both de facto=
and de jure.

Just look at the class of "stuff which OpenSSL has produced by default=
over the years for private keys", including the output of tools such a= s
'openssl req -new'. There's about a dozen different file format= s with
which applications should "Just Work", right there.

We added HMAC-SHA256 support to GnuTLS PKCS#12 just a week or two back,
because OpenSSL 1.1 does that by default. We added pbeWithMD5AndDES-CBC
support too, Turns out OpenSSL 1.0.2 is still producing *that* by
default with 'openssl pkcs8 -topk8' :)

> * implementations which produce bad or non-existent log messages
>
>
> =C2=A0 In my experience, many critical network applications or "s= ecurity"
> applications produce wonderful messages like "failed".=C2=A0= Or "byte 14
> not 6 in my_foo_function()".=C2=A0 Nonsense like that degrades se= curity.

I'd note that those are two very different classes of bad error = message.

The first is bad because it doesn't provide any information about what<= br> went wrong; merely that something did. This is the type of bad error
message which is most common.

The second is bad because it's giving the wrong information. But it'= ;s
still better than the first, because at least I can go and read
my_foo_function() and see what's going on.

> =C2=A0 I would hope that any X.509 best practice document takes this i= nto
> account.=C2=A0 i.e. recommend that the application have a "securi= ty log"
> which describes WHERE it's looking for certs, WHAT it found, WHY i= t
> worked (or didn't work).=C2=A0 Recommending formats for log messag= es would
> be a big plus.=C2=A0 It would be good to walk through typical usage > scenarios, and explain which log message should be produced when.
> Both for "it works" cases, and for "it doesn't work= " cases.

Crappy error handling is a personal bugbear of mine... but I'd a= ctually
tried *not* to get too distracted by it in putting together the draft.
It's not really specific to X.509 best practices at all. Nevertheless,<= br> some wording on it did slip into the draft that Nikos and I have
started working on, because I just couldn't help myself.

Here is a very early attempt at that draft. I have tried quite hard to
limit the scope because as this discussion has showed, there are plenty
of possibilities for "mission creep".

http://david.woodhou.se/draft-wo= odhouse-cert-best-practice.html
https://github.com/dwmw2/ietf-cert-best-practic= e

I should point out that although I put Nikos's name on it and he has contributed many improvements, any egregious errors and stupidities in
it should be blamed on me. Especially as I didn't actually double-check=
with him before posting it here. :)

--=C2=A0
dwmw2
_______________________________________________=
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag


--001a113fb46004de82053d1cc734-- From nobody Thu Sep 22 12:01:39 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6ABD12B74A; Thu, 22 Sep 2016 12:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no 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 NvmrIgt83KiV; Thu, 22 Sep 2016 12:01:36 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 E981A12B43B; Thu, 22 Sep 2016 12:01:12 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:f69] (helo=shinybook.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bn9F6-0003k9-IK; Thu, 22 Sep 2016 19:01:08 +0000 Message-ID: <1474570865.30494.68.camel@infradead.org> From: David Woodhouse To: Ted Lemon Date: Thu, 22 Sep 2016 20:01:05 +0100 In-Reply-To: References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-ZiKvNRFPg/W+IjAqnOh0" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: Nikos Mavrogiannopoulos , "spasm@ietf.org" , Michael Richardson , Security Area Advisory Group , Alan DeKok Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 19:01:38 -0000 --=-ZiKvNRFPg/W+IjAqnOh0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2016-09-22 at 14:24 -0400, Ted Lemon wrote: > This looks good generally. =C2=A0 However, one concern I have about it is > that we actually really don't want applications to have access to > private keys. =C2=A0 Well, anyway I don't. =C2=A0 I want the private key = to be > in an engine where it can't be gotten out by the application, and I > want the application to provide data for the engine to process: > cleartext in, ciphertext out.=20 This sounds a little bit like the model we were using with TPM(v1). With the OpenSSL TPM ENGINE, the user 'wraps' a key with the TPM and gets to keep a PEM file that starts like this: -----BEGIN TSS KEY BLOB----- Whenever the user wants to use that key, they simply use that PEM file instead of one of the other multitude of supported formats and it "Just Works". I had lots of fun making that work for GnuTLS too: http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/gnutls_tpm.= c Is that what you were after? I did consider writing that one down too, but figured it was a little too esoteric. And perhaps we should have exposed the TPM via a PKCS#11 provider in the first place anyway. > =C2=A0 This is a big ask, and I realize that, so I am not saying that thi= s > document is wrong. =C2=A0 But I'm bringing it up because I wonder if > you've thought about it, and possibly considered specifying this > operational model as well. =C2=A0 Not being a security expert myself, is > what I am asking for technically unreasonable, or do you just think > it doesn't need to be scoped in to this work? I absolutely agree that applications MUST NOT rely on having access to the actual private key material. They need to support using opaque keys from hardware and software tokens. But I was envisaging that PKCS#11 would be the vehicle for that. --=20 David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation --=-ZiKvNRFPg/W+IjAqnOh0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIyMTkwMTA1WjAvBgkqhkiG9w0BCQQxIgQgC5Sw0BLnGHsrtdALj2OPMRaXEYq7hbNfAOSj AeETGyQwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAMON B3cXy4mH3WHRP7k/dweuhwCILvtQCoW3YB4RmtFWOistnRradBmx2BWgeO8sl1zm6c3NuLSSaHSx +7IcqjKLY1MJ6DFTLguIVx6qkBA8SdGhI7OiThVhwMthY59esl0/JWtcg3nb6Um3JzVBwh8jq0HW KbCpnEDe7wqnmYYbzNonxzKbhlYP+orIpk+EE4IeQd2ad0wKkY77/3evD/aQC0L52KrOzbM0RWjL Ut/FG865EovwVwvCD4A1ZMxkaWjzbQhab6xe/ulcMdpKaVc8zwLht6lisSGebblaGlpYoVkQhg74 R3OiesWlIMVxCRMOZw28ioR0qRF9UayWXKNmRcbyHvFFQSPfnJpRCuAmFmsfE4Fdfd6vW2EUhcYr 4/ID9c0TnjgIPB1xN5LHeI/TeXGmv4cMxOTerHw0qm9t/ZhxzbN9WCPD8L4Y8cHFF1+zPFOvFJQP 3UgO8dbpMuhVKBagxnrO9sg6+YmpmIrDc3skA2hDzAQsXEFgTVkHTeAyLU0HDDjwJkaJ5aBRxAhp ul2oBzMGDFo7KB/JV2Qje89wMzAqwnY2az8c3vFWek88Xk94M3kaj//T4rpWRNqHjMeYOCddRBJE Pe04uqlS6tMCxYByYT7sQSiuuPk2wVihC4SeodwHmOb6vAhPCA5x8CWQlDkTS+oZgqLfx6ahAAAA AAAA --=-ZiKvNRFPg/W+IjAqnOh0-- From nobody Thu Sep 22 12:27:01 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BC712DA56 for ; Thu, 22 Sep 2016 12:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 ZVVcIQcV7_7H for ; Thu, 22 Sep 2016 12:26:55 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 415D512DA5B for ; Thu, 22 Sep 2016 12:26:53 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id g62so76424563lfe.3 for ; Thu, 22 Sep 2016 12:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vet11LBI3lqudwixskGSeEL3xK3dMGBU9gZPpei3uAI=; b=OA/TwuI46+WphzdX1G56R/pTtyFhMJO9IyhSUeTULLzzV2KNRwtSfqabcCVaffUd+C tY1/XYqfWgJhux7EBALjo1HHEWqDpT4oNmlqiSr8XbH6z1MYGJEnaHFF6krVzpqehvrc p+HCsQPSlTLMvX0hRPKH0mzNM7DodIkW/4zYl8lplghvdCnFDM1W9EzUcFQt1/9O4R3X 263GO7RbahAcFacV7fCWWqr1B2FBqk4ONSCGYRYQYjqTrbEdimhBCZdeQh6d7Xla4JUv TIo2JA0Xa3oUSORSzufqaOAcbtweYBvCT/C/1GUKWMit7WvY4b9eXJ0iaPjZEKe394bm bGfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Vet11LBI3lqudwixskGSeEL3xK3dMGBU9gZPpei3uAI=; b=UGIIUM270GqYOOcNvpiWCDi74XhLTJlwnKtiDzOJHe/MU4jac5V6ww77Fn16uh2pDi mFWSK1qYzYp/paL+mx310eV/5mxCxWRwUvE/XsAWIH/wycTropM1iANxGPJt71vCfCGj /M94ZlhBik7hnnmvwxI4EQ4k1RyoqSrHrdmzt1jPKq8/lN1d7dwKMv/2FYPrKl3u3JhV euaf9G40wukQ8PdXjAD4j1COZXwPJA4OW8vrubNMpCRu27qj1cl+fydWQ+vV5Ya7FVTD hed2KSlwIryPljHcdExjCGCOEsFQgiG2YhEh+56rdYOrwYcuGaSwsuoLu/gkHwmaMRBx TrqA== X-Gm-Message-State: AE9vXwOkVmOgCqwTYRyhqX0Qxy4koqmVzCUCmD2MJQ8J2K5zszcR2spwuxzWUvmvn6iOPYpikrdYIX0Rkvc45w== X-Received: by 10.46.9.87 with SMTP id 84mr1585103ljj.0.1474572411106; Thu, 22 Sep 2016 12:26:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Thu, 22 Sep 2016 12:26:10 -0700 (PDT) In-Reply-To: <1474570865.30494.68.camel@infradead.org> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> <1474570865.30494.68.camel@infradead.org> From: Ted Lemon Date: Thu, 22 Sep 2016 15:26:10 -0400 Message-ID: To: David Woodhouse Content-Type: multipart/alternative; boundary=001a114b0d76c28b08053d1da480 Archived-At: Cc: Nikos Mavrogiannopoulos , "spasm@ietf.org" , Michael Richardson , Security Area Advisory Group , Alan DeKok Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 19:26:57 -0000 --001a114b0d76c28b08053d1da480 Content-Type: text/plain; charset=UTF-8 Well, here is the reason that I carefully said "not a security expert" earlier. I suspect that PKCS#11 is a better answer than a shim. Thanks for the clue stick! On Thu, Sep 22, 2016 at 3:01 PM, David Woodhouse wrote: > On Thu, 2016-09-22 at 14:24 -0400, Ted Lemon wrote: > > This looks good generally. However, one concern I have about it is > > that we actually really don't want applications to have access to > > private keys. Well, anyway I don't. I want the private key to be > > in an engine where it can't be gotten out by the application, and I > > want the application to provide data for the engine to process: > > cleartext in, ciphertext out. > > This sounds a little bit like the model we were using with TPM(v1). > With the OpenSSL TPM ENGINE, the user 'wraps' a key with the TPM and > gets to keep a PEM file that starts like this: > > -----BEGIN TSS KEY BLOB----- > > Whenever the user wants to use that key, they simply use that PEM file > instead of one of the other multitude of supported formats and it "Just > Works". I had lots of fun making that work for GnuTLS too: > http://git.infradead.org/users/dwmw2/openconnect.git/ > blob/HEAD:/gnutls_tpm.c > > > Is that what you were after? I did consider writing that one down too, > but figured it was a little too esoteric. And perhaps we should have > exposed the TPM via a PKCS#11 provider in the first place anyway. > > > This is a big ask, and I realize that, so I am not saying that this > > document is wrong. But I'm bringing it up because I wonder if > > you've thought about it, and possibly considered specifying this > > operational model as well. Not being a security expert myself, is > > what I am asking for technically unreasonable, or do you just think > > it doesn't need to be scoped in to this work? > > I absolutely agree that applications MUST NOT rely on having access to > the actual private key material. They need to support using opaque keys > from hardware and software tokens. But I was envisaging that PKCS#11 > would be the vehicle for that. > > -- > David Woodhouse Open Source Technology Centre > David.Woodhouse@intel.com Intel Corporation > > --001a114b0d76c28b08053d1da480 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, here is the reason that I carefully said "not a= security expert" earlier. =C2=A0 I suspect that PKCS#11 is a better a= nswer than a shim. =C2=A0 Thanks for the clue stick!

On Thu, Sep 22, 2016 at 3:01 PM, D= avid Woodhouse <dwmw2@infradead.org> wrote:
On Thu, 2016-09-22 at 14:24 -0400, Ted= Lemon wrote:
> This looks good generally. =C2=A0 However, one concern I have about it= is
> that we actually really don't want applications to have access to<= br> > private keys. =C2=A0 Well, anyway I don't. =C2=A0 I want the priva= te key to be
> in an engine where it can't be gotten out by the application, and = I
> want the application to provide data for the engine to process:
> cleartext in, ciphertext out.

This sounds a little bit like the model we were using with TPM(v1).<= br> With the OpenSSL TPM ENGINE, the user 'wraps' a key with the TPM an= d
gets to keep a PEM file that starts like this:

-----BEGIN TSS KEY BLOB-----

Whenever the user wants to use that key, they simply use that PEM file
instead of one of the other multitude of supported formats and it "Jus= t
Works". I had lots of fun making that work for GnuTLS too:
http://git.infradead.org= /users/dwmw2/openconnect.git/blob/HEAD:/gnutls_tpm.c


Is that what you were after? I did consider writing that one down too,
but figured it was a little too esoteric. And perhaps we should have
exposed the TPM via a PKCS#11 provider in the first place anyway.

> =C2=A0 This is a big ask, and I realize that, so I am not saying that = this
> document is wrong. =C2=A0 But I'm bringing it up because I wonder = if
> you've thought about it, and possibly considered specifying this > operational model as well. =C2=A0 Not being a security expert myself, = is
> what I am asking for technically unreasonable, or do you just think > it doesn't need to be scoped in to this work?

I absolutely agree that applications MUST NOT rely on having access = to
the actual private key material. They need to support using opaque keys
from hardware and software tokens. But I was envisaging that PKCS#11
would be the vehicle for that.

--
David Woodhouse=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Open Source Technology Centre
David.Woodhouse@intel.com= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Intel Corporation


--001a114b0d76c28b08053d1da480-- From nobody Thu Sep 22 12:47:07 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C02112B971; Thu, 22 Sep 2016 12:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no 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 j2Tv_dzV81E4; Thu, 22 Sep 2016 12:47:00 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 4627012B93B; Thu, 22 Sep 2016 12:47:00 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:f69] (helo=shinybook.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bn9xT-00065n-8g; Thu, 22 Sep 2016 19:46:59 +0000 Message-ID: <1474573616.30494.90.camel@infradead.org> From: David Woodhouse To: Ted Lemon Date: Thu, 22 Sep 2016 20:46:56 +0100 In-Reply-To: References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> <1474570865.30494.68.camel@infradead.org> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-0SAm96cGgOiQR0fpAe8j" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: Nikos Mavrogiannopoulos , "spasm@ietf.org" , Alan DeKok , Security Area Advisory Group , Michael Richardson Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 19:47:02 -0000 --=-0SAm96cGgOiQR0fpAe8j Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2016-09-22 at 15:26 -0400, Ted Lemon wrote: > Well, here is the reason that I carefully said "not a security > expert" earlier. =C2=A0 I suspect that PKCS#11 is a better answer than a > shim. =C2=A0 Thanks for the clue stick! FWIW if you want to put the key beyond copying by normal users, for many purposes you can do that right now on a Linux system. See https://bugzilla.gnome.org/show_bug.cgi?id=3D704866#c9=C2=A0(and #c10) The example there is the OpenConnect VPN client, but on Fedora if you find *any* application which would accept a certificate in a file and doesn't accept a RFC7512 PKCS#11 URI, please file a bug and Cc me. Because although I'm only now working on this I-D, that much *is* already part of the Fedora packaging guidelines. And if you're not on Linux or something similar... and if you're not on Windows or OSX which have their own keystores which at least *pretend* to prevent the kind of export you're talking about, then what platform *are* you thinking of? :) --=20 dwmw2 --=-0SAm96cGgOiQR0fpAe8j Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIyMTk0NjU2WjAvBgkqhkiG9w0BCQQxIgQgAaZ3T9nAd9MKrFlmEyg15rRzhcks537QnFoU jneeZoQwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAFz2 94ibVoFuH9PwPTn9nejiOuIxJ6xPSTtRkRxOlpyOoUk0Jz6Hglo+jyHtd4dOkJUZbI7GGZiJKCmz f3AOKrg65qnyVFzY73TuDzFLkr5yHzlTAjvU/uKiC/HvtbSjouOzUSs+g93nxszg1AmCg6QFOE0U oWd46304sN+znOKYefCxhaRw/xgscESkvpBXoydLkVLIiMVWQr5hk+pwavwCbXmRur5xTPAEPEyK QrX3c1vMEW0a/CtjvnoyBUtAJf5CVgqVZJhKGdlf8GXJQn2FE4wMJgPIfx+E61rBGZieBQJ1Tw5L Zf3RWUFXIWOXFATWYgTGLmVRM6Og2v1elKoajOFsv6igOJ9Jgw7Mwdo0GLyXEmDC2zFpzN83YFHc hKMyCZE6wt9et3PawdZDhf2mkQcXvIPHk9XHryXQa6b/GPiUV5g5wwHw3aaGVz12XhB1z2G25lwT IK8DfYPdVG5JgufHILxHh/h97txGmtPs/2SITXMXldxPCczMGodwJOOUqB6dGR5Hj6LFDzcsg0I2 vochBj1aRjJJfI/ZLGfn8TRzMlDRS1U4MwHILV2kGH1PUD+l3UqIaIXbh5wqmHESHSr0+2GB0v9q hzNClFAAVmIC2IZ0nDrMly5KAqqGEADCNbE8qKtPYoWLr5wZuQsOry9HCEKRamdkOt1LPFtRAAAA AAAA --=-0SAm96cGgOiQR0fpAe8j-- From nobody Sun Sep 25 08:18:11 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4A912B237 for ; Sun, 25 Sep 2016 08:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 cpl1EILgxCa0 for ; Sun, 25 Sep 2016 08:18:09 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1922F12B226 for ; Sun, 25 Sep 2016 08:18:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4A26330066F for ; Sun, 25 Sep 2016 11:18:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id j-yvH50G6ELI for ; Sun, 25 Sep 2016 11:18:07 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 8C0343004CA for ; Sun, 25 Sep 2016 11:18:07 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <301D580E-D079-4D24-B5F5-BE8B58C12144@vigilsec.com> Date: Sun, 25 Sep 2016 11:18:07 -0400 To: SPASM Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [Spasm] DRAFT Agenda for IETF 97 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2016 15:18:10 -0000 Please review and comment. Russ = = = = = = = = LAMPS WG Agenda 0) Minute Taker, Jabber Scribe, Bluesheets 1) Agenda Bash 2) Status and open issues on WG documents a) draft-ietf-lamps-eai-addresses (Alexey and Wei) b) draft-ietf-lamps-rfc5750-bis (Jim) c) draft-ietf-lamps-rfc5751-bis (Jim) 3) Any other business (if time allows) 4) Wrap Up From nobody Sun Sep 25 08:34:25 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2768412B244 for ; Sun, 25 Sep 2016 08:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 uFwrjm-K40sC for ; Sun, 25 Sep 2016 08:34:21 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 C760E12B245 for ; Sun, 25 Sep 2016 08:34:20 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id n185so144653620qke.1 for ; Sun, 25 Sep 2016 08:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=r0CGyzPkFAJj83F3EHzVlEEp7wLzJJq0CCnYm4ji2Zw=; b=JR7UES9wUXrLpX3gSpvUetZE1RrDExdNooIFE/OsdvGqqoxZ1NglHFVs2fh+zNqulv f+eQAgbeutEhyQUbs5x3yV74Zgc0rD1rPgaR4IT+yYCAaXaruB2eqHiLgRd9FBew7DZE 6I9TdRbvS9Uz5vEefH1wKL1DsJfGdGKZh59SqrBsIWcwdoFDbhclUN4A4uejn5pMVN5/ rF76FANSvYpy2bcA7oG5ZFCOaTwLP0wDAxqN0tekfkP6AiICZ6tWhl/7B20BQEJQpo2f 1M8hbpkbRDoqCwUMcux6Rl43/jU33W6HJTl4czdTzt1E4xw1S/+UL1UitKX5jFWU0lcO JDuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=r0CGyzPkFAJj83F3EHzVlEEp7wLzJJq0CCnYm4ji2Zw=; b=fWCV4xG5Sh1WpVpMCLYF/962WAKvPTFjbc2S8wpPTsGkIDeQqVwHVgaUEKKaiWBse4 v0CZ0UULLMwT+qvQqJ42/Lm0knbb2TBLPZiFBqhY4QpJxuiaddnI/OcfGWhkkmkmDrqm /4dWJA6yo5Wrf1CFrUYbbM/P1to1kLuHyOpkHbkOR0F81keO8jnerHwNfBAotQdlKQvY xbYMakXWX3Qahb3KugKcJoVBfexL8NgAvzZB5T0V7mMv1Wiw4YeTOfajauysSHxFoTQH Cs7DrNUN7fxvqCdZ0lXuvMAG2RK+WdlvuSAqEVDaXQ0afmv5LJ85+XD8xs8Llt4DUxgV 7dpw== X-Gm-Message-State: AA6/9RnBPFOF2TW0Q9xXHm6Tndjth08Hlm5LIi1uq1TBO7GVFFxB+ua1lRZ/zh/7XMQe5xPaaMI9IyV7OE99rA== X-Received: by 10.55.160.145 with SMTP id j139mr17915359qke.167.1474817659899; Sun, 25 Sep 2016 08:34:19 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.209.87 with HTTP; Sun, 25 Sep 2016 08:34:19 -0700 (PDT) In-Reply-To: <301D580E-D079-4D24-B5F5-BE8B58C12144@vigilsec.com> References: <301D580E-D079-4D24-B5F5-BE8B58C12144@vigilsec.com> From: Phillip Hallam-Baker Date: Sun, 25 Sep 2016 11:34:19 -0400 X-Google-Sender-Auth: Tyr9YKMF2WVAznrtF02jrOyz2LE Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=94eb2c076206ba14b2053d56bee2 Archived-At: Cc: SPASM Subject: Re: [Spasm] DRAFT Agenda for IETF 97 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2016 15:34:24 -0000 --94eb2c076206ba14b2053d56bee2 Content-Type: text/plain; charset=UTF-8 I am going to be remote. One thing that I would like to bring to the WG attention is the proposal I am making for a fingerprint format that supports both S/MIME and OpenPGP. I don't think choice of email messaging format should impose a choice of trust model. So using fingerprints to identify S/MIME certs seems like a logical approach the group may wish to explore. No decision is needed from the group now. However the OpenPGP group is deciding the v5 fingerprint format and my proposal that keeps the door open for convergence is more likely to be accepted if there is support/interest from the S/MIME world. On Sun, Sep 25, 2016 at 11:18 AM, Russ Housley wrote: > Please review and comment. > > Russ > > = = = = = = = = > > LAMPS WG Agenda > > 0) Minute Taker, Jabber Scribe, Bluesheets > 1) Agenda Bash > 2) Status and open issues on WG documents > a) draft-ietf-lamps-eai-addresses (Alexey and Wei) > b) draft-ietf-lamps-rfc5750-bis (Jim) > c) draft-ietf-lamps-rfc5751-bis (Jim) > 3) Any other business (if time allows) > 4) Wrap Up > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --94eb2c076206ba14b2053d56bee2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I a= m going to be remote.

One= thing that I would like to bring to the WG attention is the proposal I am = making for a fingerprint format that supports both S/MIME and OpenPGP.


I don't think choice of email messa= ging format should impose a choice of trust model. So using fingerprints to= identify S/MIME certs seems like a logical approach the group may wish to = explore.

No decision is n= eeded from the group now. However the OpenPGP group is deciding the v5 fing= erprint format and my proposal that keeps the door open for convergence is = more likely to be accepted if there is support/interest from the S/MIME wor= ld.

<= div class=3D"gmail_default" style=3D"font-size:small">



On Sun, Sep 25, 2016 at 11:18 AM, Russ Ho= usley <housley@vigilsec.com> wrote:
Please review and comment.

Russ

=3D =3D =3D =3D =3D =3D =3D =3D

LAMPS WG Agenda

0)=C2=A0 Minute Taker, Jabber Scribe, Bluesheets
1)=C2=A0 Agenda Bash
2)=C2=A0 Status and open issues on WG documents
=C2=A0 =C2=A0 a)=C2=A0 draft-ietf-lamps-eai-addresses (Alexey and Wei)
=C2=A0 =C2=A0 b)=C2=A0 draft-ietf-lamps-rfc5750-bis (Jim)
=C2=A0 =C2=A0 c)=C2=A0 draft-ietf-lamps-rfc5751-bis (Jim)
3)=C2=A0 Any other business (if time allows)
4)=C2=A0 Wrap Up

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--94eb2c076206ba14b2053d56bee2-- From nobody Sun Sep 25 18:49:08 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AAD12B062; Sun, 25 Sep 2016 18:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no 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 0oPt1DxWeTMt; Sun, 25 Sep 2016 18:49:05 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59B512B05D; Sun, 25 Sep 2016 18:49:04 -0700 (PDT) Received: from [10.59.2.102] (unknown [206.214.36.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4A2D150A73; Sun, 25 Sep 2016 21:49:01 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: <1474387598.144982.452.camel@infradead.org> Date: Sun, 25 Sep 2016 18:48:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387598.144982.452.camel@infradead.org> To: David Woodhouse , spasm@ietf.org, Security Area Advisory Group X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Michael Richardson , Alan DeKok Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 01:49:07 -0000 > On Sep 20, 2016, at 9:06 AM, David Woodhouse = wrote: >=20 > My goal is that > we should be able to refer to certificates in a simple consistent way. >=20 > If the certificate is in a system store then applications should allow > it to be used by means of a consistent identifier string (which is > defined by RFC7512 for PKCS#11, and may be different for OSX/Windows > system certificate stores). >=20 > If the certificate is in a file, obviously the identifier is the > filename... but we need to fix applications so that they actually > *accept* all types of files. Which as I said, none of them do at the > moment. Hello David: draft-seantek-certspec =E2=80=9CTextual Specification for = Certificates=E2=80=9D is exactly what you=E2=80=99re looking for. https://tools.ietf.org/html/draft-seantek-certspec-09 That is for certificates. And yes, it handles pkcs11 just like = everything else. It also has an algorithm for automatically detecting = textual encoding (RFC 7468) vs. DER encoding. Discussions about PKCS #12 = issues were added to recent drafts. *** Private keys are another matter. The approach could easily be extended = to handle private keys. They are just identifiers, after all. However, = by definition secure private keys are a =E2=80=9Clocal matter=E2=80=9D. = I do not see the value of standardizing an identifier for private keying = materials when the implementations are all different and are not = supposed to communicate with each other. You can, of course, always = refer to a private key indirectly, by referencing an associated = certificate. It is very plausible to identify a certificate stored in a = local file (that does not need to be encrypted), and then to look up the = associated private key on a token that has a lot more protection around = the key, by using the certificate or its metadata as the dbkey/index. [The aforementioned paragraph is also responsive to Ted Lemon=E2=80=99s = concern: =E2=80=9Cone concern I have about it is that we actually really = don't want applications to have access to private keys.=E2=80=9D] Regards, Sean From nobody Sun Sep 25 18:49:21 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5F212B069 for ; Sun, 25 Sep 2016 18:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no 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 R8ZW8HHWCOSe for ; Sun, 25 Sep 2016 18:49:08 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D8612B05D for ; Sun, 25 Sep 2016 18:49:07 -0700 (PDT) Received: from [10.59.2.102] (unknown [206.214.36.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D4D9650A86; Sun, 25 Sep 2016 21:49:06 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_47F49ACF-D042-4283-BAC8-52C82CFAD4E4" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: Date: Sun, 25 Sep 2016 18:49:06 -0700 Message-Id: References: <301D580E-D079-4D24-B5F5-BE8B58C12144@vigilsec.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SPASM , Russ Housley Subject: Re: [Spasm] DRAFT Agenda for IETF 97 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 01:49:10 -0000 --Apple-Mail=_47F49ACF-D042-4283-BAC8-52C82CFAD4E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Philip: Where is your proposal? Regards, Sean > On Sep 25, 2016, at 8:34 AM, Phillip Hallam-Baker = wrote: >=20 > I am going to be remote. >=20 > One thing that I would like to bring to the WG attention is the = proposal I am making for a fingerprint format that supports both S/MIME = and OpenPGP. >=20 >=20 > I don't think choice of email messaging format should impose a choice = of trust model. So using fingerprints to identify S/MIME certs seems = like a logical approach the group may wish to explore. >=20 > No decision is needed from the group now. However the OpenPGP group is = deciding the v5 fingerprint format and my proposal that keeps the door = open for convergence is more likely to be accepted if there is = support/interest from the S/MIME world. >=20 >=20 >=20 >=20 >=20 > On Sun, Sep 25, 2016 at 11:18 AM, Russ Housley > wrote: > Please review and comment. >=20 > Russ >=20 > =3D =3D =3D =3D =3D =3D =3D =3D >=20 > LAMPS WG Agenda >=20 > 0) Minute Taker, Jabber Scribe, Bluesheets > 1) Agenda Bash > 2) Status and open issues on WG documents > a) draft-ietf-lamps-eai-addresses (Alexey and Wei) > b) draft-ietf-lamps-rfc5750-bis (Jim) > c) draft-ietf-lamps-rfc5751-bis (Jim) > 3) Any other business (if time allows) > 4) Wrap Up >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm = >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --Apple-Mail=_47F49ACF-D042-4283-BAC8-52C82CFAD4E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Philip:

Where is your proposal?

Regards,

Sean

On = Sep 25, 2016, at 8:34 AM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

I am = going to be remote.

One thing that I would = like to bring to the WG attention is the proposal I am making for a = fingerprint format that supports both S/MIME and OpenPGP.


I don't think choice = of email messaging format should impose a choice of trust model. So = using fingerprints to identify S/MIME certs seems like a logical = approach the group may wish to explore.

No decision is needed = from the group now. However the OpenPGP group is deciding the v5 = fingerprint format and my proposal that keeps the door open for = convergence is more likely to be accepted if there is support/interest = from the S/MIME world.





On Sun, Sep 25, 2016 at 11:18 AM, Russ Housley = <housley@vigilsec.com> = wrote:
Please review and = comment.

Russ

=3D =3D =3D =3D =3D =3D =3D =3D

LAMPS WG Agenda

0)  Minute Taker, Jabber Scribe, Bluesheets
1)  Agenda Bash
2)  Status and open issues on WG documents
    a)  draft-ietf-lamps-eai-addresses (Alexey and = Wei)
    b)  draft-ietf-lamps-rfc5750-bis (Jim)
    c)  draft-ietf-lamps-rfc5751-bis (Jim)
3)  Any other business (if time allows)
4)  Wrap Up

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

_______________________________________________
Spasm = mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

= --Apple-Mail=_47F49ACF-D042-4283-BAC8-52C82CFAD4E4-- From nobody Sun Sep 25 18:50:38 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0551312B067 for ; Sun, 25 Sep 2016 18:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no 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 c_kLN1np9hDh for ; Sun, 25 Sep 2016 18:50:35 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23AC912B065 for ; Sun, 25 Sep 2016 18:50:35 -0700 (PDT) Received: from [10.59.2.102] (unknown [206.214.36.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C6B0A509B6; Sun, 25 Sep 2016 21:50:33 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8C19F9D8-73DF-49EE-9CA7-7717793AA152" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: Date: Sun, 25 Sep 2016 18:50:32 -0700 Message-Id: <61E905A2-E024-4493-AA12-92AD323A2787@seantek.com> References: <301D580E-D079-4D24-B5F5-BE8B58C12144@vigilsec.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SPASM , Russ Housley Subject: Re: [Spasm] DRAFT Agenda for IETF 97 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 01:50:37 -0000 --Apple-Mail=_8C19F9D8-73DF-49EE-9CA7-7717793AA152 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My bad=E2=80=94I see the draft now. draft-hallambaker-udf-03 Sean > On Sep 25, 2016, at 6:49 PM, Sean Leonard = wrote: >=20 > Hi Philip: >=20 > Where is your proposal? >=20 > Regards, >=20 > Sean >=20 >> On Sep 25, 2016, at 8:34 AM, Phillip Hallam-Baker = > wrote: >>=20 >> I am going to be remote. >>=20 >> One thing that I would like to bring to the WG attention is the = proposal I am making for a fingerprint format that supports both S/MIME = and OpenPGP. >>=20 >>=20 >> I don't think choice of email messaging format should impose a choice = of trust model. So using fingerprints to identify S/MIME certs seems = like a logical approach the group may wish to explore. >>=20 >> No decision is needed from the group now. However the OpenPGP group = is deciding the v5 fingerprint format and my proposal that keeps the = door open for convergence is more likely to be accepted if there is = support/interest from the S/MIME world. >>=20 >>=20 >>=20 >>=20 >>=20 >> On Sun, Sep 25, 2016 at 11:18 AM, Russ Housley > wrote: >> Please review and comment. >>=20 >> Russ >>=20 >> =3D =3D =3D =3D =3D =3D =3D =3D >>=20 >> LAMPS WG Agenda >>=20 >> 0) Minute Taker, Jabber Scribe, Bluesheets >> 1) Agenda Bash >> 2) Status and open issues on WG documents >> a) draft-ietf-lamps-eai-addresses (Alexey and Wei) >> b) draft-ietf-lamps-rfc5750-bis (Jim) >> c) draft-ietf-lamps-rfc5751-bis (Jim) >> 3) Any other business (if time allows) >> 4) Wrap Up >>=20 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm = >>=20 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --Apple-Mail=_8C19F9D8-73DF-49EE-9CA7-7717793AA152 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My bad=E2=80=94I see the draft now.

draft-hallambaker-udf-03

Sean

On Sep 25, 2016, at 6:49 PM, Sean Leonard <dev+ietf@seantek.com> wrote:

Hi Philip:

Where is your = proposal?

Regards,

Sean

On Sep = 25, 2016, at 8:34 AM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

I am = going to be remote.

One thing that I would = like to bring to the WG attention is the proposal I am making for a = fingerprint format that supports both S/MIME and OpenPGP.


I don't think choice = of email messaging format should impose a choice of trust model. So = using fingerprints to identify S/MIME certs seems like a logical = approach the group may wish to explore.

No decision is needed = from the group now. However the OpenPGP group is deciding the v5 = fingerprint format and my proposal that keeps the door open for = convergence is more likely to be accepted if there is support/interest = from the S/MIME world.





On Sun, Sep 25, 2016 at 11:18 AM, Russ Housley = <housley@vigilsec.com> = wrote:
Please review and = comment.

Russ

=3D =3D =3D =3D =3D =3D =3D =3D

LAMPS WG Agenda

0)  Minute Taker, Jabber Scribe, Bluesheets
1)  Agenda Bash
2)  Status and open issues on WG documents
    a)  draft-ietf-lamps-eai-addresses (Alexey and = Wei)
    b)  draft-ietf-lamps-rfc5750-bis (Jim)
    c)  draft-ietf-lamps-rfc5751-bis (Jim)
3)  Any other business (if time allows)
4)  Wrap Up

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

_______________________________________________
Spasm = mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

= --Apple-Mail=_8C19F9D8-73DF-49EE-9CA7-7717793AA152-- From nobody Sun Sep 25 19:02:05 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB5212B05D for ; Sun, 25 Sep 2016 19:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no 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 5ONecpjHLhBk for ; Sun, 25 Sep 2016 19:02:03 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2495C12B05B for ; Sun, 25 Sep 2016 19:02:03 -0700 (PDT) Received: from [10.59.2.102] (unknown [206.214.36.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3B973509B6 for ; Sun, 25 Sep 2016 22:02:01 -0400 (EDT) From: Sean Leonard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <3E2CD03C-FC96-4E9C-99C8-CB96FB937ABD@seantek.com> Date: Sun, 25 Sep 2016 19:02:00 -0700 To: SPASM Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Spasm] Changing mailing list to LAMPS? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 02:02:04 -0000 I thought that since the WG name was changed to LAMPS, that the mailing = list name was going to change to LAMPS too. What=E2=80=99s going on = with that? Regards, Sean= From BATV+421cd2077d379962b7d4+4782+infradead.org+dwmw2@bombadil.srs.infradead.org Mon Sep 26 02:17:37 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5286712B071; Mon, 26 Sep 2016 02:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no 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 ARArsZJvO1GS; Mon, 26 Sep 2016 02:17:35 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 497E612B0A6; Mon, 26 Sep 2016 02:17:35 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1boS2V-0003a3-03; Mon, 26 Sep 2016 09:17:31 +0000 Message-ID: <1474881447.45169.205.camel@infradead.org> From: David Woodhouse To: Sean Leonard , spasm@ietf.org, Security Area Advisory Group Date: Mon, 26 Sep 2016 10:17:27 +0100 In-Reply-To: <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-OLXiXaPVXHHam9n3Gfbx" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: Michael Richardson , Alan DeKok Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 09:28:29 -0000 --=-OLXiXaPVXHHam9n3Gfbx Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2016-09-25 at 18:48 -0700, Sean Leonard wrote: > Hello David: >=20 > draft-seantek-certspec =E2=80=9CTextual Specification for Certificates=E2= =80=9D is > exactly what you=E2=80=99re looking for. >=20 > https://tools.ietf.org/html/draft-seantek-certspec-09 Thanks; that's very interesting. I'm not sure it covers exactly the same use case, but it's very closely related. > That is for certificates. And yes, it handles pkcs11 just like > everything else.=20 ... but not like RFC7512 does, I note. Is it worth trying to achieve some better consistency there? After all, I can *already* refer to the certificate in my crypto token consistently as=C2=A0 'pkcs11:manufacturer=3Dpiv_II;id=3D%01' in a variety of applications using different crypto libraries. And in fact on my operating system of choice I can file a bug for any application which *doesn't* accept that string, when it would have taken a filename. So I'd definitely like to see your draft make explicit reference to RFC7512 in some form or other. > *** >=20 > Private keys are another matter. The approach could easily be > extended to handle private keys. They are just identifiers, after > all. However, by definition secure private keys are a =E2=80=9Clocal matt= er=E2=80=9D. > I do not see the value of standardizing an identifier for private > keying materials when the implementations are all different and are > not supposed to communicate with each other.=20 Ah, but that is *precisely* the matter I was most concerned about. It's not so much about implementations communicating with each other; it's about consistency and (hence) usability. Not very long ago, in order to use that key in the crypto token I mentioned above, I had to do something *different* for fairly much every application: =C2=A0=E2=80=A2 for OpenVPN, I had to manually specifier the PKCS#11 provid= er =C2=A0 =C2=A0module and use one form of identifier string. =C2=A0=E2=80=A2 for OpenConnect, RFC7512 identifiers Just Worked, and it us= ed =C2=A0 =C2=A0the PKCS#11 providers indicated by the system configuration. (= Yay!) =C2=A0=E2=80=A2 for Curl (if built with NSS) I needed to manually edit conf= iguration =C2=A0 =C2=A0files to make it load the right module, and then refer to the =C2=A0 =C2=A0object by a *third* form of identifier string. =C2=A0=E2=80=A2 for wpa_supplicant I had to manually configure it to use an= OpenSSL =C2=A0 =C2=A0"Engine", specify the provider in yet *another* different mann= er =C2=A0 =C2=A0because that also ignored the system configuration, and then g= ive =C2=A0 =C2=A0the certificate ID in a *fourth* different form. And that was just for the applications which *could* use PKCS#11. Many just couldn't do it at all. And for some, they needed to be configured differently depending on which crypto library they'd been built against. It made me kind of sad. FWIW I have all of the above just taking PKCS#11 URIs according to RFC7512 now, without any of the additional configuration nonsense like loading engines and specifying provider modules. Now, *part* of that is addressed by your draft (although it's already addressed by RFC7512 in the case of PKCS#11, and the conflicts there want resolving). But other parts are not =E2=80=94 and I'm not sure you rea= lly want to expand your scope to cover them. They include: =C2=A0=E2=80=A2 Using the system configuration for which PKCS#11 providers = to load. =C2=A0=E2=80=A2 The search algorithm, identifying when to log in to a token= to =C2=A0 =C2=A0attempt to find a certificate with CKA_PRIVATE and how to loca= te =C2=A0 =C2=A0the key corresponding to a given certificate, etc. =C2=A0=E2=80=A2 The requirement that opaque private keys without access to = the =C2=A0 =C2=A0corresponding public key SHALL work. That's just for PKCS#11. of course. For files there are a different set of issues =E2=80=94 mostly the fact that every application on the system wi= ll currently support a *different* subset of private key file formats. So a user with a certificate+key provisioned through her organisation's proprietary scripting will find that it works with *some* applications and not others, for reasons which are entirely intractable, such as: =C2=A0=E2=80=A2 It uses the non-standard OpenSSL 'encrypted PEM' format. =C2=A0=E2=80=A2 It uses a SHA256 HMAC which isn't universally supported. =C2=A0=E2=80=A2 It is encrypted with DES-MD5, which isn't universally suppo= rted. =C2=A0=E2=80=A2 It is in DER form, which applications need to jump through = hoops =C2=A0 =C2=A0to cope with loading because crypto libraries hate us all. The idea of my draft is to give a set of "best practice" guidelines for applications so that the user *can* just use the same certificate and key with any well-behaved application, with exactly the same identifier, and it will Just Work. It's not *just* about the identifier though, and in fact I've mostly tried to make it *not* about the identifier. I just defer to RFC7512 and obviously to filenames. For the system certificate stores I just say that if a convention exists, it should be supported =E2=80=94 and it so= unds like your draft would be the ideal solution to fill that gap. So while there is certainly an overlap with your draft, there's also a lot to cope with that *isn't* already the primary target of your draft. If you want, I'm happy to work with you to *make* your draft cover this. But I suspect there would be sufficient conflict in our use cases that it's best just to ensure that they complement each other to achieve their respective goals. What do you think? For reference, the current version of my nascent draft is at http://david.woodhou.se/draft-woodhouse-cert-best-practice.html=C2=A0and it's also at=C2=A0https://github.com/dwmw2/ietf-cert-best-practice > You can, of course, always refer to a private key indirectly, by > referencing an associated certificate. It is very plausible to > identify a certificate stored in a local file (that does not need to > be encrypted), and then to look up the associated private key on a > token that has a lot more protection around the key, by using the > certificate or its metadata as the dbkey/index. Yes, there is lots of fun to be had here. Lots of reasonable heuristics for how to find a key given the certificates =E2=80=94 and thus lots of sco= pe for applications to be inconsistent and for users to complain "it works in XXX, so why doesn't exactly the same cert work in YYY?". I've attempted to address this with the search algorithm for PKCS#11. For files there's not a lot you can do although I do mention that if the cert has extension '.crt' and doesn't actually contain the private key, you might look for a corresponding file with extension 'key'. There are probably more improvements that can be made in this area, especially when it comes to the system stores on Windows and OSX. > [The aforementioned paragraph is also responsive to Ted Lemon=E2=80=99s > concern: =E2=80=9Cone concern I have about it is that we actually really > don't want applications to have access to private keys.=E2=80=9D] Yes, we absolutely need to support and encourage that use case. That is part of my motivation for pushing to have PKCS#11 supported consistently across applications on platforms where that's the best answer. --=20 dwmw2 --=-OLXiXaPVXHHam9n3Gfbx Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTI2MDkxNzI4WjAvBgkqhkiG9w0BCQQxIgQgvCAszmscVHMTXribTsWp7JlIOmXpvjd3AQjF /2tYGaAwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAF7R yop4jrnLzz1kQmPMBcok03z6D6UBVhalcxqnK1XSc4e6ILcrKZihY9QsJ2B4N7WovMvGx0/kj/Yo 7xxiv2ebj1ZPO8WPzQstlwlBBB5kvKjVc0sidWS+ww5NVoF3V0dpedztyNA6MJdlx8YyMqVS5sCN nm3eRP+vhJ/goBdHoTNHTBzX1s+PCqmJkW67lqmyprMlIVpFOjo6Qkrol98Ynv+P2udTUpVC6GyZ M+ynWsW533e5f3CAuT+2oyVx8D8nzcSln2VBppyNTDY81lzk6o8Q7MkQRcEHGAoTiNCOBuxzECWx fixrhdXq9+RuPCO0W4ZUSWV81abEzSz6k8XfIC3DaTeCMnzKZrGMdoZNC9+KjpldNt0zseIvj0d8 DuWOX1rteH4mdFnGtWm2l57Fn49eUrMg7TE2ylb9cH9cB0t1EnKDPBXNLIvsoFP9SSasqsLY1yIJ n2tv7iBZrIXTFKj0USzUm3P6/c+hHmS7+rSbERh11CIQ3nKuuPp5T2PAkDDiZggBEGTj4qsTB/Ui RVJK6QtQe2k89oJXri5yKigkzPqWEStFx+A7hW0Y3Y9ZaHdhoLFypHmlfGBWevQ6YqAADB0D30aL 3FzS7wCtYQLVG1FqxcRDRNgMAG+Ay91AQOyCa4cafMhdJ0oTcoSeyNF0fBmkxyW6EBM8+8VCAAAA AAAA --=-OLXiXaPVXHHam9n3Gfbx-- From nobody Mon Sep 26 12:09:09 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B9912B2A7; Mon, 26 Sep 2016 12:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no 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 M0NLQFzEs43s; Mon, 26 Sep 2016 12:09:02 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C8A12B26E; Mon, 26 Sep 2016 12:09:01 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1DE3950A84; Mon, 26 Sep 2016 15:08:59 -0400 (EDT) To: David Woodhouse , spasm@ietf.org, Security Area Advisory Group References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> From: Sean Leonard Message-ID: <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> Date: Mon, 26 Sep 2016 12:10:41 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1474881447.45169.205.camel@infradead.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Michael Richardson , Alan DeKok Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 19:09:09 -0000 On 9/26/2016 2:17 AM, David Woodhouse wrote: > On Sun, 2016-09-25 at 18:48 -0700, Sean Leonard wrote: >> Hello David: >> >> draft-seantek-certspec =E2=80=9CTextual Specification for Certificates= =E2=80=9D is >> exactly what you=E2=80=99re looking for. >> >> https://tools.ietf.org/html/draft-seantek-certspec-09 > Thanks; that's very interesting. I'm not sure it covers exactly the > same use case, but it's very closely related. Great! > >> That is for certificates. And yes, it handles pkcs11 just like >> everything else. > ... but not like RFC7512 does, I note. Is it worth trying to achieve > some better consistency there? After all, I can *already* refer to the > certificate in my crypto token consistently as > > 'pkcs11:manufacturer=3Dpiv_II;id=3D%01' > > in a variety of applications using different crypto libraries. And in > fact on my operating system of choice I can file a bug for any > application which *doesn't* accept that string, when it would have > taken a filename. So I'd definitely like to see your draft make > explicit reference to RFC7512 in some form or other. I can do that...although the value of doing so may be a bit lost on me.=20 The general syntax would be: URI:pkcs11:manufacturer=3Dpiv_II;id=3D%01 The syntax of "URI:uri" (with URI: prepended) has a long and tumultuous=20 history. You can look at the draft history to see why. Applications for draft-seantek-certspec are hunting for certificates on=20 the order of sub-milliseconds: looking up a certificate could be done in = a blocking operation. This would be the case, for example, when a TLS=20 server (web server, IMAP server, etc.) or client boots up and needs the=20 certificate before starting its first TLS connection. As a general=20 matter, URIs strongly imply network access; therefore they are not as=20 important as the other types of specs. Any application that plans on using a certificate with its corresponding = private key should obviously have the certificate on-hand and=20 at-the-ready. Even if the private key is unavailable (e.g., the hardware = token is not in the slot), some pointer that shows that a private key is = known to be around, has to be immediately available. That way the UI can = prompt the user for the right device. A distinguishing feature of URIs is that it is limited in its repertoire = of characters to a strict subset of ASCII, with % percent-encoding. This = means that LDAP strings are going to look very convoluted, with a lot of = %20, %2F, %3B, etc. throughout. If you want to permit users to specify=20 strings without double or triple % encoding and \ escaping and whatnot,=20 then I can buy an argument to promote "p11:" or similar to the top of a=20 certspec, and not buried into the "URI:" spec type. There is precedent=20 for this because there are already BASE64 and HEX specs, which duplicate = URI:data: in functionality, but are demonstrably easier to use. By the way, RFC 7512 contains a serious bug: the | character is not=20 valid in URI [RFC3986]. I don't know how that character snuck through=20 the RFC process, but it's not a valid URI. RFC 7512 contains a second, less serious bug: "The URI scheme does not=20 use the fragment component." Well that may or may not be good advice. I=20 don't see why a PKCS #11 token can't return a blob that is plain text=20 (text/plain), in which case, fragment would be defined by RFC 5147.=20 Furthermore, PKCS #11 is actually Internet media type-aware: see=20 CKA_MIME_TYPES, for example, in that standard. > >> *** >> >> Private keys are another matter. The approach could easily be >> extended to handle private keys. They are just identifiers, after >> all. However, by definition secure private keys are a =E2=80=9Clocal m= atter=E2=80=9D. >> I do not see the value of standardizing an identifier for private >> keying materials when the implementations are all different and are >> not supposed to communicate with each other. > Ah, but that is *precisely* the matter I was most concerned about. It's= > not so much about implementations communicating with each other; it's > about consistency and (hence) usability. > > Not very long ago, in order to use that key in the crypto token I > mentioned above, I had to do something *different* for fairly much > every application: > > =E2=80=A2 for OpenVPN, I had to manually specifier the PKCS#11 provid= er > module and use one form of identifier string. > =E2=80=A2 for OpenConnect, RFC7512 identifiers Just Worked, and it us= ed > the PKCS#11 providers indicated by the system configuration. (Yay!)= > =E2=80=A2 for Curl (if built with NSS) I needed to manually edit conf= iguration > files to make it load the right module, and then refer to the > object by a *third* form of identifier string. > =E2=80=A2 for wpa_supplicant I had to manually configure it to use an= OpenSSL > "Engine", specify the provider in yet *another* different manner > because that also ignored the system configuration, and then give > the certificate ID in a *fourth* different form. > > And that was just for the applications which *could* use PKCS#11. Many > just couldn't do it at all. And for some, they needed to be configured > differently depending on which crypto library they'd been built > against. > > It made me kind of sad. FWIW I have all of the above just taking > PKCS#11 URIs according to RFC7512 now, without any of the additional > configuration nonsense like loading engines and specifying provider > modules. That is indeed a list of horribles. But for applications that are PKCS #11 based, one could easily write a=20 script that takes a pkcs11: URI as input and outputs the right flips,=20 switches, config files, and API calls to do what the pkcs11: URI is=20 saying to do. Probably would take less than a day. For applications that are *not* PKCS #11 based (macOS Keychain Services, = Windows CNG), using a PKCS #11 URI would be..."grotesque". I don't know=20 of a better way to put it. > > Now, *part* of that is addressed by your draft (although it's already > addressed by RFC7512 in the case of PKCS#11, and the conflicts there > want resolving). But other parts are not =E2=80=94 and I'm not sure you= really > want to expand your scope to cover them. They include: > > =E2=80=A2 Using the system configuration for which PKCS#11 providers = to load. > =E2=80=A2 The search algorithm, identifying when to log in to a token= to > attempt to find a certificate with CKA_PRIVATE and how to locate > the key corresponding to a given certificate, etc. > =E2=80=A2 The requirement that opaque private keys without access to = the > corresponding public key SHALL work. > > That's just for PKCS#11. of course. For files there are a different set= > of issues =E2=80=94 mostly the fact that every application on the syste= m will > currently support a *different* subset of private key file formats. So > a user with a certificate+key provisioned through her organisation's > proprietary scripting will find that it works with *some* applications > and not others, for reasons which are entirely intractable, such as: > > =E2=80=A2 It uses the non-standard OpenSSL 'encrypted PEM' format. > =E2=80=A2 It uses a SHA256 HMAC which isn't universally supported. > =E2=80=A2 It is encrypted with DES-MD5, which isn't universally suppo= rted. > =E2=80=A2 It is in DER form, which applications need to jump through = hoops > to cope with loading because crypto libraries hate us all. > > The idea of my draft is to give a set of "best practice" guidelines for= > applications so that the user *can* just use the same certificate and > key with any well-behaved application, with exactly the same > identifier, and it will Just Work. > > It's not *just* about the identifier though, and in fact I've mostly > tried to make it *not* about the identifier. I just defer to RFC7512 > and obviously to filenames. For the system certificate stores I just > say that if a convention exists, it should be supported =E2=80=94 and i= t sounds > like your draft would be the ideal solution to fill that gap. > > So while there is certainly an overlap with your draft, there's also a > lot to cope with that *isn't* already the primary target of your draft.= Okay. Yes, the primary target of the draft is identifying certificates=20 (uniquely and unambiguously), and providing associated attributes with=20 the certspec. Interestingly, one of those "associated attributes" could=20 very well be: "hint or directive about where to find the private key".=20 So that is a point of extension that we could collaborate on, whether in = draft-seantek-certspec or in a related draft. For interoperable private key formats, I favor PKCS #8 PrivateKeyInfo=20 (as .p8) and PKCS #8 EncryptedPrivateKeyInfo (as .p8e). They are=20 standardized, widely-supported, and algorithm-agile. They are also=20 simple enough that even if a crypto stack doesn't support them directly, = "adapters" can be built that shoehorn the data into other container=20 formats, such as PKCS #12, OpenSSL's proprietary formats, and so on.=20 (Note that I worked on the registrations for both application/pkcs12 and = application/pkcs8-encrypted.) > If you want, I'm happy to work with you to *make* your draft cover > this. But I suspect there would be sufficient conflict in our use cases= > that it's best just to ensure that they complement each other to > achieve their respective goals. What do you think? I am happy to make draft-seantek-certspec more useful to different=20 constituents! The focus needs to remain on uniquely identifying cryptographic data=20 items, rather than as a generalized querying format. (Discussed in=20 draft.) However, I like the idea of a standardized attribute that points = to the location of a private key. Such an attribute could also be=20 conveniently serialized into other formats, e.g., as attributes in PKCS=20 #11 and PKCS #12, and as Certificate Properties in Microsoft CryptoAPI.=20 That is exactly how crypto stacks operate anyway: they tag a certificate = with a little pointer that points to where to find the private key, if=20 one exists. > > For reference, the current version of my nascent draft is at > http://david.woodhou.se/draft-woodhouse-cert-best-practice.html and > it's also at https://github.com/dwmw2/ietf-cert-best-practice Thanks, I read it. > >> You can, of course, always refer to a private key indirectly, by >> referencing an associated certificate. It is very plausible to >> identify a certificate stored in a local file (that does not need to >> be encrypted), and then to look up the associated private key on a >> token that has a lot more protection around the key, by using the >> certificate or its metadata as the dbkey/index. > Yes, there is lots of fun to be had here. Lots of reasonable heuristics= > for how to find a key given the certificates =E2=80=94 and thus lots of= scope > for applications to be inconsistent and for users to complain "it works= > in XXX, so why doesn't exactly the same cert work in YYY?". > > I've attempted to address this with the search algorithm for PKCS#11. > For files there's not a lot you can do although I do mention that if > the cert has extension '.crt' and doesn't actually contain the private > key, you might look for a corresponding file with extension 'key'. > > There are probably more improvements that can be made in this area, > especially when it comes to the system stores on Windows and OSX. Okay. >> [The aforementioned paragraph is also responsive to Ted Lemon=E2=80=99= s >> concern: =E2=80=9Cone concern I have about it is that we actually real= ly >> don't want applications to have access to private keys.=E2=80=9D] > Yes, we absolutely need to support and encourage that use case. That is= > part of my motivation for pushing to have PKCS#11 supported > consistently across applications on platforms where that's the best > answer. Good. Regards, Sean From nobody Mon Sep 26 12:48:58 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540B812B29C; Mon, 26 Sep 2016 12:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no 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 hGl_O_WykIln; Mon, 26 Sep 2016 12:48:50 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 8A94E12B249; Mon, 26 Sep 2016 12:48:50 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bobtR-00028W-4b; Mon, 26 Sep 2016 19:48:49 +0000 Message-ID: <1474919326.45169.305.camel@infradead.org> From: David Woodhouse To: Sean Leonard , spasm@ietf.org, Security Area Advisory Group Date: Mon, 26 Sep 2016 20:48:46 +0100 In-Reply-To: <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-NDDM2SvdXvsnlz5v8HQb" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: Michael Richardson , Alan DeKok Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 19:48:52 -0000 --=-NDDM2SvdXvsnlz5v8HQb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2016-09-26 at 12:10 -0700, Sean Leonard wrote: > > > That is for certificates. And yes, it handles pkcs11 just like > > > everything else. > > ... but not like RFC7512 does, I note. Is it worth trying to achieve > > some better consistency there? After all, I can *already* refer to the > > certificate in my crypto token consistently as > >=20 > > 'pkcs11:manufacturer=3Dpiv_II;id=3D%01' > >=20 > > in a variety of applications using different crypto libraries. And in > > fact on my operating system of choice I can file a bug for any > > application which *doesn't* accept that string, when it would have > > taken a filename. So I'd definitely like to see your draft make > > explicit reference to RFC7512 in some form or other. >=20 > I can do that...although the value of doing so may be a bit lost on me.= =20 > The general syntax would be: >=20 > URI:pkcs11:manufacturer=3Dpiv_II;id=3D%01 >=20 > The syntax of "URI:uri" (with URI: prepended) has a long and tumultuous= =20 > history. You can look at the draft history to see why. >=20 > Applications for draft-seantek-certspec are hunting for certificates on= =20 > the order of sub-milliseconds: looking up a certificate could be done in= =20 > a blocking operation. This would be the case, for example, when a TLS=20 > server (web server, IMAP server, etc.) or client boots up and needs the= =20 > certificate before starting its first TLS connection. As a general=20 > matter, URIs strongly imply network access; therefore they are not as=20 > important as the other types of specs. As far as I can tell, the PKCS#11 URI is not a URI. It's just a set of search terms, similar in many ways to the ones in your own draft =E2=80=94 except with a specific focus on what's searchable in the PKCS#11 API. It's just an identifier; it's not valid to make general inferences about it, along the lines of "URIs strongly imply network access". As such, I'd be inclined to suggest that the general syntax for it in your draft might be the PKCS#11 URI itself, starting with 'pkcs11:'. > Any application that plans on using a certificate with its corresponding= =20 > private key should obviously have the certificate on-hand and=20 > at-the-ready. Even if the private key is unavailable (e.g., the hardware= =20 > token is not in the slot), some pointer that shows that a private key is= =20 > known to be around, has to be immediately available. That way the UI can= =20 > prompt the user for the right device. >=20 > A distinguishing feature of URIs is that it is limited in its repertoire= =20 > of characters to a strict subset of ASCII, with % percent-encoding. This= =20 > means that LDAP strings are going to look very convoluted, with a lot of= =20 > %20, %2F, %3B, etc. throughout.=20 Who said anything about LDAP strings? I was *only* talking about the PKCS#11 identifiers as defined in RFC7512. Which aren't really URIs although that term is used there quite a lot :) > If you want to permit users to specify=20 > strings without double or triple % encoding and \ escaping and whatnot,= =20 > then I can buy an argument to promote "p11:" or similar to the top of a= =20 > certspec, and not buried into the "URI:" spec type.=20 No, I absolutely don't want *more* ways of referring to the same objects, and more things for the users to try, and discover are inconsistently supported across the set of applcatiions they use. > By the way, RFC 7512 contains a serious bug: the | character is not=20 > valid in URI [RFC3986]. I don't know how that character snuck through=20 > the RFC process, but it's not a valid URI. Fine, there are almost no circumstances when you might want to use the RFC7512 identifier as if it's *really* a URI. It looks like you *suggested* it above, but I think you're the first, and I just told you not to :) > RFC 7512 contains a second, less serious bug: "The URI scheme does not= =20 > use the fragment component." Well that may or may not be good advice. I= =20 > don't see why a PKCS #11 token can't return a blob that is plain text=20 > (text/plain), in which case, fragment would be defined by RFC 5147.=20 > Furthermore, PKCS #11 is actually Internet media type-aware: see=20 > CKA_MIME_TYPES, for example, in that standard. It's an identifier for an object. It is (deliberately AFAICT) not actually a real URI that you might for example put into the location bar of your web browser and expect it to do anything useful. > That is indeed a list of horribles. >=20 > But for applications that are PKCS #11 based, one could easily write a= =20 > script that takes a pkcs11: URI as input and outputs the right flips,=20 > switches, config files, and API calls to do what the pkcs11: URI is=20 > saying to do. Probably would take less than a day. You could do that. Not sure it would entirely meet my criteria for usability though. Better to fix the applications so that they all just accept the objects in the same form, than to have different 'wrappers' and 'config generators' for each application to work around their differences and convert keys between formats. > For applications that are *not* PKCS #11 based (macOS Keychain Services,= =20 > Windows CNG), using a PKCS #11 URI would be..."grotesque". I don't know= =20 > of a better way to put it. Yes. Don't attempt to use a PKCS#11 identifier for something that's not PKCS#11; that would be strange. Having said that... =E2=88=83 PKCS#11 modules which expose the functionalit= y of the keychain and of CAPI/CNG: =C2=A0 =C2=A0 =C2=A0https://github.com/slushpupie/KeychainToken =C2=A0 =C2=A0 =C2=A0https://github.com/risacher/p11-capi .. and then I suppose you *do* end up referencing objects therein via PKCS#11 attributes :) > > So while there is certainly an overlap with your draft, there's also a > > lot to cope with that *isn't* already the primary target of your draft. >=20 > Okay. Yes, the primary target of the draft is identifying certificates= =20 > (uniquely and unambiguously), and providing associated attributes with= =20 > the certspec. Interestingly, one of those "associated attributes" could= =20 > very well be: "hint or directive about where to find the private key".= =20 > So that is a point of extension that we could collaborate on, whether in= =20 > draft-seantek-certspec or in a related draft. Yes, that definitely warrants a further look. > For interoperable private key formats, I favor PKCS #8 PrivateKeyInfo=20 > (as .p8) and PKCS #8 EncryptedPrivateKeyInfo (as .p8e). They are=20 > standardized, widely-supported, and algorithm-agile.=20 They are also non-portable, because even when RFC5958 was published in 2010, FFS, it didn't mandate the conversion of the password to UTF-8 (let alone any mention of Unicode normalisation) for the purpose of the key derivation. PKCS#12 at least gets *part* of that right, by mandating UTF16BE (BMP). --=20 dwmw2 --=-NDDM2SvdXvsnlz5v8HQb Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTI2MTk0ODQ2WjAvBgkqhkiG9w0BCQQxIgQgv3ciyCODh4uAiXpTs2jlOFCdRCHX/bfo6KkI 5mNW38AwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAM+A 54eGxSrlXnpr0NzYNJPOASmnQcys2afNV/fL2m43mayptSZh69F0nmTaoE21JfQ8nH3Mu+dtr3Ge 9ItyKeHFejwewXpsls/CzxIgXqdkpGUuCJ1aaKTv5hxdHXIusPGhcWkbR2BhDR5et4sPVy308s7L USN5BTc1pKyM14HJ+MrUL3F+6IjdPE0x9i0Gi/xdr+6TVVxf8KWE1JRCHQiBTxexv6vP5L5Ulywx PNqdp2TCiPpa423MEOnYA7JIuc3myHLCsWUI+qKnkA/RFHokwb2v7SRQ3gGJUhv05XOEYJY+6YQB gWkWksYiWd16eY9LbpAiN0HssSbGFvNvcwThCqiX3pfPjxTRDIfxRUbqgEgpNHzMG8ZhrBn1grwQ CE7UDOz5wGRJWD4SQvGottTW57EK3mLBP8x6kex0PVpjG0yCHPhcXjS0uW8ypJn81RsG/f+kClSl V21SZGqGyBjIz4XeTdQCJYolk5tAGoxdM4ALty5CuktQYtURG5KS3T4yldC+oPdOZQd926ckI38C ZpM+qKeAmTug3wkZYXR7wTVqFZmLYJ3TGk7GD1tcfbt0BXrYWdPubmVlgAsC7ulgqYtCTfcRE88B Ga4+1nw6NNTucOqOGJiJjqx71ONtMt4Odo89KiXXZ4vy2InyF5Y9uBkr90XU9GKiBpOMGATsAAAA AAAA --=-NDDM2SvdXvsnlz5v8HQb-- From nobody Mon Sep 26 12:54:07 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74F312B249; Mon, 26 Sep 2016 12:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no 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 RiZE5hz6zCz1; Mon, 26 Sep 2016 12:54:04 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88961127076; Mon, 26 Sep 2016 12:54:04 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2EBDF50A84; Mon, 26 Sep 2016 15:54:03 -0400 (EDT) To: David Woodhouse , spasm@ietf.org, Security Area Advisory Group References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org> From: Sean Leonard Message-ID: Date: Mon, 26 Sep 2016 12:55:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1474919326.45169.305.camel@infradead.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Michael Richardson , Alan DeKok Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 19:54:06 -0000 On 9/26/2016 12:48 PM, David Woodhouse wrote: > >> For interoperable private key formats, I favor PKCS #8 PrivateKeyInfo >> (as .p8) and PKCS #8 EncryptedPrivateKeyInfo (as .p8e). They are >> standardized, widely-supported, and algorithm-agile. > They are also non-portable, because even when RFC5958 was published in > 2010, FFS, it didn't mandate the conversion of the password to UTF-8 > (let alone any mention of Unicode normalisation) for the purpose of the > key derivation. > > PKCS#12 at least gets *part* of that right, by mandating UTF16BE (BMP). draft-seantek-pkcs8-encrypted-01 Glad to see someone else cares about password mapping. :) Sean From nobody Mon Sep 26 13:32:56 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5540D12B23C; Mon, 26 Sep 2016 13:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, T_MIME_MALF=0.01] autolearn=unavailable autolearn_force=no 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 UAyeZY4miY9H; Mon, 26 Sep 2016 13:32:53 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 B8F7712B011; Mon, 26 Sep 2016 13:26:02 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bocTR-00085W-Qi; Mon, 26 Sep 2016 20:26:02 +0000 Message-ID: <1474921558.45169.314.camel@infradead.org> From: David Woodhouse To: Sean Leonard , spasm@ietf.org, Security Area Advisory Group Date: Mon, 26 Sep 2016 21:25:58 +0100 In-Reply-To: References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-RDHdfDJX+ViU75AAMyGb" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: Michael Richardson , Alan DeKok Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 20:32:54 -0000 --=-RDHdfDJX+ViU75AAMyGb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2016-09-26 at 12:55 -0700, Sean Leonard wrote: > On 9/26/2016 12:48 PM, David Woodhouse wrote: > > > >> For interoperable private key formats, I favor PKCS #8 PrivateKeyInfo > >> (as .p8) and PKCS #8 EncryptedPrivateKeyInfo (as .p8e). They are > >> standardized, widely-supported, and algorithm-agile. > > They are also non-portable, because even when RFC5958 was published in > > 2010, FFS, it didn't mandate the conversion of the password to UTF-8 > > (let alone any mention of Unicode normalisation) for the purpose of the > > key derivation. > > > > PKCS#12 at least gets *part* of that right, by mandating UTF16BE (BMP). >=20 > draft-seantek-pkcs8-encrypted-01 OK... so now we have can say Content-Type: application/pkcs8-encrypted; password-mapping=3DUTF-8 (Did you intend '*pkcs12' to mean UTF16-BE which is BMP, not UTF-16LE?) But I've *never* seen an application make use of certs/files from any container where that Content-Type: header might be present. It's not even permitted to put it in PEM files, is it? So does this really buy me anything in practice?=C2=A0 And it still doesn't cover Unicode normalisation. :) > Glad to see someone else cares about password mapping. Mostly when it breaks :) --=20 dwmw2 --=-RDHdfDJX+ViU75AAMyGb Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTI2MjAyNTU4WjAvBgkqhkiG9w0BCQQxIgQgGEEnwMMnnMDrfbkNynxOW3KkjszFgPRTnRbV PVV4AqgwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAABO 7Flm15FY8eR6I6fctFZ+jb3SuPRDeUPKx2RC9AXu8gIrJkDvDcwkKhilAZ3Jzu+oSTqsEsMQmR9A UjN2psln6XOaWfJsBGMZQMk4BDqPZ1kMnhDD187avveTDJJMru9vKNJfJT/CtW0GuMLDTkyAKXCr 3eggOhUqSdyIWVWSPGT2ImmSqVATySGpZuLAlASzmQQQiFR7/2SKqY1zGO8qjx0LnDW7GJR8r6k3 0cPYpPh/a8rBnwx9XHwsMjJrzxr6GQQ3yVNBjaIXY4lPkaZvypq58ffi1EnHof7EijcN7MZZOdrV pXhCFB41fKdk/IsVX058s8dP7BNyjPectW0GGAbhP0uC8K+6M+rBl2SKZ8H2diex2JA0JXPSdRFb vHfVUB2JFnQMor9wOVfVPW7P4YuCuigIDcu5zoKGnvHEpsMEwjgkvKAWLdZQ0U/4FDdnm3CsndI5 P7fgLgDG3DPHfmleaBV6KMtWC5S0DQsKopU2wYIdKmEOFgywosH8UlCm3sWWilCqexDF8PjQGfyo mq4jfnIhJyKwZGPX+VRuH639/CmEeQCnf6BkrglwYgfM/OmsEIMDejrNBlk908UmkMCar7LnHcfh ypGsPsWeARW6+Z3NFslzPVd3rzIIFGzZAC39DT2p5pqIysS3cl1Um4Igf8yW+YGsLDyjCe9xAAAA AAAA --=-RDHdfDJX+ViU75AAMyGb-- From nobody Mon Sep 26 13:59:59 2016 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2465612B01C; Mon, 26 Sep 2016 13:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no 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 tRgKlOldfg0D; Mon, 26 Sep 2016 13:59:56 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3DA312B016; Mon, 26 Sep 2016 13:59:55 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5872B50A87; Mon, 26 Sep 2016 16:59:54 -0400 (EDT) To: David Woodhouse , spasm@ietf.org, Security Area Advisory Group References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org> <1474921558.45169.314.camel@infradead.org> From: Sean Leonard Message-ID: Date: Mon, 26 Sep 2016 14:01:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1474921558.45169.314.camel@infradead.org> Content-Type: multipart/alternative; boundary="------------03FB81F1BBAC8E1DD532BC03" Archived-At: Cc: Michael Richardson , Alan DeKok Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 20:59:58 -0000 This is a multi-part message in MIME format. --------------03FB81F1BBAC8E1DD532BC03 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 9/26/2016 1:25 PM, David Woodhouse wrote: > On Mon, 2016-09-26 at 12:55 -0700, Sean Leonard wrote: >> On 9/26/2016 12:48 PM, David Woodhouse wrote: >>>> For interoperable private key formats, I favor PKCS #8 PrivateKeyInf= o >>>> (as .p8) and PKCS #8 EncryptedPrivateKeyInfo (as .p8e). They are >>>> standardized, widely-supported, and algorithm-agile. >>> They are also non-portable, because even when RFC5958 was published i= n >>> 2010, FFS, it didn't mandate the conversion of the password to UTF-8 >>> (let alone any mention of Unicode normalisation) for the purpose of t= he >>> key derivation. >>> >>> PKCS#12 at least gets *part* of that right, by mandating UTF16BE (BMP= ). >> draft-seantek-pkcs8-encrypted-01 > OK... so now we have can say > > Content-Type: application/pkcs8-encrypted; password-mapping=3DUTF-8 > > (Did you intend '*pkcs12' to mean UTF16-BE which is BMP, not UTF-16LE?)= Yes, I meant UTF-16BE. That was a typo. By the way, I've actually done quite a lot of tests on several crypto=20 stacks, and none of them enforce that the Unicode code point has to be=20 in the BMP. You can use surrogate pairs (which are in the BMP anyway)=20 just fine. > > But I've *never* seen an application make use of certs/files from any > container where that Content-Type: header might be present. It's not > even permitted to put it in PEM files, is it? So does this really buy > me anything in practice? As with any "new thing", people have to write code for the "new thing"=20 to use the "new thing". If you build it, they will come... The alternative would be to shoehorn the password mapping into some=20 attribute in ASN.1. But there's no practical place for that in PKCS #8=20 EncryptedPrivateKeyInfo, which is just: EncryptedPrivateKeyInfo ::=3D SEQUENCE { encryptionAlgorithm AlgorithmIdentifier {{KeyEncryptionAlgorithms}},= encryptedData EncryptedData } I mean, you *could* put it in the PBKDF2-params, with a new algorithm=20 identifier. But that will require writing new code to deal with the "new = thing". No way around it, sorry. > > And it still doesn't cover Unicode normalisation. :) Actually it does. PRECIS says NFC for password/OpaqueString. See Section = 6.2 of RFC 7613. There were much earlier draft registrations (see the media-types mailing = list, it's been kicking around for many months now; see also PRECIS=20 mailing list) that went into some detail about NFC and stuff like that.=20 The rough consensus was that it's best to let PRECIS handle that stuff:=20 doing it in the security space (aka PKCS #8 or similar container) is not = where the expertise lies. The other point is that there is only one party that cares about the=20 encoding: "you". You =3D the private key holder. Private keys aren't mean= t=20 to be shared. Frankly, who cares what the octets are, as long as you can = input the same ones into the decryption process. If you are creating the = private key and using it on the same computing device, the encoding=20 doesn't actually matter. You could record mouse clicks or voice samples=20 or raw key scan codes from the kernel, and it wouldn't affect the result.= Annex M.4 of IEEE 802.11-2012 has similar insights (which is why I cited = it). Adding the encoding parameter actually facilitates attacks, because it=20 tells an eavesdropper what bit patterns will *not* appear. Well-formed=20 UTF-8 can never have octets C0, C1, or F5-FF, for example; well-formed=20 UTF-8 will also bias the input to make certain bit patterns far more=20 likely than others. (The KDF is designed to mitigate against biased=20 input anyway, though.) The encoding parameter can also thwart attacks,=20 by intentionally mislabeling the encoding. It's not cryptographically=20 protected so it is subject to undetectable tampering. Best regards, Sean --------------03FB81F1BBAC8E1DD532BC03 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 9/26/2016 1:25 PM, David Woodhouse wrote:
On Mon, 2016-09-26 at 12:55 -0700, Sean Leonard wrote:

On 9/26/2016 12:48 PM, David Woodhouse wrote:


          

            
For interoperable private key formats, I favor PKCS #8 PrivateKeyInfo
(as .p8) and PKCS #8 EncryptedPrivateKeyInfo (as .p8e). They are
standardized, widely-supported, and algorithm-agile.


          

          
They are also non-portable, because even when RFC5958 was published in
2010, FFS, it didn't mandate the conversion of the password to UTF-8
(let alone any mention of Unicode normalisation) for the purpose of the
key derivation.

PKCS#12 at least gets *part* of that right, by mandating UTF16BE (BMP).


        

        
draft-seantek-pkcs8-encrypted-01


      

      
OK... so now we have can say

Content-Type: application/pkcs8-encrypted; password-mapping=UTF-8

(Did you intend '*pkcs12' to mean UTF16-BE which is BMP, not UTF-16LE?)

    

    Yes, I meant UTF-16BE. That was a typo.

    

    By the way, I've actually done quite a lot of tests on several
    crypto stacks, and none of them enforce that the Unicode code point
    has to be in the BMP. You can use surrogate pairs (which are in the
    BMP anyway) just fine.

    

    

      

But I've *never* seen an application make use of certs/files from any
container where that Content-Type: header might be present. It's not
even permitted to put it in PEM files, is it? So does this really buy
me anything in practice? 


    

    

    As with any "new thing", people have to write code for the "new
    thing" to use the "new thing". If you build it, they will come...

    

    The alternative would be to shoehorn the password mapping into some
    attribute in ASN.1. But there's no practical place for that in PKCS
    #8 EncryptedPrivateKeyInfo, which is just:

    

    
EncryptedPrivateKeyInfo ::= SEQUENCE {
    encryptionAlgorithm AlgorithmIdentifier {{KeyEncryptionAlgorithms}},
    encryptedData EncryptedData
}


    

    I mean, you *could* put it in the PBKDF2-params, with a new
    algorithm identifier. But that will require writing new code to deal
    with the "new thing". No way around it, sorry.

    

    

      

And it still doesn't cover Unicode normalisation. :)

    

    

    Actually it does. PRECIS says NFC for password/OpaqueString. See
    Section 6.2 of RFC 7613.

    

    There were much earlier draft registrations (see the media-types
    mailing list, it's been kicking around for many months now; see also
    PRECIS mailing list) that went into some detail about NFC and stuff
    like that. The rough consensus was that it's best to let PRECIS
    handle that stuff: doing it in the security space (aka PKCS #8 or
    similar container) is not where the expertise lies.

    

    The other point is that there is only one party that cares about the
    encoding: "you". You = the private key holder. Private keys aren't
    meant to be shared. Frankly, who cares what the octets are, as long
    as you can input the same ones into the decryption process. If you
    are creating the private key and using it on the same computing
    device, the encoding doesn't actually matter. You could record mouse
    clicks or voice samples or raw key scan codes from the kernel, and
    it wouldn't affect the result.

    

    Annex M.4 of IEEE 802.11-2012 has similar insights (which is why I
    cited it).

    

    Adding the encoding parameter actually facilitates attacks, because
    it tells an eavesdropper what bit patterns will *not* appear.
    Well-formed UTF-8 can never have octets C0, C1, or F5-FF, for
    example; well-formed UTF-8 will also bias the input to make certain
    bit patterns far more likely than others. (The KDF is designed to
    mitigate against biased input anyway, though.) The encoding
    parameter can also thwart attacks, by intentionally mislabeling the
    encoding. It's not cryptographically protected so it is subject to
    undetectable tampering.

    

    Best regards,

    

    Sean
  


--------------03FB81F1BBAC8E1DD532BC03--


From nobody Mon Sep 26 14:15:43 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6512312B0A3; Mon, 26 Sep 2016 14:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.516
X-Spam-Level: 
X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
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 HnsBTokkkZOY; Mon, 26 Sep 2016 14:15:39 -0700 (PDT)
Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 A259212B027; Mon, 26 Sep 2016 14:15:39 -0700 (PDT)
Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bodFR-0006H4-Ef; Mon, 26 Sep 2016 21:15:37 +0000
Message-ID: <1474924534.45169.325.camel@infradead.org>
From: David Woodhouse 
To: Sean Leonard , spasm@ietf.org, Security Area Advisory Group 
Date: Mon, 26 Sep 2016 22:15:34 +0100
In-Reply-To: 
References: <1474280601.144982.263.camel@infradead.org>     <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>  <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org>  <1474921558.45169.314.camel@infradead.org> 
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-OyKiTFKL7rG+ghtMPcZg"
X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) 
Mime-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from  by bombadil.infradead.org. See http://www.infradead.org/rpr.html
Archived-At: 
Cc: Michael Richardson , Alan DeKok 
Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Sep 2016 21:15:41 -0000

--=-OyKiTFKL7rG+ghtMPcZg
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2016-09-26 at 14:01 -0700, Sean Leonard wrote:
> On 9/26/2016 1:25 PM, David Woodhouse wrote:
> > But I've *never* seen an application make use of certs/files from any
> > container where that Content-Type: header might be present. It's not
> > even permitted to put it in PEM files, is it? So does this really buy
> > me anything in practice?=20
> =C2=A0
> As with any "new thing", people have to write code for the "new
> thing" to use the "new thing". If you build it, they will come...

Sure, But with this you might as well say "write it on a Post-it note
and stick it to the monitor". Because that MIME header doesn't actually
live anywhere near the key when it's stored.

If I *wanted* to fix my OpenConnect VPN client to support this, for
example, how would I go about doing so? If I've got a PKCS#8 DER
file... where do I look for this header? If I have a PEM file, do I
look for it after the '-----BEGIN ENCRYPTED PRIVATE KEY-----' line?=C2=A0

> The alternative would be to shoehorn the password mapping into some
> attribute in ASN.1. But there's no practical place for that in PKCS
> #8 EncryptedPrivateKeyInfo, which is just:
>=20
> EncryptedPrivateKeyInfo ::=3D SEQUENCE {
>     encryptionAlgorithm AlgorithmIdentifier {{KeyEncryptionAlgorithms}},
>     encryptedData EncryptedData
> }
>=20
> I mean, you *could* put it in the PBKDF2-params, with a new algorithm
> identifier. But that will require writing new code to deal with the
> "new thing". No way around it, sorry.

Agreed. Or just observe that actually, PKCS#5 got it right all along:
Use ASCII or UTF-8. Which are actually the same thing, since one is a
superset of the other: use UTF-8.

> The other point is that there is only one party that cares about the
> encoding: "you". You =3D the private key holder. Private keys aren't
> meant to be shared. Frankly, who cares what the octets are, as long
> as you can input the same ones into the decryption process. If you
> are creating the private key and using it on the same computing
> device, the encoding doesn't actually matter. You could record mouse
> clicks or voice samples or raw key scan codes from the kernel, and it
> wouldn't affect the result.

Generally true, and that's the only reason why things even work as well
as they do. Also why my draft can get away with saying you should *try*
the locale charset, and also try UTF-8, etc.

But it's not *universally* true. Users operate with different locales.
Sometimes a user provisions a certificate for e.g. 802.1x
authentication, then installs it in a location where the *system* can
use it... and suddenly the locale might be different when the key is
being used. And people *do* move files between machines, perhaps as
backups or perhaps on upgrading hardware. And *sometimes* the user's
locale in the two environments might be different.

On the whole though, I'm mostly content to say that anyone who isn't
using UTF-8 consistently, this far into the 21st century, deserves
everything they get. Especially if they try using non-ASCII in their
passwords :)

--=20
dwmw2
--=-OyKiTFKL7rG+ghtMPcZg
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw
ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO
bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q
n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS
slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO
AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO
BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI
MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t
MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O
BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y
MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv
bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh
2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw
5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07
v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y
klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy
CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD
o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2
B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6
jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p
eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve
JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp
MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc
MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk
ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z
x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+
tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m
liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO
2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f
wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t
w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR
Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK
FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU
IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV
HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD
VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn
SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t
MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j
cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu
Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V
kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL
cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo
WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8
edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc
CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq
hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE
CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs
YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE
AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y
ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU
I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw
s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK
ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4
h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW
9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M
MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk
x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1
KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm
2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E
BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE
FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G
CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG
AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD
VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G
A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy
dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov
L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK
AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A
YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs
IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh
zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj
TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg
hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MTYwOTI2MjExNTM0WjAvBgkqhkiG9w0BCQQxIgQgAPPdliE/CWMqkssj0JCxHCC7zCNSYerfM7Dq
qlHfJngwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV
BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG
9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t
IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAKVo
BQ4bZ+tHmjsq6rtXR61EWpgx91fi7eTKWeq5WHwzwNddDOFDUT5VVfi9zDjVx+teb7XcHLPd1WNp
EiAKwBSZXcAgPt0UsKsjzLn8Mg9RWzV91dsGWBkGiiIBNShDhhyiT78RHM/fDG561N7hv4IvyV3g
sybjGbgkizYaqif8bFrNkAHo02W42/3Sbg0FAnbpu+neheEZjvxwqEXMQpoPwZWdjx5DvKmJ3nyF
9adhWQWYmexOwUJchjRf+DK7jJzpu5LPzIpHzeUqc+yRKlcXjbdsx2rXKkmpeBkKL51oPB8fFHJv
x1/dbiUwvSmbOYKRe5XeWO+LeSU2tm+TMJsgpCRk3fKsWmNQsQG/3+vOxL6sk8YSQDhhiEUeKXhs
AVCa1AbMbCIGUzZdBjTgW6RV2nqyIJKKCc204LqZ4JMZHcLoYmva7C6cElaHNRLHbqX1sJrTaDTS
eQyGnN2p22OGQ00p0vLmYI1rOyOITy/x0RLXfEs6CEy+qkhn6Rix+/xfpAKIN5daq/jMmRFnkcW6
Jq+aewFz9/lCrhY6YTGvKGGrh0ISfIU6DdhDDEqi9HFhkESxZLydcP85HEMhYVRht5R+BZoYnzpw
aRY+E5T/yDkAMR2NSeaHR6ghQoPauGEWEPXKX3/5ihVu/I74nFEvHnjzyl72n6QSaGUaN8s9AAAA
AAAA


--=-OyKiTFKL7rG+ghtMPcZg--


From nobody Mon Sep 26 14:18:36 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8646E12B09C; Mon, 26 Sep 2016 14:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
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 POS7QdxlAXwL; Mon, 26 Sep 2016 14:18:31 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5BD012B01C; Mon, 26 Sep 2016 14:18:30 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0B79150A73; Mon, 26 Sep 2016 17:18:28 -0400 (EDT)
To: David Woodhouse , spasm@ietf.org, Security Area Advisory Group 
References: <1474280601.144982.263.camel@infradead.org>     <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>  <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org>
From: Sean Leonard 
Message-ID: <6a3feeee-c575-8763-6e2a-ed9d07dbdfc0@seantek.com>
Date: Mon, 26 Sep 2016 14:20:10 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <1474919326.45169.305.camel@infradead.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: Michael Richardson , Alan DeKok 
Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Sep 2016 21:18:32 -0000

On 9/26/2016 12:48 PM, David Woodhouse wrote:
> On Mon, 2016-09-26 at 12:10 -0700, Sean Leonard wrote:
>>>> That is for certificates. And yes, it handles pkcs11 just like
>>>> everything else.
>>> ... but not like RFC7512 does, I note. Is it worth trying to achieve
>>> some better consistency there? After all, I can *already* refer to th=
e
>>> certificate in my crypto token consistently as
>>>
>>> 	'pkcs11:manufacturer=3Dpiv_II;id=3D%01'
>>>
>>> in a variety of applications using different crypto libraries. And in=

>>> fact on my operating system of choice I can file a bug for any
>>> application which *doesn't* accept that string, when it would have
>>> taken a filename. So I'd definitely like to see your draft make
>>> explicit reference to RFC7512 in some form or other.
>> I can do that...although the value of doing so may be a bit lost on me=
=2E
>> The general syntax would be:
>>
>> URI:pkcs11:manufacturer=3Dpiv_II;id=3D%01
>>
>> The syntax of "URI:uri" (with URI: prepended) has a long and tumultuou=
s
>> history. You can look at the draft history to see why.
>>
>> Applications for draft-seantek-certspec are hunting for certificates o=
n
>> the order of sub-milliseconds: looking up a certificate could be done =
in
>> a blocking operation. This would be the case, for example, when a TLS
>> server (web server, IMAP server, etc.) or client boots up and needs th=
e
>> certificate before starting its first TLS connection. As a general
>> matter, URIs strongly imply network access; therefore they are not as
>> important as the other types of specs.
> As far as I can tell, the PKCS#11 URI is not a URI. It's just a set of
> search terms, similar in many ways to the ones in your own draft =E2=80=
=94
> except with a specific focus on what's searchable in the PKCS#11 API.

This is surprising, because RFC 7512 Section 4.1. registers it as a=20
permanent URI scheme in the Permanent URI Schemes Registry. =3D:-O

I thought that the whole point of a document called "The PKCS #11 URI=20
Scheme" would be to make PKCS #11 items accessible in URI protocol=20
slots, and conversely, to make URI protocol slots useful to PKCS=20
#11-consuming applications (in addition to other URI items such as http: =

, ldap: , data: , etc.).

>
> It's just an identifier; it's not valid to make general inferences
> about it, along the lines of "URIs strongly imply network access".
>
> As such, I'd be inclined to suggest that the general syntax for it in
> your draft might be the PKCS#11 URI itself, starting with 'pkcs11:'.

URIs are meant for Internet-accessing things. The specific URI scheme=20
itself may not actually do any network access, such as data: or file:.=20
(Or for that matter, http://localhost/ .) But a robust=20
"URI-dereferencer" is going to have to have Internet access to be of=20
much use. In contrast, a file path API does not have to have Internet=20
access per-se to be of use to a broad class of applications.


>
>> Any application that plans on using a certificate with its correspondi=
ng
>> private key should obviously have the certificate on-hand and
>> at-the-ready. Even if the private key is unavailable (e.g., the hardwa=
re
>> token is not in the slot), some pointer that shows that a private key =
is
>> known to be around, has to be immediately available. That way the UI c=
an
>> prompt the user for the right device.
>>
>> A distinguishing feature of URIs is that it is limited in its repertoi=
re
>> of characters to a strict subset of ASCII, with % percent-encoding. Th=
is
>> means that LDAP strings are going to look very convoluted, with a lot =
of
>> %20, %2F, %3B, etc. throughout.
> Who said anything about LDAP strings? I was *only* talking about the
> PKCS#11 identifiers as defined in RFC7512. Which aren't really URIs
> although that term is used there quite a lot :)

Maybe because they are trying to be URIs. :)

LDAP Strings are used by ISSUERSN: in draft-seantek-certspec to identify =

a certificate. It's natural, readable, and widely supported.

Notably, PKCS #11 also uses distinguished names, e.g., in CKA_SUBJECT.=20
But that is a digression so we need not go there too much.

>
>> If you want to permit users to specify
>> strings without double or triple % encoding and \ escaping and whatnot=
,
>> then I can buy an argument to promote "p11:" or similar to the top of =
a
>> certspec, and not buried into the "URI:" spec type.
> No, I absolutely don't want *more* ways of referring to the same
> objects, and more things for the users to try, and discover are
> inconsistently supported across the set of applcatiions they use.
>
>> By the way, RFC 7512 contains a serious bug: the | character is not
>> valid in URI [RFC3986]. I don't know how that character snuck through
>> the RFC process, but it's not a valid URI.
> Fine, there are almost no circumstances when you might want to use the
> RFC7512 identifier as if it's *really* a URI. It looks like you
> *suggested* it above, but I think you're the first, and I just told you=

> not to :)

I think RFC 7512 itself suggests it :)


>> RFC 7512 contains a second, less serious bug: "The URI scheme does not=

>> use the fragment component." Well that may or may not be good advice. =
I
>> don't see why a PKCS #11 token can't return a blob that is plain text
>> (text/plain), in which case, fragment would be defined by RFC 5147.
>> Furthermore, PKCS #11 is actually Internet media type-aware: see
>> CKA_MIME_TYPES, for example, in that standard.
> It's an identifier for an object. It is (deliberately AFAICT) not
> actually a real URI that you might for example put into the location
> bar of your web browser and expect it to do anything useful.

A general-purpose URI dereferencer should be able to work just fine with =

pkcs11: the same way it works with any other URI.

>
>> That is indeed a list of horribles.
>>
>> But for applications that are PKCS #11 based, one could easily write a=

>> script that takes a pkcs11: URI as input and outputs the right flips,
>> switches, config files, and API calls to do what the pkcs11: URI is
>> saying to do. Probably would take less than a day.
> You could do that. Not sure it would entirely meet my criteria for
> usability though. Better to fix the applications so that they all just
> accept the objects in the same form, than to have different 'wrappers'
> and 'config generators' for each application to work around their
> differences and convert keys between formats.

OK.

I believe, in some circles, it is called "vendor lock-in".

Budget, please. :)


>
>> For applications that are *not* PKCS #11 based (macOS Keychain Service=
s,
>> Windows CNG), using a PKCS #11 URI would be..."grotesque". I don't kno=
w
>> of a better way to put it.
> Yes. Don't attempt to use a PKCS#11 identifier for something that's not=

> PKCS#11; that would be strange.
>
> Having said that... =E2=88=83 PKCS#11 modules which expose the function=
ality of
> the keychain and of CAPI/CNG:
>       https://github.com/slushpupie/KeychainToken
>       https://github.com/risacher/p11-capi
> .. and then I suppose you *do* end up referencing objects therein via
> PKCS#11 attributes :)

ok
>
>>> So while there is certainly an overlap with your draft, there's also =
a
>>> lot to cope with that *isn't* already the primary target of your draf=
t.
>> Okay. Yes, the primary target of the draft is identifying certificates=

>> (uniquely and unambiguously), and providing associated attributes with=

>> the certspec. Interestingly, one of those "associated attributes" coul=
d
>> very well be: "hint or directive about where to find the private key".=

>> So that is a point of extension that we could collaborate on, whether =
in
>> draft-seantek-certspec or in a related draft.
> Yes, that definitely warrants a further look.

Great! Let's take a look at that angle.

Sean


From nobody Mon Sep 26 14:30:59 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B2312B2D2; Mon, 26 Sep 2016 14:30:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 HT8MMWnJCM0g; Mon, 26 Sep 2016 14:30:53 -0700 (PDT)
Received: from mail-ua0-x244.google.com (mail-ua0-x244.google.com [IPv6:2607:f8b0:400c:c08::244]) (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 7E75612B247; Mon, 26 Sep 2016 14:30:53 -0700 (PDT)
Received: by mail-ua0-x244.google.com with SMTP id i25so95924uab.0; Mon, 26 Sep 2016 14:30:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2YhyLF1ZkVQi5h/o5WAdnJ6hIjJofMvBt/Wz49cw6qY=; b=V+9iZWdIBCAW1xjPx9qyKn+MAQ9uj62EySbPpkx16QJHpMw6LVZPVdepk1iwmeO9Tk r6Z0p5ZT/28vOa3fYOx76ahLVBIk3PLELkZYA6pX5J9XjFRpOjVy1eLJAKCTVJsV9yF1 Ef99rwdZzeYPy6EqE2wikuq+2prjJLcgxIhWAB060icTNa+AjMZaGpnO+koJ4uV3+eQZ swRKUpe4/NMYCnjuXx38NpF6+8aQ8vlPdF8djvaAZrtHPT4loR44qLXoT6yGyEyKAuST WORGjjTGYi0ZSX3g91vctin+SEc4bhnlz1XJX8cze0wN7CLV7WsRdpMry62+AIuPEUT4 XR8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2YhyLF1ZkVQi5h/o5WAdnJ6hIjJofMvBt/Wz49cw6qY=; b=G8lMH/uKlfZeoHu9XTLNvG3sxiKo/DAUpHd8f5i/IpC4vUUIlRkUY5d/fgnocB22oP mHGxpj8cTZ5hx9hrlnLEYnL7wLr926eWyJEuEMolC2WDMeoYpIiNUy6EDWJLHCCkk30M I0uC0KEshzpL5PJ2EEk9d+R8+CxC1qUraTaHTYnB5KhsErHJUBZpgSGUh3J93G00gbnv 2WQdqqjzk9hJFaSLb7r6qvHW4kjP2NeE6fFg0vlVjwhci+/jSFxsLauTHNJ3edddt77c ZSuN864R0hN1gTqquVh/9Aa4d1q2/392lHzXYdNEfxEJVZ7I1T07tkekLetmPkyJykXU 3vxw==
X-Gm-Message-State: AA6/9RkyP8YILltSpkxDCx/LZVtVMJhzGeb5j8F7mYxloOPS9MZZh6b8orJF/ZkuQTM2w+SoDrtyx3HDS4tr4A==
X-Received: by 10.159.53.12 with SMTP id o12mr483838uao.81.1474925452417; Mon, 26 Sep 2016 14:30:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.4.102 with HTTP; Mon, 26 Sep 2016 14:30:51 -0700 (PDT)
In-Reply-To: 
References: <1474280601.144982.263.camel@infradead.org>     <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>  <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org>  <1474921558.45169.314.camel@infradead.org> 
From: Watson Ladd 
Date: Mon, 26 Sep 2016 14:30:51 -0700
Message-ID: 
To: Sean Leonard 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: spasm@ietf.org, Michael Richardson , David Woodhouse , Security Area Advisory Group 
Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Sep 2016 21:30:55 -0000

On Mon, Sep 26, 2016 at 2:01 PM, Sean Leonard  wrote:
> On 9/26/2016 1:25 PM, David Woodhouse wrote:
>
> On Mon, 2016-09-26 at 12:55 -0700, Sean Leonard wrote:
>
> On 9/26/2016 12:48 PM, David Woodhouse wrote:
>

>
> The other point is that there is only one party that cares about the
> encoding: "you". You = the private key holder. Private keys aren't meant to
> be shared. Frankly, who cares what the octets are, as long as you can input
> the same ones into the decryption process. If you are creating the private
> key and using it on the same computing device, the encoding doesn't actually
> matter. You could record mouse clicks or voice samples or raw key scan codes
> from the kernel, and it wouldn't affect the result.

Explain to me how you make a certificate and install it in your
favorite web server without sharing the private key between two
different programs. For extra points try changing mail clients both
with S/MIME set up, and assume you want to read all your own emails
without moving keys. That's the problem we are trying to solve.

Sincerely,
Watson Ladd


From nobody Mon Sep 26 14:32:13 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E07F12B2FC; Mon, 26 Sep 2016 14:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.516
X-Spam-Level: 
X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
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 Cxiod8Sxnqso; Mon, 26 Sep 2016 14:32:05 -0700 (PDT)
Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 EB12512B2AE; Mon, 26 Sep 2016 14:32:05 -0700 (PDT)
Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bodVN-0003Rj-Cx; Mon, 26 Sep 2016 21:32:05 +0000
Message-ID: <1474925522.45169.337.camel@infradead.org>
From: David Woodhouse 
To: Sean Leonard , spasm@ietf.org, Security Area Advisory Group 
Date: Mon, 26 Sep 2016 22:32:02 +0100
In-Reply-To: <6a3feeee-c575-8763-6e2a-ed9d07dbdfc0@seantek.com>
References: <1474280601.144982.263.camel@infradead.org>     <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>  <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org> <6a3feeee-c575-8763-6e2a-ed9d07dbdfc0@seantek.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-1HgdSsD+Hq5kHU2oIEgT"
X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) 
Mime-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from  by bombadil.infradead.org. See http://www.infradead.org/rpr.html
Archived-At: 
Cc: Michael Richardson , Alan DeKok 
Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Sep 2016 21:32:07 -0000

--=-1HgdSsD+Hq5kHU2oIEgT
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2016-09-26 at 14:20 -0700, Sean Leonard wrote:
> > As far as I can tell, the PKCS#11 URI is not a URI. It's just a set of
> > search terms, similar in many ways to the ones in your own draft =E2=80=
=94
> > except with a specific focus on what's searchable in the PKCS#11 API.
>=20
> This is surprising, because RFC 7512 Section 4.1. registers it as a=20
> permanent URI scheme in the Permanent URI Schemes Registry. =3D:-O
>=20
> I thought that the whole point of a document called "The PKCS #11 URI=20
> Scheme" would be to make PKCS #11 items accessible in URI protocol=20
> slots, and conversely, to make URI protocol slots useful to PKCS=20
> #11-consuming applications (in addition to other URI items such as http:=
=20
> , ldap: , data: , etc.).

Perhaps that was the intent; we would have to ask its authors. I cannot
tell. But it doesn't seem stunningly useful in that form to me.,

> > It's an identifier for an object. It is (deliberately AFAICT) not
> > actually a real URI that you might for example put into the location
> > bar of your web browser and expect it to do anything useful.
>=20
> A general-purpose URI dereferencer should be able to work just fine with=
=20
> pkcs11: the same way it works with any other URI.

Yes, but I thought you just raised a bunch of reasons why you *didn't*
want to have generic URI support :)

--=20
dwmw2
--=-1HgdSsD+Hq5kHU2oIEgT
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw
ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO
bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q
n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS
slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO
AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO
BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI
MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t
MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O
BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y
MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv
bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh
2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw
5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07
v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y
klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy
CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD
o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2
B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6
jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p
eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve
JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp
MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc
MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk
ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z
x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+
tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m
liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO
2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f
wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t
w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR
Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK
FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU
IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV
HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD
VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn
SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t
MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j
cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu
Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V
kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL
cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo
WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8
edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc
CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq
hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE
CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs
YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE
AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y
ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU
I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw
s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK
ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4
h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW
9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M
MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk
x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1
KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm
2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E
BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE
FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G
CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG
AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD
VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G
A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy
dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov
L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK
AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A
YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs
IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh
zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj
TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg
hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MTYwOTI2MjEzMjAyWjAvBgkqhkiG9w0BCQQxIgQg4WXEDyHd86pNjpcjuvUhydSI91s+NMYTm1GI
9e2ERLswgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV
BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG
9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t
IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAE8a
uYHgVKmn1QZVuwjf9dC8l2zakKJlsnku+0hCUzFQu6afiKafryzm81Ke3YclgozXZ54EqIPrEyDN
EpeK9tFt3za3QsFtiWnEyzIN7hcw2Yy4Mme5mzXfek2D9MT+tqLMPYunRFjR/Cgd0gA0qgWFmuRP
h1lXfW4yXSBh9k+8U8EAPUaKJl0IxN9ljY+y673wNDSn0QgS6hlrfipVsVOn0OealJeQNreU6XKg
cBJuDw52F5PZ0RL8p+evuU63QLUna5g65YkBekzR19Ei8zsKB5z/qbBNHE9z3u5HU7Jhi5Rgwf0L
f9DWdgyxJxgPaGFf9KSS7E1hzdam+XLQ/THdlmAJsRtjN9Irac3qOHRWGhHVZyTrrD6Wwki8LLoq
cssWeL9IVd7+bGiUqIitn0nKr4TuRSi3O6O9bCNwSCqWFFv4g6AwaWr7B9dnsx/2qRQgMZBVsBEq
tbXj5ZFhbn7QyliEx/+ekX0NoiDZlbQ2senhiwmlxlSkRSVGhs70byLiBluzRS68XG2Iv+i604ky
ziFqx/5xTipBk79sYTOypW9yzUZmXukjv5csIPXmfWHuV2TrL1kCz4r0Gn0Hnwvz8GtS0uFMushq
CtfrZ8x+TkKRx57pWWfShxwSdPlCQO9DEI+6qowRo5JNEc6HIlwcsIsZ+kyngpwAA4QMv0GqAAAA
AAAA


--=-1HgdSsD+Hq5kHU2oIEgT--


From nobody Mon Sep 26 14:53:37 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D80D12B02C; Mon, 26 Sep 2016 14:53:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
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 ZlynG0M9pq28; Mon, 26 Sep 2016 14:53:30 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C22112B343; Mon, 26 Sep 2016 14:53:30 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4917E50A86; Mon, 26 Sep 2016 17:53:29 -0400 (EDT)
To: Watson Ladd 
References: <1474280601.144982.263.camel@infradead.org>     <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>  <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org>  <1474921558.45169.314.camel@infradead.org>  
From: Sean Leonard 
Message-ID: <1c555d80-991c-cca7-4018-be220cdddcdf@seantek.com>
Date: Mon, 26 Sep 2016 14:55:11 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: spasm@ietf.org, Michael Richardson , David Woodhouse , Security Area Advisory Group 
Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Sep 2016 21:53:32 -0000

On 9/26/2016 2:30 PM, Watson Ladd wrote:
> On Mon, Sep 26, 2016 at 2:01 PM, Sean Leonard  wr=
ote:
>> On 9/26/2016 1:25 PM, David Woodhouse wrote:
>>
>> On Mon, 2016-09-26 at 12:55 -0700, Sean Leonard wrote:
>>
>> On 9/26/2016 12:48 PM, David Woodhouse wrote:
>>
> 
>> The other point is that there is only one party that cares about the
>> encoding: "you". You =3D the private key holder. Private keys aren't m=
eant to
>> be shared. Frankly, who cares what the octets are, as long as you can =
input
>> the same ones into the decryption process. If you are creating the pri=
vate
>> key and using it on the same computing device, the encoding doesn't ac=
tually
>> matter. You could record mouse clicks or voice samples or raw key scan=
 codes
>> from the kernel, and it wouldn't affect the result.
> Explain to me how you make a certificate and install it in your
> favorite web server without sharing the private key between two
> different programs. For extra points try changing mail clients both
> with S/MIME set up, and assume you want to read all your own emails
> without moving keys. That's the problem we are trying to solve.

I am not entirely sure what you're trying to get at...

Having just refreshed my web server's certificate and private key=20
today...first of all, I don't "make a certificate". I generated a=20
private key, and created a Certificate Signing Request. Then I uploaded=20
the CSR to a commercial CA. Then I downloaded the certificate that the=20
*CA* made for me.

Then I copied-and-pasted the certificate into a web form for my web=20
server's control panel. I also copied-and-pasted the private key into=20
the same web form. The private key was not password protected, so it has =

nothing to do with PKCS #8 EncryptedPrivateKeyInfo. There is no point in =

password-protecting the private key, because the web service (taken a=20
whole) needs to see the private key anyway, and the connection to the=20
web-based control panel was protected with TLS.

With S/MIME, I just use PKCS #12 like everyone else. And that workflow=20
specifies the password mapping as UTF-16BE with NULL. :)

When I use cryptographic tokens such as smart cards, the private key=20
never leaves the token. So, there is no password: it's irrelevant.=20
Sometimes the token is configured with a PIN, but the PIN is not the=20
subject of this PKCS #8 EncryptedPrivateKeyInfo discussion.

Sincerely,

Sean


From nobody Mon Sep 26 14:54:39 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8178C12B2AC; Mon, 26 Sep 2016 14:54:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
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 U7ztKX7ipCXP; Mon, 26 Sep 2016 14:54:33 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 038E712B2FF; Mon, 26 Sep 2016 14:54:33 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C2F7950A73; Mon, 26 Sep 2016 17:54:31 -0400 (EDT)
To: David Woodhouse , spasm@ietf.org, Security Area Advisory Group 
References: <1474280601.144982.263.camel@infradead.org>     <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>  <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org> <6a3feeee-c575-8763-6e2a-ed9d07dbdfc0@seantek.com> <1474925522.45169.337.camel@infradead.org>
From: Sean Leonard 
Message-ID: 
Date: Mon, 26 Sep 2016 14:56:13 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <1474925522.45169.337.camel@infradead.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: Michael Richardson , Alan DeKok 
Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Sep 2016 21:54:35 -0000

On 9/26/2016 2:32 PM, David Woodhouse wrote:
> On Mon, 2016-09-26 at 14:20 -0700, Sean Leonard wrote:
>>> As far as I can tell, the PKCS#11 URI is not a URI. It's just a set of
>>> search terms, similar in many ways to the ones in your own draft —
>>> except with a specific focus on what's searchable in the PKCS#11 API.
>> This is surprising, because RFC 7512 Section 4.1. registers it as a
>> permanent URI scheme in the Permanent URI Schemes Registry. =:-O
>>
>> I thought that the whole point of a document called "The PKCS #11 URI
>> Scheme" would be to make PKCS #11 items accessible in URI protocol
>> slots, and conversely, to make URI protocol slots useful to PKCS
>> #11-consuming applications (in addition to other URI items such as http:
>> , ldap: , data: , etc.).
> Perhaps that was the intent; we would have to ask its authors. I cannot
> tell. But it doesn't seem stunningly useful in that form to me.,
>
>>> It's an identifier for an object. It is (deliberately AFAICT) not
>>> actually a real URI that you might for example put into the location
>>> bar of your web browser and expect it to do anything useful.
>> A general-purpose URI dereferencer should be able to work just fine with
>> pkcs11: the same way it works with any other URI.
> Yes, but I thought you just raised a bunch of reasons why you *didn't*
> want to have generic URI support :)

In certspec, identifying a certificate by URI is sensible for a broad 
range of applications. Identifying a certificate by file path is also 
sensible for a broad range of applications. But it's not the only way. 
And URI (and file path) require formatting all strings in particular 
ways, which may not actually be sensible. The draft discusses 
cut-and-paste-ability.

If someone implements certspec URI specs, the easiest way to deal with 
it is to pass the URI to the system's general-purpose URI-dereferencing 
API so it "does the right thing and gives back a blob of bytes (possibly 
with media type information)".

Sean


From nobody Mon Sep 26 15:37:04 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AC812B01C; Mon, 26 Sep 2016 15:36:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.516
X-Spam-Level: 
X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
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 wgrXR3Rah4X3; Mon, 26 Sep 2016 15:36:51 -0700 (PDT)
Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 7E5ED12B02E; Mon, 26 Sep 2016 15:36:51 -0700 (PDT)
Received: from [2001:8b0:10b:1:841b:5eff:0:f69] (helo=shinybook.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1boeW1-0002M2-9d; Mon, 26 Sep 2016 22:36:49 +0000
Message-ID: <1474929405.11690.59.camel@infradead.org>
From: David Woodhouse 
To: Sean Leonard , spasm@ietf.org, Security Area Advisory Group 
Date: Mon, 26 Sep 2016 23:36:45 +0100
In-Reply-To: 
References: <1474280601.144982.263.camel@infradead.org>     <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>  <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org> <6a3feeee-c575-8763-6e2a-ed9d07dbdfc0@seantek.com> <1474925522.45169.337.camel@infradead.org> 
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-VCORYkEUiI8tyoef4rnk"
X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) 
Mime-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from  by bombadil.infradead.org. See http://www.infradead.org/rpr.html
Archived-At: 
Cc: Michael Richardson , Alan DeKok 
Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Sep 2016 22:36:59 -0000

--=-VCORYkEUiI8tyoef4rnk
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2016-09-26 at 14:56 -0700, Sean Leonard wrote:
>=20
> In certspec, identifying a certificate by URI is sensible for a broad=C2=
=A0
> range of applications. Identifying a certificate by file path is also=C2=
=A0
> sensible for a broad range of applications. But it's not the only way.=C2=
=A0
> And URI (and file path) require formatting all strings in particular=C2=
=A0
> ways, which may not actually be sensible. The draft discusses=C2=A0
> cut-and-paste-ability.
>=20
> If someone implements certspec URI specs, the easiest way to deal with=C2=
=A0
> it is to pass the URI to the system's general-purpose URI-dereferencing=
=C2=A0
> API so it "does the right thing and gives back a blob of bytes (possibly=
=C2=A0
> with media type information)".

Except that there is no "blob of bytes" that can be returned for a
private key in a PKCS#11 token.

For certificates, sure. But not keys.

--=20
dwmw2



--=-VCORYkEUiI8tyoef4rnk
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw
ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO
bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q
n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS
slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO
AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO
BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI
MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t
MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O
BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y
MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv
bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh
2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw
5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07
v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y
klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy
CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD
o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2
B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6
jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p
eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve
JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp
MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc
MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk
ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z
x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+
tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m
liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO
2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f
wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t
w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR
Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK
FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU
IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV
HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD
VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn
SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t
MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j
cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu
Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V
kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL
cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo
WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8
edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc
CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq
hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE
CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs
YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE
AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y
ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU
I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw
s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK
ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4
h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW
9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M
MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk
x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1
KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm
2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E
BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE
FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G
CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG
AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD
VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G
A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy
dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov
L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK
AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A
YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs
IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh
zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj
TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg
hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MTYwOTI2MjIzNjQ1WjAvBgkqhkiG9w0BCQQxIgQgjtTsf1q4Znm4TJyBfUdYQE9alLmsbEZNAOtS
HGgS7fcwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV
BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG
9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t
IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAGPP
qaXdjC9a+HN97oeqqZTD5vv+hT9B7U5FaMMwZejF1BMO3JV4opmsLAV+4wndiduvvdSqVGnxgcgh
rkOGZvnA/cUyz4L0yEjg8GYf3pNbsktl9SCH/wlMwBeGaFgzoZiXoUwyFdQiPMGbG75Xi0uqk3pV
+Q1MKmviKcwQX1rSXIpvL8ErRCgOn+d4vkRjZ/xwOCxAZGT8dwdoIyGhyUQlxO44VooMiDyrnTxr
nq8d2JrGNNXXdE7Lz1DX/L6yEviiiCgfYXVSLM6kq5maPMGCsaVde6/R5Qz1lKDW+Xqagni0qmiW
cbZXzMXmnsT8v2xWc1NXBFABQikDnrVJBMJ0eZE34W+HKzJo9CZ46sApQPvkM9jHgt9YC0EZmwW8
2Y5bZx5xeUopUQ0OgRsSTzy8Oe8xepoJtvG5V5n8NBrUFc/o6mKRp5TVqI8pQyBYureN8ky5DcdQ
t+mktactEdLUe8dp7ieEH2WvEgACHfQfZTUlTm+2UJkm/kgNNjsI5fL/uxUqal34/cGGzZgc+L69
cV+bUQa/q2A6zjY6YyS6VdAo6aNwH4xQlLX6VOH0hemucYEaeNQhJJCc1q+CiZ3digZJogxNEep5
Gyl7Xab2nhE9XehjsxP6lcJg/TNPMfpbEXV0jBUW2/r22aTwd1X3P1tr2cIhZ5PH3Ul8BZApAAAA
AAAA


--=-VCORYkEUiI8tyoef4rnk--


From nobody Mon Sep 26 15:43:48 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E6912B244; Mon, 26 Sep 2016 15:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.516
X-Spam-Level: 
X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
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 ZXasDBvvUbuG; Mon, 26 Sep 2016 15:43:45 -0700 (PDT)
Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 0B2AA12B041; Mon, 26 Sep 2016 15:43:45 -0700 (PDT)
Received: from [2001:8b0:10b:1:841b:5eff:0:f69] (helo=shinybook.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1boeci-00050G-29; Mon, 26 Sep 2016 22:43:44 +0000
Message-ID: <1474929821.11690.66.camel@infradead.org>
From: David Woodhouse 
To: Sean Leonard , Watson Ladd 
Date: Mon, 26 Sep 2016 23:43:41 +0100
In-Reply-To: <1c555d80-991c-cca7-4018-be220cdddcdf@seantek.com>
References: <1474280601.144982.263.camel@infradead.org>     <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>  <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org>  <1474921558.45169.314.camel@infradead.org>   <1c555d80-991c-cca7-4018-be220cdddcdf@seantek.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-iw78fHFEfYACz2SE5vAy"
X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) 
Mime-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from  by bombadil.infradead.org. See http://www.infradead.org/rpr.html
Archived-At: 
Cc: spasm@ietf.org, Michael Richardson , Security Area Advisory Group 
Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Sep 2016 22:43:47 -0000

--=-iw78fHFEfYACz2SE5vAy
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2016-09-26 at 14:55 -0700, Sean Leonard wrote:
> With S/MIME, I just use PKCS #12 like everyone else. And that workflow=C2=
=A0
> specifies the password mapping as UTF-16BE with NULL. :)

Right. PKCS#12 is preferable to PKCS#8 in this regard. (And thanks,
OpenSSL, for screwing that up for us.=C2=B9)

> When I use cryptographic tokens such as smart cards, the private key=C2=
=A0
> never leaves the token. So, there is no password: it's irrelevant.=C2=A0
> Sometimes the token is configured with a PIN, but the PIN is not the=C2=
=A0
> subject of this PKCS #8 EncryptedPrivateKeyInfo discussion.

Well... looking a bit further back in the thread (or indeed at
$SUBJECT), this was about application best practice. And I probably
*do* need to look at what to do with non-ASCII PINs and C_Login().

And again, I think the recommendation there needs to be the same as
PKCs#8: By all means *try* the local character set of the current
system, but make sure you also try UTF-8. I'll update my draft.

And perhaps I should make it abundantly clear that anyone who sets a
PIN in a legacy 8-bit character set, just like anyone who sets a PKCS#8
password in a legacy 8-bit character set, had better expect it to break
if they ever fall through a timewarp into the 21st century. Or travel a
few hundred miles.

You're right that it's a different problem, but it's actually *really*
similar.

--=20
dwmw2

=C2=B9 And yes, that time I *am* complaining, Viktor :)



--=-iw78fHFEfYACz2SE5vAy
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw
ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO
bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q
n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS
slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO
AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO
BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI
MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t
MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O
BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y
MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv
bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh
2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw
5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07
v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y
klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy
CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD
o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2
B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6
jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p
eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve
JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp
MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc
MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk
ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z
x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+
tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m
liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO
2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f
wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t
w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR
Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK
FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU
IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV
HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD
VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn
SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t
MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j
cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu
Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V
kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL
cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo
WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8
edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc
CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq
hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE
CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs
YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE
AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y
ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU
I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw
s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK
ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4
h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW
9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M
MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk
x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1
KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm
2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E
BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE
FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G
CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG
AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD
VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G
A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy
dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov
L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK
AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A
YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs
IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh
zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj
TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg
hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MTYwOTI2MjI0MzQxWjAvBgkqhkiG9w0BCQQxIgQgRV/kt0v3am0Zeju/NjHdXT7A+S3ltg2FHVK0
LqGKkoAwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV
BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG
9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t
IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAIa4
BdZbo1OE5G9dhqeBj3mNlAq3z7eFxQZz/NQKaYtVe8c6tywHeOfI1b7FtF/suK8Igut2ue+JHuUq
KI9YXF+7B/jQfrk49ZhGuPF99CHJhWLwS+DLKp4MSYkwVgu7V2+G0gDBMefTULquetYDFFMW98/C
6HIwFhvSTmn9P2/wQ0EIDwD6fG7mTDq8zVFUkhBnyYr1tjvCdFDcDAELCq1Vfm3qMDDEVf2CBvJD
RpsVQQaljgPyjHa7c25GUFvkQvI+J3KNXbe3u+YcD4a6prUM9QeMjWdK7YyVdXw/mkrgL3MzFQUl
wNQr1CQFwbDaZBlYfDiw+BBMcMMx2TLlSyW7Qfc0kv22S3341C9P2OMOSZ1CFnHPBtx24KRtOLHc
GmBaEh0Fd7QOkqbIU4bj7cGCvmTGAEcAHjFdsY+ZwrnXzCDsaMUjwT6XD2dsSNn1lH8q6zjJsJCb
mZqCBAEm8ov1h3m5/WL0egnV3hPQ1F+Lb/dp4paXrf+KLoQz45wGM2OkvfqoBkqQhI6Dcrbd7Ij+
wcXGeCu6OmtsA/t8/quscfTq5SP3FZ0y5dOlPJavvdbG5rHX4JB0+0yTauLQFTn2277JT1oJEw6l
k5LW8saUiV87VONM9OM4LTZRw9hBmaBgPpjx1FNEpv8WSOqKgOc1h9ErVYfgVK9wdVatFOyRAAAA
AAAA


--=-iw78fHFEfYACz2SE5vAy--


From nobody Tue Sep 27 01:17:46 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D02612B40A; Tue, 27 Sep 2016 01:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level: 
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 OxivlYUR0Q3s; Tue, 27 Sep 2016 01:17:39 -0700 (PDT)
Received: from mail-ua0-f181.google.com (mail-ua0-f181.google.com [209.85.217.181]) (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 F0C9812B409; Tue, 27 Sep 2016 01:17:38 -0700 (PDT)
Received: by mail-ua0-f181.google.com with SMTP id i25so4816810uab.0; Tue, 27 Sep 2016 01:17:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=YSaR4scVL21z9XbcN38L2vZaoXAH9re+ogqL0Ne97ZA=; b=O1ePBm47DIEICd6E8II+UsMx0iNCi8EEpY2N2/DSSzoUPyNZazPfMsKxGWG497ngM1 A+rdUf2a0FfiPDMaxYmvnbPYmsvmOkKMP8i3a5s76fJxs2yD05vXigdhr/MUXeEoKBOm GV7qMoXR4c0wrPKGVm02n923Dg/jFnXrb7TEUmcnu5YPVHtkLldcN7NJCxbI0hd/OLzO JZN9HX0/B75xRfywdFUYtt8BuCLELsAzPrenwx3Yrbp1IdSeBvJf23B1hE8pEMUsMZTX ETPLsTXGydoOH3c1kisVNTgCPDtFOtf2h4CMN6x7acDjNIPLyCH1UNCqgxd9hgHj3SC3 C6+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=YSaR4scVL21z9XbcN38L2vZaoXAH9re+ogqL0Ne97ZA=; b=WQnmOj3+4P0lMbmCP0GCU2Gv5E7Ps+7yNQptWsInCSuMgJ67CxYqpunVHkHnDmy8kT cGo4KPsFChUdugh9LWp96v7Oio/DN0lHere+fI3PBdVyIcUOV85wbZlvXPPjhKdoiAFD 2fPaUT/DPyz+urOK1+/ATy5zoPJZ1XTesaDNV2TGdEFWJpVciyibYBm1XQ2SMuXpVTxl 9kXCmcjOcSGcI7/ZMD1jrvVor8wqRcThiArjD63EXVyMn0nEL1sMbAN847Rmd6R60Yu3 bc6iuherWTmE7qYHKVpbkv6V1YBLcOdZL5XWSIzg5IdcfbE83yK6i4pisYo9bJK3u5Yc UyaQ==
X-Gm-Message-State: AA6/9RmoWBGBYzqNYTnlsLe5lrR7A4V7sqegugc6d6bATGFJU+G0+nHANSqjQQKBMyNZaLWMJQUVzCeaUbjBSQ==
X-Received: by 10.176.86.129 with SMTP id a1mr1803397uab.125.1474964197734; Tue, 27 Sep 2016 01:16:37 -0700 (PDT)
MIME-Version: 1.0
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.103.118.4 with HTTP; Tue, 27 Sep 2016 01:15:56 -0700 (PDT)
In-Reply-To: <1474925522.45169.337.camel@infradead.org>
References: <1474280601.144982.263.camel@infradead.org>     <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>  <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org> <6a3feeee-c575-8763-6e2a-ed9d07dbdfc0@seantek.com> <1474925522.45169.337.camel@infradead.org>
From: Nikos Mavrogiannopoulos 
Date: Tue, 27 Sep 2016 10:15:56 +0200
X-Google-Sender-Auth: JUTD0KCXt6cExuhv2EXEwdPAYek
Message-ID: 
To: David Woodhouse 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: spasm@ietf.org, Michael Richardson , Security Area Advisory Group , Sean Leonard 
Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2016 08:17:40 -0000

On Mon, Sep 26, 2016 at 11:32 PM, David Woodhouse  wrote:

>> This is surprising, because RFC 7512 Section 4.1. registers it as a
>> permanent URI scheme in the Permanent URI Schemes Registry. =:-O
>>
>> I thought that the whole point of a document called "The PKCS #11 URI
>> Scheme" would be to make PKCS #11 items accessible in URI protocol
>> slots, and conversely, to make URI protocol slots useful to PKCS
>> #11-consuming applications (in addition to other URI items such as http:
>> , ldap: , data: , etc.).
> Perhaps that was the intent; we would have to ask its authors. I cannot
> tell. But it doesn't seem stunningly useful in that form to me.,

I am not one of the authors, but I participated in the drafting of
that document. The intent was to provide a consistent way for
applications to access objects stored in PKCS#11 tokens. A URI (a
string of characters identifying a resource) seemed the appropriate
way to do it.

>>URIs are meant for Internet-accessing things

Not the PKCS#11 URI.

regards,
Nikos


From nobody Tue Sep 27 03:52:44 2016
Return-Path: 
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264A412B0DE; Tue, 27 Sep 2016 03:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 pk5KiVzFSBsd; Tue, 27 Sep 2016 03:52:38 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94ECC12B0DD; Tue, 27 Sep 2016 03:52:37 -0700 (PDT)
Received: from [10.100.100.215] (unknown [195.149.146.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 537F56C05; Tue, 27 Sep 2016 12:52:29 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "Olle E. Johansson" 
In-Reply-To: 
Date: Tue, 27 Sep 2016 12:52:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <73F3E0AD-762D-4911-ACD6-4F513E51DD4C@edvina.net>
References: <1474280601.144982.263.camel@infradead.org>     <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>  <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org> <6a3feeee-c575-8763-6e2a-ed9d07dbdfc0@seantek.com> <1474925522.45169.337.camel@infradead.org> 
To: Nikos Mavrogiannopoulos 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Michael Richardson , Olle E Johansson , spasm@ietf.org, Security Area Advisory Group , Sean Leonard , David Woodhouse 
Subject: Re: [Spasm] [saag] Best practices for applications using X.509 client certificates
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2016 10:52:41 -0000

> On 27 Sep 2016, at 10:15, Nikos Mavrogiannopoulos  =
wrote:
>=20
> On Mon, Sep 26, 2016 at 11:32 PM, David Woodhouse =
 wrote:
>=20
>>> This is surprising, because RFC 7512 Section 4.1. registers it as a
>>> permanent URI scheme in the Permanent URI Schemes Registry. =3D:-O
>>>=20
>>> I thought that the whole point of a document called "The PKCS #11 =
URI
>>> Scheme" would be to make PKCS #11 items accessible in URI protocol
>>> slots, and conversely, to make URI protocol slots useful to PKCS
>>> #11-consuming applications (in addition to other URI items such as =
http:
>>> , ldap: , data: , etc.).
>> Perhaps that was the intent; we would have to ask its authors. I =
cannot
>> tell. But it doesn't seem stunningly useful in that form to me.,
>=20
> I am not one of the authors, but I participated in the drafting of
> that document. The intent was to provide a consistent way for
> applications to access objects stored in PKCS#11 tokens. A URI (a
> string of characters identifying a resource) seemed the appropriate
> way to do it.
>=20
>>> URIs are meant for Internet-accessing things
>=20
> Not the PKCS#11 URI.


RFC 3986 states:=20
"A Uniform Resource Identifier (URI) is a compact sequence of
   characters that identifies an abstract or physical resource.=E2=80=9D

In definition of a =E2=80=9Cresource=E2=80=9D it clearly says:
" A resource is not necessarily
      accessible via the Internet; e.g., human beings, corporations, and
      bound books in a library can also be resources.  Likewise,
      abstract concepts can be resources, such as the operators and
      operands of a mathematical equation, the types of a relationship
      (e.g., "parent" or "employee"), or numeric values (e.g., zero,
      one, and infinity).=E2=80=9D

/O=