From nobody Fri Apr 1 09:43:39 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9949012D0CC for ; Fri, 1 Apr 2016 09:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=FAv52VhN; dkim=pass (1536-bit key) header.d=taugh.com header.b=G2om66MG 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 XCIVAk6EsC0Z for ; Fri, 1 Apr 2016 09:43:34 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BB4212D199 for ; Fri, 1 Apr 2016 09:43:29 -0700 (PDT) Received: (qmail 5041 invoked from network); 1 Apr 2016 16:43:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=13b0.56fea530.k1604; bh=aK4BQ0OQ8QRx6INEL4g+wgrwXTUboiNt2vFMJJna6PI=; b=FAv52VhNk0mpGJLxbm0DYcW073PC3X3QwTgUUMi7gYgunLGP6XX3FHlDodUSE6s7oTm9U4YmZWcTAoIJ4ejVgqWXEI3I7TWrmgnaLEl0RfOlcJDLsECLXOQYHvxBzgqK7BjFlapMZgK+AWfnJxfW217EwBAINwyIAGNNqG+KNbzcwsfp4akNqqzclTEntbcnipHfb33BqBJdzgN1UIl+ZpQJOpYXL+tpITtHE0Nz3y1h+hYBcJlc+PFNJcaPGXlz DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=13b0.56fea530.k1604; bh=aK4BQ0OQ8QRx6INEL4g+wgrwXTUboiNt2vFMJJna6PI=; b=G2om66MG/3KDF7gji2pJngFfjKZAJ7c6QEX+8C2CfjwH+32+7HlqcJA7hHK7wj67rFp6CKVd/7ff1Ah4Ha9qHPnzn+tpDXwCoAFL8bdIZXzecrv7b8weOn/9Yx1l2sVFlBJz1zfaMOXcqa1DyRKOxbl0LnW8q2M02rU0vj4/BtyVo1vzytiwMwT3APlYpmuAJa8piaxWhR4ep777vhaVGqR12e1rAawguRVspVJWQMT4n9wxxShFwHjcjaWMgXXO Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 01 Apr 2016 16:43:28 -0000 Date: 1 Apr 2016 12:43:27 -0400 Message-ID: From: "John R Levine" To: "Tom Ritter" In-Reply-To: References: User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: PKIX , IETF SMIME Subject: Re: [smime] [pkix] Identified Work Items and Discussion Summary (was: possible new pkix and/or smime work) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 16:43:36 -0000 > If people are unaware, protection of email headers (for PGP) is > progressing at https://modernpgp.org/memoryhole/ (although it may be a > bit stalled.) This looks like the usual approach of wrapping the message in an outer message with all of the headers genericised. Ned Freed has said this has severe patent problems. I don't know the details. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri Apr 1 10:47:14 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC11E12D543 for ; Fri, 1 Apr 2016 10:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 wNpPtkU0-NfU for ; Fri, 1 Apr 2016 10:47:09 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::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 5B8E612D120 for ; Fri, 1 Apr 2016 10:47:09 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id g3so176988009ywa.3 for ; Fri, 01 Apr 2016 10:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Q4sHTrOqMhtSiJqJPYPZ+2pNp0CRoj9pBD/8bkjIhv4=; b=SMxurLj3NcaynIuDSDqotGuNksRz++1TRuR4OYolO5R+i67Iohk9G5NqgNQzjKq8RK 1u/hE39TpmcNLqQC1JoY1Kxw8vewbGDBPvOXsmZXap8pE45TOMDSXoqD3FtKD5XHWh+z wNHJiXLmFSww0KDk11fHiiUkqyj1bhZ8MnFsDLoTTuOnG2c0RWqK8HYGBp/uLxYtVqDg SxX+TcTHQADFtpnD4v7ayI4IhjLDB7HP0qVK8zb5ssRpyeaqIvUSq5TTQYM+DItNr7f5 wLrhJzw031/Bqd8/HtnM+V7luxXM95Tg+Gj+mhgeYLet+JC02AHLhspzpg5Mk0p8ktw7 7viw== 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:date :message-id:subject:from:to:cc; bh=Q4sHTrOqMhtSiJqJPYPZ+2pNp0CRoj9pBD/8bkjIhv4=; b=b1Ju18rqIwWuBimM0jqvCEDBdoywWC3D41s+kx58XSlrhNG/GR8wTkPD2OjX2tWKcZ 3hl6oQLyJpAJ9DN9S1xYs+pI6q/KMC/dF7ISlgnNTn1pglPn+RGtKEv3yllKAgpexgz5 6tC69tWhtBvXknt0wXV9BkGBSeNyWiIkLjkCIe+ipZoP64Iib84sZV9fQxNhdiL7bCdv T7i4xH5GKKdauVTHcf1ocdIo7Bae7yqm08id+XTfSo5xsoat29HR3MqW7WS0aW/Np9uz CJWUaRdBLdedc35F8mpzAntA3ZFWzANgbTADPDvrGQFGScqX7378h5al8qsZgLHPLR+9 49tg== X-Gm-Message-State: AD7BkJLQ19/kK10WZBMjNteBsc+uiNjL21s5ugwfNrwo3fvoZq7/b4U+/WYBFMv3KnCrhCCJhAeHFFjO86QQQHtM MIME-Version: 1.0 X-Received: by 10.31.44.77 with SMTP id s74mr2453787vks.4.1459532828402; Fri, 01 Apr 2016 10:47:08 -0700 (PDT) Received: by 10.176.3.211 with HTTP; Fri, 1 Apr 2016 10:47:08 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Apr 2016 10:47:08 -0700 Message-ID: From: Wei Chuang To: John R Levine Content-Type: multipart/alternative; boundary=001a11c075a2c6ca8e052f6ff724 Archived-At: Cc: PKIX , Tom Ritter , IETF SMIME Subject: Re: [smime] [pkix] Identified Work Items and Discussion Summary (was: possible new pkix and/or smime work) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 17:47:12 -0000 --001a11c075a2c6ca8e052f6ff724 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit There's also an experimental RFC7508 "Securing Header Fields with S/MIME" plus RFC5751 mentions using message/rfc822 though that is not completely specified. One issue likely common with these approaches is keeping private the sender and recipient(s). I've pitched the idea of doing some form of onion routing to mitigate that. Hopefully these are things folks would be interested in pursuing. -Wei On Fri, Apr 1, 2016 at 9:43 AM, John R Levine wrote: > If people are unaware, protection of email headers (for PGP) is >> progressing at https://modernpgp.org/memoryhole/ (although it may be a >> bit stalled.) >> > > This looks like the usual approach of wrapping the message in an outer > message with all of the headers genericised. Ned Freed has said this has > severe patent problems. I don't know the details. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. > --001a11c075a2c6ca8e052f6ff724 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
There's also an experimental RFC7508 "Securing Header Fields with S/MIME" plus RFC5751 mentions using message/rfc822 though that is not completely specified.  One issue likely common with these approaches is keeping private the sender and recipient(s).  I've pitched the idea of doing some form of onion routing to mitigate that.  Hopefully these are things folks would be interested in pursuing.

-Wei

On Fri, Apr 1, 2016 at 9:43 AM, John R Levine <johnl@taugh.com> wrote:
If people are unaware, protection of email headers (for PGP) is
progressing at https://modernpgp.org/memoryhole/ (although it may be a
bit stalled.)

 This looks like the usual approach of wrapping the message in an outer message with all of the headers genericised.  Ned Freed has said this has severe patent problems.  I don't know the details.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

--001a11c075a2c6ca8e052f6ff724-- From nobody Sat Apr 2 08:35:38 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3037D12D17A for ; Fri, 1 Apr 2016 09:36:25 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg 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 SqP8FF9v3Yz3 for ; Fri, 1 Apr 2016 09:36:23 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 1FA0912D0EF for ; Fri, 1 Apr 2016 09:36:23 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id g3so172468359ywa.3 for ; Fri, 01 Apr 2016 09:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YZ3jfAA9QrGGidTYCpurQxtGeJfFKUJq3rg8HCIwabo=; b=Nbbqlkmw3+/Yv4rWI/ulmWLrcqaDz1fLXg0hwgnzfgjH/+CEA+kjdpZ+phUdMjVZwt 0CYU3Eqn6AXeJXNOWgb36qG5vDvI/7/YMapf7yWZDrF8N1bw1ep9z7Zn4tlINw3qf3XN 8TYnTXaooc5hAhuykmRDaks8zlqAGEyWBKSww= 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=YZ3jfAA9QrGGidTYCpurQxtGeJfFKUJq3rg8HCIwabo=; b=OfSyfyanr5xjgTA0ySKjU2Wmkb/VeX0Xgbu1/qbwRaopFa+gM046uHCV369++T9og9 mZaaRFL02I4XPHh0mUvFe8R6PDxnWA08EyLa7vL5eb2JjzHDcOlkp4OFI+zqwRbRgtaT 17Pf5/ndDb/Qgvod6n+udIFVqpKdXq1FEwnJ/z9boySupXSwWoWtjwQRSpiuEPBLeOSP NO8mJQotK7Nq3G7gueUoGBIlGR5e7hW5wARZY3z+8ua6mzyXzzvwnkoU0pgSbz7/rGTx ok789dsCJJejBIy32pju+SRtNxTMvRxp975JyD4CxjXo5zLxNdpQngGQV9oIIvgOXiz9 zV3A== X-Gm-Message-State: AD7BkJKdaM6sQkncCfpW6miA9CXl6L8JQNVaofz3YcqxOvgaeDBEiorNQsIHzQ2TmHBrgmBnou5sqnSvwwUq4kDz X-Received: by 10.37.65.22 with SMTP id o22mr3628669yba.170.1459528582286; Fri, 01 Apr 2016 09:36:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.126.197 with HTTP; Fri, 1 Apr 2016 09:36:02 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Fri, 1 Apr 2016 11:36:02 -0500 Message-ID: To: Wei Chuang Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Sat, 02 Apr 2016 08:35:37 -0700 Cc: John Levine , PKIX , IETF SMIME Subject: Re: [smime] [pkix] Identified Work Items and Discussion Summary (was: possible new pkix and/or smime work) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 16:36:25 -0000 If people are unaware, protection of email headers (for PGP) is progressing at https://modernpgp.org/memoryhole/ (although it may be a bit stalled.) -tom From nobody Sat Apr 2 08:35:40 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67AFF12D62F for ; Fri, 1 Apr 2016 11:16:43 -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=ritter.vg 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 3upk4B9lh42Z for ; Fri, 1 Apr 2016 11:16:41 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 A404012D652 for ; Fri, 1 Apr 2016 11:16:41 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id g3so178856646ywa.3 for ; Fri, 01 Apr 2016 11:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/ODaKAhHeIveA91AYaZ290MeCfl/j7TF2K1WKeppD4I=; b=WnNcHg76LruVnMhFsNVzVe8auUxwnUQ9ypKPjSVjBU+/nI0ozzjHaKWnkZmp9F8Cpb 0dCBsvrI8xBPBSklwZOZNGMeUKIVOknUmTitIFilkvQo9pD+HNtQztwJVWPzvO1LOfaJ epIMh6CjKSY4P1TQCHHY9/S7zE3uGZr2n9qMA= 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=/ODaKAhHeIveA91AYaZ290MeCfl/j7TF2K1WKeppD4I=; b=liHXl2jO+yrbWZ/uS9/dj7JMHdvsgXmjHVWfkAeO81Kw2d6PVRJqQTTCJfVmafgpLx SKBVHvC95AWL2em0b5NiQTYfjrmM2LxdsVST6N+14iYcCL3g59C2F7N9RlKUCRbwaFyb 0xYF8Xc/lDzy2bdvfEmIv2rwECBxPs5Y0xgGgFPXAhKPnkDcbXlJoGrIzedP6vdT8MmF XvIXZFdtyd7GAVXh4jp5KQEC9YW018R+nG9oIaU4sX6CF9Zg0vWkMC2dygolxqwGpIry dl6c2IEadQwnLX9RnSoxn3zjoP9I65IWXa0ot26ch9tnPUg2obFpJz0sh34F8bKiUpeR hPoQ== X-Gm-Message-State: AD7BkJIeZvyvk06Q85Z9DLFF1VPKD2XtAYE7FNeD1Y7Zk+UVTyLJKgTIqwVa/8r0V/3XkIZdBM0i5ziT2gB4rizD X-Received: by 10.129.72.148 with SMTP id v142mr10799254ywa.228.1459534600855; Fri, 01 Apr 2016 11:16:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.126.197 with HTTP; Fri, 1 Apr 2016 11:16:21 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Fri, 1 Apr 2016 13:16:21 -0500 Message-ID: To: Wei Chuang Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Sat, 02 Apr 2016 08:35:37 -0700 Cc: PKIX , IETF SMIME Subject: Re: [smime] [pkix] Identified Work Items and Discussion Summary (was: possible new pkix and/or smime work) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 18:16:43 -0000 On 1 April 2016 at 12:47, Wei Chuang wrote: > There's also an experimental RFC7508 "Securing Header Fields with S/MIME" > plus RFC5751 mentions using message/rfc822 though that is not completely > specified. One issue likely common with these approaches is keeping private > the sender and recipient(s). I've pitched the idea of doing some form of > onion routing to mitigate that. Hopefully these are things folks would be > interested in pursuing. I'm super interested in that. I've been interested and worked casually on mix networks for a bit, for strong anonymity. But there are lots of problems there, including reliability (and throughput) of nodes, abuse, and of course the 'going dark on spam' problem . Lately I've been thinking about something weaker and potentially more deployable. Model it as four parties at play: Sender, Receiver, Sender Provider, Receiver Provider. Right now each party sees everything - goal is to reduce that. One idea I've had is that each provider can publish a remailer@provider.com address. You encrypt a message to remailer@gmail.com specifying alice@gmail.com as the recipient with the body additionally encrypted (or not) to Alice. Google decrypts and then forwards to Alice. This makes the Recipient private from the Sender Provider, and doesn't impact any sort of incoming spam controls. (It does impact outgoing spam controls to a certain degree.) Another idea is that the sending provider can strip all identifying information from the message as it passes through them. The information is contained inside the encrypted envelope to the final recipient. Sending provider will still know who's sending the message (SMTP authentication) - but the Receiving Provider doesn't learn the Sender. You've got lots of concerns about impersonation here, but I think we could device a cryptographic protocol that gives the Sending Provider assurance the Sender isn't trying to masquerade as someone else. (The simplest one would just have the Sending Provider encrypt the Sender to the Recipient.) -tom From nobody Mon Apr 4 08:07:48 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FD512D68E for ; Mon, 4 Apr 2016 08:07:46 -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 4QtX8GKf_RgD for ; Mon, 4 Apr 2016 08:07:43 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 268B812D783 for ; Mon, 4 Apr 2016 08:07:26 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 272D4F24087 for ; Mon, 4 Apr 2016 11:07:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id SqsZBlecI6ND for ; Mon, 4 Apr 2016 10:53:00 -0400 (EDT) Received: from dhcp-b4d9.meeting.ietf.org (dhcp-b4d9.meeting.ietf.org [31.133.180.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 629B3F2403D for ; Mon, 4 Apr 2016 11:07:25 -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: Mon, 4 Apr 2016 11:07:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C73F4BDB8A8@uxcn10-5.UoA.auckland.ac.nz> <56d70399.8d41620a.19ae8.ffffeb3bSMTPIN_ADDED_MISSING@mx.google.com> To: IETF SMIME X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [smime] Message takeover attacks against S/MIME X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 15:07:47 -0000 Regarding item 2, we already have RFC 5084 that specifies the use of = AES-CCM and AES-GCM with CMS. I have just posted an I-D that specifies = the use of ChaCha20 with Poly1305 with CMS: = https://www.ietf.org/id/draft-housley-cms-chacha20-poly1305-00.txt Please read and review. Russ On Mar 8, 2016, at 1:58 AM, Russ Housley wrote: > I am hearing interest in these topics (a combination of things on this = list and side conversations). >=20 > (1) Specify the way to use authenticated encryption in S/MIME. Note = that it is already done for CMS. >=20 > (2) Specify conventions for AES-CCM, AES-GCM, and ChaCha20 with = Poly1305 authenticated encryption algorithms. >=20 > (3) Specify conventions for using Curve25519 and Curve448 for key = agreement. >=20 > (4) Specify conventions for using the CFRG chosen curves for elliptic = curve digital signature. >=20 > (5) Specify a way to use PGP public keys in addition to PKIX = certificates. >=20 > Anything else? >=20 > Is this enough to re-charter the S/MIME WG? >=20 > Russ From nobody Mon Apr 4 12:22:02 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3376412D0C1; Mon, 4 Apr 2016 12:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 tvUMg_kTSWBg; Mon, 4 Apr 2016 12:21:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1E812D7EA; Mon, 4 Apr 2016 12:21:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2E00FBE83; Mon, 4 Apr 2016 20:21:51 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsYWQUy-Vr19; Mon, 4 Apr 2016 20:21:50 +0100 (IST) Received: from [31.133.178.21] (dhcp-b215.meeting.ietf.org [31.133.178.21]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3131CBE7C; Mon, 4 Apr 2016 20:21:47 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1459797709; bh=Yn69VOfwaWf6dTWju84FT8UPSwaIgCCMkLxD9oDEv9s=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=LCp1APV6Y12OPoLnqBnPadGYE8cYlc7uLiylvuAyCO9OkD8YzfkzkQkMUz8WgS+Ba PqOscIhP+R9DL/ADHdeUA3vnk1zYYjTNHapkFyLwISrgk7aQn+eEDSpHD2wsrH1C38 Uw86kGLaERZuCBnUJRQxYbr/hatUdDpiWzhYlKz8= To: Wei Chuang , PKIX , IETF SMIME References: <56FD7597.4020601@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5702BEC9.7040403@cs.tcd.ie> Date: Mon, 4 Apr 2016 20:21:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56FD7597.4020601@cs.tcd.ie> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000809030703040903030509" Archived-At: Cc: John Levine Subject: Re: [smime] [pkix] Identified Work Items and Discussion Summary (was: possible new pkix and/or smime work) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 19:21:59 -0000 This is a cryptographically signed message in MIME format. --------------ms000809030703040903030509 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 31/03/16 20:08, Stephen Farrell wrote: >=20 > And separately, I'd like to try get interested folks who'll be > at IETF95 together for a chat if we can. If you're interested in this and at IETF95, I've booked a room (Paraiso, 5th floor) for Thursday 1945 to chat about whether or not we seem to have enough work and interest to charter a WG for some of these. I think we should aim to be quick about that so I've just booked 30 minutes. Chat can of course continue after that at bits'n'bytes or elsewhere. Please send me an offlist reply to this if you'd like to take part, just for room-size. Thanks, S. --------------ms000809030703040903030509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA0MDQx OTIxNDVaMC8GCSqGSIb3DQEJBDEiBCCqMeywKU3uYO+NTWA/t0xUeZRQCwsyP0VLI6HKPiCy KTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAlhDHjHuquv+VgqKaiQA5rex7Lp6ztmvznnUZKbHhDjlwOTNep7Jkx 3WM+nenQKtQNTrUW/DLj/xNd1dgz8psOG4p2jQPZctxjAJVhaMIjXJpZmavgxDWBkk2aCnh5 QGUtLSJzXDUs7DX6lu11dHgY5IDXU0C9hQrDpkO/B+QhwQ5ZF3lYBtyK2g26U4ySSt0dhH0g bKEow/lr8EB6OhzM0VQO/8/Z/jzI26Gjig2p5vEc8zVTQW1+rhnJl+wI1c2DM3XJrOyJQT0z +tS9QDs/uvKW1+Zzu2brI6G8Tk3odBWyxaoCyCTL8iHoQ2pw7l2y8H9xIVO7BGXDc7vdg+fv AAAAAAAA --------------ms000809030703040903030509-- From nobody Mon Apr 4 15:20:17 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D8C12D646; Mon, 4 Apr 2016 15:20:15 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 l8qc_QcmDuoF; Mon, 4 Apr 2016 15:20:13 -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 2740D12D190; Mon, 4 Apr 2016 15:20:13 -0700 (PDT) Received: from dhcp-aa67.meeting.ietf.org (unknown [31.133.170.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 21660509B6; Mon, 4 Apr 2016 18:20:10 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_2AAAC662-09D8-483E-AC29-211072D21E82" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: Date: Mon, 4 Apr 2016 19:20:10 -0300 Message-Id: References: To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: smime@ietf.org Subject: Re: [smime] [pkix] Support for email address internationalization in RFC5280 certificates X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:20:15 -0000 --Apple-Mail=_2AAAC662-09D8-483E-AC29-211072D21E82 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 7, 2016, at 12:15 PM, Wei Chuang wrote: >=20 >=20 >=20 > On Fri, Feb 5, 2016 at 4:46 PM, Peter Bowen > wrote: > On Thu, Feb 4, 2016 at 11:05 AM, Wei Chuang > wrote: > > PKIX community, > > > > We've observed a limitation for specifying internationalized email = addresses > > as the local part which is restricted to essentially ASCII. That is = subject > > or issuer email addresses which should be stored as subject-alt-name = or > > issuer-alt-name rfc822Name and are encoded as IA5String. This is = despite > > the internationalization in email usage as specified by = internationalization > > of email headers in RFC6532 allowing Unicode in To, From, etc fields = and > > becoming fairly commonplace. RFC5280 already specifies = internationalization > > of the domain but lacks any specification for the local-part. Up until now, I have tried to lay low on this topic. However, having = reviewed the relevant standards and implementations in the field, I have = my 22=C2=A2: The proposed methods are to create an otherName form and assign a new = object identifier for it (A. Melnikov, ed., = draft-ietf-pkix-eai-addresses-00), and to encode the local part in = base64 with =E2=80=9C:=E2=80=9D as an escape signal (L. Baudoin, et. = al., draft-lbaudoin-iemax-02). There is also a counterproposal on the = agenda, which I will label as #3, to make rfc822Name a CHOICE = {IA5String, UTF8String}. There are two other methods that deserve = serious consideration. My 0.2=C2=A2 is on #4 and my 21.8=C2=A2 is on #5: #4 Extend GeneralName with a new name type: GeneralName ::=3D CHOICE { otherName [0] INSTANCE OF OTHER-NAME, rfc822Name [1] IA5String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [7] OCTET STRING, registeredID [8] OBJECT IDENTIFIER, eaiName [9] UTF8String ... } The advantage of this approach is that it conforms to X.509:2012, which = uses =E2=80=A6 syntax to show that the CHOICE is extensible. However, = the IETF invented GeneralName (RFC 2459), and the latest ASN.1 (RFC = 5912) does not use =E2=80=A6 syntax for extensibility. (Basically I = think most implementations would barf on this CHOICE, and would cause = the overall ASN.1 decoding op to fail, meaning all places where = GeneralName is directly encoded, would cause implementations to barf.) #5 Change GeneralName so that rfc822Name is actually just UTF8String: GeneralName ::=3D CHOICE { otherName [0] INSTANCE OF OTHER-NAME, rfc822Name [1] UTF8String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [7] OCTET STRING, registeredID [8] OBJECT IDENTIFIER } GeneralName is in the IMPLICIT TAGS part of PKIX. That means that on the = wire, a GeneralName will (almost always) just be serialized as the application tag in the choice, followed by the length and the data. The = counterproposal of a CHOICE {IA5String, UTF8String} is flawed in that it = will force ALL rfc822Names to include an additional tag UNIVERSAL 22 in = the case of IA5String, because the choice is ambiguous without the tag = (so a proper ASN.1 compiler will force the serialization and = de-serialization of the tag). Note: UTF8String (in a CHOICE) would force = serialization of the tag UNIVERSAL 12. With this proposal #5, UTF8String is just a superset of IA5String. = Therefore, new implementations will =E2=80=9Cjust work=E2=80=9D with = virtually no further coding. The high-octet data in UTF8String will = violate expectations for older implementations that are looking for = IA5String. But enforcement of octets 00-7F is almost never done in the = decoding step, or if it is done, it does not cause the entire ASN.1 = decoding op to fail. (Note: this would be an =E2=80=9CASN.1 value = constraint violation.=E2=80=9D) If most implementations will continue to = decode the ASN.1 and simply skip over what it perceives to be =E2=80=9Cinv= alid ASCII=E2=80=9D (or simply rejects that particular alternative when = doing name comparisons), we are good to go. This basically mirrors the = way that EAI itself works in RFCs 6530-6532. To test this, one would want to construct a signed certificate with = =E2=80=9Cinvalid=E2=80=9D IA5String data that actually contains valid = Unicode octets, and see what happens with various implementations. I am not saying that this is the =E2=80=9Cright=E2=80=9D approach, but I = do think that it deserves serious consideration when evaluating = alternatives. An example of an advantage is that it should preserve name = constraints with no additional coding. Regards, Sean= --Apple-Mail=_2AAAC662-09D8-483E-AC29-211072D21E82 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 7, 2016, at 12:15 PM, Wei Chuang <weihaw@google.com> = wrote:



On Fri, Feb 5, 2016 at 4:46 PM, = Peter Bowen <pzbowen@gmail.com> wrote:
On Thu, Feb = 4, 2016 at 11:05 AM, Wei Chuang <weihaw@google.com> wrote:
> PKIX community,
>
> We've observed a limitation for specifying internationalized email = addresses
> as the local part which is restricted to essentially ASCII.  = That is subject
> or issuer email addresses which should be stored as = subject-alt-name or
> issuer-alt-name rfc822Name and are encoded as IA5String.  This = is despite
> the internationalization in email usage as specified by = internationalization
> of email headers in RFC6532 allowing Unicode in To, From, etc = fields and
> becoming fairly commonplace.  RFC5280 already specifies = internationalization
> of the domain but lacks any specification for the = local-part.
<= br class=3D"">
Up until now, I have tried to lay low on this = topic. However, having reviewed the relevant standards and = implementations in the field, I have my 22=C2=A2:

The proposed methods are to create an otherName = form and assign a new object identifier for it (A. Melnikov, ed., = draft-ietf-pkix-eai-addresses-00), and to encode the local part in = base64 with =E2=80=9C:=E2=80=9D as an escape signal (L. Baudoin, et. = al., draft-lbaudoin-iemax-02). There is also a counterproposal on the = agenda, which I will label as #3, to make rfc822Name a CHOICE {IA5String, UTF8String}. There = are two other methods that deserve serious consideration. My 0.2=C2=A2 = is on #4 and my 21.8=C2=A2 is on #5:

#4 Extend GeneralName with a new name = type:

GeneralName ::=3D CHOICE {
  otherName [0] INSTANCE OF OTHER-NAME,
  rfc822Name [1] IA5String,
  dNSName [2] IA5String,
  x400Address [3] ORAddress,
  directoryName [4] Name,
  ediPartyName [5] EDIPartyName,
  uniformResourceIdentifier [6] = IA5String,
  iPAddress [7] OCTET = STRING,
  registeredID [8] OBJECT = IDENTIFIER,
  eaiName = [9] UTF8String
  ... = }

The advantage of this = approach is that it conforms to X.509:2012, which uses =E2=80=A6 syntax = to show that the CHOICE is extensible. However, the IETF invented = GeneralName (RFC 2459), and the latest ASN.1 (RFC 5912) does not use =E2=80= =A6 syntax for extensibility. (Basically I think most implementations = would barf on this CHOICE, and would cause the overall ASN.1 decoding op = to fail, meaning all places where GeneralName is directly encoded, would = cause implementations to barf.)

#5 Change = GeneralName so that rfc822Name is actually just = UTF8String:

   GeneralName ::=3D =
CHOICE {
        otherName                   [0]  INSTANCE OF OTHER-NAME,
        rfc822Name                  [1]  UTF8String,
        dNSName                     [2]  IA5String,
        x400Address                 [3]  ORAddress,
        directoryName               [4]  Name,
        ediPartyName                [5]  EDIPartyName,
        uniformResourceIdentifier   [6]  IA5String,
        iPAddress                   [7]  OCTET STRING,
        registeredID                [8]  OBJECT IDENTIFIER
   }

GeneralName= is in the IMPLICIT TAGS part of PKIX. That means that on the wire, a = GeneralName will (almost always) just be serialized as the
application tag in the choice, followed by the length and the = data. The counterproposal of a CHOICE {IA5String, UTF8String} is flawed in that = it will force ALL rfc822Names to include an additional tag UNIVERSAL 22 = in the case of IA5String, because the choice is ambiguous without the = tag (so a proper ASN.1 compiler will force the serialization and = de-serialization of the tag). Note: UTF8String (in a CHOICE) would force = serialization of the tag UNIVERSAL 12.

With this proposal #5, UTF8String is = just a superset of IA5String. Therefore, new implementations will = =E2=80=9Cjust work=E2=80=9D with virtually no further coding. The = high-octet data in UTF8String will violate expectations for older = implementations that are looking for IA5String. But enforcement of = octets 00-7F is almost never done in the decoding step, or if it is = done, it does not cause the entire ASN.1 decoding op to fail. (Note: = this would be an =E2=80=9CASN.1 value constraint violation.=E2=80=9D) If = most implementations will continue to decode the ASN.1 and simply skip = over what it perceives to be =E2=80=9Cinvalid ASCII=E2=80=9D (or simply = rejects that particular alternative when doing name comparisons), we are = good to go. This basically mirrors the way that EAI itself works in RFCs = 6530-6532.

To = test this, one would want to construct a signed certificate with = =E2=80=9Cinvalid=E2=80=9D IA5String data that actually contains valid = Unicode octets, and see what happens with various = implementations.

I am not saying that this is the =E2=80=9Cright=E2=80=9D = approach, but I do think that it deserves serious consideration when = evaluating alternatives. An example of an advantage is that it should = preserve name constraints with no additional coding.

Regards,

Sean
= --Apple-Mail=_2AAAC662-09D8-483E-AC29-211072D21E82-- From nobody Tue Apr 5 06:56:48 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE1012D581; Tue, 5 Apr 2016 06:56:45 -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 iQdzgBl3A__S; Tue, 5 Apr 2016 06:56:42 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id A17FB12D59A; Tue, 5 Apr 2016 06:56:39 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 16F90F24062; Tue, 5 Apr 2016 09:56:39 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id BVqbx5nwMUh8; Tue, 5 Apr 2016 09:41:58 -0400 (EDT) Received: from dhcp-9a55.meeting.ietf.org (dhcp-9a55.meeting.ietf.org [31.133.154.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 63DD0F24035; Tue, 5 Apr 2016 09:56:26 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_65D25184-2D90-4756-A697-0D563996BB2D" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Tue, 5 Apr 2016 08:18:05 -0400 Message-Id: References: To: Sean Leonard X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF PKIX , IETF SMIME Subject: Re: [smime] [pkix] Support for email address internationalization in RFC5280 certificates X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 13:56:45 -0000 --Apple-Mail=_65D25184-2D90-4756-A697-0D563996BB2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I am opposed to extending GeneralName with a new item in the CHOICE = because the syntax in RFC5280. That syntax is aligned with X.509. We = would need to work with ITU-T to make an addition to the CHOICE, = otherwise the ITU-T could make a change to their specification in the = future that causes interoperability problems. I am strongly opposed to changing the type of rfc822name. As above, = this syntax belongs to X.509. In addition, this change would cause = decode errors for existing software, and we have seen decode errors lead = to very surprising user experiences. I believe that using the otherName extension mechanism does not have any = of the problems with these two proposals. Russ On Apr 4, 2016, at 6:20 PM, Sean Leonard wrote: >=20 >> On Feb 7, 2016, at 12:15 PM, Wei Chuang wrote: >>=20 >>=20 >>=20 >> On Fri, Feb 5, 2016 at 4:46 PM, Peter Bowen = wrote: >> On Thu, Feb 4, 2016 at 11:05 AM, Wei Chuang = wrote: >> > PKIX community, >> > >> > We've observed a limitation for specifying internationalized email = addresses >> > as the local part which is restricted to essentially ASCII. That = is subject >> > or issuer email addresses which should be stored as = subject-alt-name or >> > issuer-alt-name rfc822Name and are encoded as IA5String. This is = despite >> > the internationalization in email usage as specified by = internationalization >> > of email headers in RFC6532 allowing Unicode in To, From, etc = fields and >> > becoming fairly commonplace. RFC5280 already specifies = internationalization >> > of the domain but lacks any specification for the local-part. >=20 > Up until now, I have tried to lay low on this topic. However, having = reviewed the relevant standards and implementations in the field, I have = my 22=A2: >=20 > The proposed methods are to create an otherName form and assign a new = object identifier for it (A. Melnikov, ed., = draft-ietf-pkix-eai-addresses-00), and to encode the local part in = base64 with =93:=94 as an escape signal (L. Baudoin, et. al., = draft-lbaudoin-iemax-02). There is also a counterproposal on the agenda, = which I will label as #3, to make rfc822Name a CHOICE {IA5String, = UTF8String}. There are two other methods that deserve serious = consideration. My 0.2=A2 is on #4 and my 21.8=A2 is on #5: >=20 > #4 Extend GeneralName with a new name type: >=20 > GeneralName ::=3D CHOICE { > otherName [0] INSTANCE OF OTHER-NAME, > rfc822Name [1] IA5String, > dNSName [2] IA5String, > x400Address [3] ORAddress, > directoryName [4] Name, > ediPartyName [5] EDIPartyName, > uniformResourceIdentifier [6] IA5String, > iPAddress [7] OCTET STRING, > registeredID [8] OBJECT IDENTIFIER, > eaiName [9] UTF8String > ... } >=20 > The advantage of this approach is that it conforms to X.509:2012, = which uses =85 syntax to show that the CHOICE is extensible. However, = the IETF invented GeneralName (RFC 2459), and the latest ASN.1 (RFC = 5912) does not use =85 syntax for extensibility. (Basically I think most = implementations would barf on this CHOICE, and would cause the overall = ASN.1 decoding op to fail, meaning all places where GeneralName is = directly encoded, would cause implementations to barf.) >=20 > #5 Change GeneralName so that rfc822Name is actually just UTF8String: >=20 > GeneralName ::=3D CHOICE { > otherName [0] INSTANCE OF OTHER-NAME, > rfc822Name [1] UTF8String, > dNSName [2] IA5String, > x400Address [3] ORAddress, > directoryName [4] Name, > ediPartyName [5] EDIPartyName, > uniformResourceIdentifier [6] IA5String, > iPAddress [7] OCTET STRING, > registeredID [8] OBJECT IDENTIFIER > } >=20 > GeneralName is in the IMPLICIT TAGS part of PKIX. That means that on = the wire, a GeneralName will (almost always) just be serialized as the > application tag in the choice, followed by the length and the data. = The counterproposal of a CHOICE {IA5String, UTF8String} is flawed in = that it will force ALL rfc822Names to include an additional tag = UNIVERSAL 22 in the case of IA5String, because the choice is ambiguous = without the tag (so a proper ASN.1 compiler will force the serialization = and de-serialization of the tag). Note: UTF8String (in a CHOICE) would = force serialization of the tag UNIVERSAL 12. >=20 > With this proposal #5, UTF8String is just a superset of IA5String. = Therefore, new implementations will =93just work=94 with virtually no = further coding. The high-octet data in UTF8String will violate = expectations for older implementations that are looking for IA5String. = But enforcement of octets 00-7F is almost never done in the decoding = step, or if it is done, it does not cause the entire ASN.1 decoding op = to fail. (Note: this would be an =93ASN.1 value constraint violation.=94) = If most implementations will continue to decode the ASN.1 and simply = skip over what it perceives to be =93invalid ASCII=94 (or simply rejects = that particular alternative when doing name comparisons), we are good to = go. This basically mirrors the way that EAI itself works in RFCs = 6530-6532. >=20 > To test this, one would want to construct a signed certificate with = =93invalid=94 IA5String data that actually contains valid Unicode = octets, and see what happens with various implementations. >=20 > I am not saying that this is the =93right=94 approach, but I do think = that it deserves serious consideration when evaluating alternatives. An = example of an advantage is that it should preserve name constraints with = no additional coding. >=20 > Regards, >=20 > Sean > _______________________________________________ > smime mailing list > smime@ietf.org > https://www.ietf.org/mailman/listinfo/smime --Apple-Mail=_65D25184-2D90-4756-A697-0D563996BB2D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I am = opposed to extending GeneralName with a new item in the CHOICE because = the syntax in RFC5280.  That syntax is aligned with X.509.  We = would need to work with ITU-T to make an addition to the CHOICE, = otherwise the ITU-T could make a change to their specification in the = future that causes interoperability problems.

I am = strongly opposed to changing the type of rfc822name.  As above, = this syntax belongs to X.509.  In addition, this change would cause = decode errors for existing software, and we have seen decode errors lead = to very surprising user experiences.

I believe = that using the otherName extension mechanism does not have any of the = problems with these two = proposals.

Russ


On Apr 4, 2016, at 6:20 PM, Sean Leonard <dev+ietf@seantek.com> = wrote:


On = Feb 7, 2016, at 12:15 PM, Wei Chuang <weihaw@google.com> = wrote:



On Fri, Feb 5, 2016 at 4:46 PM, = Peter Bowen <pzbowen@gmail.com> wrote:
On Thu, Feb = 4, 2016 at 11:05 AM, Wei Chuang <weihaw@google.com> wrote:
> PKIX community,
>
> We've observed a limitation for specifying internationalized email = addresses
> as the local part which is restricted to essentially ASCII.  = That is subject
> or issuer email addresses which should be stored as = subject-alt-name or
> issuer-alt-name rfc822Name and are encoded as IA5String.  This = is despite
> the internationalization in email usage as specified by = internationalization
> of email headers in RFC6532 allowing Unicode in To, From, etc = fields and
> becoming fairly commonplace.  RFC5280 already specifies = internationalization
> of the domain but lacks any specification for the = local-part.
<= br class=3D"">
Up until now, I have tried to lay low on this = topic. However, having reviewed the relevant standards and = implementations in the field, I have my 22=A2:

The proposed methods are to create an otherName = form and assign a new object identifier for it (A. Melnikov, ed., = draft-ietf-pkix-eai-addresses-00), and to encode the local part in = base64 with =93:=94 as an escape signal (L. Baudoin, et. al., = draft-lbaudoin-iemax-02). There is also a counterproposal on the agenda, = which I will label as #3, to make rfc822Name a CHOICE {IA5String, UTF8String}. There are two other = methods that deserve serious consideration. My 0.2=A2 is on #4 and my = 21.8=A2 is on #5:

#4 Extend = GeneralName with a new name type:

GeneralName ::=3D CHOICE {
  otherName [0] INSTANCE OF OTHER-NAME,
  rfc822Name [1] IA5String,
  dNSName [2] IA5String,
  x400Address [3] ORAddress,
  directoryName [4] Name,
  ediPartyName [5] EDIPartyName,
  uniformResourceIdentifier [6] = IA5String,
  iPAddress [7] OCTET = STRING,
  registeredID [8] OBJECT = IDENTIFIER,
  eaiName = [9] UTF8String
  ... = }

The advantage of this = approach is that it conforms to X.509:2012, which uses =85 syntax to = show that the CHOICE is extensible. However, the IETF invented = GeneralName (RFC 2459), and the latest ASN.1 (RFC 5912) does not use =85 = syntax for extensibility. (Basically I think most implementations would = barf on this CHOICE, and would cause the overall ASN.1 decoding op to = fail, meaning all places where GeneralName is directly encoded, would = cause implementations to barf.)

#5 Change = GeneralName so that rfc822Name is actually just = UTF8String:

   GeneralName ::=3D CHOICE {
        otherName                   [0]  INSTANCE OF OTHER-NAME,
        rfc822Name                  [1]  UTF8String,
        dNSName                     [2]  IA5String,
        x400Address                 [3]  ORAddress,
        directoryName               [4]  Name,
        ediPartyName                [5]  EDIPartyName,
        uniformResourceIdentifier   [6]  IA5String,
        iPAddress                   [7]  OCTET STRING,
        registeredID                [8]  OBJECT IDENTIFIER
   }

GeneralName= is in the IMPLICIT TAGS part of PKIX. That means that on the wire, a = GeneralName will (almost always) just be serialized as the
application tag in the choice, followed by the length and the = data. The counterproposal of a CHOICE {IA5String, UTF8String} is flawed in that = it will force ALL rfc822Names to include an additional tag UNIVERSAL 22 = in the case of IA5String, because the choice is ambiguous without the = tag (so a proper ASN.1 compiler will force the serialization and = de-serialization of the tag). Note: UTF8String (in a CHOICE) would force = serialization of the tag UNIVERSAL 12.

With this proposal #5, UTF8String is = just a superset of IA5String. Therefore, new implementations will =93just = work=94 with virtually no further coding. The high-octet data in = UTF8String will violate expectations for older implementations that are = looking for IA5String. But enforcement of octets 00-7F is almost never = done in the decoding step, or if it is done, it does not cause the = entire ASN.1 decoding op to fail. (Note: this would be an =93ASN.1 value = constraint violation.=94) If most implementations will continue to = decode the ASN.1 and simply skip over what it perceives to be =93invalid = ASCII=94 (or simply rejects that particular alternative when doing name = comparisons), we are good to go. This basically mirrors the way that EAI = itself works in RFCs 6530-6532.

To test this, one would want to = construct a signed certificate with =93invalid=94 IA5String data that = actually contains valid Unicode octets, and see what happens with = various implementations.

I am not saying that this is the =93right=94 approach, but I = do think that it deserves serious consideration when evaluating = alternatives. An example of an advantage is that it should preserve name = constraints with no additional coding.

Regards,

Sean
___________________________________= ____________
smime mailing list
smime@ietf.org
https://www.ietf.org/= mailman/listinfo/smime

= --Apple-Mail=_65D25184-2D90-4756-A697-0D563996BB2D-- From nobody Tue Apr 5 10:30:48 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1ED412D1D2; Tue, 5 Apr 2016 10:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 tsqULvEDhhkb; Tue, 5 Apr 2016 10:30:39 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A18A712D7B2; Tue, 5 Apr 2016 10:30:37 -0700 (PDT) Received: from hebrews (dhcp-aae6.meeting.ietf.org [31.133.170.230]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 75EE92CA95; Tue, 5 Apr 2016 10:30:35 -0700 (PDT) From: "Jim Schaad" To: "'Russ Housley'" , "'Sean Leonard'" References: In-Reply-To: Date: Tue, 5 Apr 2016 14:30:32 -0300 Message-ID: <028101d18f60$dd6262e0$982728a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0282_01D18F47.B81AF740" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLOjVDltmejIMpm0/V7VsO85IxshwHtG1NEAiFZuIcCIOHxwQIN1F2GnT+9coA= Content-Language: en-us Archived-At: Cc: 'IETF PKIX' , 'IETF SMIME' Subject: Re: [smime] [pkix] Support for email address internationalization in RFC5280 certificates X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 17:30:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0282_01D18F47.B81AF740 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It would also be a good way to have all existing implementations crash = as they see an option in the choice they do not support. =20 I agree with the use of the OtherName extension. =20 Jim =20 =20 From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Russ Housley Sent: Tuesday, April 05, 2016 9:18 AM To: Sean Leonard Cc: IETF PKIX ; IETF SMIME Subject: Re: [pkix] [smime] Support for email address = internationalization in RFC5280 certificates =20 I am opposed to extending GeneralName with a new item in the CHOICE = because the syntax in RFC5280. That syntax is aligned with X.509. We would = need to work with ITU-T to make an addition to the CHOICE, otherwise the ITU-T = could make a change to their specification in the future that causes interoperability problems. =20 I am strongly opposed to changing the type of rfc822name. As above, = this syntax belongs to X.509. In addition, this change would cause decode = errors for existing software, and we have seen decode errors lead to very surprising user experiences. =20 I believe that using the otherName extension mechanism does not have any = of the problems with these two proposals. =20 Russ =20 =20 On Apr 4, 2016, at 6:20 PM, Sean Leonard > wrote: =20 On Feb 7, 2016, at 12:15 PM, Wei Chuang > wrote: =20 =20 =20 On Fri, Feb 5, 2016 at 4:46 PM, Peter Bowen > wrote: On Thu, Feb 4, 2016 at 11:05 AM, Wei Chuang > wrote: > PKIX community, > > We've observed a limitation for specifying internationalized email addresses > as the local part which is restricted to essentially ASCII. That is subject > or issuer email addresses which should be stored as subject-alt-name = or > issuer-alt-name rfc822Name and are encoded as IA5String. This is = despite > the internationalization in email usage as specified by internationalization > of email headers in RFC6532 allowing Unicode in To, From, etc fields = and > becoming fairly commonplace. RFC5280 already specifies internationalization > of the domain but lacks any specification for the local-part. =20 Up until now, I have tried to lay low on this topic. However, having reviewed the relevant standards and implementations in the field, I have = my 22=A2: =20 The proposed methods are to create an otherName form and assign a new = object identifier for it (A. Melnikov, ed., draft-ietf-pkix-eai-addresses-00), = and to encode the local part in base64 with =93:=94 as an escape signal (L. = Baudoin, et. al., draft-lbaudoin-iemax-02). There is also a counterproposal on = the agenda, which I will label as #3, to make rfc822Name a CHOICE = {IA5String, UTF8String}. There are two other methods that deserve serious = consideration. My 0.2=A2 is on #4 and my 21.8=A2 is on #5: =20 #4 Extend GeneralName with a new name type: =20 GeneralName ::=3D CHOICE { otherName [0] INSTANCE OF OTHER-NAME, rfc822Name [1] IA5String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [7] OCTET STRING, registeredID [8] OBJECT IDENTIFIER, eaiName [9] UTF8String ... } =20 The advantage of this approach is that it conforms to X.509:2012, which = uses =85 syntax to show that the CHOICE is extensible. However, the IETF = invented GeneralName (RFC 2459), and the latest ASN.1 (RFC 5912) does not use =85 syntax for extensibility. (Basically I think most implementations would = barf on this CHOICE, and would cause the overall ASN.1 decoding op to fail, meaning all places where GeneralName is directly encoded, would cause implementations to barf.) =20 #5 Change GeneralName so that rfc822Name is actually just UTF8String: =20 GeneralName ::=3D CHOICE { otherName [0] INSTANCE OF OTHER-NAME, rfc822Name [1] UTF8String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [7] OCTET STRING, registeredID [8] OBJECT IDENTIFIER } =20 GeneralName is in the IMPLICIT TAGS part of PKIX. That means that on the wire, a GeneralName will (almost always) just be serialized as the application tag in the choice, followed by the length and the data. The counterproposal of a CHOICE {IA5String, UTF8String} is flawed in that it will force ALL rfc822Names to include an additional tag UNIVERSAL 22 in = the case of IA5String, because the choice is ambiguous without the tag (so a proper ASN.1 compiler will force the serialization and de-serialization = of the tag). Note: UTF8String (in a CHOICE) would force serialization of = the tag UNIVERSAL 12. =20 With this proposal #5, UTF8String is just a superset of IA5String. Therefore, new implementations will =93just work=94 with virtually no = further coding. The high-octet data in UTF8String will violate expectations for older implementations that are looking for IA5String. But enforcement of octets 00-7F is almost never done in the decoding step, or if it is = done, it does not cause the entire ASN.1 decoding op to fail. (Note: this would = be an =93ASN.1 value constraint violation.=94) If most implementations will = continue to decode the ASN.1 and simply skip over what it perceives to be = =93invalid ASCII=94 (or simply rejects that particular alternative when doing name comparisons), we are good to go. This basically mirrors the way that EAI itself works in RFCs 6530-6532. =20 To test this, one would want to construct a signed certificate with =93invalid=94 IA5String data that actually contains valid Unicode = octets, and see what happens with various implementations. =20 I am not saying that this is the =93right=94 approach, but I do think = that it deserves serious consideration when evaluating alternatives. An example = of an advantage is that it should preserve name constraints with no = additional coding. =20 Regards, =20 Sean _______________________________________________ smime mailing list smime@ietf.org =20 https://www.ietf.org/mailman/listinfo/smime =20 ------=_NextPart_000_0282_01D18F47.B81AF740 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

It would = also be a good way to have all existing implementations crash as they = see an option in the choice they do not support.

 

I agree with = the use of the OtherName extension.

 

Jim

 

 

From:<= /b> = pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Russ = Housley
Sent: Tuesday, April 05, 2016 9:18 AM
To: = Sean Leonard <dev+ietf@seantek.com>
Cc: IETF PKIX = <pkix@ietf.org>; IETF SMIME = <smime@ietf.org>
Subject: Re: [pkix] [smime] Support for = email address internationalization in RFC5280 = certificates

 

I am opposed = to extending GeneralName with a new item in the CHOICE because the = syntax in RFC5280.  That syntax is aligned with X.509.  We = would need to work with ITU-T to make an addition to the CHOICE, = otherwise the ITU-T could make a change to their specification in the = future that causes interoperability problems.

 

I = am strongly opposed to changing the type of rfc822name.  As above, = this syntax belongs to X.509.  In addition, this change would cause = decode errors for existing software, and we have seen decode errors lead = to very surprising user experiences.

 

I = believe that using the otherName extension mechanism does not have any = of the problems with these two proposals.

 

Russ

 

 

On = Apr 4, 2016, at 6:20 PM, Sean Leonard <dev+ietf@seantek.com> = wrote:



 

On Feb 7, 2016, at 12:15 PM, Wei Chuang <weihaw@google.com> = wrote:

 

 

 

On Fri, = Feb 5, 2016 at 4:46 PM, Peter Bowen <pzbowen@gmail.com> = wrote:

On Thu, Feb 4, 2016 at 11:05 AM, Wei Chuang <weihaw@google.com> = wrote:
> PKIX = community,
>
> We've observed a limitation for specifying = internationalized email addresses
> as the local part which is restricted to = essentially ASCII.  That is subject
> or issuer email addresses which should be = stored as subject-alt-name or
> = issuer-alt-name rfc822Name and are encoded as IA5String.  This is = despite
> the = internationalization in email usage as specified by = internationalization
> of email = headers in RFC6532 allowing Unicode in To, From, etc fields = and
> becoming fairly = commonplace.  RFC5280 already specifies = internationalization
> of the = domain but lacks any specification for the = local-part.

 

Up until now, I have tried to lay low on this topic. = However, having reviewed the relevant standards and implementations in = the field, I have my 22=A2:

 

The proposed methods are to create an otherName form = and assign a new object identifier for it (A. Melnikov, ed., = draft-ietf-pkix-eai-addresses-00), and to encode the local part in = base64 with “:” as an escape signal (L. Baudoin, et. al., = draft-lbaudoin-iemax-02). There is also a counterproposal on the agenda, = which I will label as #3, to make rfc822Name a CHOICE {IA5String, UTF8String}. = There are two other methods that deserve serious consideration. My = 0.2=A2 is on #4 and my 21.8=A2 is on #5:

 

#4 Extend GeneralName with a new = name type:

 

GeneralName ::=3D CHOICE = {

  otherName [0] = INSTANCE OF OTHER-NAME,

  rfc822Name [1] = IA5String,

  dNSName [2] = IA5String,

  x400Address [3] = ORAddress,

  directoryName [4] = Name,

  ediPartyName [5] = EDIPartyName,

  = uniformResourceIdentifier [6] = IA5String,

  iPAddress [7] OCTET = STRING,

  registeredID [8] = OBJECT IDENTIFIER,

  eaiName [9] = UTF8String

  ... = }

 

The advantage of this approach is that it conforms to = X.509:2012, which uses … syntax to show that the CHOICE is = extensible. However, the IETF invented GeneralName (RFC 2459), and the = latest ASN.1 (RFC 5912) does not use … syntax for extensibility. = (Basically I think most implementations would barf on this CHOICE, and = would cause the overall ASN.1 decoding op to fail, meaning all places = where GeneralName is directly encoded, would cause implementations to = barf.)

 

#5 Change GeneralName so that = rfc822Name is actually just UTF8String:

 

=A0=A0 GeneralName ::=3D CHOICE =
{
=A0=A0=A0=A0=A0=A0=A0 =
otherName=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [0]=A0 =
INSTANCE OF OTHER-NAME,
=A0=A0=A0=A0=A0=A0=A0 =
rfc822Name=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [1]=A0 =
UTF8String,
=A0=A0=A0=A0=A0=A0=A0 =
dNSName=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
[2]=A0 IA5String,
=A0=A0=A0=A0=A0=A0=A0 =
x400Address=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [3]=A0 =
ORAddress,
=A0=A0=A0=A0=A0=A0=A0 =
directoryName=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [4]=A0 =
Name,
=A0=A0=A0=A0=A0=A0=A0 =
ediPartyName=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [5]=A0 =
EDIPartyName,
=A0=A0=A0=A0=A0=A0=A0 =
uniformResourceIdentifier=A0=A0 [6]=A0 IA5String,
=A0=A0=A0=A0=A0=A0=A0 =
iPAddress=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [7]=A0 =
OCTET STRING,
=A0=A0=A0=A0=A0=A0=A0 =
registeredID=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [8]=A0 OBJECT =
IDENTIFIER
=A0=A0 }

 

GeneralName is in the IMPLICIT TAGS part of PKIX. That = means that on the wire, a GeneralName will (almost always) just be = serialized as the

application tag in the choice, followed by the length = and the data. The counterproposal of a CHOICE {IA5String, = UTF8String} is flawed in that it will force ALL rfc822Names = to include an additional tag UNIVERSAL 22 in the case of IA5String, = because the choice is ambiguous without the tag (so a proper ASN.1 = compiler will force the serialization and de-serialization of the tag). = Note: UTF8String (in a CHOICE) would force serialization of the tag = UNIVERSAL 12.

 

With this proposal #5, UTF8String is just a superset = of IA5String. Therefore, new implementations will “just = work” with virtually no further coding. The high-octet data in = UTF8String will violate expectations for older implementations that are = looking for IA5String. But enforcement of octets 00-7F is almost never = done in the decoding step, or if it is done, it does not cause the = entire ASN.1 decoding op to fail. (Note: this would be an “ASN.1 = value constraint violation.”) If most implementations will = continue to decode the ASN.1 and simply skip over what it perceives to = be “invalid ASCII” (or simply rejects that particular = alternative when doing name comparisons), we are good to go. This = basically mirrors the way that EAI itself works in RFCs = 6530-6532.

 

To test this, one would want to construct a signed = certificate with “invalid” IA5String data that actually = contains valid Unicode octets, and see what happens with various = implementations.

 

I = am not saying that this is the “right” approach, but I do = think that it deserves serious consideration when evaluating = alternatives. An example of an advantage is that it should preserve name = constraints with no additional coding.

 

Regards,

 

Sean

_______________________________________________
smim= e mailing list
smime@ietf.org
https://www.ietf.org= /mailman/listinfo/smime

 

------=_NextPart_000_0282_01D18F47.B81AF740-- From nobody Tue Apr 5 15:00:51 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F1412D1F0 for ; Tue, 5 Apr 2016 15:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 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, OBFUSCATING_COMMENT=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 QROB-KgEncn2 for ; Tue, 5 Apr 2016 15:00:47 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::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 131A312D0CC for ; Tue, 5 Apr 2016 15:00:43 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id e185so35718755vkb.1 for ; Tue, 05 Apr 2016 15:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=1rZNpOZiN2+PTNRRxkDyDxi5mN1v9s0ROjMLbm/IbIo=; b=LV3+9ScxcygG0h89FAiWVaEygyzfwLE5vS47p3SZpKR67rHRbALW/6BUf6rGMnRRCs g1H6dEoabYoNA3jRfvfGtRz5K16ek2RTGVb4HIq6XCYjjt4ixx2dr7fvJKiYBAdYQz8w sskuH/Tnoq+0LBVj2u7W12J+azC6IBg1yTqZQgzpR5QEb+MfJjdyaBjOyJq5SWospbjU gybqArIw/mkiGtfT5w3gj9IhyyuObSedyPd5Y8oM4ZRrIlAUwfei2y4sExMbDb4R4FUo ATbIAwatZ5BemWN0Hqfg+tUOuZX1+bxYSX2Q5Ca9LO1Xoza/db2VQONJuixWd1FxIrRH c8eA== 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:date :message-id:subject:from:to:cc; bh=1rZNpOZiN2+PTNRRxkDyDxi5mN1v9s0ROjMLbm/IbIo=; b=KsQ6zS5feTKqYib/WOUWohj2AsJzB10fZ6/09HF2kehY56L/9rq8QoxBdDRX/9T1Fe jkch8Wdw+PlxWqMdXS4l5jnTFT+AgC7YnIXh1MOBsjra8VKFu4dZwPaBXGnGEoDlmyMW od6IvoFLj4wAJAlBgI1b1MZ5NfhQm4DkZlKq3ZgGmlJdKoKL4V4+MjvjityF1F8mlQNX VGBnMcbtYaIbVKX0QzqKI9QXCn/ctK96aLJJhwQnu3JnrGuZwVtD+QxHTdBXc0BJIvaI yN/7NIai8aJNI/rJiqsNqjquOpynrT5ex17Zowsl1hImkSouXlt+wSEBmsw0awwSTTZQ kiuQ== X-Gm-Message-State: AD7BkJJFhUikQOg8NTF6ip8y2A9TcmCtDldPdteGRaU69xd57qWG4XKEaUojx2Niw4XtDb7XPw7bXNG5gONwhf6m MIME-Version: 1.0 X-Received: by 10.176.1.105 with SMTP id 96mr6214411uak.54.1459886756158; Tue, 05 Apr 2016 13:05:56 -0700 (PDT) Received: by 10.176.3.211 with HTTP; Tue, 5 Apr 2016 13:05:56 -0700 (PDT) In-Reply-To: <028101d18f60$dd6262e0$982728a0$@augustcellars.com> References: <028101d18f60$dd6262e0$982728a0$@augustcellars.com> Date: Tue, 5 Apr 2016 13:05:56 -0700 Message-ID: From: Wei Chuang To: Jim Schaad Content-Type: multipart/alternative; boundary=001a1142fcb483bee5052fc25f33 Archived-At: Cc: IETF PKIX , Sean Leonard , IETF SMIME Subject: Re: [smime] [pkix] Support for email address internationalization in RFC5280 certificates X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 22:00:49 -0000 --001a1142fcb483bee5052fc25f33 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Tue, Apr 5, 2016 at 10:30 AM, Jim Schaad wrote: > It would also be a good way to have all existing implementations crash as > they see an option in the choice they do not support. > > > > I agree with the use of the OtherName extension. > FWIW I pinged someone in OpenSSL about extending OtherName for international email address, and the reply was that it won't be an issue to support this modulo their long release cycle (about one a year), and current OpenSSL won't of course recognize the extension but won't break either. Depending on the situation it may be possible to get a change faster too, and of course supplying a patch could help. -Wei > > > Jim > > > > > > *From:* pkix [mailto:pkix-bounces@ietf.org] *On Behalf Of *Russ Housley > *Sent:* Tuesday, April 05, 2016 9:18 AM > *To:* Sean Leonard > *Cc:* IETF PKIX ; IETF SMIME > *Subject:* Re: [pkix] [smime] Support for email address > internationalization in RFC5280 certificates > > > > I am opposed to extending GeneralName with a new item in the CHOICE > because the syntax in RFC5280. That syntax is aligned with X.509. We > would need to work with ITU-T to make an addition to the CHOICE, otherwise > the ITU-T could make a change to their specification in the future that > causes interoperability problems. > > > > I am strongly opposed to changing the type of rfc822name. As above, this > syntax belongs to X.509. In addition, this change would cause decode > errors for existing software, and we have seen decode errors lead to very > surprising user experiences. > > > > I believe that using the otherName extension mechanism does not have any > of the problems with these two proposals. > > > > Russ > > > > > > On Apr 4, 2016, at 6:20 PM, Sean Leonard wrote: > > > > > > On Feb 7, 2016, at 12:15 PM, Wei Chuang wrote: > > > > > > > > On Fri, Feb 5, 2016 at 4:46 PM, Peter Bowen wrote: > > On Thu, Feb 4, 2016 at 11:05 AM, Wei Chuang wrote: > > PKIX community, > > > > We've observed a limitation for specifying internationalized email > addresses > > as the local part which is restricted to essentially ASCII. That is > subject > > or issuer email addresses which should be stored as subject-alt-name or > > issuer-alt-name rfc822Name and are encoded as IA5String. This is despite > > the internationalization in email usage as specified by > internationalization > > of email headers in RFC6532 allowing Unicode in To, From, etc fields and > > becoming fairly commonplace. RFC5280 already specifies > internationalization > > of the domain but lacks any specification for the local-part. > > > > Up until now, I have tried to lay low on this topic. However, having > reviewed the relevant standards and implementations in the field, I have my > 22¢: > > > > The proposed methods are to create an otherName form and assign a new > object identifier for it (A. Melnikov, ed., draft-ietf-pkix-eai-addresses-00), > and to encode the local part in base64 with “:” as an escape signal (L. > Baudoin, et. al., draft-lbaudoin-iemax-02). There is also a counterproposal > on the agenda, which I will label as #3, to make rfc822Name a CHOICE > {IA5String, UTF8String}. There are two other methods that deserve serious > consideration. My 0.2¢ is on #4 and my 21.8¢ is on #5: > > > > *#4* Extend GeneralName with a new name type: > > > > GeneralName ::= CHOICE { > > otherName [0] INSTANCE OF OTHER-NAME, > > rfc822Name [1] IA5String, > > dNSName [2] IA5String, > > x400Address [3] ORAddress, > > directoryName [4] Name, > > ediPartyName [5] EDIPartyName, > > uniformResourceIdentifier [6] IA5String, > > iPAddress [7] OCTET STRING, > > registeredID [8] OBJECT IDENTIFIER, > > *eaiName [9] UTF8String* > > ... } > > > > The advantage of this approach is that it conforms to X.509:2012, which > uses … syntax to show that the CHOICE is extensible. However, the IETF > invented GeneralName (RFC 2459), and the latest ASN.1 (RFC 5912) does not > use … syntax for extensibility. (Basically I think most implementations > would barf on this CHOICE, and would cause the overall ASN.1 decoding op to > fail, meaning all places where GeneralName is directly encoded, would cause > implementations to barf.) > > > > *#5* Change GeneralName so that rfc822Name is actually just UTF8String: > > > > GeneralName ::= CHOICE { > > otherName [0] INSTANCE OF OTHER-NAME, > > rfc822Name [1] *UTF8String*, > > dNSName [2] IA5String, > > x400Address [3] ORAddress, > > directoryName [4] Name, > > ediPartyName [5] EDIPartyName, > > uniformResourceIdentifier [6] IA5String, > > iPAddress [7] OCTET STRING, > > registeredID [8] OBJECT IDENTIFIER > > } > > > > GeneralName is in the IMPLICIT TAGS part of PKIX. That means that on the > wire, a GeneralName will (almost always) just be serialized as the > > application tag in the choice, followed by the length and the data. The > counterproposal of a CHOICE {IA5String, UTF8String} is flawed in that it > will force ALL rfc822Names to include an additional tag UNIVERSAL 22 in the > case of IA5String, because the choice is ambiguous without the tag (so a > proper ASN.1 compiler will force the serialization and de-serialization of > the tag). Note: UTF8String (in a CHOICE) would force serialization of the > tag UNIVERSAL 12. > > > > With this proposal #5, UTF8String is just a superset of IA5String. > Therefore, new implementations will “just work” with virtually no further > coding. The high-octet data in UTF8String will violate expectations for > older implementations that are looking for IA5String. But enforcement of > octets 00-7F is almost never done in the decoding step, or if it is done, > it does not cause the entire ASN.1 decoding op to fail. (Note: this would > be an “ASN.1 value constraint violation.”) If most implementations will > continue to decode the ASN.1 and simply skip over what it perceives to be > “invalid ASCII” (or simply rejects that particular alternative when doing > name comparisons), we are good to go. This basically mirrors the way that > EAI itself works in RFCs 6530-6532. > > > > To test this, one would want to construct a signed certificate with > “invalid” IA5String data that actually contains valid Unicode octets, and > see what happens with various implementations. > > > > I am not saying that this is the “right” approach, but I do think that it > deserves serious consideration when evaluating alternatives. An example of > an advantage is that it should preserve name constraints with no additional > coding. > > > > Regards, > > > > Sean > > _______________________________________________ > smime mailing list > smime@ietf.org > https://www.ietf.org/mailman/listinfo/smime > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > --001a1142fcb483bee5052fc25f33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On Tue, Apr 5, 2016 at 10:30 AM, Jim Schaad <ietf@augustcellars.com> wrote:

It would also be a good way to have all existing implementations crash as they see an option in the choice they do not support.

 

I agree with the use of the OtherName extension.


FWIW I pinged someone in OpenSSL about extending OtherName for international email address, and the reply was that it won't be an issue to support this modulo their long release cycle (about one a year), and current OpenSSL won't of course recognize the extension but won't break either.  Depending on the situation it may be possible to get a change faster too, and of course supplying a patch could help.

-Wei

 

 

Jim

 

 

From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Tuesday, April 05, 2016 9:18 AM
To: Sean Leonard <dev+ietf@seantek.com>
Cc: IETF PKIX <pkix@ietf.org>; IETF SMIME <smime@ietf.org>
Subject: Re: [pkix] [smime] Support for email address internationalization in RFC5280 certificates

 

I am opposed to extending GeneralName with a new item in the CHOICE because the syntax in RFC5280.  That syntax is aligned with X.509.  We would need to work with ITU-T to make an addition to the CHOICE, otherwise the ITU-T could make a change to their specification in the future that causes interoperability problems.

 

I am strongly opposed to changing the type of rfc822name.  As above, this syntax belongs to X.509.  In addition, this change would cause decode errors for existing software, and we have seen decode errors lead to very surprising user experiences.

 

I believe that using the otherName extension mechanism does not have any of the problems with these two proposals.

 

Russ

 

 

On Apr 4, 2016, at 6:20 PM, Sean Leonard <dev+ietf@seantek.com> wrote:



 

On Feb 7, 2016, at 12:15 PM, Wei Chuang <weihaw@google.com> wrote:

 

 

 

On Fri, Feb 5, 2016 at 4:46 PM, Peter Bowen <pzbowen@gmail.com> wrote:

On Thu, Feb 4, 2016 at 11:05 AM, Wei Chuang <weihaw@google.com> wrote:
> PKIX community,
>
> We've observed a limitation for specifying internationalized email addresses
> as the local part which is restricted to essentially ASCII.  That is subject
> or issuer email addresses which should be stored as subject-alt-name or
> issuer-alt-name rfc822Name and are encoded as IA5String.  This is despite
> the internationalization in email usage as specified by internationalization
> of email headers in RFC6532 allowing Unicode in To, From, etc fields and
> becoming fairly commonplace.  RFC5280 already specifies internationalization
> of the domain but lacks any specification for the local-part.

 

Up until now, I have tried to lay low on this topic. However, having reviewed the relevant standards and implementations in the field, I have my 22¢:

 

The proposed methods are to create an otherName form and assign a new object identifier for it (A. Melnikov, ed., draft-ietf-pkix-eai-addresses-00), and to encode the local part in base64 with “:” as an escape signal (L. Baudoin, et. al., draft-lbaudoin-iemax-02). There is also a counterproposal on the agenda, which I will label as #3, to make rfc822Name a CHOICE {IA5String, UTF8String}. There are two other methods that deserve serious consideration. My 0.2¢ is on #4 and my 21.8¢ is on #5:

 

#4 Extend GeneralName with a new name type:

 

GeneralName ::= CHOICE {

  otherName [0] INSTANCE OF OTHER-NAME,

  rfc822Name [1] IA5String,

  dNSName [2] IA5String,

  x400Address [3] ORAddress,

  directoryName [4] Name,

  ediPartyName [5] EDIPartyName,

  uniformResourceIdentifier [6] IA5String,

  iPAddress [7] OCTET STRING,

  registeredID [8] OBJECT IDENTIFIER,

  eaiName [9] UTF8String

  ... }

 

The advantage of this approach is that it conforms to X.509:2012, which uses … syntax to show that the CHOICE is extensible. However, the IETF invented GeneralName (RFC 2459), and the latest ASN.1 (RFC 5912) does not use … syntax for extensibility. (Basically I think most implementations would barf on this CHOICE, and would cause the overall ASN.1 decoding op to fail, meaning all places where GeneralName is directly encoded, would cause implementations to barf.)

 

#5 Change GeneralName so that rfc822Name is actually just UTF8String:

 

   GeneralName ::= CHOICE {
        otherName                   [0]  INSTANCE OF OTHER-NAME,
        rfc822Name                  [1]  UTF8String,
        dNSName                     [2]  IA5String,
        x400Address                 [3]  ORAddress,
        directoryName               [4]  Name,
        ediPartyName                [5]  EDIPartyName,
        uniformResourceIdentifier   [6]  IA5String,
        iPAddress                   [7]  OCTET STRING,
        registeredID                [8]  OBJECT IDENTIFIER
   }

 

GeneralName is in the IMPLICIT TAGS part of PKIX. That means that on the wire, a GeneralName will (almost always) just be serialized as the

application tag in the choice, followed by the length and the data. The counterproposal of a CHOICE {IA5String, UTF8String} is flawed in that it will force ALL rfc822Names to include an additional tag UNIVERSAL 22 in the case of IA5String, because the choice is ambiguous without the tag (so a proper ASN.1 compiler will force the serialization and de-serialization of the tag). Note: UTF8String (in a CHOICE) would force serialization of the tag UNIVERSAL 12.

 

With this proposal #5, UTF8String is just a superset of IA5String. Therefore, new implementations will “just work” with virtually no further coding. The high-octet data in UTF8String will violate expectations for older implementations that are looking for IA5String. But enforcement of octets 00-7F is almost never done in the decoding step, or if it is done, it does not cause the entire ASN.1 decoding op to fail. (Note: this would be an “ASN.1 value constraint violation.”) If most implementations will continue to decode the ASN.1 and simply skip over what it perceives to be “invalid ASCII” (or simply rejects that particular alternative when doing name comparisons), we are good to go. This basically mirrors the way that EAI itself works in RFCs 6530-6532.

 

To test this, one would want to construct a signed certificate with “invalid” IA5String data that actually contains valid Unicode octets, and see what happens with various implementations.

 

I am not saying that this is the “right” approach, but I do think that it deserves serious consideration when evaluating alternatives. An example of an advantage is that it should preserve name constraints with no additional coding.

 

Regards,

 

Sean

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

 


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


--001a1142fcb483bee5052fc25f33-- From nobody Tue Apr 5 16:54:14 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6142712D1E9; Tue, 5 Apr 2016 16:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.62 X-Spam-Level: X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_NAME_DR=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=no 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 7GF-2lwRZxHR; Tue, 5 Apr 2016 16:54:07 -0700 (PDT) Received: from claranet-outbound-smtp05.uk.clara.net (claranet-outbound-smtp05.uk.clara.net [195.8.89.38]) by ietfa.amsl.com (Postfix) with ESMTP id 9518812D121; Tue, 5 Apr 2016 16:54:06 -0700 (PDT) Received: from 92.40.248.79.threembb.co.uk ([92.40.248.79]:19134 helo=[192.168.43.31]) by relay05.mail.eu.clara.net (relay.clara.net [81.171.239.35]:10465) with esmtpa (authdaemon_plain:drh) id 1ananM-000683-Hd (return-path ); Tue, 05 Apr 2016 23:54:05 +0000 To: George Michaelson , IETF PKIX References: <028101d18f60$dd6262e0$982728a0$@augustcellars.com> From: Dr Stephen Henson Message-ID: <57045015.9010103@drh-consultancy.co.uk> Date: Wed, 6 Apr 2016 00:53:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF SMIME Subject: Re: [smime] [pkix] Support for email address internationalization in RFC5280 certificates X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 23:54:10 -0000 On 05/04/2016 22:02, George Michaelson wrote: > IIRC OpenSSL choses the most compact syntactically acceptable ASN.1 > alphabet to represent strings. So, if your labels fit in IA5String, > thats what it is. But if tomorrow you re-issue and they no longer fit, > then it promotes to the next minimally correct ASN.1 alphabet. > It can do that if it is configured to do so and the API is used with appropriate flags. However that is not mandatory behaviour and if you don't want that you don't have to use it. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From nobody Wed Apr 6 08:11:51 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1F412DA19 for ; Tue, 5 Apr 2016 14:03: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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=algebras-org.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 mM2Eiaif6sfT for ; Tue, 5 Apr 2016 14:03:29 -0700 (PDT) Received: from mail-oi0-x242.google.com (mail-oi0-x242.google.com [IPv6:2607:f8b0:4003:c06::242]) (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 7A13B12DA13 for ; Tue, 5 Apr 2016 14:03:14 -0700 (PDT) Received: by mail-oi0-x242.google.com with SMTP id v126so3996038oia.3 for ; Tue, 05 Apr 2016 14:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=pg930UewqaR1QYhvRl/cYjc0hrvLqy/pA3E9Qz1+sAE=; b=K7h9QOjt2yH55Gpe+Z6UEl3xxstutSltcsy/+JPzpAG1Jy1CouqDcqOpSrv/kGCnNI 3yPOD5Go9yNzNvPIxwV2TsJTcShaZXSLp1wsg3FMfpXpYdN3ZLOIQQ0yCLw5hP1VGPwU BVH61t3Y6CJps1tn/eiSJ0wtvihYg0yDzH7/n7H0ZpHA2ad6qpnSOXC3SjhWmWw6lEXV xAdflHDzo+Tl4ARP5Ajdj5xsY0/BwEp+Gae5xqvEyld/ut2Bt6Dcsqfpwd+JAsxiUlTp M3Lf+q+fGLrNDWdS7bm99avpqxVtMLjxy6FC1jo93UKEkuVR8176ol7XV28APqCAbn8X UEdg== 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:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=pg930UewqaR1QYhvRl/cYjc0hrvLqy/pA3E9Qz1+sAE=; b=In4yZWW6SlxfJEItEekC71P3sntHOCl6W0xUhM+mErjf1Q1BRk+ea2/Mk8tQd0t4jv tV9P0lkF/758NRnL3qHpVWcB9DF4b59r8nQYu0pBJLy5NAyZjJceODo0JQnuSKzPtbMT jn6qBUyGtGs/yXnr0FVCUUXjsoZP3XAoEXR7WtHiUkq+mt08MA19RKc/ZXtblVvvZ/Mi Jk3oSKhnknFyFK5uUSr1g/yFa3D3lIejfBSWMspMBDOgre82zdqfc2Gn1u8tmCp9F1Ve 9c3I6eg5OsIMgPeXcfLgmMTED0ykORcT2Ekp7ybVWNyNheIhV69RpBmsmgI21/xhxbmb jZIg== X-Gm-Message-State: AD7BkJJ3UyyvRNGDeUiFmnmGTqrUh+WnYKz8SE0eDqXTjpOtm1GqguoOrztGYoaIabaL+jL2nbYLcSBwJbMo+g== MIME-Version: 1.0 X-Received: by 10.157.36.132 with SMTP id z4mr6429838ota.105.1459890160027; Tue, 05 Apr 2016 14:02:40 -0700 (PDT) Received: by 10.182.187.97 with HTTP; Tue, 5 Apr 2016 14:02:39 -0700 (PDT) X-Originating-IP: [2001:67c:370:176:6ce6:1c9:2ded:23e] In-Reply-To: References: <028101d18f60$dd6262e0$982728a0$@augustcellars.com> Date: Tue, 5 Apr 2016 18:02:39 -0300 Message-ID: From: George Michaelson To: IETF PKIX Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Wed, 06 Apr 2016 08:11:47 -0700 Cc: IETF SMIME Subject: Re: [smime] [pkix] Support for email address internationalization in RFC5280 certificates X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 21:03:32 -0000 IIRC OpenSSL choses the most compact syntactically acceptable ASN.1 alphabet to represent strings. So, if your labels fit in IA5String, thats what it is. But if tomorrow you re-issue and they no longer fit, then it promotes to the next minimally correct ASN.1 alphabet. For compact encoding stuff, this probably makes sense. for POLA its pretty awful. We got hit by this in RPKI implementation with non-conforming names and other things, because the OpenSSL library detected we were writing hex chars, and down-graded to IA5 when we didn't expect it. So, if the intent is to have the stringfield encompass UTF-8 bear in mind, it often won't be marked as UTF8 on the wire, if you don't force it to be. -G On Tue, Apr 5, 2016 at 5:05 PM, Wei Chuang wrote: > > > On Tue, Apr 5, 2016 at 10:30 AM, Jim Schaad wrot= e: >> >> It would also be a good way to have all existing implementations crash a= s >> they see an option in the choice they do not support. >> >> >> >> I agree with the use of the OtherName extension. > > > FWIW I pinged someone in OpenSSL about extending OtherName for internatio= nal > email address, and the reply was that it won't be an issue to support thi= s > modulo their long release cycle (about one a year), and current OpenSSL > won't of course recognize the extension but won't break either. Dependin= g > on the situation it may be possible to get a change faster too, and of > course supplying a patch could help. > > -Wei > > >> >> >> >> Jim >> >> >> >> >> >> From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Russ Housley >> Sent: Tuesday, April 05, 2016 9:18 AM >> To: Sean Leonard >> Cc: IETF PKIX ; IETF SMIME >> Subject: Re: [pkix] [smime] Support for email address internationalizati= on >> in RFC5280 certificates >> >> >> >> I am opposed to extending GeneralName with a new item in the CHOICE >> because the syntax in RFC5280. That syntax is aligned with X.509. We w= ould >> need to work with ITU-T to make an addition to the CHOICE, otherwise the >> ITU-T could make a change to their specification in the future that caus= es >> interoperability problems. >> >> >> >> I am strongly opposed to changing the type of rfc822name. As above, thi= s >> syntax belongs to X.509. In addition, this change would cause decode er= rors >> for existing software, and we have seen decode errors lead to very >> surprising user experiences. >> >> >> >> I believe that using the otherName extension mechanism does not have any >> of the problems with these two proposals. >> >> >> >> Russ >> >> >> >> >> >> On Apr 4, 2016, at 6:20 PM, Sean Leonard wrote: >> >> >> >> >> >> On Feb 7, 2016, at 12:15 PM, Wei Chuang wrote: >> >> >> >> >> >> >> >> On Fri, Feb 5, 2016 at 4:46 PM, Peter Bowen wrote: >> >> On Thu, Feb 4, 2016 at 11:05 AM, Wei Chuang wrote: >> > PKIX community, >> > >> > We've observed a limitation for specifying internationalized email >> > addresses >> > as the local part which is restricted to essentially ASCII. That is >> > subject >> > or issuer email addresses which should be stored as subject-alt-name o= r >> > issuer-alt-name rfc822Name and are encoded as IA5String. This is >> > despite >> > the internationalization in email usage as specified by >> > internationalization >> > of email headers in RFC6532 allowing Unicode in To, From, etc fields a= nd >> > becoming fairly commonplace. RFC5280 already specifies >> > internationalization >> > of the domain but lacks any specification for the local-part. >> >> >> >> Up until now, I have tried to lay low on this topic. However, having >> reviewed the relevant standards and implementations in the field, I have= my >> 22=C2=A2: >> >> >> >> The proposed methods are to create an otherName form and assign a new >> object identifier for it (A. Melnikov, ed., >> draft-ietf-pkix-eai-addresses-00), and to encode the local part in base6= 4 >> with =E2=80=9C:=E2=80=9D as an escape signal (L. Baudoin, et. al., draft= -lbaudoin-iemax-02). >> There is also a counterproposal on the agenda, which I will label as #3,= to >> make rfc822Name a CHOICE {IA5String, UTF8String}. There are two other >> methods that deserve serious consideration. My 0.2=C2=A2 is on #4 and my= 21.8=C2=A2 is >> on #5: >> >> >> >> #4 Extend GeneralName with a new name type: >> >> >> >> GeneralName ::=3D CHOICE { >> >> otherName [0] INSTANCE OF OTHER-NAME, >> >> rfc822Name [1] IA5String, >> >> dNSName [2] IA5String, >> >> x400Address [3] ORAddress, >> >> directoryName [4] Name, >> >> ediPartyName [5] EDIPartyName, >> >> uniformResourceIdentifier [6] IA5String, >> >> iPAddress [7] OCTET STRING, >> >> registeredID [8] OBJECT IDENTIFIER, >> >> eaiName [9] UTF8String >> >> ... } >> >> >> >> The advantage of this approach is that it conforms to X.509:2012, which >> uses =E2=80=A6 syntax to show that the CHOICE is extensible. However, th= e IETF >> invented GeneralName (RFC 2459), and the latest ASN.1 (RFC 5912) does no= t >> use =E2=80=A6 syntax for extensibility. (Basically I think most implemen= tations >> would barf on this CHOICE, and would cause the overall ASN.1 decoding op= to >> fail, meaning all places where GeneralName is directly encoded, would ca= use >> implementations to barf.) >> >> >> >> #5 Change GeneralName so that rfc822Name is actually just UTF8String: >> >> >> >> GeneralName ::=3D CHOICE { >> >> otherName [0] INSTANCE OF OTHER-NAME, >> >> rfc822Name [1] UTF8String, >> >> dNSName [2] IA5String, >> >> x400Address [3] ORAddress, >> >> directoryName [4] Name, >> >> ediPartyName [5] EDIPartyName, >> >> uniformResourceIdentifier [6] IA5String, >> >> iPAddress [7] OCTET STRING, >> >> registeredID [8] OBJECT IDENTIFIER >> >> } >> >> >> >> GeneralName is in the IMPLICIT TAGS part of PKIX. That means that on the >> wire, a GeneralName will (almost always) just be serialized as the >> >> application tag in the choice, followed by the length and the data. The >> counterproposal of a CHOICE {IA5String, UTF8String} is flawed in that it >> will force ALL rfc822Names to include an additional tag UNIVERSAL 22 in = the >> case of IA5String, because the choice is ambiguous without the tag (so a >> proper ASN.1 compiler will force the serialization and de-serialization = of >> the tag). Note: UTF8String (in a CHOICE) would force serialization of th= e >> tag UNIVERSAL 12. >> >> >> >> With this proposal #5, UTF8String is just a superset of IA5String. >> Therefore, new implementations will =E2=80=9Cjust work=E2=80=9D with vir= tually no further >> coding. The high-octet data in UTF8String will violate expectations for >> older implementations that are looking for IA5String. But enforcement of >> octets 00-7F is almost never done in the decoding step, or if it is done= , it >> does not cause the entire ASN.1 decoding op to fail. (Note: this would b= e an >> =E2=80=9CASN.1 value constraint violation.=E2=80=9D) If most implementat= ions will continue >> to decode the ASN.1 and simply skip over what it perceives to be =E2=80= =9Cinvalid >> ASCII=E2=80=9D (or simply rejects that particular alternative when doing= name >> comparisons), we are good to go. This basically mirrors the way that EAI >> itself works in RFCs 6530-6532. >> >> >> >> To test this, one would want to construct a signed certificate with >> =E2=80=9Cinvalid=E2=80=9D IA5String data that actually contains valid Un= icode octets, and >> see what happens with various implementations. >> >> >> >> I am not saying that this is the =E2=80=9Cright=E2=80=9D approach, but I= do think that it >> deserves serious consideration when evaluating alternatives. An example = of >> an advantage is that it should preserve name constraints with no additio= nal >> coding. >> >> >> >> Regards, >> >> >> >> Sean >> >> _______________________________________________ >> smime mailing list >> smime@ietf.org >> https://www.ietf.org/mailman/listinfo/smime >> >> >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From nobody Wed Apr 6 08:11:53 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A159B12D0F8 for ; Wed, 6 Apr 2016 02:32:43 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=algebras-org.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 Nfi_bDOdiimW for ; Wed, 6 Apr 2016 02:32:40 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 D3C7F12D0BC for ; Wed, 6 Apr 2016 02:32:39 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id y204so50756542oie.3 for ; Wed, 06 Apr 2016 02:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=PdyXdaAmDiTMApxQ8e/EmRU1oI9MIkSN+1PL1MX+p9c=; b=uaPbUXwNrlBy0YX3RZdBEFOqfqMj3cOmTW08G46Sn5lTL3p65oHZ4tYuUl8rN15MUz vRVZqbcGljhD1qyaJKf2TkOu2+Z05LIht92Ym0Q7ivvvI2aprINfhgjQgVsi4BxFL4OS KfOxYoLDoSvalEOhwtwcxpJ0bunUHTbYU/SCMUu5TyMDguDi8a1Ar3Qy1DwC+Ns1G7/B akIDCrLmboIsO7X/RRiy7ZXBTGjVCrX7DbZW20T8c7GEHhq07F65JtB92DWLv2dJgTXv O/sHVJxhev4+Iivv10Eggo7Dg4Gn4mYoOeyXnDSjFYKa/tP+wzPXS+IwY/Y/d616Z6nm tnLg== 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:date :message-id:subject:from:to:cc; bh=PdyXdaAmDiTMApxQ8e/EmRU1oI9MIkSN+1PL1MX+p9c=; b=K93bz+FvKKdq6s77iIvs+ysBc9FFvofenyVlxT20TWAhKM/f//i7xyipmT9ckiojsN /ub228bXTI/cF3ZWWDF0MyA5g4k3Tg0PvpqR81mXLDyPXqEhWT1CmxoBgRwo8cK5D0ZA 8Uofuz7HRcFcO4yVkNaT65BsXK+DkPXQAQEz9EAEH/EGaScimCpF79joayKQ0rc7zPFk 94yvGdrujcg0SYLA6BZN6kuppcmQ3omGa9SEH1TcHflynezeurbK4sXqjvmBG4BiJtAH v7foUSd7Ho47a05oAHkxBk+5nlzjiCTg3/5ojNCH2DOLdKlqVtbAeOFzFC17Mm1FxGcZ 07wg== X-Gm-Message-State: AD7BkJIJNnkebIFowkjK4lw3uwHyVhjdVIjqW75dmPJMKAYRUEG5kfEolt4iZylgATlFnd9b1ss8Duj3jWvFvg== MIME-Version: 1.0 X-Received: by 10.157.12.200 with SMTP id o8mr16963680otd.148.1459935158501; Wed, 06 Apr 2016 02:32:38 -0700 (PDT) Received: by 10.182.187.97 with HTTP; Wed, 6 Apr 2016 02:32:38 -0700 (PDT) X-Originating-IP: [190.104.245.184] In-Reply-To: <57045015.9010103@drh-consultancy.co.uk> References: <028101d18f60$dd6262e0$982728a0$@augustcellars.com> <57045015.9010103@drh-consultancy.co.uk> Date: Wed, 6 Apr 2016 06:32:38 -0300 Message-ID: From: George Michaelson To: Dr Stephen Henson Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Wed, 06 Apr 2016 08:11:47 -0700 Cc: IETF PKIX , IETF SMIME Subject: Re: [smime] [pkix] Support for email address internationalization in RFC5280 certificates X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 09:32:43 -0000 Oh, if its not the *default* thats much better. I had assumed from how the problem presented this was because of default settings, but if we shot ourselves in the foot by selecting this mode, then there isn't an issue. Thanks for the clarification Stephen. -George On Tue, Apr 5, 2016 at 8:53 PM, Dr Stephen Henson wrote: > On 05/04/2016 22:02, George Michaelson wrote: >> IIRC OpenSSL choses the most compact syntactically acceptable ASN.1 >> alphabet to represent strings. So, if your labels fit in IA5String, >> thats what it is. But if tomorrow you re-issue and they no longer fit, >> then it promotes to the next minimally correct ASN.1 alphabet. >> > > It can do that if it is configured to do so and the API is used with appropriate > flags. However that is not mandatory behaviour and if you don't want that you > don't have to use it. > > Steve. > -- > Dr Stephen N. Henson. > Core developer of the OpenSSL project: http://www.openssl.org/ > Freelance consultant see: http://www.drh-consultancy.co.uk/ > Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From nobody Wed Apr 6 10:41:26 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0BE12D623; Wed, 6 Apr 2016 10:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 7DnxIeoSPq1R; Wed, 6 Apr 2016 10:41:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197D912D71D; Wed, 6 Apr 2016 10:41:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C367DBE2D; Wed, 6 Apr 2016 18:41:04 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8Tl-gseeUmY; Wed, 6 Apr 2016 18:41:03 +0100 (IST) Received: from [31.133.178.21] (dhcp-b215.meeting.ietf.org [31.133.178.21]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D1B47BE3F; Wed, 6 Apr 2016 18:41:00 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1459964463; bh=GZKQlin4kx1Szg5b6OeTO2QJhjUJ/xWd8A9zP8j1Cao=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Wn7akztJrk3FTdAs3gfTeUvU2ymAk0qua24tC7E1jsLJkwlrPEj+AE7RbnXR1SeaH RN1mEkW17AiQzftWB0T5FZJPTihKJM236KJ9fLfbR4Bwj655H+8Ni9+wFGMZXhyziA E09M7ruYbP/wK6+rr6fUFnAd01EgtQ57a/xY3qm0= To: Wei Chuang , PKIX , IETF SMIME References: <56FD7597.4020601@cs.tcd.ie> <5702BEC9.7040403@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <57054A29.1050404@cs.tcd.ie> Date: Wed, 6 Apr 2016 18:40:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5702BEC9.7040403@cs.tcd.ie> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090207030500010005010504" Archived-At: Cc: John Levine Subject: [smime] Room change wasRe: [pkix] Identified Work Items and Discussion Summary (was: possible new pkix and/or smime work) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:41:23 -0000 This is a cryptographically signed message in MIME format. --------------ms090207030500010005010504 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, I got 10 folks saying they'll come which is the capacity of the room and since I should probably also be there we're changing the room to Atlantico A at the same time (1945 Thu). That holds about 40 which should be plenty so no more need to ping me and say you'll come, just turn up if in B-A and interested. Cheers, S On 04/04/16 20:21, Stephen Farrell wrote: >=20 > Hiya, >=20 > On 31/03/16 20:08, Stephen Farrell wrote: >> >> And separately, I'd like to try get interested folks who'll be >> at IETF95 together for a chat if we can. >=20 > If you're interested in this and at IETF95, I've booked a room > (Paraiso, 5th floor) for Thursday 1945 to chat about whether or > not we seem to have enough work and interest to charter a WG > for some of these. I think we should aim to be quick about that > so I've just booked 30 minutes. Chat can of course continue > after that at bits'n'bytes or elsewhere. >=20 > Please send me an offlist reply to this if you'd like to take > part, just for room-size. >=20 > Thanks, > S. >=20 >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix >=20 --------------ms090207030500010005010504 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA0MDYx NzQwNTdaMC8GCSqGSIb3DQEJBDEiBCBrtqdzcyrGHTilfO1NAB6JhVBjqYGHRaFyRTnbYE5C jjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQC1VZ7kw6oPyNU6GwhIZtf8Fk8VOONVGq7ka8VP5lKJaxNhi6kuq5nq JhZ9VMbMFTzXo6V6KZOnO4QHuXU3AR5ZA6CC6l5XiZyY37sJYCUgsxel8Anmp424xzBObHbj 44qCLBwoYNpIr1OwAMICqwKZ8KQZcHhpTDEgOKkfVYYe8cbP/WpJhGZCtMGK//Wi0nEb8eam QZVYz60stZlA6Z4IPNlVR1wIZ6n1gs2VKteFy6UCVxqjDjZSBMcJpA4viESo3qec9zxJvyxG GHJq1iJMFt6pqaXrvZyReBkoJT3mxV3hDQYlQ+p3R4bPayhPQVm4qQqYp72q5V2/Y0+kzpDM AAAAAAAA --------------ms090207030500010005010504-- From nobody Wed Apr 6 15:49:03 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D4812D587; Wed, 6 Apr 2016 15:49:02 -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 tMM_keGSAPDM; Wed, 6 Apr 2016 15:48:59 -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 72B6C12D134; Wed, 6 Apr 2016 15:48:59 -0700 (PDT) Received: from dhcp-aa67.meeting.ietf.org (unknown [31.133.170.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2D6EB509B8; Wed, 6 Apr 2016 18:48:56 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_287785AE-60CE-4385-A20B-13D10B28B9B6" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: Date: Wed, 6 Apr 2016 19:48:54 -0300 Message-Id: <3851E218-C5F4-4BB3-B9DB-B8679361A2B9@seantek.com> References: <028101d18f60$dd6262e0$982728a0$@augustcellars.com> To: IETF PKIX , IETF SMIME X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jim Schaad Subject: Re: [smime] [pkix] Support for email address internationalization in RFC5280 certificates X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 22:49:02 -0000 --Apple-Mail=_287785AE-60CE-4385-A20B-13D10B28B9B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 To be clear, the otherName form (draft-ietf-pkix-eai-addresses-00) is a = sensible path forward. That is how GeneralName was designed to be = extended all along. Russ corrected me offline and pointed out that GeneralName is = =E2=80=9Cowned=E2=80=9D (well, created originally anyway) by ITU-T = X.509. It is not an IETF-originated extension. Any EAI mechanism will have consider the impact of Name Constraints, the = functionality of which needs to be preserved. Additionally, the EAI document should say something about whether = A-labels (i.e., Punycode) or U-labels ought to be used on the domain = side. I believe that U-labels should be used on the domain side when in = the otherName UTF8String. There are three solid reasons: #1 Since it=E2=80=99s UTF8String, it=E2=80=99s simply =E2=80=9Cmore = correct=E2=80=9D to use U-labels instead of A-labels. The requirements = of RFC 5280 regarding IDN don=E2=80=99t really apply because those are = about stuffing U-labels into ASCII protocol slots (i.e., by making them = A-labels). #2 When displayed to a user, U-labels are going to make sense; A-labels = will not. (Note: there are homograph attacks. But that is not a problem = specific to this choice, and IDNA procedures are supposed to mitigate = that.) #3 U-labels are supposed to be compared =E2=80=9CAS-IS=E2=80=9D (RFC = 5891), but A-labels are case-insensitive. Since the local-part is = case-sensitive, this opens the possibility that e-mail address strings = in certificates can (under the proper circumstances) be compared using a = binary comparison operation (i.e., exact equality). Back to the alternatives: I am not withdrawing my suggestion but merely = proposing it as an alternative that should be empirically examined = before being dismissed, especially since CHOICE { IA5String, UTF8String = } is (or was?) on the table at the time. Best regards, Sean > On Apr 5, 2016, at 5:05 PM, Wei Chuang wrote: >=20 >=20 > On Tue, Apr 5, 2016 at 10:30 AM, Jim Schaad > wrote: >=20 >=20 > From: pkix [mailto:pkix-bounces@ietf.org = ] On Behalf Of Russ Housley > Sent: Tuesday, April 05, 2016 9:18 AM > Cc: IETF PKIX >; IETF SMIME = > > Subject: Re: [pkix] [smime] Support for email address = internationalization in RFC5280 certificates >=20 > =20 >=20 > On Apr 4, 2016, at 6:20 PM: >=20 >=20 >=20 >=20 > =20 >=20 > On Feb 7, 2016, at 12:15 PM, Wei Chuang > wrote: >=20 > =20 >=20 > On Fri, Feb 5, 2016 at 4:46 PM, Peter Bowen > wrote: >=20 > On Thu, Feb 4, 2016 at 11:05 AM, Wei Chuang > wrote: > > PKIX community, > > > > We've observed a limitation for specifying internationalized email = addresses > > as the local part which is restricted to essentially ASCII. That is = subject > > or issuer email addresses which should be stored as subject-alt-name = or > > issuer-alt-name rfc822Name and are encoded as IA5String. This is = despite > > the internationalization in email usage as specified by = internationalization > > of email headers in RFC6532 allowing Unicode in To, From, etc fields = and > > becoming fairly commonplace. RFC5280 already specifies = internationalization > > of the domain but lacks any specification for the local-part. >=20 > =20 >=20 > Up until now, I have tried to lay low on this topic. However, having = reviewed the relevant standards and implementations in the field, I have = my 22=C2=A2: >=20 > =20 >=20 > The proposed methods are to create an otherName form and assign a new = object identifier for it (A. Melnikov, ed., = draft-ietf-pkix-eai-addresses-00), and to encode the local part in = base64 with =E2=80=9C:=E2=80=9D as an escape signal (L. Baudoin, et. = al., draft-lbaudoin-iemax-02). There is also a counterproposal on the = agenda, which I will label as #3, to make rfc822Name a CHOICE = {IA5String, UTF8String}. There are two other methods that deserve = serious consideration. My 0.2=C2=A2 is on #4 and my 21.8=C2=A2 is on #5: >=20 > =20 >=20 > #4 Extend GeneralName with a new name type: >=20 > =20 >=20 > GeneralName ::=3D CHOICE { >=20 > otherName [0] INSTANCE OF OTHER-NAME, >=20 > rfc822Name [1] IA5String, >=20 > dNSName [2] IA5String, >=20 > x400Address [3] ORAddress, >=20 > directoryName [4] Name, >=20 > ediPartyName [5] EDIPartyName, >=20 > uniformResourceIdentifier [6] IA5String, >=20 > iPAddress [7] OCTET STRING, >=20 > registeredID [8] OBJECT IDENTIFIER, >=20 > eaiName [9] UTF8String >=20 > ... } >=20 > =20 >=20 > The advantage of this approach is that it conforms to X.509:2012, = which uses =E2=80=A6 syntax to show that the CHOICE is extensible. = However, the IETF invented GeneralName (RFC 2459), and the latest ASN.1 = (RFC 5912) does not use =E2=80=A6 syntax for extensibility. (Basically I = think most implementations would barf on this CHOICE, and would cause = the overall ASN.1 decoding op to fail, meaning all places where = GeneralName is directly encoded, would cause implementations to barf.) >=20 > =20 >=20 > #5 Change GeneralName so that rfc822Name is actually just UTF8String: >=20 > =20 >=20 > GeneralName ::=3D CHOICE { > otherName [0] INSTANCE OF OTHER-NAME, > rfc822Name [1] UTF8String, > dNSName [2] IA5String, > x400Address [3] ORAddress, > directoryName [4] Name, > ediPartyName [5] EDIPartyName, > uniformResourceIdentifier [6] IA5String, > iPAddress [7] OCTET STRING, > registeredID [8] OBJECT IDENTIFIER > } > =20 >=20 > GeneralName is in the IMPLICIT TAGS part of PKIX. That means that on = the wire, a GeneralName will (almost always) just be serialized as the >=20 > application tag in the choice, followed by the length and the data. = The counterproposal of a CHOICE {IA5String, UTF8String} is flawed in = that it will force ALL rfc822Names to include an additional tag = UNIVERSAL 22 in the case of IA5String, because the choice is ambiguous = without the tag (so a proper ASN.1 compiler will force the serialization = and de-serialization of the tag). Note: UTF8String (in a CHOICE) would = force serialization of the tag UNIVERSAL 12. >=20 > =20 >=20 > With this proposal #5, UTF8String is just a superset of IA5String. = Therefore, new implementations will =E2=80=9Cjust work=E2=80=9D with = virtually no further coding. The high-octet data in UTF8String will = violate expectations for older implementations that are looking for = IA5String. But enforcement of octets 00-7F is almost never done in the = decoding step, or if it is done, it does not cause the entire ASN.1 = decoding op to fail. (Note: this would be an =E2=80=9CASN.1 value = constraint violation.=E2=80=9D) If most implementations will continue to = decode the ASN.1 and simply skip over what it perceives to be =E2=80=9Cinv= alid ASCII=E2=80=9D (or simply rejects that particular alternative when = doing name comparisons), we are good to go. This basically mirrors the = way that EAI itself works in RFCs 6530-6532. >=20 > =20 >=20 > To test this, one would want to construct a signed certificate with = =E2=80=9Cinvalid=E2=80=9D IA5String data that actually contains valid = Unicode octets, and see what happens with various implementations. >=20 > =20 >=20 > I am not saying that this is the =E2=80=9Cright=E2=80=9D approach, but = I do think that it deserves serious consideration when evaluating = alternatives. An example of an advantage is that it should preserve name = constraints with no additional coding. >=20 >=20 --Apple-Mail=_287785AE-60CE-4385-A20B-13D10B28B9B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 To be clear, the otherName form = (draft-ietf-pkix-eai-addresses-00) is a sensible path = forward. That is how GeneralName was designed to be extended all = along.

Russ = corrected me offline and pointed out that GeneralName is =E2=80=9Cowned=E2= =80=9D (well, created originally anyway) by ITU-T X.509. It is not an = IETF-originated extension.

Any EAI mechanism will have consider = the impact of Name Constraints, the functionality of which needs to be = preserved.

Additionally, the EAI document should say something about = whether A-labels (i.e., Punycode) or U-labels ought to be used on the = domain side. I believe that U-labels should be used on the domain side = when in the otherName UTF8String. There are three solid = reasons:
#1 Since it=E2=80=99s UTF8String, it=E2=80=99= s simply =E2=80=9Cmore correct=E2=80=9D to use U-labels instead of = A-labels. The requirements of RFC 5280 regarding IDN don=E2=80=99t = really apply because those are about stuffing U-labels into ASCII = protocol slots (i.e., by making them A-labels).
#2 = When displayed to a user, U-labels are going to make sense; A-labels = will not. (Note: there are homograph attacks. But that is not a problem = specific to this choice, and IDNA procedures are supposed to mitigate = that.)
#3 U-labels are supposed to be compared = =E2=80=9CAS-IS=E2=80=9D (RFC 5891), but A-labels are case-insensitive. = Since the local-part is case-sensitive, this opens the possibility that = e-mail address strings in certificates can (under the proper = circumstances) be compared using a binary comparison operation (i.e., = exact equality).

Back to the alternatives: I am not withdrawing my suggestion = but merely proposing it as an alternative that should be empirically = examined before being dismissed, especially since CHOICE { IA5String, = UTF8String } is (or was?) on the table at the time.

Best regards,

Sean

On Apr 5, 2016, at 5:05 PM, Wei Chuang <weihaw@google.com> = wrote:


On Tue, Apr 5, 2016 at 10:30 AM, Jim Schaad <ietf@augustcellars.com> = wrote:


From: pkix [mailto:pkix-bounces@ietf.org] On = Behalf Of Russ Housley
Sent: = Tuesday, April 05, 2016 9:18 AM
Cc: IETF = PKIX <pkix@ietf.org>; IETF SMIME <smime@ietf.org>
Subject:= Re: [pkix] [smime] Support for email address internationalization in = RFC5280 certificates

 

On Apr 4, 2016, at 6:20 PM:



 

On Feb 7, 2016, at 12:15 PM, Wei = Chuang <weihaw@google.com> wrote:

 

On Fri, Feb 5, 2016 at = 4:46 PM, Peter Bowen <pzbowen@gmail.com> wrote:

On = Thu, Feb 4, 2016 at 11:05 AM, Wei Chuang <weihaw@google.com> wrote:
> PKIX = community,
>
> We've = observed a limitation for specifying internationalized email = addresses
> as the local part which = is restricted to essentially ASCII.  That is subject
> or = issuer email addresses which should be stored as subject-alt-name or
> issuer-alt-name = rfc822Name and are encoded as IA5String.  This is despite
> the = internationalization in email usage as specified by = internationalization
> of email headers in = RFC6532 allowing Unicode in To, From, etc fields and
> = becoming fairly commonplace.  RFC5280 already specifies = internationalization
> of the domain but lacks = any specification for the local-part.

 

Up until = now, I have tried to lay low on this topic. However, having reviewed the = relevant standards and implementations in the field, I have my 22=C2=A2:

 

The proposed methods are to create an otherName form = and assign a new object identifier for it (A. Melnikov, ed., = draft-ietf-pkix-eai-addresses-00), and to encode the = local part in base64 with =E2=80=9C:=E2=80=9D as an escape signal (L. = Baudoin, et. al., draft-lbaudoin-iemax-02). There is also a = counterproposal on the agenda, which I will label as #3, to make = rfc822Name a CHOICE = {IA5String, UTF8String}. There are two other methods that deserve = serious consideration. My 0.2=C2=A2 is on #4 and my 21.8=C2=A2 is on = #5:

 

#4 Extend GeneralName with a new name type:

 

GeneralName ::=3D CHOICE {

  otherName [0] INSTANCE OF OTHER-NAME,

  rfc822Name [1] IA5String,

  dNSName [2] IA5String,

  x400Address [3] ORAddress,

  directoryName [4] Name,

  ediPartyName [5] EDIPartyName,

  uniformResourceIdentifier [6] IA5String,

  = iPAddress [7] OCTET STRING,

  registeredID [8] OBJECT IDENTIFIER,

  eaiName [9] UTF8String

  ... }

 

The = advantage of this approach is that it conforms to X.509:2012, which uses = =E2=80=A6 syntax to show that the CHOICE is extensible. However, the = IETF invented GeneralName (RFC 2459), and the latest ASN.1 (RFC 5912) = does not use =E2=80=A6 syntax for extensibility. (Basically I think most = implementations would barf on this CHOICE, and would cause the overall ASN.1 decoding op to fail, meaning all places where = GeneralName is directly encoded, would cause implementations to barf.)

 

#5 Change GeneralName so that rfc822Name is = actually just UTF8String:

 

   GeneralName ::=3D CHOICE {
        =
otherName           =
;        [0]  INSTANCE OF =
OTHER-NAME,
        =
rfc822Name          &nbs=
p;       [1]  UTF8String,
        =
dNSName           &=
nbsp;         [2]  =
IA5String,
        =
x400Address          &nb=
sp;      [3]  ORAddress,
        =
directoryName          &=
nbsp;    [4]  Name,
        =
ediPartyName          &n=
bsp;     [5]  EDIPartyName,
        =
uniformResourceIdentifier   [6]  IA5String,
        =
iPAddress           =
;        [7]  OCTET STRING,
        =
registeredID          &n=
bsp;     [8]  OBJECT IDENTIFIER
   }

 

GeneralName is in the IMPLICIT TAGS part of PKIX. = That means that on the wire, a GeneralName will (almost always) just be = serialized as the

application tag in the choice, = followed by the length and the data. The counterproposal of a CHOICE {IA5String, = UTF8String} is flawed in that it will force ALL rfc822Names = to include an additional tag UNIVERSAL 22 in the case of IA5String, because the choice is ambiguous without the tag (so a proper = ASN.1 compiler will force the serialization and de-serialization of the = tag). Note: UTF8String (in a CHOICE) would force serialization of the = tag UNIVERSAL 12.

 

With = this proposal #5, UTF8String is just a superset of IA5String. Therefore, = new implementations will =E2=80=9Cjust work=E2=80=9D with virtually no = further coding. The high-octet data in UTF8String will violate = expectations for older implementations that are looking for IA5String. = But enforcement of octets 00-7F is almost never done in the decoding = step, or if it is done, it does not cause the entire ASN.1 decoding op = to fail. (Note: this would be an =E2=80=9CASN.1 value constraint = violation.=E2=80=9D) If most implementations will continue to decode the = ASN.1 and simply skip over what it perceives to be =E2=80=9Cinvalid = ASCII=E2=80=9D (or simply rejects that particular alternative when doing name comparisons), we are good to go. This basically mirrors = the way that EAI itself works in RFCs 6530-6532.

 

To test this, one would want to construct a signed = certificate with =E2=80=9Cinvalid=E2=80=9D IA5String data that actually = contains valid Unicode octets, and see what happens with various = implementations.

 

I am not = saying that this is the =E2=80=9Cright=E2=80=9D approach, but I do think = that it deserves serious consideration when evaluating alternatives. An = example of an advantage is that it should preserve name constraints with = no additional coding.

=
=

= --Apple-Mail=_287785AE-60CE-4385-A20B-13D10B28B9B6-- From nobody Fri Apr 15 07:17:33 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A22B12E152 for ; Fri, 15 Apr 2016 07:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 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_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 prTPVklLTUjX for ; Fri, 15 Apr 2016 07:17:30 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0468512E131 for ; Fri, 15 Apr 2016 07:17:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C7666BE25 for ; Fri, 15 Apr 2016 15:17:28 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjmxjiOenuC2 for ; Fri, 15 Apr 2016 15:17:26 +0100 (IST) Received: from [10.87.49.100] (unknown [86.42.21.187]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 386A9BE3F for ; Fri, 15 Apr 2016 15:17:26 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1460729846; bh=DwD6rrby248znx+ouTvzzT9K07tJRvA7nMtmYAV6+lg=; h=Subject:References:To:From:Date:In-Reply-To:From; b=qH78S/EVpSJZT4EHeTLM1hDb1OKhMxqI4gH53hdNIQZWrf7Q7TM7BA5UZdmRcpgsx tbt6KFapniRLDATGPO3cLr0pbRrBZFdFaAUZrPj1uV2iQT2vzSmgVuJGyL+phNUYOb rMJ5FaaT31fQFg1AhtbnuKIsBHWlvOKCfnYdWUnA= References: <5710F7A0.8020108@cs.tcd.ie> To: 'IETF SMIME' From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <5710F7A0.8020108@cs.tcd.ie> Message-ID: <5710F7F5.7090903@cs.tcd.ie> Date: Fri, 15 Apr 2016 15:17:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5710F7A0.8020108@cs.tcd.ie> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060101080108040602010903" Archived-At: Subject: [smime] Fwd: [Spasm] side meeting at IETF95 on possible PKIX/SMIME work (and new spasm list) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 14:17:31 -0000 This is a cryptographically signed message in MIME format. --------------ms060101080108040602010903 Content-Type: multipart/mixed; boundary="------------050904050609000200090901" This is a multi-part message in MIME format. --------------050904050609000200090901 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable -------- Forwarded Message -------- Subject: [Spasm] side meeting at IETF95 on possible PKIX/SMIME work (and new spasm list) Date: Fri, 15 Apr 2016 15:16:00 +0100 From: Stephen Farrell To: spasm@ietf.org Hiya, About 10 of us who were at IETF95 had a side meeting to continue the recent discussion about potential work items that would have been handled in the PKIX and SMIME working groups before those closed. A number of such work items in this space have recently been proposed on the PKIX and SMIME mailing lists. In the discussion we concluded that it might be a good plan to try charter a WG to (initially) handle a small number of these tasks. We also recognised that there is a bit of a history in this space of people proposing work that doesn't end up being implemented and deployed (and I'm as guilty of that as anyone;-) so we wanted to not do that this time around. To that end I said that I'd be happy to help with seeing if we have consensus to charter a working group to tackle a smallish list of specific work items where: - the proposal is sane - we're pretty confident the proposal will be implemented in a real way (not a toy, but doesn't have to be on every phone) - to the extent we can, we think there's a good chance that the proposal will be deployed - each proposal has an I-D already published that is called out in the charter as the starting point for the work If we start that WG and if it turns out to do good work well and in a timely fashion then I'd guess that it could be re-chartered to add additional items that meet the above criteria. We also figured that a new list (spasm [1]) would be a better way to handle this as it crosses two previous lists (which will remain open) with much broader topics. Russ Housley, Stefan Santesson and Wei Chuang have agreed to try to craft charter text for that so they'll send that to the spasm list [1] in a few days once folks have had a chance to sign up. So please hold off discussion of this for a few days and then continue the discussion on the spasm list. Cheers, S. [1] https://www.ietf.org/mailman/listinfo/spasm --------------050904050609000200090901 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KU3Bhc20g bWFpbGluZyBsaXN0ClNwYXNtQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc3Bhc20KCg== --------------050904050609000200090901-- --------------ms060101080108040602010903 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA0MTUx NDE3MjVaMC8GCSqGSIb3DQEJBDEiBCB+fIik1SviRPAvJbkeE+g1vAOBi5n2uaWSmKnf2YjR UTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQALDAXUYF9TwiFgJR0IpOJVhzgcfOiQW++kj4ApBOhoSmtVI6xUs8r9 jiQR6M9SaKXsCqI8ZIJENKL8TsAZmaHB3Nq+qcgk5RJnC47A09UXpvfvf3djuJ1xnexrrgnM nwuy4gb0qDMY3uRpS/eKnfvu/E8mLLoMqDhkX7AkTIwMwravWjZJPhcy3l3somOxQdBY7PpZ uwH7EFJeSgdoOig7l8wwSPVF9m2T6xMRcvlsOxdp66j+XjwOHn6C3hLwEqfF75MdmxJDMLm6 Ys/QmyJXvllJFCAyZVSmqIkAgEcqCKR6pEnE4daF0WIZBYqaLqaLPKx+n5Nkth5GRTyOWmUi AAAAAAAA --------------ms060101080108040602010903-- From nobody Fri Apr 15 10:38:53 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF9112DB62 for ; Fri, 15 Apr 2016 10:38:52 -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 DjRnJHi4THJu for ; Fri, 15 Apr 2016 10:38:51 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 34E3C12D930 for ; Fri, 15 Apr 2016 10:38:44 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 9ED0F9A4007 for ; Fri, 15 Apr 2016 13:38:43 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id lBvKHgdKY5v3 for ; Fri, 15 Apr 2016 13:23:35 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 464B29A4003 for ; Fri, 15 Apr 2016 13:38:43 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Apr 2016 13:38:41 -0400 References: <20160415173651.17440.40557.idtracker@ietfa.amsl.com> To: IETF SMIME Message-Id: <010E70F1-8C6A-4785-8CE8-F2EF8D94C922@vigilsec.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [smime] Fwd: New Version Notification for draft-housley-cms-ecdh-new-curves-00.txt X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 17:38:53 -0000 I expect this will be discussed on the CURDLE WG mail list, but folks on = this list may also be interested. Russ > A new version of I-D, draft-housley-cms-ecdh-new-curves-00.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. >=20 > Name: draft-housley-cms-ecdh-new-curves > Revision: 00 > Title: Use of the Elliptic Curve Diffie-Hellamn Key = Agreement Algorithm with Curve 25519 and Curve 448 in the Cryptographic = Message Syntax (CMS) > Document date: 2016-04-15 > Group: Individual Submission > Pages: 11 > URL: = https://www.ietf.org/internet-drafts/draft-housley-cms-ecdh-new-curves-00.= txt > Status: = https://datatracker.ietf.org/doc/draft-housley-cms-ecdh-new-curves/ > Htmlized: = https://tools.ietf.org/html/draft-housley-cms-ecdh-new-curves-00 >=20 >=20 > Abstract: > This document describes the conventions for using Elliptic Curve > Diffie-Hellamn (ECDH) key agreement algorithm using Curve 25519 and > Curve 448 in the Cryptographic Message Syntax (CMS). >=20 From nobody Mon Apr 18 17:00:35 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A090612D9A5 for ; Mon, 18 Apr 2016 17:00:32 -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 RrzRnz3cCaH5 for ; Mon, 18 Apr 2016 17:00:31 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id E815912D790 for ; Mon, 18 Apr 2016 17:00:30 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 884A89A4003 for ; Mon, 18 Apr 2016 20:00:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id zE2hocHWQJSC for ; Mon, 18 Apr 2016 19:44:59 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 25E5C9A4002 for ; Mon, 18 Apr 2016 20:00:20 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Apr 2016 20:00:19 -0400 References: <20160418235730.11103.60515.idtracker@ietfa.amsl.com> To: IETF SMIME Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [smime] Fwd: New Version Notification for draft-housley-cms-eddsa-signatures-00.txt X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 00:00:32 -0000 I expect this will be discussed on the CURDLE WG mail list, but folks on = this list may also be interested. Russ > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-housley-cms-eddsa-signatures-00.txt > Date: April 18, 2016 at 7:57:30 PM EDT > To: "Russ Housley" >=20 >=20 > A new version of I-D, draft-housley-cms-eddsa-signatures-00.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. >=20 > Name: draft-housley-cms-eddsa-signatures > Revision: 00 > Title: Use of EdDSA Signatures in the Cryptographic = Message Syntax (CMS) > Document date: 2016-04-18 > Group: Individual Submission > Pages: 4 > URL: = https://www.ietf.org/internet-drafts/draft-housley-cms-eddsa-signatures-00= .txt > Status: = https://datatracker.ietf.org/doc/draft-housley-cms-eddsa-signatures/ > Htmlized: = https://tools.ietf.org/html/draft-housley-cms-eddsa-signatures-00 >=20 >=20 > Abstract: > This document describes the conventions for using Edwards-curve > Digital Signature Algorithm (EdDSA) in the Cryptographic Message > Syntax (CMS). The conventions for Ed25519, Ed25519ph, Ed448, and > Ed448ph are described. >=20 From nobody Wed Apr 20 11:40:48 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B3512EA3A for ; Wed, 20 Apr 2016 11:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 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_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 kfOxSZ6Ahy7j for ; Wed, 20 Apr 2016 11:40:40 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BCF812E836 for ; Wed, 20 Apr 2016 11:40:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 75F38BE56 for ; Wed, 20 Apr 2016 19:32:33 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ohng0jvjF0wd for ; Wed, 20 Apr 2016 19:32:32 +0100 (IST) Received: from [10.87.49.100] (unknown [86.46.28.69]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 67473BE54 for ; Wed, 20 Apr 2016 19:32:31 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1461177151; bh=lYhtC38XwQSfP+4LjzexeZq6YV23nxvxW0BLAkhnoGw=; h=From:Subject:To:References:Date:In-Reply-To:From; b=4OkYoCDA/DKXs/tQKJxiHXThtzlGMm8g5lMDDkG2YHyYhsnyLnOz/AUtZ0XjAJHgc DF4K0+3JcZOrFgvym86C1+HfvGbJpfIHnWNVQIcAwXXQKDJk6+fCpWPmJsQiW+CUrH FCFsUtGUPzoa+YQANdm/H6zG4ZUAuUoWrfff8eY4= From: Stephen Farrell To: 'IETF SMIME' References: <5710F7A0.8020108@cs.tcd.ie> <5710F815.3020900@cs.tcd.ie> Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5717CB3F.1070703@cs.tcd.ie> Date: Wed, 20 Apr 2016 19:32:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5710F815.3020900@cs.tcd.ie> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070606010403000302090706" Archived-At: Subject: Re: [smime] [saag] Fwd: [Spasm] side meeting at IETF95 on possible PKIX/SMIME work (and new spasm list) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 18:40:44 -0000 This is a cryptographically signed message in MIME format. --------------ms070606010403000302090706 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI - discussion of a potential charter is starting now on that list [1] please join in there if interested. S. [1] https://www.ietf.org/mail-archive/web/spasm/current/msg00006.html On 15/04/16 15:17, Stephen Farrell wrote: >=20 >=20 >=20 > -------- Forwarded Message -------- > Subject: [Spasm] side meeting at IETF95 on possible PKIX/SMIME work (an= d > new spasm list) > Date: Fri, 15 Apr 2016 15:16:00 +0100 > From: Stephen Farrell > To: spasm@ietf.org >=20 >=20 > Hiya, >=20 > About 10 of us who were at IETF95 had a side meeting to continue > the recent discussion about potential work items that would have > been handled in the PKIX and SMIME working groups before those > closed. A number of such work items in this space have recently > been proposed on the PKIX and SMIME mailing lists. >=20 > In the discussion we concluded that it might be a good plan to > try charter a WG to (initially) handle a small number of these > tasks. We also recognised that there is a bit of a history in > this space of people proposing work that doesn't end up being > implemented and deployed (and I'm as guilty of that as anyone;-) > so we wanted to not do that this time around. >=20 > To that end I said that I'd be happy to help with seeing if we > have consensus to charter a working group to tackle a smallish > list of specific work items where: >=20 > - the proposal is sane > - we're pretty confident the proposal will be implemented in a > real way (not a toy, but doesn't have to be on every phone) > - to the extent we can, we think there's a good chance that the > proposal will be deployed > - each proposal has an I-D already published that is called out > in the charter as the starting point for the work >=20 > If we start that WG and if it turns out to do good work well and > in a timely fashion then I'd guess that it could be re-chartered > to add additional items that meet the above criteria. >=20 > We also figured that a new list (spasm [1]) would be a better way > to handle this as it crosses two previous lists (which will > remain open) with much broader topics. >=20 > Russ Housley, Stefan Santesson and Wei Chuang have agreed to try > to craft charter text for that so they'll send that to the spasm > list [1] in a few days once folks have had a chance to sign up. > So please hold off discussion of this for a few days and then > continue the discussion on the spasm list. >=20 > Cheers, > S. >=20 > [1] https://www.ietf.org/mailman/listinfo/spasm >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --------------ms070606010403000302090706 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA0MjAx ODMyMzFaMC8GCSqGSIb3DQEJBDEiBCCV7GlVCfXmwIvStok8BVOEQd/Rpop/tq+/5Spsvoya 0DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQArbntdfN+e9SzodX/rVMSzO5Xna4/PXfx9dI87dok8hJHcmnTYCah2 ngxoFyAslW9JjqGGlvS9RHjBmNRyBjcJhtYM2BueL1W0kw99L3Jkb0H4DGirkY0Sb2CE2C2q fqvKStXm4o20/rb34UTgx+KuaADVLRcR0TO//r9Ejc/mpWVL3hwBrAhC4h5KRCkKnZpHQY9b mRZdkdid85pICUOkTG+GuJjmDVEU04Vk7thLRGDLCXN2fnhuOtYfcE7eEKP42IM+cSdnra8N GTZmyrqXlg0QZZ0kjHLGC4aCpISHkYSEV2Z4j3JKY0+xhsFLoMdu+WF/BzUPboe9dgMSojqg AAAAAAAA --------------ms070606010403000302090706--