From nobody Fri Apr 1 09:36:26 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE48112D18E for ; Fri, 1 Apr 2016 09:36:24 -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 ovAu1IPCPNmZ for ; Fri, 1 Apr 2016 09:36:23 -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 1FB6612D17A for ; Fri, 1 Apr 2016 09:36:23 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id d68so34284104ywe.1 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=VB2IMBbJMH0wm6tDyx1nSBL8jzNVsGEE05R6qjAbAUp3JK6ctSEtGjMriTY25M3Rqv gApzAQ15tWcuuJmVheoqDeBudNY6KSGgtl3wOiDg7AGuC7uYdgOuIK8wf6Ok/Yi7u0G5 K7rpG8DLBB/R6t1a81cWriIsdCmdcjFvwfIAzFWGJZiPBWoMnjCyzeik1YVvxrr07mRe NUsUFTgLx0G2+J5i5jI/O6Ei5HsH3OqD6F83FHNENXM07rAyMmeMabYxFn6Ff1PcYKEZ wOQ7shPFKElzr1MKugp5r98iyXYjvobx0HrDi0p2XPNQnzTFMf2OVBjpTTcPPOLfPgiW 2LTQ== X-Gm-Message-State: AD7BkJLqtdXGZwm3lykCpVQI98+zRQ553kxeakOhzh08r2XyvGeX5beI8NiH8Wktls7hBQde5Wg86Q0lHNpq1XVN 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: Cc: John Levine , PKIX , IETF SMIME Subject: Re: [pkix] Identified Work Items and Discussion Summary (was: possible new pkix and/or smime work) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX 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 Fri Apr 1 09:43:37 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A4912D0CC for ; Fri, 1 Apr 2016 09:43:35 -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=ham 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 0Wg9eQRVw0Aj for ; Fri, 1 Apr 2016 09:43:33 -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 8B6ED12D18E 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: [pkix] Identified Work Items and Discussion Summary (was: possible new pkix and/or smime work) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 16:43:35 -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:12 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4260D12D678 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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0bNu217DjYZ for ; Fri, 1 Apr 2016 10:47:09 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E29612D543 for ; Fri, 1 Apr 2016 10:47:09 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id d68so38800992ywe.1 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=C5oGo/MUJ5Ki/hOKxC+qqrtljyd49wXLlr9bC4Qm061UTm/BjgSHjffbiAp05iqwYn AMVlvDWFLW1I1w1DGd6fIM4vupmojm51sp9dFlRkLI87mfMtVCABn7V1wrTvUc2/8WpI TeHz2pC54G1aYwda9WmPJuu5qZiryXk75ft/bQevPN+Y2kWnvs7Ti6QFOOsD9TK9FEFC NxegXJ+ky8US0z2WpuuHL8TzNu5UjOv/X10WIZ05HQRtJCI4mwXat9JHNk80ZD7sfaEC rSQEgC+gf4TZ/GFublYu1TggLysxaC3m0pd7rKquCwmYh/rNKmWbJ1FsfSPpt2MbDqhC 2lUA== X-Gm-Message-State: AD7BkJI5toLA/R9Z45pDacGaf5H063NPVq5aVirqQ7zbNIWi3/qzu9BUIHOc2hNFbxV26FuylHrfSPJC7Y8sUSkX 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 , IETF SMIME Subject: Re: [pkix] Identified Work Items and Discussion Summary (was: possible new pkix and/or smime work) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 17:47:11 -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 Fri Apr 1 11:16:45 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C69212D55A for ; Fri, 1 Apr 2016 11:16:44 -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 GuIl2pd6Agxp for ; Fri, 1 Apr 2016 11:16:41 -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 A1D0812D172 for ; Fri, 1 Apr 2016 11:16:41 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id d68so40670568ywe.1 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=f+d64EC3JYTtIX+ng9LZ86DMwbWhz/VdKUnHjlrV/MrT2FQu7mTKp/duxofKlT4O/k brEp4NqLkkNPFKkdpJ415/ti+2OBFXEoN9xzAtpQvc7RjLu4zfbRR1auN2qlAqvx/5Vr 1EW1cHEWN8OdBAPKLkJIwYRpYrnhbbdyEw9l4zUTzCUhXJdx/9vKK5zpzt7c02qMJ3aS pfGMjngNBmwyUUUtgguiiUaQxaGZomGw9E7RkhoKDBs5Opmx/flWYQiWm9Er14S+AWCF Km49EqJH77wbjrNMmpyGrlwpCgJJZ/cPow63luZCKQ57oqcp2KmPbFcGO+lVH46mjGA4 4l7Q== X-Gm-Message-State: AD7BkJLUgJmtnHpjwHQ8V2JrnKOhOVc4rXsze7p6TxUZzqss5neQ0OGZxrE7IVZ+v7ZJSRh3n/hceTGJ2dUbmC2+ 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: Cc: PKIX , John R Levine , IETF SMIME Subject: Re: [pkix] Identified Work Items and Discussion Summary (was: possible new pkix and/or smime work) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 18:16:44 -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 12:07:31 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143C012D61D for ; Mon, 4 Apr 2016 12:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohfsmrj7Tl6m for ; Mon, 4 Apr 2016 12:07:26 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1AEC12D1E2 for ; Mon, 4 Apr 2016 12:07:26 -0700 (PDT) Received: by mail-pa0-x22d.google.com with SMTP id td3so149277188pab.2 for ; Mon, 04 Apr 2016 12:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=zYAZZXgzzGZHCZpqtjVL60jyrh1XtUacgttI3NXW9cg=; b=UpZeGJi3SNvOqnr6BLIsRKZrX3yl8xWHBSZrD1w4MB4qmFzZnHhjJQGsNox6U80zOu FgqjxB1+8ekAf4TnTiNHt3S0fcOYTKHB/BFJYSnw/GtFx2R9KtMLVVk+SB+FAjP2FW3c xmsoqSLhZqfsLJ51/4meLXT62rGrUeR9WJYdPi+au9OGHuiEyhgKyHIAMq6bRsiWO1+M qckljpO0O6cNiaR0WfXDbBGhiAtrJk3ubYiAuT6haH+mFEZeqBkQp/BxmDCvkck2Zgbx 5yNeeGkLGa/eSFmQBDUKoKJtkUQKdgCfmJLxbRF3XSVCz9e815c6JOBYVzymMjTJhJEi jMfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=zYAZZXgzzGZHCZpqtjVL60jyrh1XtUacgttI3NXW9cg=; b=hgzCFCB7/JzubBaiaaGnDWwFaNNoPjMkX0puDeNuddjR+0cKYU6feY5kydCOorhW3d gDBquxWZyhe/VSBG1W0FsvJrBSIuetpEHuZy5uGrYGvW87gaRpAqVtJ9+7cdmskmweq6 Z200RYQTzkwwzyypE7YVHiTeTW6r8J89DhTghLrZZS47AfZILXHlJkJdfVnXtRQkXZ3E rS9/caye6GU7ROztobpcRJ8+PAb3V79507pVWOW5b7RBRFM7ZGPafLzGXK9OmAJMPKDy 9lQw/RF3FeORW1LBG635FUvwt9BbjGUIcflvZ1SZgOJceuIJ1WyOHtUyzsjcUb9ASCdT Klng== X-Gm-Message-State: AD7BkJIJeDsW93L3nh3a44zCuDNq8sW2C6BS9MhrjtZQ6Klqo31qEN8B8D6nXXbOd9G0x//7yKzH+0/DDocsnw== MIME-Version: 1.0 X-Received: by 10.66.66.167 with SMTP id g7mr48806763pat.111.1459796846332; Mon, 04 Apr 2016 12:07:26 -0700 (PDT) Received: by 10.67.1.2 with HTTP; Mon, 4 Apr 2016 12:07:26 -0700 (PDT) Date: Mon, 4 Apr 2016 15:07:26 -0400 Message-ID: From: daniel bryan To: pkix@ietf.org Content-Type: multipart/alternative; boundary=001a1133b57878532f052fad7091 Archived-At: Subject: [pkix] OCSP Signing Certificate Key usage standards X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 19:07:29 -0000 --001a1133b57878532f052fad7091 Content-Type: text/plain; charset=UTF-8 Hello, I am looking for guidance/standards on deploying an OCSP service in specific regards to the key management of the OCSP Signing certificate. Suppose I have a service, and I want to provide certificate status on 20 different certificate authorities using a "CA Designated responder" described in section 2.2 of RFC 6960. Technically I have a few options: *Option #1:* Generate 20 Keys on my HSM, Create 20 PKCS 10s, Submit all 20 for Signing to each CA. Import the Signed Certificate into my OCSP service. *Option #2:* Generate 1 Key on the HSM, Create 1 PKCS 10 with a generic CN, Submit 1 CSR to all 20 CA's. The CA will override the CN value during Signing to reference their CA name, Import all 20 Signed certificates into my OCSP service. Option #1 adds complexity to key management, could potentially have an impact on signing speed. An advantage is that if a key is lost/compromised, it would only involve troubling one CA instead of all. Option #2 will greatly simplify key management, and I speculate it will increase the signing speed potential of the HSM, being that it doesn't have to determine which key to use from a pool of 20 keys. Obviously the bad side is, if we ever loose the key, I would have to get all 20 CAs to sign another request. This is especially bad when the certs have the noCheck extension. Here are my 2 questions: *Q1:* From a security perspective, is option #2 worth considering. Simplification is a huge priority, but security is a must. *Q2:* Does the IETF/cabforum/Any other authority provide guidance/standards on key management in this situation that I can use to support/defend the choice? Thanks, --Dan --001a1133b57878532f052fad7091 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
He= llo,

I am looking for guidance/standards on deploying an OCSP service in=20 specific regards to the key management of the OCSP Signing certificate.
Suppose I have a service, and I want to provide certificate status on 20=20 different certificate authorities using a "CA Designated responder&quo= t;=20 described in section 2.2 of RFC 6960. Technically I have a few options:
=
Option #1: Generate 20 Keys on my HSM, Create 20 PKCS 10s, Submit all 20 for=20 Signing to each CA. Import the Signed Certificate into my OCSP service.
=
Option #2: Generate 1 Key on the HSM, Create 1 PKCS 10 with a generic CN, Submit 1 CSR to all 20 CA's. The CA will override the CN value during Signing t= o reference their CA name, Import all 20 Signed certificates into my OCSP service.

Option #1 adds complexity to key management, could potentially have an impact=20 on signing speed. An advantage is that if a key is lost/compromised, it=20 would only involve troubling one CA instead of all.

Option #2 will g= reatly simplify key management, and I=20 speculate it will increase the signing speed potential of the HSM, being that it doesn't have to determine which key to use from a pool of 20= =20 keys.=C2=A0 Obviously the bad side is, if we ever loose the key, I would ha= ve to get all 20 CAs to sign another request. This is especially bad when the= certs have the noCheck extension.


Here are my 2 questions:

Q1: From a security perspective, is = option #2 worth considering. Simplification is a huge priority, but securit= y is a must.

Q2: Does the IETF/cabforum/Any other authority p= rovide guidance/standards on key management in this situation that I can us= e to support/defend the choice?

Th= anks,

--Dan
--001a1133b57878532f052fad7091-- From nobody Mon Apr 4 12:22:00 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@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: [pkix] Identified Work Items and Discussion Summary (was: possible new pkix and/or smime work) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX 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 12:44:31 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6953112D84B for ; Mon, 4 Apr 2016 12:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuT4eWoyW4Uu for ; Mon, 4 Apr 2016 12:44:26 -0700 (PDT) Received: from mail.ascertia.com (ds9380.dedicated.turbodns.co.uk [94.136.51.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A67F12D821 for ; Mon, 4 Apr 2016 12:44:25 -0700 (PDT) Received: from LKHP ([86.174.155.70]) by ascertia.com with MailEnable ESMTP; Mon, 4 Apr 2016 20:43:40 +0100 From: "Liaquat Khan" To: "'daniel bryan'" , References: In-Reply-To: Date: Mon, 4 Apr 2016 20:44:13 +0100 Message-ID: <054a01d18eaa$5dbdcf40$19396dc0$@ascertia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_054B_01D18EB2.BF8348B0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQL1Uy8z7zfvtsa3DKL/u2P6x7wU/50yqP+w Content-Language: en-gb X-MXScan-Scan: Scanned by MxScan 3.1.101.0 for DS9380 X-MXScan-Msgid: 8BAF19311CF94794BCA4EE1A4FB9C1CB_ X-MXScan-Country-Sequence: UNITED KINGDOM->Destination X-MXScan-AntiVirus: ClamAV 0.98.7/21484/Fri Apr 01 21:09:25 2016 [Clean] X-MXScan-AntiSpam: [Disabled for SMTP-OUT(1)] X-MXScan-ProcessingTime: 0.062 sec(s) X-ME-Bayesian: 0.000000 Archived-At: Subject: Re: [pkix] OCSP Signing Certificate Key usage standards X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 19:44:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_054B_01D18EB2.BF8348B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Daniel=20 =20 We have deployed both options in the past, although with a variation on = option 2 in that we generate separate PKCS#10 CSR from the same public = key to send to the different CAs. I don=E2=80=99t think there is much = difference in performance with either option, remember the OCSP = responder needs to find the right responder certificate to attach to the = OCSP response even if it=E2=80=99s using a single private key =E2=80=93 = although I have not specifically tested the performance difference. In = terms of security having separate keys is better although if they are in = an HSM compromise is unlikely and if somehow one can be comprised then = so can others. I am not aware of any specific industry/standards-based = guidance to help choose between these options.=20 =20 Regards LK =20 From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of daniel bryan Sent: 04 April 2016 20:07 To: pkix@ietf.org Subject: [pkix] OCSP Signing Certificate Key usage standards =20 Hello, I am looking for guidance/standards on deploying an OCSP service in = specific regards to the key management of the OCSP Signing certificate.=20 Suppose I have a service, and I want to provide certificate status on 20 = different certificate authorities using a "CA Designated responder" = described in section 2.2 of RFC 6960. Technically I have a few options: Option #1: Generate 20 Keys on my HSM, Create 20 PKCS 10s, Submit all 20 = for Signing to each CA. Import the Signed Certificate into my OCSP = service. Option #2: Generate 1 Key on the HSM, Create 1 PKCS 10 with a generic = CN, Submit 1 CSR to all 20 CA's. The CA will override the CN value = during Signing to reference their CA name, Import all 20 Signed = certificates into my OCSP service. Option #1 adds complexity to key management, could potentially have an = impact on signing speed. An advantage is that if a key is = lost/compromised, it would only involve troubling one CA instead of all. Option #2 will greatly simplify key management, and I speculate it will = increase the signing speed potential of the HSM, being that it doesn't = have to determine which key to use from a pool of 20 keys. Obviously = the bad side is, if we ever loose the key, I would have to get all 20 = CAs to sign another request. This is especially bad when the certs have = the noCheck extension. Here are my 2 questions: =20 Q1: From a security perspective, is option #2 worth considering. = Simplification is a huge priority, but security is a must. Q2: Does the IETF/cabforum/Any other authority provide = guidance/standards on key management in this situation that I can use to = support/defend the choice? Thanks, --Dan ------=_NextPart_000_054B_01D18EB2.BF8348B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Daniel =

 

We have = deployed both options in the past, although with a variation on option 2 = in that we generate separate PKCS#10 CSR from the same public key to = send to the different CAs.=C2=A0 I don=E2=80=99t think there is much = difference in performance with either option, remember the OCSP = responder needs to find the right responder certificate to attach to the = OCSP response even if it=E2=80=99s using a single private key =E2=80=93 = although I have not specifically tested the performance = difference.=C2=A0 In terms of security having separate keys is better = although if they are in an HSM compromise is unlikely and if somehow one = can be comprised then so can others. =C2=A0=C2=A0I am not aware of any = specific industry/standards-based guidance to help choose between these = options.

 

Regards<= /o:p>

LK=

 

From:<= /b> = pkix [mailto:pkix-bounces@ietf.org] On Behalf Of daniel = bryan
Sent: 04 April 2016 20:07
To: = pkix@ietf.org
Subject: [pkix] OCSP Signing Certificate Key = usage standards

 

Hello,<= /span>

I am looking for = guidance/standards on deploying an OCSP service in specific regards to = the key management of the OCSP Signing certificate. =

Suppose I have a = service, and I want to provide certificate status on 20 different = certificate authorities using a "CA Designated responder" = described in section 2.2 of RFC 6960. Technically I have a few = options:

Option = #1: Generate 20 Keys = on my HSM, Create 20 PKCS 10s, Submit all 20 for Signing to each CA. = Import the Signed Certificate into my OCSP = service.

Option = #2: Generate 1 Key = on the HSM, Create 1 PKCS 10 with a generic CN, Submit 1 CSR to all 20 = CA's. The CA will override the CN value during Signing to reference = their CA name, Import all 20 Signed certificates into my OCSP = service.

Option #1 adds = complexity to key management, could potentially have an impact on = signing speed. An advantage is that if a key is lost/compromised, it = would only involve troubling one CA instead of all.

Option #2 = will greatly simplify key management, and I speculate it will increase = the signing speed potential of the HSM, being that it doesn't have to = determine which key to use from a pool of 20 keys.  Obviously the = bad side is, if we ever loose the key, I would have to get all 20 CAs to = sign another request. This is especially bad when the certs have the = noCheck extension.

Here are my 2 = questions:

 <= /span>

Q1: From a = security perspective, is option #2 worth considering. Simplification is = a huge priority, but security is a must.

Q2: Does the = IETF/cabforum/Any other authority provide guidance/standards on key = management in this situation that I can use to support/defend the = choice?

Thanks,=

--Dan

------=_NextPart_000_054B_01D18EB2.BF8348B0-- From nobody Mon Apr 4 15:20:19 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@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: [pkix] Support for email address internationalization in RFC5280 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX 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 Mon Apr 4 16:10:27 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1292512D875 for ; Mon, 4 Apr 2016 16:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xHTv-0d_CqJ for ; Mon, 4 Apr 2016 16:10:24 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27C8712D156 for ; Mon, 4 Apr 2016 16:10:24 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id fe3so153384830pab.1 for ; Mon, 04 Apr 2016 16:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=tEd70pjkJ1nHV08UpPaNpZ3IQqQTvzxbMBV4FhoEL0c=; b=SqP48L7iOl2fB1HAXYx7Kym/iasArx1rlcfH88aF4RopQ8+/Dv37iOowXLlCiFZ8ip d/YHlkU1fbTP5lbEbHc28F4RisiDCh3xQ6hCNRVNuy3IiWdOuaeoali6eHdJfhjK9cP8 VlhWYxmYXgMrtdOsDMepQZDO7aB3ijrimTsPHaDoF+6wzuboFYSToJ8zzF0MnF7/D8eB y5CSThqFPkaCTk4QRkEJH7T2+vGbwL9EGYTQkTEhJIPycgfTC6S+v0UDfqQfLvV+/sdh INeqKUEMCok6XjYtDu+NNV8HM3FZQF65BOjbG8JnBSE40NrPg3magqVcyn801rrBMl2z ntAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=tEd70pjkJ1nHV08UpPaNpZ3IQqQTvzxbMBV4FhoEL0c=; b=H+nFgJUJ9/qR/6fGb9MSs3Oz7cqPcSMJDeqjrzAlUJMadf4eqY5kGcGtVWwVaWPxF8 DK+fWiwuZwUtF56D4ixjWJUTJcn/3fjaUzC5uBq+Ab5iXqIQUz3g9NJwMYREM1DYMdkQ cy3qN/y3Q7KYGRZUz6iknNPyzH6NvkGjVM9nweUuR+Aak29o1fsWE/ezKwz4CeJtmgGM U/qNvpl2poig+SbjPeAT5EDbKe62Qf3gpGzSZk4mxn5xIsuYfZv2J88UXnUSV4l+xc59 pR4cxlWu+vrEpj2PVyxPnbBuLlGOM//Ug0ryhEns017IKm7nsLIlMlQISGm1uIe1tDsz beuw== X-Gm-Message-State: AD7BkJIb6J49UtGgb7ybXNaM7S8zAjEWBQdo/alPuKoHCicHV6c6r3dSlEy/CNvddtuBuV/aM1ZHxFclpkSUSA== X-Received: by 10.66.120.46 with SMTP id kz14mr57152697pab.61.1459811423679; Mon, 04 Apr 2016 16:10:23 -0700 (PDT) MIME-Version: 1.0 References: <054a01d18eaa$5dbdcf40$19396dc0$@ascertia.com> In-Reply-To: <054a01d18eaa$5dbdcf40$19396dc0$@ascertia.com> From: daniel bryan Date: Mon, 04 Apr 2016 23:10:13 +0000 Message-ID: To: Liaquat Khan , pkix@ietf.org Content-Type: multipart/alternative; boundary=047d7b0721da58fd2b052fb0d5a6 Archived-At: Subject: Re: [pkix] OCSP Signing Certificate Key usage standards X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 23:10:26 -0000 --047d7b0721da58fd2b052fb0d5a6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the info, I agree with you that it doesn't matter if 1 key, or all the keys are on the HSM, if the HSM is compromised, everything would need to rekeyed. On Mon, Apr 4, 2016 at 3:44 PM Liaquat Khan wrote: > Hi Daniel > > > > We have deployed both options in the past, although with a variation on > option 2 in that we generate separate PKCS#10 CSR from the same public ke= y > to send to the different CAs. I don=E2=80=99t think there is much differ= ence in > performance with either option, remember the OCSP responder needs to find > the right responder certificate to attach to the OCSP response even if it= =E2=80=99s > using a single private key =E2=80=93 although I have not specifically tes= ted the > performance difference. In terms of security having separate keys is > better although if they are in an HSM compromise is unlikely and if someh= ow > one can be comprised then so can others. I am not aware of any specific > industry/standards-based guidance to help choose between these options. > > > > Regards > > LK > > > > *From:* pkix [mailto:pkix-bounces@ietf.org] *On Behalf Of *daniel bryan > *Sent:* 04 April 2016 20:07 > *To:* pkix@ietf.org > *Subject:* [pkix] OCSP Signing Certificate Key usage standards > > > > Hello, > > I am looking for guidance/standards on deploying an OCSP service in > specific regards to the key management of the OCSP Signing certificate. > > Suppose I have a service, and I want to provide certificate status on 20 > different certificate authorities using a "CA Designated responder" > described in section 2.2 of RFC 6960. Technically I have a few options: > > *Option #1:* Generate 20 Keys on my HSM, Create 20 PKCS 10s, Submit all > 20 for Signing to each CA. Import the Signed Certificate into my OCSP > service. > > *Option #2:* Generate 1 Key on the HSM, Create 1 PKCS 10 with a generic > CN, Submit 1 CSR to all 20 CA's. The CA will override the CN value during > Signing to reference their CA name, Import all 20 Signed certificates int= o > my OCSP service. > > Option #1 adds complexity to key management, could potentially have an > impact on signing speed. An advantage is that if a key is lost/compromise= d, > it would only involve troubling one CA instead of all. > > Option #2 will greatly simplify key management, and I speculate it will > increase the signing speed potential of the HSM, being that it doesn't ha= ve > to determine which key to use from a pool of 20 keys. Obviously the bad > side is, if we ever loose the key, I would have to get all 20 CAs to sign > another request. This is especially bad when the certs have the noCheck > extension. > > Here are my 2 questions: > > > > *Q1:* From a security perspective, is option #2 worth considering. > Simplification is a huge priority, but security is a must. > > *Q2:* Does the IETF/cabforum/Any other authority provide > guidance/standards on key management in this situation that I can use to > support/defend the choice? > > Thanks, > > --Dan > --047d7b0721da58fd2b052fb0d5a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the info, I agree with you that it doesn't = matter if 1 key, or all the keys are on the HSM, if the HSM is compromised,= everything would need to rekeyed.

=
On Mon, Apr 4, 2016 at 3:44 PM Liaquat Khan <liaquat.khan@ascertia.com> wrote:=

Hi Daniel =

=C2=A0

=

We have deployed both options in the= past, although with a variation on option 2 in that we generate separate P= KCS#10 CSR from the same public key to send to the different CAs.=C2=A0 I d= on=E2=80=99t think there is much difference in performance with either opti= on, remember the OCSP responder needs to find the right responder certifica= te to attach to the OCSP response even if it=E2=80=99s using a single priva= te key =E2=80=93 although I have not specifically tested the performance di= fference.=C2=A0 In terms of security having separate keys is better althoug= h if they are in an HSM compromise is unlikely and if somehow one can be co= mprised then so can others. =C2=A0=C2=A0I am not aware of any specific indu= stry/standards-based guidance to help choose between these options. =

=C2=A0

Regards

LK

=

=C2=A0

From: pkix [mailto:pkix-bounces@ietf.org] On Behal= f Of daniel bryan
Sent: 04 April 2016 20:07
To: pkix@ietf.org
Sub= ject: [pkix] OCSP Signing Certificate Key usage standards=

=C2=A0

Hello,

I am looking = for guidance/standards on deploying an OCSP service in specific regards to = the key management of the OCSP Signing certificate.

Suppose I ha= ve a service, and I want to provide certificate status on 20 different cert= ificate authorities using a "CA Designated responder" described i= n section 2.2 of RFC 6960. Technically I have a few options:<= /span>

= O= ption #1: Generate 20 Keys on my HSM, Create 20 PKCS 10s, Submit all= 20 for Signing to each CA. Import the Signed Certificate into my OCSP serv= ice.

Option #2: Generate 1 Key on the HSM, Create 1 PKC= S 10 with a generic CN, Submit 1 CSR to all 20 CA's. The CA will overri= de the CN value during Signing to reference their CA name, Import all 20 Si= gned certificates into my OCSP service.

=

Option #1 adds complexity= to key management, could potentially have an impact on signing speed. An a= dvantage is that if a key is lost/compromised, it would only involve troubl= ing one CA instead of all.

Option #2 will greatly simplify key manag= ement, and I speculate it will increase the signing speed potential of the = HSM, being that it doesn't have to determine which key to use from a po= ol of 20 keys.=C2=A0 Obviously the bad side is, if we ever loose the key, I= would have to get all 20 CAs to sign another request. This is especially b= ad when the certs have the noCheck extension.

<= /p>

Here are my 2 questions:

=C2=A0

<= div>

Q1: From a = security perspective, is option #2 worth considering. Simplification is a h= uge priority, but security is a must.

Q2: Does the IETF/cabfo= rum/Any other authority provide guidance/standards on key management in thi= s situation that I can use to support/defend the choice?

Thanks,<= u>

--Dan=

--047d7b0721da58fd2b052fb0d5a6-- From nobody Tue Apr 5 06:56:46 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@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: [pkix] [smime] Support for email address internationalization in RFC5280 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX 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 07:13:56 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1820D12D542 for ; Tue, 5 Apr 2016 07:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_DR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaHoUjyJ_3Qi for ; Tue, 5 Apr 2016 07:13:53 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (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 BC23A12D4FB for ; Tue, 5 Apr 2016 07:13:52 -0700 (PDT) Received: by mail-qg0-x230.google.com with SMTP id j35so11205480qge.0 for ; Tue, 05 Apr 2016 07:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to; bh=+JXRAV5zoG+a38bTybkTb2fl78KVnnkUt/a5atb+Arg=; b=RzSdBPkLFEnmVzRUw4F5NI0Lj9wMtKUQvjKixGtrB2ahGI7qj0a67Z7ftybpU0lwfO BbbrPaWhDzmxBZKRPUcRkesGj6NbIpyoMOM1I4bQtHPUAJ/31hpxPX6fYBfEoEb4h+Ro 17g2ma9LykN1RRc4B3Jhs8HuoK3HlSUa45YykE7hMJVdKjFNdYzcI9KQeC8GEGS7+cTj po15dBYsHgvQjhRdKpL+6RUTrt7GliAbezzYrrOArgHXmnnlC7Q4zYjy7f+vuTRyhoib 5G/ezau/R/vOxaWA9TkeALk8d/77Z1CmaoyVkk33Q6uH7gCR2bDW8Dk2oa5tLhXMx+5h mmjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to; bh=+JXRAV5zoG+a38bTybkTb2fl78KVnnkUt/a5atb+Arg=; b=kW3a8fXiNTkKGPPieo5YgGe8a2ltWFFIDV5n1FGXEHjsz6WAc0/dH41je2nvgE30R1 VwkfNtzLOPH4SgGb1uPC0sWJt901Q4ET5Al1R8UkfbV9FgOHQXFAxR6wH9G0doROe4wa z5xOcxGbS9MryOtSAnFnk0u28qQ6wyvak2VU5ggDTwCvHGTp4FU5H04VOJDmMTnm9F3G 6WtxL4+scLrUpS5FYXvx/H+C7pt7klAYZJrWYbFaai6AuXj89LfeXhcw03WbJI2WiXyx wmZwpBEcPuwjgl0WZ98TZzBbgLItj50XY7FVhLWTzDT17oGL8BZNXZcs3SU24IK3dRyq 3SEg== X-Gm-Message-State: AD7BkJJji0+RVzDmUuYlrXwHOsXal0STyHMbea6UmEuJaMRThZl9iSWlbNX+SZDnteoVSA== X-Received: by 10.140.23.139 with SMTP id 11mr17320343qgp.62.1459865631817; Tue, 05 Apr 2016 07:13:51 -0700 (PDT) Received: from iMassi.local ([2001:67c:1231:998:b4eb:f1f4:3a02:7256]) by smtp.googlemail.com with ESMTPSA id s8sm14511317qhb.20.2016.04.05.07.13.50 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2016 07:13:51 -0700 (PDT) From: "Dr. Massimiliano Pala" To: pkix@ietf.org References: Message-ID: <5703C81C.50906@gmail.com> Date: Tue, 5 Apr 2016 11:13:48 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040606070507080403080001" Archived-At: Subject: Re: [pkix] OCSP Signing Certificate Key usage standards X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 14:13:55 -0000 This is a multi-part message in MIME format. --------------040606070507080403080001 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Daniel, personally, as long as the key is properly protected (and you are using HSMs for that - so it should be ok) and rotated (limited lifetime) and you have an easy way to request the different certificates from the different CAs (hopefully you have an automated interface to them), I would go with Option #2 - this simplifies key management as you said. However, this comes with a price on security in case the key is compromised - in this case, you will have to revoke 20 certificates at once and get a new certificate for all the 20 CAs you are serving. For this, the "automation" for getting the certificate and have the old ones revoked is a key feature, IMHO. To address the last point, my suggestion would be to play ahead. Have 2 different keys and have certificates issued for both of them. Use one key in production and keep the other one in a safe place (separate form the deployment one). Then setup a procedure to switch the keys when needed - this allows you to stop using a compromised key without having to wait for the 20 (or more) CAs to process your revocation and new certificate requests which can now be processed in parallel. (This said, clients will continue to trust the compromised key until the proper revocation is provided by the different CAs - but that is true for both options) If you value simplicity, this might provide you with an easy implementation and yet gives you the ability to respond quickly. Of course, not knowing the capabilities and setup of your systems there might be more clever and/or better fitting solutions... this is a very generic response! Last but not least - I am a bit curious about the HSM you are using: in my experience current HSMs are really too slow for any crypto operation that is in response to live traffic (modern CPUs outperform them by A LOT). For that reason (and others, actually) it is common, today, to pre-produce all responses and store them in CDNs so that the performance of the HSMs is not an issue (but, of course, you might have a "publishing" window vulnerability in this case). I hope this helps, Cheers, Max On 4/4/16 4:07 PM, daniel bryan wrote: > Hello, > > I am looking for guidance/standards on deploying an OCSP service in > specific regards to the key management of the OCSP Signing certificate. > > Suppose I have a service, and I want to provide certificate status on > 20 different certificate authorities using a "CA Designated responder" > described in section 2.2 of RFC 6960. Technically I have a few options: > > *Option #1:* Generate 20 Keys on my HSM, Create 20 PKCS 10s, Submit > all 20 for Signing to each CA. Import the Signed Certificate into my > OCSP service. > > *Option #2:* Generate 1 Key on the HSM, Create 1 PKCS 10 with a > generic CN, Submit 1 CSR to all 20 CA's. The CA will override the CN > value during Signing to reference their CA name, Import all 20 Signed > certificates into my OCSP service. > > Option #1 adds complexity to key management, could potentially have an > impact on signing speed. An advantage is that if a key is > lost/compromised, it would only involve troubling one CA instead of all. > > Option #2 will greatly simplify key management, and I speculate it > will increase the signing speed potential of the HSM, being that it > doesn't have to determine which key to use from a pool of 20 keys. > Obviously the bad side is, if we ever loose the key, I would have to > get all 20 CAs to sign another request. This is especially bad when > the certs have the noCheck extension. > > > Here are my 2 questions: > > *Q1:* From a security perspective, is option #2 worth considering. > Simplification is a huge priority, but security is a must. > * > Q2:* Does the IETF/cabforum/Any other authority provide > guidance/standards on key management in this situation that I can use > to support/defend the choice? > > Thanks, > > --Dan > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > -- > Massimiliano Pala, PhD > Director at OpenCA Labs > twitter: @openca --------------040606070507080403080001 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Daniel,

personally, as long as the key is properly protected (and you are using HSMs for that - so it should be ok) and rotated (limited lifetime) and you have an easy way to request the different certificates from the different CAs (hopefully you have an automated interface to them), I would go with Option #2 - this simplifies key management as you said.

However, this comes with a price on security in case the key is compromised - in this case, you will have to revoke 20 certificates at once and get a new certificate for all the 20 CAs you are serving. For this, the "automation" for getting the certificate and have the old ones revoked is a key feature, IMHO.

To address the last point, my suggestion would be to play ahead. Have 2 different keys and have certificates issued for both of them. Use one key in production and keep the other one in a safe place (separate form the deployment one). Then setup a procedure to switch the keys when needed - this allows you to stop using a compromised key without having to wait for the 20 (or more) CAs to process your revocation and new certificate requests which can now be processed in parallel. (This said, clients will continue to trust the compromised key until the proper revocation is provided by the different CAs - but that is true for both options)

If you value simplicity, this might provide you with an easy implementation and yet gives you the ability to respond quickly. Of course, not knowing the capabilities and setup of your systems there might be more clever and/or better fitting solutions... this is a very generic response!

Last but not least - I am a bit curious about the HSM you are using: in my experience current HSMs are really too slow for any crypto operation that is in response to live traffic (modern CPUs outperform them by A LOT). For that reason (and others, actually) it is common, today, to pre-produce all responses and store them in CDNs so that the performance of the HSMs is not an issue (but, of course, you might have a "publishing" window vulnerability in this case).

I hope this helps,

Cheers,
Max


On 4/4/16 4:07 PM, daniel bryan wrote:
Hello,

I am looking for guidance/standards on deploying an OCSP service in specific regards to the key management of the OCSP Signing certificate.

Suppose I have a service, and I want to provide certificate status on 20 different certificate authorities using a "CA Designated responder" described in section 2.2 of RFC 6960. Technically I have a few options:

Option #1: Generate 20 Keys on my HSM, Create 20 PKCS 10s, Submit all 20 for Signing to each CA. Import the Signed Certificate into my OCSP service.

Option #2: Generate 1 Key on the HSM, Create 1 PKCS 10 with a generic CN, Submit 1 CSR to all 20 CA's. The CA will override the CN value during Signing to reference their CA name, Import all 20 Signed certificates into my OCSP service.

Option #1 adds complexity to key management, could potentially have an impact on signing speed. An advantage is that if a key is lost/compromised, it would only involve troubling one CA instead of all.

Option #2 will greatly simplify key management, and I speculate it will increase the signing speed potential of the HSM, being that it doesn't have to determine which key to use from a pool of 20 keys. Obviously the bad side is, if we ever loose the key, I would have to get all 20 CAs to sign another request. This is especially bad when the certs have the noCheck extension.


Here are my 2 questions:

Q1: From a security perspective, is option #2 worth considering. Simplification is a huge priority, but security is a must.

Q2: Does the IETF/cabforum/Any other authority provide guidance/standards on key management in this situation that I can use to support/defend the choice?

Thanks,

--Dan


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


-- 
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca
--------------040606070507080403080001-- From nobody Tue Apr 5 10:02:04 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322D812D86E for ; Tue, 5 Apr 2016 10:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_NAME_DR=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 aVi13QVJAP83 for ; Tue, 5 Apr 2016 10:02:01 -0700 (PDT) Received: from mail.katezarealty.com (cvps8815162906.hostwindsdns.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 473E012D8A1 for ; Tue, 5 Apr 2016 10:01:59 -0700 (PDT) Received: from iMassi.local (unknown [IPv6:2001:67c:1231:998:fcb8:f7a1:6531:7f0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id AF2E93743B7B for ; Mon, 4 Apr 2016 15:54:44 -0400 (EDT) To: pkix@ietf.org References: From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <5702C682.1020700@openca.org> Date: Mon, 4 Apr 2016 16:54:42 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------070009070903050108000802" Archived-At: Subject: Re: [pkix] OCSP Signing Certificate Key usage standards X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 17:02:03 -0000 This is a multi-part message in MIME format. --------------070009070903050108000802 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Daniel, personally, as long as the key is properly protected (and you are using HSMs for that - so it should be ok) and rotated (limited lifetime) and you have an easy way to request the different certificates from the different CAs (hopefully you have an automated interface to them), I would go with Option #2 - this simplifies key management as you said. However, this comes with a price on security in case the key is compromised - in this case, you will have to revoke 20 certificates at once and get a new certificate for all the 20 CAs you are serving. For this, the "automation" for getting the certificate and have the old ones revoked is a key feature, IMHO. To address the last point, my suggestion would be to play ahead. Have 2 different keys and have certificates issued for both of them. Use one key in production and keep the other one in a safe place (separate form the deployment one). Then setup a procedure to switch the keys when needed - this allows you to stop using a compromised key without having to wait for the 20 (or more) CAs to process your revocation and new certificate requests which can now be processed in parallel. (This said, clients will continue to trust the compromised key until the proper revocation is provided by the different CAs - but that is true for both options) If you value simplicity, this might provide you with an easy implementation and yet gives you the ability to respond quickly. Of course, not knowing the capabilities and setup of your systems there might be more clever and/or better fitting solutions... this is a very generic response! Last but not least - I am a bit curious about the HSM you are using: in my experience current HSMs are really too slow for any crypto operation that is in response to live traffic (modern CPUs outperform them by A LOT). For that reason (and others, actually) it is common, today, to pre-produce all responses and store them in CDNs so that the performance of the HSMs is not an issue (but, of course, you might have a "publishing" window vulnerability in this case). I hope this helps, Cheers, Max On 4/4/16 4:07 PM, daniel bryan wrote: > Hello, > > I am looking for guidance/standards on deploying an OCSP service in > specific regards to the key management of the OCSP Signing certificate. > > Suppose I have a service, and I want to provide certificate status on > 20 different certificate authorities using a "CA Designated responder" > described in section 2.2 of RFC 6960. Technically I have a few options: > > *Option #1:* Generate 20 Keys on my HSM, Create 20 PKCS 10s, Submit > all 20 for Signing to each CA. Import the Signed Certificate into my > OCSP service. > > *Option #2:* Generate 1 Key on the HSM, Create 1 PKCS 10 with a > generic CN, Submit 1 CSR to all 20 CA's. The CA will override the CN > value during Signing to reference their CA name, Import all 20 Signed > certificates into my OCSP service. > > Option #1 adds complexity to key management, could potentially have an > impact on signing speed. An advantage is that if a key is > lost/compromised, it would only involve troubling one CA instead of all. > > Option #2 will greatly simplify key management, and I speculate it > will increase the signing speed potential of the HSM, being that it > doesn't have to determine which key to use from a pool of 20 keys. > Obviously the bad side is, if we ever loose the key, I would have to > get all 20 CAs to sign another request. This is especially bad when > the certs have the noCheck extension. > > > Here are my 2 questions: > > *Q1:* From a security perspective, is option #2 worth considering. > Simplification is a huge priority, but security is a must. > * > Q2:* Does the IETF/cabforum/Any other authority provide > guidance/standards on key management in this situation that I can use > to support/defend the choice? > > Thanks, > > --Dan > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > -- > Massimiliano Pala, PhD > Director at OpenCA Labs > twitter: @openca --------------070009070903050108000802 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Daniel,

personally, as long as the key is properly protected (and you are using HSMs for that - so it should be ok) and rotated (limited lifetime) and you have an easy way to request the different certificates from the different CAs (hopefully you have an automated interface to them), I would go with Option #2 - this simplifies key management as you said.

However, this comes with a price on security in case the key is compromised - in this case, you will have to revoke 20 certificates at once and get a new certificate for all the 20 CAs you are serving. For this, the "automation" for getting the certificate and have the old ones revoked is a key feature, IMHO.

To address the last point, my suggestion would be to play ahead. Have 2 different keys and have certificates issued for both of them. Use one key in production and keep the other one in a safe place (separate form the deployment one). Then setup a procedure to switch the keys when needed - this allows you to stop using a compromised key without having to wait for the 20 (or more) CAs to process your revocation and new certificate requests which can now be processed in parallel. (This said, clients will continue to trust the compromised key until the proper revocation is provided by the different CAs - but that is true for both options)

If you value simplicity, this might provide you with an easy implementation and yet gives you the ability to respond quickly. Of course, not knowing the capabilities and setup of your systems there might be more clever and/or better fitting solutions... this is a very generic response!

Last but not least - I am a bit curious about the HSM you are using: in my experience current HSMs are really too slow for any crypto operation that is in response to live traffic (modern CPUs outperform them by A LOT). For that reason (and others, actually) it is common, today, to pre-produce all responses and store them in CDNs so that the performance of the HSMs is not an issue (but, of course, you might have a "publishing" window vulnerability in this case).

I hope this helps,

Cheers,
Max


On 4/4/16 4:07 PM, daniel bryan wrote:
Hello,

I am looking for guidance/standards on deploying an OCSP service in specific regards to the key management of the OCSP Signing certificate.

Suppose I have a service, and I want to provide certificate status on 20 different certificate authorities using a "CA Designated responder" described in section 2.2 of RFC 6960. Technically I have a few options:

Option #1: Generate 20 Keys on my HSM, Create 20 PKCS 10s, Submit all 20 for Signing to each CA. Import the Signed Certificate into my OCSP service.

Option #2: Generate 1 Key on the HSM, Create 1 PKCS 10 with a generic CN, Submit 1 CSR to all 20 CA's. The CA will override the CN value during Signing to reference their CA name, Import all 20 Signed certificates into my OCSP service.

Option #1 adds complexity to key management, could potentially have an impact on signing speed. An advantage is that if a key is lost/compromised, it would only involve troubling one CA instead of all.

Option #2 will greatly simplify key management, and I speculate it will increase the signing speed potential of the HSM, being that it doesn't have to determine which key to use from a pool of 20 keys. Obviously the bad side is, if we ever loose the key, I would have to get all 20 CAs to sign another request. This is especially bad when the certs have the noCheck extension.


Here are my 2 questions:

Q1: From a security perspective, is option #2 worth considering. Simplification is a huge priority, but security is a must.

Q2: Does the IETF/cabforum/Any other authority provide guidance/standards on key management in this situation that I can use to support/defend the choice?

Thanks,

--Dan


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


-- 
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca
--------------070009070903050108000802-- From nobody Tue Apr 5 10:30:46 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@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: [pkix] [smime] Support for email address internationalization in RFC5280 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX 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 10:32:04 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C8A12D74E for ; Tue, 5 Apr 2016 10:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_NAME_DR=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 TQrixuwQwEIA for ; Tue, 5 Apr 2016 10:32:01 -0700 (PDT) Received: from mail.katezarealty.com (cvps8815162906.hostwindsdns.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 981D312D8E3 for ; Tue, 5 Apr 2016 10:31:58 -0700 (PDT) Received: from iMassi.local (unknown [IPv6:2001:67c:1231:998:b4eb:f1f4:3a02:7256]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id C4C273743F8C for ; Tue, 5 Apr 2016 09:53:47 -0400 (EDT) From: "Dr. Pala" To: pkix@ietf.org References: Organization: OpenCA Labs Message-ID: <5703C369.7080700@openca.org> Date: Tue, 5 Apr 2016 10:53:45 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080100090503050401040304" Archived-At: Subject: Re: [pkix] OCSP Signing Certificate Key usage standards X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 17:32:03 -0000 This is a multi-part message in MIME format. --------------080100090503050401040304 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Daniel, personally, as long as the key is properly protected (and you are using HSMs for that - so it should be ok) and rotated (limited lifetime) and you have an easy way to request the different certificates from the different CAs (hopefully you have an automated interface to them), I would go with Option #2 - this simplifies key management as you said. However, this comes with a price on security in case the key is compromised - in this case, you will have to revoke 20 certificates at once and get a new certificate for all the 20 CAs you are serving. For this, the "automation" for getting the certificate and have the old ones revoked is a key feature, IMHO. To address the last point, my suggestion would be to play ahead. Have 2 different keys and have certificates issued for both of them. Use one key in production and keep the other one in a safe place (separate form the deployment one). Then setup a procedure to switch the keys when needed - this allows you to stop using a compromised key without having to wait for the 20 (or more) CAs to process your revocation and new certificate requests which can now be processed in parallel. (This said, clients will continue to trust the compromised key until the proper revocation is provided by the different CAs - but that is true for both options) If you value simplicity, this might provide you with an easy implementation and yet gives you the ability to respond quickly. Of course, not knowing the capabilities and setup of your systems there might be more clever and/or better fitting solutions... this is a very generic response! Last but not least - I am a bit curious about the HSM you are using: in my experience current HSMs are really too slow for any crypto operation that is in response to live traffic (modern CPUs outperform them by A LOT). For that reason (and others, actually) it is common, today, to pre-produce all responses and store them in CDNs so that the performance of the HSMs is not an issue (but, of course, you might have a "publishing" window vulnerability in this case). I hope this helps, Cheers, Max On 4/4/16 4:07 PM, daniel bryan wrote: > Hello, > > I am looking for guidance/standards on deploying an OCSP service in > specific regards to the key management of the OCSP Signing certificate. > > Suppose I have a service, and I want to provide certificate status on > 20 different certificate authorities using a "CA Designated responder" > described in section 2.2 of RFC 6960. Technically I have a few options: > > *Option #1:* Generate 20 Keys on my HSM, Create 20 PKCS 10s, Submit > all 20 for Signing to each CA. Import the Signed Certificate into my > OCSP service. > > *Option #2:* Generate 1 Key on the HSM, Create 1 PKCS 10 with a > generic CN, Submit 1 CSR to all 20 CA's. The CA will override the CN > value during Signing to reference their CA name, Import all 20 Signed > certificates into my OCSP service. > > Option #1 adds complexity to key management, could potentially have an > impact on signing speed. An advantage is that if a key is > lost/compromised, it would only involve troubling one CA instead of all. > > Option #2 will greatly simplify key management, and I speculate it > will increase the signing speed potential of the HSM, being that it > doesn't have to determine which key to use from a pool of 20 keys. > Obviously the bad side is, if we ever loose the key, I would have to > get all 20 CAs to sign another request. This is especially bad when > the certs have the noCheck extension. > > > Here are my 2 questions: > > *Q1:* From a security perspective, is option #2 worth considering. > Simplification is a huge priority, but security is a must. > * > Q2:* Does the IETF/cabforum/Any other authority provide > guidance/standards on key management in this situation that I can use > to support/defend the choice? > > Thanks, > > --Dan > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > -- > Massimiliano Pala, PhD > Director at OpenCA Labs > twitter: @openca --------------080100090503050401040304 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Daniel,

personally, as long as the key is properly protected (and you are using HSMs for that - so it should be ok) and rotated (limited lifetime) and you have an easy way to request the different certificates from the different CAs (hopefully you have an automated interface to them), I would go with Option #2 - this simplifies key management as you said.

However, this comes with a price on security in case the key is compromised - in this case, you will have to revoke 20 certificates at once and get a new certificate for all the 20 CAs you are serving. For this, the "automation" for getting the certificate and have the old ones revoked is a key feature, IMHO.

To address the last point, my suggestion would be to play ahead. Have 2 different keys and have certificates issued for both of them. Use one key in production and keep the other one in a safe place (separate form the deployment one). Then setup a procedure to switch the keys when needed - this allows you to stop using a compromised key without having to wait for the 20 (or more) CAs to process your revocation and new certificate requests which can now be processed in parallel. (This said, clients will continue to trust the compromised key until the proper revocation is provided by the different CAs - but that is true for both options)

If you value simplicity, this might provide you with an easy implementation and yet gives you the ability to respond quickly. Of course, not knowing the capabilities and setup of your systems there might be more clever and/or better fitting solutions... this is a very generic response!

Last but not least - I am a bit curious about the HSM you are using: in my experience current HSMs are really too slow for any crypto operation that is in response to live traffic (modern CPUs outperform them by A LOT). For that reason (and others, actually) it is common, today, to pre-produce all responses and store them in CDNs so that the performance of the HSMs is not an issue (but, of course, you might have a "publishing" window vulnerability in this case).

I hope this helps,

Cheers,
Max


On 4/4/16 4:07 PM, daniel bryan wrote:
Hello,

I am looking for guidance/standards on deploying an OCSP service in specific regards to the key management of the OCSP Signing certificate.

Suppose I have a service, and I want to provide certificate status on 20 different certificate authorities using a "CA Designated responder" described in section 2.2 of RFC 6960. Technically I have a few options:

Option #1: Generate 20 Keys on my HSM, Create 20 PKCS 10s, Submit all 20 for Signing to each CA. Import the Signed Certificate into my OCSP service.

Option #2: Generate 1 Key on the HSM, Create 1 PKCS 10 with a generic CN, Submit 1 CSR to all 20 CA's. The CA will override the CN value during Signing to reference their CA name, Import all 20 Signed certificates into my OCSP service.

Option #1 adds complexity to key management, could potentially have an impact on signing speed. An advantage is that if a key is lost/compromised, it would only involve troubling one CA instead of all.

Option #2 will greatly simplify key management, and I speculate it will increase the signing speed potential of the HSM, being that it doesn't have to determine which key to use from a pool of 20 keys. Obviously the bad side is, if we ever loose the key, I would have to get all 20 CAs to sign another request. This is especially bad when the certs have the noCheck extension.


Here are my 2 questions:

Q1: From a security perspective, is option #2 worth considering. Simplification is a huge priority, but security is a must.

Q2: Does the IETF/cabforum/Any other authority provide guidance/standards on key management in this situation that I can use to support/defend the choice?

Thanks,

--Dan


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


-- 
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca
--------------080100090503050401040304-- From nobody Tue Apr 5 10:37:02 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887BE12D645 for ; Tue, 5 Apr 2016 10:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_NAME_DR=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 qdp5Bsc1NcW8 for ; Tue, 5 Apr 2016 10:36:58 -0700 (PDT) Received: from mail.katezarealty.com (cvps8815162906.hostwindsdns.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3EF12D53D for ; Tue, 5 Apr 2016 10:36:58 -0700 (PDT) Received: from iMassi.local (unknown [IPv6:2001:67c:1231:998:b4eb:f1f4:3a02:7256]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 7D5E03743B78 for ; Tue, 5 Apr 2016 09:57:12 -0400 (EDT) From: "Dr. Pala" To: pkix@ietf.org References: Organization: OpenCA Labs Message-ID: <5703C436.70207@openca.org> Date: Tue, 5 Apr 2016 10:57:10 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------060207060208040903040000" Archived-At: Subject: Re: [pkix] OCSP Signing Certificate Key usage standards X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 17:37:00 -0000 This is a multi-part message in MIME format. --------------060207060208040903040000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Daniel, personally, as long as the key is properly protected (and you are using HSMs for that - so it should be ok) and rotated (limited lifetime) and you have an easy way to request the different certificates from the different CAs (hopefully you have an automated interface to them), I would go with Option #2 - this simplifies key management as you said. However, this comes with a price on security in case the key is compromised - in this case, you will have to revoke 20 certificates at once and get a new certificate for all the 20 CAs you are serving. For this, the "automation" for getting the certificate and have the old ones revoked is a key feature, IMHO. To address the last point, my suggestion would be to play ahead. Have 2 different keys and have certificates issued for both of them. Use one key in production and keep the other one in a safe place (separate form the deployment one). Then setup a procedure to switch the keys when needed - this allows you to stop using a compromised key without having to wait for the 20 (or more) CAs to process your revocation and new certificate requests which can now be processed in parallel. (This said, clients will continue to trust the compromised key until the proper revocation is provided by the different CAs - but that is true for both options) If you value simplicity, this might provide you with an easy implementation and yet gives you the ability to respond quickly. Of course, not knowing the capabilities and setup of your systems there might be more clever and/or better fitting solutions... this is a very generic response! Last but not least - I am a bit curious about the HSM you are using: in my experience current HSMs are really too slow for any crypto operation that is in response to live traffic (modern CPUs outperform them by A LOT). For that reason (and others, actually) it is common, today, to pre-produce all responses and store them in CDNs so that the performance of the HSMs is not an issue (but, of course, you might have a "publishing" window vulnerability in this case). I hope this helps, Cheers, Max On 4/4/16 4:07 PM, daniel bryan wrote: > Hello, > > I am looking for guidance/standards on deploying an OCSP service in > specific regards to the key management of the OCSP Signing certificate. > > Suppose I have a service, and I want to provide certificate status on > 20 different certificate authorities using a "CA Designated responder" > described in section 2.2 of RFC 6960. Technically I have a few options: > > *Option #1:* Generate 20 Keys on my HSM, Create 20 PKCS 10s, Submit > all 20 for Signing to each CA. Import the Signed Certificate into my > OCSP service. > > *Option #2:* Generate 1 Key on the HSM, Create 1 PKCS 10 with a > generic CN, Submit 1 CSR to all 20 CA's. The CA will override the CN > value during Signing to reference their CA name, Import all 20 Signed > certificates into my OCSP service. > > Option #1 adds complexity to key management, could potentially have an > impact on signing speed. An advantage is that if a key is > lost/compromised, it would only involve troubling one CA instead of all. > > Option #2 will greatly simplify key management, and I speculate it > will increase the signing speed potential of the HSM, being that it > doesn't have to determine which key to use from a pool of 20 keys. > Obviously the bad side is, if we ever loose the key, I would have to > get all 20 CAs to sign another request. This is especially bad when > the certs have the noCheck extension. > > > Here are my 2 questions: > > *Q1:* From a security perspective, is option #2 worth considering. > Simplification is a huge priority, but security is a must. > * > Q2:* Does the IETF/cabforum/Any other authority provide > guidance/standards on key management in this situation that I can use > to support/defend the choice? > > Thanks, > > --Dan > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > -- > Massimiliano Pala, PhD > Director at OpenCA Labs > twitter: @openca --------------060207060208040903040000 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Daniel,

personally, as long as the key is properly protected (and you are using HSMs for that - so it should be ok) and rotated (limited lifetime) and you have an easy way to request the different certificates from the different CAs (hopefully you have an automated interface to them), I would go with Option #2 - this simplifies key management as you said.

However, this comes with a price on security in case the key is compromised - in this case, you will have to revoke 20 certificates at once and get a new certificate for all the 20 CAs you are serving. For this, the "automation" for getting the certificate and have the old ones revoked is a key feature, IMHO.

To address the last point, my suggestion would be to play ahead. Have 2 different keys and have certificates issued for both of them. Use one key in production and keep the other one in a safe place (separate form the deployment one). Then setup a procedure to switch the keys when needed - this allows you to stop using a compromised key without having to wait for the 20 (or more) CAs to process your revocation and new certificate requests which can now be processed in parallel. (This said, clients will continue to trust the compromised key until the proper revocation is provided by the different CAs - but that is true for both options)

If you value simplicity, this might provide you with an easy implementation and yet gives you the ability to respond quickly. Of course, not knowing the capabilities and setup of your systems there might be more clever and/or better fitting solutions... this is a very generic response!

Last but not least - I am a bit curious about the HSM you are using: in my experience current HSMs are really too slow for any crypto operation that is in response to live traffic (modern CPUs outperform them by A LOT). For that reason (and others, actually) it is common, today, to pre-produce all responses and store them in CDNs so that the performance of the HSMs is not an issue (but, of course, you might have a "publishing" window vulnerability in this case).

I hope this helps,

Cheers,
Max


On 4/4/16 4:07 PM, daniel bryan wrote:
Hello,

I am looking for guidance/standards on deploying an OCSP service in specific regards to the key management of the OCSP Signing certificate.

Suppose I have a service, and I want to provide certificate status on 20 different certificate authorities using a "CA Designated responder" described in section 2.2 of RFC 6960. Technically I have a few options:

Option #1: Generate 20 Keys on my HSM, Create 20 PKCS 10s, Submit all 20 for Signing to each CA. Import the Signed Certificate into my OCSP service.

Option #2: Generate 1 Key on the HSM, Create 1 PKCS 10 with a generic CN, Submit 1 CSR to all 20 CA's. The CA will override the CN value during Signing to reference their CA name, Import all 20 Signed certificates into my OCSP service.

Option #1 adds complexity to key management, could potentially have an impact on signing speed. An advantage is that if a key is lost/compromised, it would only involve troubling one CA instead of all.

Option #2 will greatly simplify key management, and I speculate it will increase the signing speed potential of the HSM, being that it doesn't have to determine which key to use from a pool of 20 keys. Obviously the bad side is, if we ever loose the key, I would have to get all 20 CAs to sign another request. This is especially bad when the certs have the noCheck extension.


Here are my 2 questions:

Q1: From a security perspective, is option #2 worth considering. Simplification is a huge priority, but security is a must.

Q2: Does the IETF/cabforum/Any other authority provide guidance/standards on key management in this situation that I can use to support/defend the choice?

Thanks,

--Dan


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


-- 
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca
--------------060207060208040903040000-- From nobody Tue Apr 5 10:37:16 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4741912D612 for ; Tue, 5 Apr 2016 10:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_NAME_DR=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 ndCUBzuQh-dU for ; Tue, 5 Apr 2016 10:36:58 -0700 (PDT) Received: from mail.katezarealty.com (cvps8815162906.hostwindsdns.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 7545112D119 for ; Tue, 5 Apr 2016 10:36:58 -0700 (PDT) Received: from iMassi.local (unknown [IPv6:2001:67c:1231:998:b4eb:f1f4:3a02:7256]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 19C2837412B2 for ; Tue, 5 Apr 2016 09:39:33 -0400 (EDT) From: "Dr. Pala" To: pkix@ietf.org References: Organization: OpenCA Labs Message-ID: <5703C014.9060306@openca.org> Date: Tue, 5 Apr 2016 10:39:32 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040206090509090103040703" Archived-At: Subject: Re: [pkix] OCSP Signing Certificate Key usage standards X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 17:37:05 -0000 This is a multi-part message in MIME format. --------------040206090509090103040703 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Daniel, personally, as long as the key is properly protected (and you are using HSMs for that - so it should be ok) and rotated (limited lifetime) and you have an easy way to request the different certificates from the different CAs (hopefully you have an automated interface to them), I would go with Option #2 - this simplifies key management as you said. However, this comes with a price on security in case the key is compromised - in this case, you will have to revoke 20 certificates at once and get a new certificate for all the 20 CAs you are serving. For this, the "automation" for getting the certificate and have the old ones revoked is a key feature, IMHO. To address the last point, my suggestion would be to play ahead. Have 2 different keys and have certificates issued for both of them. Use one key in production and keep the other one in a safe place (separate form the deployment one). Then setup a procedure to switch the keys when needed - this allows you to stop using a compromised key without having to wait for the 20 (or more) CAs to process your revocation and new certificate requests which can now be processed in parallel. (This said, clients will continue to trust the compromised key until the proper revocation is provided by the different CAs - but that is true for both options) If you value simplicity, this might provide you with an easy implementation and yet gives you the ability to respond quickly. Of course, not knowing the capabilities and setup of your systems there might be more clever and/or better fitting solutions... this is a very generic response! Last but not least - I am a bit curious about the HSM you are using: in my experience current HSMs are really too slow for any crypto operation that is in response to live traffic (modern CPUs outperform them by A LOT). For that reason (and others, actually) it is common, today, to pre-produce all responses and store them in CDNs so that the performance of the HSMs is not an issue (but, of course, you might have a "publishing" window vulnerability in this case). I hope this helps, Cheers, Max On 4/4/16 4:07 PM, daniel bryan wrote: > Hello, > > I am looking for guidance/standards on deploying an OCSP service in > specific regards to the key management of the OCSP Signing certificate. > > Suppose I have a service, and I want to provide certificate status on > 20 different certificate authorities using a "CA Designated responder" > described in section 2.2 of RFC 6960. Technically I have a few options: > > *Option #1:* Generate 20 Keys on my HSM, Create 20 PKCS 10s, Submit > all 20 for Signing to each CA. Import the Signed Certificate into my > OCSP service. > > *Option #2:* Generate 1 Key on the HSM, Create 1 PKCS 10 with a > generic CN, Submit 1 CSR to all 20 CA's. The CA will override the CN > value during Signing to reference their CA name, Import all 20 Signed > certificates into my OCSP service. > > Option #1 adds complexity to key management, could potentially have an > impact on signing speed. An advantage is that if a key is > lost/compromised, it would only involve troubling one CA instead of all. > > Option #2 will greatly simplify key management, and I speculate it > will increase the signing speed potential of the HSM, being that it > doesn't have to determine which key to use from a pool of 20 keys. > Obviously the bad side is, if we ever loose the key, I would have to > get all 20 CAs to sign another request. This is especially bad when > the certs have the noCheck extension. > > > Here are my 2 questions: > > *Q1:* From a security perspective, is option #2 worth considering. > Simplification is a huge priority, but security is a must. > * > Q2:* Does the IETF/cabforum/Any other authority provide > guidance/standards on key management in this situation that I can use > to support/defend the choice? > > Thanks, > > --Dan > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > -- > Massimiliano Pala, PhD > Director at OpenCA Labs > twitter: @openca --------------040206090509090103040703 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Daniel,

personally, as long as the key is properly protected (and you are using HSMs for that - so it should be ok) and rotated (limited lifetime) and you have an easy way to request the different certificates from the different CAs (hopefully you have an automated interface to them), I would go with Option #2 - this simplifies key management as you said.

However, this comes with a price on security in case the key is compromised - in this case, you will have to revoke 20 certificates at once and get a new certificate for all the 20 CAs you are serving. For this, the "automation" for getting the certificate and have the old ones revoked is a key feature, IMHO.

To address the last point, my suggestion would be to play ahead. Have 2 different keys and have certificates issued for both of them. Use one key in production and keep the other one in a safe place (separate form the deployment one). Then setup a procedure to switch the keys when needed - this allows you to stop using a compromised key without having to wait for the 20 (or more) CAs to process your revocation and new certificate requests which can now be processed in parallel. (This said, clients will continue to trust the compromised key until the proper revocation is provided by the different CAs - but that is true for both options)

If you value simplicity, this might provide you with an easy implementation and yet gives you the ability to respond quickly. Of course, not knowing the capabilities and setup of your systems there might be more clever and/or better fitting solutions... this is a very generic response!

Last but not least - I am a bit curious about the HSM you are using: in my experience current HSMs are really too slow for any crypto operation that is in response to live traffic (modern CPUs outperform them by A LOT). For that reason (and others, actually) it is common, today, to pre-produce all responses and store them in CDNs so that the performance of the HSMs is not an issue (but, of course, you might have a "publishing" window vulnerability in this case).

I hope this helps,

Cheers,
Max


On 4/4/16 4:07 PM, daniel bryan wrote:
Hello,

I am looking for guidance/standards on deploying an OCSP service in specific regards to the key management of the OCSP Signing certificate.

Suppose I have a service, and I want to provide certificate status on 20 different certificate authorities using a "CA Designated responder" described in section 2.2 of RFC 6960. Technically I have a few options:

Option #1: Generate 20 Keys on my HSM, Create 20 PKCS 10s, Submit all 20 for Signing to each CA. Import the Signed Certificate into my OCSP service.

Option #2: Generate 1 Key on the HSM, Create 1 PKCS 10 with a generic CN, Submit 1 CSR to all 20 CA's. The CA will override the CN value during Signing to reference their CA name, Import all 20 Signed certificates into my OCSP service.

Option #1 adds complexity to key management, could potentially have an impact on signing speed. An advantage is that if a key is lost/compromised, it would only involve troubling one CA instead of all.

Option #2 will greatly simplify key management, and I speculate it will increase the signing speed potential of the HSM, being that it doesn't have to determine which key to use from a pool of 20 keys. Obviously the bad side is, if we ever loose the key, I would have to get all 20 CAs to sign another request. This is especially bad when the certs have the noCheck extension.


Here are my 2 questions:

Q1: From a security perspective, is option #2 worth considering. Simplification is a huge priority, but security is a must.

Q2: Does the IETF/cabforum/Any other authority provide guidance/standards on key management in this situation that I can use to support/defend the choice?

Thanks,

--Dan


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


-- 
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca
--------------040206090509090103040703-- From nobody Tue Apr 5 12:04:49 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DA512D9B3 for ; Tue, 5 Apr 2016 12:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYWyq8BzArvS for ; Tue, 5 Apr 2016 12:04:44 -0700 (PDT) Received: from mail-pf0-f179.google.com (mail-pf0-f179.google.com [209.85.192.179]) (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 C47D712DA1C for ; Tue, 5 Apr 2016 12:02:50 -0700 (PDT) Received: by mail-pf0-f179.google.com with SMTP id n1so16288923pfn.2 for ; Tue, 05 Apr 2016 12:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=KZFkNUfqHRJOOOkzcZ/+73yfklW3pA2LkKF1+fsMe+o=; b=L7Bu3rTEwpjEzXEx85jeqyGwDvrpJ3uctfUNzA0cIxhqFRmuEE+At3aNZJadoWcdKL VWclp+dFz8gOwjmDpnyU07Tq9jx6LlQYsTsiJN81upd/upHBf5Wlvg/QraMaGHFKLkQD lXUTvlzo/xAY5LSypOtjJscXL2NWy8KP3+Y4d6+UJctURXeCRPWQikY6m2tIQSUNrry7 Z1WhPf2dcTVuyUX+samiRGN6kbX/VSbsqZsidOeY/UklDnJ9TBBNfxGTZ/9QXWDcYqcB 3Sgriz5bK5Ts5W+a0q06F45zaq5ilERb5kQzUN34pFiti7vsmvZ1iuq3WrS0LJhs67pA qT9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=KZFkNUfqHRJOOOkzcZ/+73yfklW3pA2LkKF1+fsMe+o=; b=iKxkigUXL2tzOkTAZ9DQeB/geqJKdSuRP9U1kpVquMqLu2k6Z72F38itliFtYwQ5fS +n5qhs5cYEcLp4WxioTTJUzrV5OTANJHrMbthSvU4fS0Ht0rburEmR/CwiofW5g0yLaY w6CuGdOv5SG70aIrnHrHvtzUGNMNfruWCdtbSTwWLahaLbrB774gZ1xyNYSMwRFc7LoH h9NTCRaYKA5P/Ez4IeDQjoeIfkzaeBT4O/q87/HAPfRjk9hurjisVT731RPlXyan3sR7 o9YNQmY1n/gwCe5ErMS2x1hCSjVFIAvGQa1+ZUDaVWlMlN+VjwJhlrAhegXOdB/9dleV a7tA== X-Gm-Message-State: AD7BkJJcZzM/l47iNB8RSi8lbapSs50GAmqVPnO+NpMjD1DTaQpfWPjLJJ+gkzcYcRqA0VeMHNVvjsQH+MlYkw== X-Received: by 10.98.71.70 with SMTP id u67mr32232181pfa.85.1459882669964; Tue, 05 Apr 2016 11:57:49 -0700 (PDT) MIME-Version: 1.0 References: <5703C014.9060306@openca.org> In-Reply-To: <5703C014.9060306@openca.org> From: daniel bryan Date: Tue, 05 Apr 2016 18:57:40 +0000 Message-ID: To: "Dr. Pala" , pkix@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0bac7ef50768052fc16b18 Archived-At: Subject: Re: [pkix] OCSP Signing Certificate Key usage standards X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 19:04:47 -0000 --94eb2c0bac7ef50768052fc16b18 Content-Type: text/plain; charset=UTF-8 Max, thanks for the info. I think you brought up some great points, and I agree that auto enrollment would save lots of time during the re-key. I also appreciate you sharing the idea of having a spare key on standby in a separate secure location. Do you typically use the noCheck extension on OCSP Signing certificates? I imagine if you don't revocation loops could be introduced in your PKI. I also agree with you that HSMs are slower then modern CPUs for real time crypto operations, and it's important to use pre-computed responses, e-tags, stapling, anything to offload the OCSP/HSM. Sometimes a client needs high assurance of real time status and forces a a signing operation by sending a nonce in the request. Is this what you meant when you says "publishing window vulnerability"? In my opinion anything you can do to increase the signing speed potential seems beneficial. Thanks again for the info, and for openca! On Tue, Apr 5, 2016 at 1:37 PM Dr. Pala wrote: > Hi Daniel, > > personally, as long as the key is properly protected (and you are using > HSMs for that - so it should be ok) and rotated (limited lifetime) and you > have an easy way to request the different certificates from the different > CAs (hopefully you have an automated interface to them), I would go with > Option #2 - this simplifies key management as you said. > > However, this comes with a price on security in case the key is > compromised - in this case, you will have to revoke 20 certificates at once > and get a new certificate for all the 20 CAs you are serving. For this, the > "automation" for getting the certificate and have the old ones revoked is a > key feature, IMHO. > > To address the last point, my suggestion would be to play ahead. Have 2 > different keys and have certificates issued for both of them. Use one key > in production and keep the other one in a safe place (separate form the > deployment one). Then setup a procedure to switch the keys when needed - > this allows you to stop using a compromised key without having to wait for > the 20 (or more) CAs to process your revocation and new certificate > requests which can now be processed in parallel. (This said, clients will > continue to trust the compromised key until the proper revocation is > provided by the different CAs - but that is true for both options) > > If you value simplicity, this might provide you with an easy > implementation and yet gives you the ability to respond quickly. Of course, > not knowing the capabilities and setup of your systems there might be more > clever and/or better fitting solutions... this is a very generic response! > > Last but not least - I am a bit curious about the HSM you are using: in my > experience current HSMs are really too slow for any crypto operation that > is in response to live traffic (modern CPUs outperform them by A LOT). For > that reason (and others, actually) it is common, today, to pre-produce all > responses and store them in CDNs so that the performance of the HSMs is not > an issue (but, of course, you might have a "publishing" window > vulnerability in this case). > > I hope this helps, > > Cheers, > Max > > > On 4/4/16 4:07 PM, daniel bryan wrote: > > Hello, > > I am looking for guidance/standards on deploying an OCSP service in > specific regards to the key management of the OCSP Signing certificate. > > Suppose I have a service, and I want to provide certificate status on 20 > different certificate authorities using a "CA Designated responder" > described in section 2.2 of RFC 6960. Technically I have a few options: > > *Option #1:* Generate 20 Keys on my HSM, Create 20 PKCS 10s, Submit all > 20 for Signing to each CA. Import the Signed Certificate into my OCSP > service. > > *Option #2:* Generate 1 Key on the HSM, Create 1 PKCS 10 with a generic > CN, Submit 1 CSR to all 20 CA's. The CA will override the CN value during > Signing to reference their CA name, Import all 20 Signed certificates into > my OCSP service. > > Option #1 adds complexity to key management, could potentially have an > impact on signing speed. An advantage is that if a key is lost/compromised, > it would only involve troubling one CA instead of all. > > Option #2 will greatly simplify key management, and I speculate it will > increase the signing speed potential of the HSM, being that it doesn't have > to determine which key to use from a pool of 20 keys. Obviously the bad > side is, if we ever loose the key, I would have to get all 20 CAs to sign > another request. This is especially bad when the certs have the noCheck > extension. > > > Here are my 2 questions: > > *Q1:* From a security perspective, is option #2 worth considering. > Simplification is a huge priority, but security is a must. > > * Q2:* Does the IETF/cabforum/Any other authority provide > guidance/standards on key management in this situation that I can use to > support/defend the choice? > > Thanks, > > --Dan > > > _______________________________________________ > pkix mailing listpkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix > > > -- > Massimiliano Pala, PhD > Director at OpenCA Labs > twitter: @openca > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --94eb2c0bac7ef50768052fc16b18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Max, thanks for the info. I think you brought up some grea= t points, and I agree that auto enrollment would save lots of time during t= he re-key. I also appreciate you sharing the idea of having a spare key on = standby in a separate secure location.=C2=A0 Do you typically use the noChe= ck extension on OCSP Signing certificates? I imagine if you don't revoc= ation loops could be introduced in your PKI.=C2=A0 I also agree with you th= at HSMs are slower then modern CPUs for real time crypto operations, and it= 's important to use pre-computed responses, e-tags, stapling, anything = to offload the OCSP/HSM. Sometimes a client needs high assurance of real ti= me status and forces a a signing operation by sending a nonce in the reques= t. Is this what you meant when you says "publishing window vulnerabili= ty"? In my opinion anything you can do to increase the signing speed p= otential seems beneficial. Thanks again for the info, and for openca!

On Tue, Apr 5, 2016 at = 1:37 PM Dr. Pala <director@openca= .org> wrote:
Hi Daniel,

personally, as long as the key is properly protected (and you are using HSMs for that - so it should be ok) and rotated (limited lifetime) and you have an easy way to request the different certificates from the different CAs (hopefully you have an automated interface to them), I would go with Option #2 - this simplifies key management as you said.

However, this comes with a price on security in case the key is compromised - in this case, you will have to revoke 20 certificates at once and get a new certificate for all the 20 CAs you are serving. For this, the "automation" for getting the certifica= te and have the old ones revoked is a key feature, IMHO.

To address the last point, my suggestion would be to play ahead. Have 2 different keys and have certificates issued for both of them. Use one key in production and keep the other one in a safe place (separate form the deployment one). Then setup a procedure to switch the keys when needed - this allows you to stop using a compromised key without having to wait for the 20 (or more) CAs to process your revocation and new certificate requests which can now be processed in parallel. (This said, clients will continue to trust the compromised key until the proper revocation is provided by the different CAs - but that is true for both options)

If you value simplicity, this might provide you with an easy implementation and yet gives you the ability to respond quickly. Of course, not knowing the capabilities and setup of your systems there might be more clever and/or better fitting solutions... this is a very generic response!

Last but not least - I am a bit curious about the HSM you are using: in my experience current HSMs are really too slow for any crypto operation that is in response to live traffic (modern CPUs outperform them by A LOT). For that reason (and others, actually) it is common, today, to pre-produce all responses and store them in CDNs so that the performance of the HSMs is not an issue (but, of course, you might have a "publishing" window vulnerability in= this case).

I hope this helps,

Cheers,
Max


On 4/4/16 4:07 PM, daniel bryan wrote:
Hello,

I am looking for guidance/standards on deploying an OCSP service in specific regards to the key management of the OCSP Signing certificate.

Suppose I have a service, and I want to provide certificate status on 20 different certificate authorities using a "CA Designated responder" described in section 2.2 of RFC 6960= . Technically I have a few options:

Option #1: Generate 20 Keys on my HSM, Create 20 PKCS 10s, Submit all 20 for Signing to each CA. Import the Signed Certificate into my OCSP service.

Option #2: Generate 1 Key on the HSM, Create 1 PKCS 10 with a generic CN, Submit 1 CSR to all 20 CA's. The CA will override the CN value during Signing to reference their CA name, Import all 20 Signed certificates into my OCSP service.

Option #1 adds complexity to key management, could potentially have an impact on signing speed. An advantage is that if a key is lost/compromised, it would only involve troubling one CA instead of all.

Option #2 will greatly simplify key management, and I speculate it will increase the signing speed potential of the HSM, being that it doesn't have to determine which key to use from a pool of 20 keys.=C2=A0 Obviously the bad side is, if we ever loose the key, I would have to get all 20 CAs to sign another request. This is especially bad when the certs have the noCheck extension.


Here are my 2 questions:

Q1: From a security perspective, is option #2 worth considering. Simplification is a huge priority, but security is a must.

Q2: Does the IETF/cabforum/Any other authority provide guidance/standards on key management in this situation that I can use to support/defend the choice?

Thanks,

--Dan


_______________________________________________
pkix mailing list
pkix@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/pkix


--=20
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca
_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--94eb2c0bac7ef50768052fc16b18-- From nobody Tue Apr 5 13:14:02 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC8912D181 for ; Tue, 5 Apr 2016 13:13:59 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7I3uCZzdAvfo for ; Tue, 5 Apr 2016 13:13:57 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 BA18A12D7FC for ; Tue, 5 Apr 2016 13:13:48 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id e6so32393087vkh.2 for ; Tue, 05 Apr 2016 13:13:48 -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=Y6Mj9sg1qLI/L2AUeWreodIJgHQeaKLIVlBnv4UdcnDwR2rgbm2p7rlPZHc4wto368 YuNPLynn8lPntml9lTcyrqdcw1m3UuM3ca2jLeWKs+n77ESBt/pqx1Md35JmCwGNGADl ecRrN15XpiWVhYqW90Vt7YWdftYaEucND4LahPrNDtaI7dcXWG22wngOv9bEczOKxR2d HbpwVIDkotecr0sjB5MfyW3Y1EA56yG3eghsuR8B4TX2luikOo3BaHTtJhZBC61hDs+A bdl/NIVEImLYo4J8mjGYd7LdTqZRW4+BX3IaMCVtvV08W6VPTF9HguVToD+TrtSEF9Df 2FtQ== X-Gm-Message-State: AD7BkJILvzDbURs72kQsY4ljHTf5A5eXYbKGULKun9BXM8jSiCB1iQRwK95J2JQiv/mDVD/WwjiV2rLMdEWI8oei 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: [pkix] [smime] Support for email address internationalization in RFC5280 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 20:14:00 -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:30:08 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562CA12D5FD for ; Tue, 5 Apr 2016 16:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (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 t86LJzr0Jww7 for ; Tue, 5 Apr 2016 16:30:05 -0700 (PDT) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (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 DBAA912D5CC for ; Tue, 5 Apr 2016 16:30:03 -0700 (PDT) Received: by mail-oi0-x241.google.com with SMTP id v126so4496142oia.3 for ; Tue, 05 Apr 2016 16:30:03 -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=CZdSaqf7wae0wdvZCkf2a8tDk261uMzGO5tF8M4x6OvofH9z8aP0/qWGXSGnp6VIC+ g4RgiHNUoa4CnrbfjnaPUDfDP9mTJ3t0AG5LaNx+td5qRlSBG6520Nd43FhCnR2FWxE/ TGLZ/pxAOKivby34UP43R6CC8oH25zTvIquazaJzo6B366AvnMk80y1OmkzV7yGt3sw1 0j70O3+p/7ovTyZSvjbQVRQwqOJgg7uQ9xjuRSx0jF2dHGsUVmXl1HBbAv7mAYgENm7L NlzsreK/eV1Mmy5lq6OoNjDh/COLIxAL2fz+UTTDPpwbfoxsJMiax15RGq4ueJMPt8db Bppw== X-Gm-Message-State: AD7BkJIt8konbIpN3CEmJ1ixRz8s+iXmOzo+jLQzvACUZit37EQAPIdhTJD+3lg4+T6xz+Xdls9At8s8RsWG1Q== 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: Cc: IETF SMIME Subject: Re: [pkix] [smime] Support for email address internationalization in RFC5280 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 23:30:07 -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 Tue Apr 5 16:54:11 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@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: [pkix] [smime] Support for email address internationalization in RFC5280 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX 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 02:32:46 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6CF12D0BC for ; Wed, 6 Apr 2016 02:32:44 -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=unavailable 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 EaStqVoBaOHa for ; Wed, 6 Apr 2016 02:32:40 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A4D12D0B6 for ; Wed, 6 Apr 2016 02:32:39 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id w85so50913955oiw.0 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=FqFyL96sKUwvZ04ssEHtHLVMJSEPKRkhLyrouTM5RW9EmfpECyV2910Sfl4bejCL5Z hSqA5t0Ux/9PweD2d6kQ7EQQUTKodLbGuDnb79phtdTEDkNazfQ5ZOV1g4ii6GXWKhcF /+YQbhnRzbSOcxE3R+iuq0phyu+5aBXJys0wF0HRm49iQBp4zCLWk3ZVqJTnRL23FH6J EOXU80sqXqtHSzvlhCiVKGHFk4gEKKabApTLPNaNpapUFa1I2h25d/WWNurJsKekSoYY 46cI6L3PD2jipHXOBA+LaQxatLihEVJpeEXUh2eXNoMrHtHwN/5++lRf+7HdisSTzg8n fQWA== X-Gm-Message-State: AD7BkJL0ue/Adls5oFsTTKeISmKBZbMO6b+jn3OdIAFwY98V7rUetqLEBvA1LiKDEC4mMIx6JfD7ocDHRVXcxA== 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: Cc: IETF PKIX , IETF SMIME Subject: Re: [pkix] [smime] Support for email address internationalization in RFC5280 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 09:32:44 -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 06:49:54 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D771E12D55E for ; Wed, 6 Apr 2016 06:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.13 X-Spam-Level: X-Spam-Status: No, score=-0.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_NAME_DR=1, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] 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 ApF14bzfgdij for ; Wed, 6 Apr 2016 06:49:51 -0700 (PDT) Received: from mail.katezarealty.com (cvps8815162906.hostwindsdns.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 4A41112D555 for ; Wed, 6 Apr 2016 06:49:51 -0700 (PDT) Received: from iMassi.local (unknown [200.61.9.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 0578E37423E8; Wed, 6 Apr 2016 09:49:49 -0400 (EDT) To: daniel bryan , pkix@ietf.org References: <5703C014.9060306@openca.org> From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <570513FB.8000805@openca.org> Date: Wed, 6 Apr 2016 10:49:47 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090907030604080600040800" Archived-At: Subject: Re: [pkix] OCSP Signing Certificate Key usage standards X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 13:49:54 -0000 This is a multi-part message in MIME format. --------------090907030604080600040800 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Daniel, for the noCheck extension - that is a tricky one. In general, it does simplify checks on the client side for sure. The only issue is then that you can not reliably revoke the certificate (although you can stop using it!) in case of compromise. That means that if you plan to use that, you might want to use short-lived certificates for that. In particular, a validity period of 1 or 2 weeks might be a good choice (since no reliable revocation can be put in place). This, of course, depends on how easy is the integration with your CA. I have seen deployments with a 3-6 months validity period for such certificates as well - it all depends on your risk profile. For the "vulnerability window", I refer to the fact that in the pre-computed environments, usually the OCSP will generate all the responses every few hours. So, unless your system makes "exceptions" in case of revocation events (e.g., triggers the generation of the OCSP response for the revoked certificate and its publication on the CDN right away), there might be a delay between the revocation request/event and the publication of the appropriate OCSP response on the CDN (e.g., if the publication happens once every 6 hrs, you might have a "vulnerability window" as big as 6 hrs). Last thing I want to point out is that if you use pre-computed responses (i.e., no NONCE is present that links the response to a specific client request), you are susceptible to reply attacks for the validity of the response. In the pre-computed environment this is bad since even if your system publishes the revoked OCSP response right away after revocation, an attacker could use the original non-revoked response for up to the expiration of the response (which, in the example above, should be greater than 6 hrs). On the other hand, where "real-time" revocation information is needed, the use of short-lived OCSP responses and the use of NONCEs provides better security (which seems what you might need). A mixed solution could be to generate the responses with short validity period (e.g., 5mins) [no NONCE] and cache them for that period. This would allow for better performance (e.g., less signatures required than the NONCE case), at the expense of not being able to leverage CDN deployments (usually needed only for billions of requests per day). Cheers, Max P.S.: Another option to speedup the validation process is to use the CA's certificate as the OCSP responder directly. This removes the requirement of validating a certificate chain (although, as you can imagine, it would be appropriate only for the pre-computed case as you do not want to expose those keys to possible attacks) P.P.S.: Long time ago I promised myself I would publish some I-D about the OCSP-over-DNS idea (pre-computed, but distributed and eliminates the need for large OCSP infrastructures for CAs == lower costs) and its successor that tackles the redundancy of information in the case of "valid" responses (but this requires a new type of response). On 4/5/16 3:57 PM, daniel bryan wrote: > Max, thanks for the info. I think you brought up some great points, > and I agree that auto enrollment would save lots of time during the > re-key. I also appreciate you sharing the idea of having a spare key > on standby in a separate secure location. Do you typically use the > noCheck extension on OCSP Signing certificates? I imagine if you don't > revocation loops could be introduced in your PKI. I also agree with > you that HSMs are slower then modern CPUs for real time crypto > operations, and it's important to use pre-computed responses, e-tags, > stapling, anything to offload the OCSP/HSM. Sometimes a client needs > high assurance of real time status and forces a a signing operation by > sending a nonce in the request. Is this what you meant when you says > "publishing window vulnerability"? In my opinion anything you can do > to increase the signing speed potential seems beneficial. Thanks again > for the info, and for openca! > > On Tue, Apr 5, 2016 at 1:37 PM Dr. Pala > wrote: > > Hi Daniel, > > personally, as long as the key is properly protected (and you are > using HSMs for that - so it should be ok) and rotated (limited > lifetime) and you have an easy way to request the different > certificates from the different CAs (hopefully you have an > automated interface to them), I would go with Option #2 - this > simplifies key management as you said. > > However, this comes with a price on security in case the key is > compromised - in this case, you will have to revoke 20 > certificates at once and get a new certificate for all the 20 CAs > you are serving. For this, the "automation" for getting the > certificate and have the old ones revoked is a key feature, IMHO. > > To address the last point, my suggestion would be to play ahead. > Have 2 different keys and have certificates issued for both of > them. Use one key in production and keep the other one in a safe > place (separate form the deployment one). Then setup a procedure > to switch the keys when needed - this allows you to stop using a > compromised key without having to wait for the 20 (or more) CAs to > process your revocation and new certificate requests which can now > be processed in parallel. (This said, clients will continue to > trust the compromised key until the proper revocation is provided > by the different CAs - but that is true for both options) > > If you value simplicity, this might provide you with an easy > implementation and yet gives you the ability to respond quickly. > Of course, not knowing the capabilities and setup of your systems > there might be more clever and/or better fitting solutions... this > is a very generic response! > > Last but not least - I am a bit curious about the HSM you are > using: in my experience current HSMs are really too slow for any > crypto operation that is in response to live traffic (modern CPUs > outperform them by A LOT). For that reason (and others, actually) > it is common, today, to pre-produce all responses and store them > in CDNs so that the performance of the HSMs is not an issue (but, > of course, you might have a "publishing" window vulnerability in > this case). > > I hope this helps, > > Cheers, > Max > > > On 4/4/16 4:07 PM, daniel bryan wrote: >> Hello, >> >> I am looking for guidance/standards on deploying an OCSP service >> in specific regards to the key management of the OCSP Signing >> certificate. >> >> Suppose I have a service, and I want to provide certificate >> status on 20 different certificate authorities using a "CA >> Designated responder" described in section 2.2 of RFC 6960. >> Technically I have a few options: >> >> *Option #1:* Generate 20 Keys on my HSM, Create 20 PKCS 10s, >> Submit all 20 for Signing to each CA. Import the Signed >> Certificate into my OCSP service. >> >> *Option #2:* Generate 1 Key on the HSM, Create 1 PKCS 10 with a >> generic CN, Submit 1 CSR to all 20 CA's. The CA will override the >> CN value during Signing to reference their CA name, Import all 20 >> Signed certificates into my OCSP service. >> >> Option #1 adds complexity to key management, could potentially >> have an impact on signing speed. An advantage is that if a key is >> lost/compromised, it would only involve troubling one CA instead >> of all. >> >> Option #2 will greatly simplify key management, and I speculate >> it will increase the signing speed potential of the HSM, being >> that it doesn't have to determine which key to use from a pool of >> 20 keys. Obviously the bad side is, if we ever loose the key, I >> would have to get all 20 CAs to sign another request. This is >> especially bad when the certs have the noCheck extension. >> >> >> Here are my 2 questions: >> >> *Q1:* From a security perspective, is option #2 worth >> considering. Simplification is a huge priority, but security is a >> must. >> * >> Q2:* Does the IETF/cabforum/Any other authority provide >> guidance/standards on key management in this situation that I can >> use to support/defend the choice? >> >> Thanks, >> >> --Dan >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> >> -- >> Massimiliano Pala, PhD >> Director at OpenCA Labs >> twitter: @openca > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Massimiliano Pala, PhD Director at OpenCA Labs twitter: @openca --------------090907030604080600040800 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Daniel,

for the noCheck extension - that is a tricky one. In general, it does simplify checks on the client side for sure. The only issue is then that you can not reliably revoke the certificate (although you can stop using it!) in case of compromise. That means that if you plan to use that, you might want to use short-lived certificates for that. In particular, a validity period of 1 or 2 weeks might be a good choice (since no reliable revocation can be put in place). This, of course, depends on how easy is the integration with your CA. I have seen deployments with a 3-6 months validity period for such certificates as well - it all depends on your risk profile.

For the "vulnerability window", I refer to the fact that in the pre-computed environments, usually the OCSP will generate all the responses every few hours. So, unless your system makes "exceptions" in case of revocation events (e.g., triggers the generation of the OCSP response for the revoked certificate and its publication on the CDN right away), there might be a delay between the revocation request/event and the publication of the appropriate OCSP response on the CDN (e.g., if the publication happens once every 6 hrs, you might have a "vulnerability window" as big as 6 hrs).

Last thing I want to point out is that if you use pre-computed responses (i.e., no NONCE is present that links the response to a specific client request), you are susceptible to reply attacks for the validity of the response. In the pre-computed environment this is bad since even if your system publishes the revoked OCSP response right away after revocation, an attacker could use the original non-revoked response for up to the expiration of the response (which, in the example above, should be greater than 6 hrs). On the other hand, where "real-time" revocation information is needed, the use of short-lived OCSP responses and the use of NONCEs provides better security (which seems what you might need).

A mixed solution could be to generate the responses with short validity period (e.g., 5mins) [no NONCE] and cache them for that period. This would allow for better performance (e.g., less signatures required than the NONCE case), at the expense of not being able to leverage CDN deployments (usually needed only for billions of requests per day).

Cheers,
Max

P.S.: Another option to speedup the validation process is to use the CA's certificate as the OCSP responder directly. This removes the requirement of validating a certificate chain (although, as you can imagine, it would be appropriate only for the pre-computed case as you do not want to expose those keys to possible attacks)

P.P.S.: Long time ago I promised myself I would publish some I-D about the OCSP-over-DNS idea (pre-computed, but distributed and eliminates the need for large OCSP infrastructures for CAs == lower costs) and its successor that tackles the redundancy of information in the case of "valid" responses (but this requires a new type of response).


On 4/5/16 3:57 PM, daniel bryan wrote:
Max, thanks for the info. I think you brought up some great points, and I agree that auto enrollment would save lots of time during the re-key. I also appreciate you sharing the idea of having a spare key on standby in a separate secure location.  Do you typically use the noCheck extension on OCSP Signing certificates? I imagine if you don't revocation loops could be introduced in your PKI.  I also agree with you that HSMs are slower then modern CPUs for real time crypto operations, and it's important to use pre-computed responses, e-tags, stapling, anything to offload the OCSP/HSM. Sometimes a client needs high assurance of real time status and forces a a signing operation by sending a nonce in the request. Is this what you meant when you says "publishing window vulnerability"? In my opinion anything you can do to increase the signing speed potential seems beneficial. Thanks again for the info, and for openca!

On Tue, Apr 5, 2016 at 1:37 PM Dr. Pala <director@openca.org> wrote:
Hi Daniel,

personally, as long as the key is properly protected (and you are using HSMs for that - so it should be ok) and rotated (limited lifetime) and you have an easy way to request the different certificates from the different CAs (hopefully you have an automated interface to them), I would go with Option #2 - this simplifies key management as you said.

However, this comes with a price on security in case the key is compromised - in this case, you will have to revoke 20 certificates at once and get a new certificate for all the 20 CAs you are serving. For this, the "automation" for getting the certificate and have the old ones revoked is a key feature, IMHO.

To address the last point, my suggestion would be to play ahead. Have 2 different keys and have certificates issued for both of them. Use one key in production and keep the other one in a safe place (separate form the deployment one). Then setup a procedure to switch the keys when needed - this allows you to stop using a compromised key without having to wait for the 20 (or more) CAs to process your revocation and new certificate requests which can now be processed in parallel. (This said, clients will continue to trust the compromised key until the proper revocation is provided by the different CAs - but that is true for both options)

If you value simplicity, this might provide you with an easy implementation and yet gives you the ability to respond quickly. Of course, not knowing the capabilities and setup of your systems there might be more clever and/or better fitting solutions... this is a very generic response!

Last but not least - I am a bit curious about the HSM you are using: in my experience current HSMs are really too slow for any crypto operation that is in response to live traffic (modern CPUs outperform them by A LOT). For that reason (and others, actually) it is common, today, to pre-produce all responses and store them in CDNs so that the performance of the HSMs is not an issue (but, of course, you might have a "publishing" window vulnerability in this case).

I hope this helps,

Cheers,
Max


On 4/4/16 4:07 PM, daniel bryan wrote:
Hello,

I am looking for guidance/standards on deploying an OCSP service in specific regards to the key management of the OCSP Signing certificate.

Suppose I have a service, and I want to provide certificate status on 20 different certificate authorities using a "CA Designated responder" described in section 2.2 of RFC 6960. Technically I have a few options:

Option #1: Generate 20 Keys on my HSM, Create 20 PKCS 10s, Submit all 20 for Signing to each CA. Import the Signed Certificate into my OCSP service.

Option #2: Generate 1 Key on the HSM, Create 1 PKCS 10 with a generic CN, Submit 1 CSR to all 20 CA's. The CA will override the CN value during Signing to reference their CA name, Import all 20 Signed certificates into my OCSP service.

Option #1 adds complexity to key management, could potentially have an impact on signing speed. An advantage is that if a key is lost/compromised, it would only involve troubling one CA instead of all.

Option #2 will greatly simplify key management, and I speculate it will increase the signing speed potential of the HSM, being that it doesn't have to determine which key to use from a pool of 20 keys.  Obviously the bad side is, if we ever loose the key, I would have to get all 20 CAs to sign another request. This is especially bad when the certs have the noCheck extension.


Here are my 2 questions:

Q1: From a security perspective, is option #2 worth considering. Simplification is a huge priority, but security is a must.

Q2: Does the IETF/cabforum/Any other authority provide guidance/standards on key management in this situation that I can use to support/defend the choice?

Thanks,

--Dan


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


-- 
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca
_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

-- 
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca
--------------090907030604080600040800-- From nobody Wed Apr 6 10:41:24 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@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: [pkix] Room change wasRe: Identified Work Items and Discussion Summary (was: possible new pkix and/or smime work) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX 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:05 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@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: [pkix] [smime] Support for email address internationalization in RFC5280 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX 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 Thu Apr 7 14:28:23 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853FB12D738 for ; Thu, 7 Apr 2016 14:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.106 X-Spam-Level: X-Spam-Status: No, score=-0.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_NAME_DR=1, HTML_MESSAGE=0.001, RDNS_NONE=0.793] 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 7U8K9_Pdd2pK for ; Thu, 7 Apr 2016 14:28:12 -0700 (PDT) Received: from mail.katezarealty.com (unknown [IPv6:2607:5501:1000:1ff::87c4]) by ietfa.amsl.com (Postfix) with ESMTP id E212B12D741 for ; Thu, 7 Apr 2016 14:28:09 -0700 (PDT) Received: from iMassi.local (unknown [IPv6:2001:67c:1231:998:e441:1876:7519:1b0a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id E8FBE3743B5B for ; Thu, 7 Apr 2016 17:28:08 -0400 (EDT) From: "Dr. Pala" To: pkix@ietf.org References: <56FD7597.4020601@cs.tcd.ie> Organization: OpenCA Labs Message-ID: <5706D0E7.6020503@openca.org> Date: Thu, 7 Apr 2016 18:28:07 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56FD7597.4020601@cs.tcd.ie> Content-Type: multipart/alternative; boundary="------------090500070000030402070105" Archived-At: Subject: Re: [pkix] Identified Work Items and Discussion Summary X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:28:19 -0000 This is a multi-part message in MIME format. --------------090500070000030402070105 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi all, I really welcome this initiative - I think there are items that should be worked on and the closing of the pkix prevented any real advancement in the PKIX workspace that definitely impacted the deployment of PKIs and strong authentication (especially client-side). I added some work items that were discussed at the time the WG was closed in the form of comments in the GDocs document. Although I think this could tackle the issue of having "Trust Lists" in applications (e.g., browsers, etc.) - I refrain to add some work items to the document that might be perceived as "boil the pki ocean" (e.g., an infrastructure for discoverability of Internet PKIs - http://dl.acm.org/citation.cfm?id=1750404) at this time and do not want this good initiative to fail because of this... Stephen: thanks for being open to this possibility and start the discussion :-D Looking forward to the meeting later. Cheers, Max On 3/31/16 4:08 PM, Stephen Farrell wrote: > Thanks for doing that. > > What I'm most interested in for now is who would implement and/or > deploy which bits of possible work. So if you can annotate Wei's > document with that kind of information or otherwise make that > clear on the list, that'd be very useful. (Please note that I am > much much more interested if someone says they'd implement, > compared to someone just expressing interest or wishing that > someone else would implement.) > > And separately, I'd like to try get interested folks who'll be > at IETF95 together for a chat if we can. At the moment, either > Monday lunch or Thursday about 8pm (during bits'n'bytes) seem > like they'd work for me. If you'd come along please send a mail > to me, Wei and John Levine and we can see what's likely best. > (If you really like to be involved in that but are remote, do > say so. I'm not sure having many remote folks will work so well > for this kind of discussion but we can try if need be.) > > Cheers, > S. > > PS: I'll be travelling from tomorrow so offline a good bit, > but please keep the discussion going on the list. > > On 31/03/16 19:59, Wei Chuang wrote: >> Hi all, >> >> I've created a Google Docs of the potential work items and discussion >> summary (associated with my personal email account). This will make it >> easy to take comments on the document and incorporate them into the >> document easily. The following link goes to the document: >> https://goo.gl/xXbBoc (i.e. >> https://docs.google.com/document/d/1bZ9BHiw1FvTj1HKEWlfUqe4811KroY_Ottzl3fye-eE/edit?usp=sharing >> which might get split by some email clients) >> >> Here's a link to the help center on how to make a comment in the docs: >> https://support.google.com/docs/answer/65129?co=GENIE. >> Platform%3DDesktop&hl=en >> >> For those who prefer a text document, I've inlined it below. Please use >> the above Google Doc link, because it automates making changes to document. >> >> thanks, >> -Wei >> >> ---------- >> >> IETF PKIX / S/MIME Feb-Mar 2016 >> Work Items >> Potential work list: >> >> >> Short term: >> 1. EKU for intermediate CA certificate >> 2. Manufacturer Usage Description URI certificate extension >> 3. Certificate i18n email address support >> 4. Non authoritative key lookup (see bhjl draft) >> 5. Solving incomplete certificate chains and handing expired certificates >> cleanly on clients >> 6. Adding new S/MIME crypto: AEAD: AES-CCB, AES-GCM, >> AES-CCChaCha20-Poly1305, CRFG ECC Curves >> 7. Deprecate old ciphers e.g. md5, sha1 >> 8. Support for PGP keys in CMS >> 9. Update RFC4134 i.e. S/MIME examples >> 10. drafts >> 1. draft-lear-ietf-pkix-mud-extension-00 >> 2. draft-lbaudoin-iemax-02 >> 3. draft-ietf-pkix-eai-addresses-00 >> 4. draft-bhjl-x509-srv-00 >> 5. Draft-melnikov-smime-msa-to-mda-04 >> >> >> Long term >> 1. Certificate discovery and reenrollment >> 2. Solving email address canonicalization (perhaps via bhjl oracle) >> 3. Header privacy >> 4. Prevent signature stripping attack >> 5. Painless client configuration >> >> >> Even longer term >> 1. Supporting Webmail >> 2. Preventing Spam >> 3. Combining PGP S/MIME >> 4. Email identity >> >> >> ________________ >> >> >> Opinions >> >> >> PKIX Mailing List >> >> >> Strings in certificates: Want clarifications in 5280 regarding strings >> * Date: 18 Jan 16 >> * Issue: Deprecating types; interpretation for DisplayText; Unicode >> normalization; Control Characters; Unicode for rfc882Name >> * Discussion: See X.520 and other documentation >> >> >> EKU for intermediate certificates: Allow EKU in intermediate CA cert to >> allow technical constraints as specified by CABF >> * Start: 4 Feb 16 >> * Issue: Worry significant change since EKU wasnt meant to impact path >> validation; Implementers havent been following path constraints very well; >> Interoperability challenge due to different standards >> * Proposal: New extension; New interpretation; Follow policy OID; other >> answers in archive >> >> >> Is it time for a pkix extensions (or similar) wg? >> * Start: 5 Feb 16 >> * Proposals: Manufacturer cert extension (see lear draft); i18n for cert >> rfc822Name (see lbaudoin, eai-addresses drafts) spawned address discussion >> noted below; S/MIME name matching selector in SignerInfo: case, >> normalization? What about S/MIME WG (stephen farrell)? >> * Issue: S/MIME: biggest problem how to tell senders what they should >> do; successor to S/MIME and PGP?; Enough work for two working group? Or >> just one working group? >> * Drafts: draft-lear-ietf-pkix-mud-extension-00; draft-lbaudoin-iemax-02; >> draft-ietf-pkix-eai-addresses-00.txt >> >> >> Email address matching rules (was Re: Is it time for a pkix extensions (or >> similar) wg?) >> * Start: 6 Feb 16 >> * Issue: email address local part normalization is against RFC5321; Sec 7 >> of RFC5280 needs updating; Security model >> * Proposal: Sender should normalize (see 5750); define rules in DKIM or >> DNS; define OTHER-NAME in cert SAN/IAN in UTF8String with encoding of >> matching rules; Regex SAN/IAN; Formalize security model; Sender does cert >> lookup to find alternate address variant certificate; >> * Note: large discussion by SMTP folks noted below in: Another attempt to >> canonicalize local parts >> * Drafts: draft-bhjl-x509-srv-00 >> >> >> Support for email address internationalization in RFC5280 certificates >> * Start: 4 Feb 16 >> * Draft: draft-lbaudoin-iemax-02.txt (see also >> draft-ietf-pkix-eai-addresses-00) >> * Counter proposal: Consider instead redefining Rfc822Name as CHOICE >> including UTF8String >> >> >> key identities >> * Start: 14 Mar 16 (from tmiller on: why you shouldn't even try to >> canonicalize local parts) >> * Proposal: Verify signature and cert path, TOFU the address FROM/SENDER >> address and remember public key; identify by public key SKID, subsequently >> only verify the signature from the public key; Key roll over >> * Issue: signing?; a priori discovery?; human comprehensible notion of >> identity or name >> >> >> Summary of S/MIME Problems/Issues >> * Start: 11 Mar 16 (from mrex on: another attempt to canonicalize local >> parts) >> * Issues: Incomplete chains; Mail archival problems when certificates >> expire i.e. revalidating signature or decryption due to MUA certificate and >> timestamp management, and lack of help from CAs >> >> >> Another attempt to canonicalize local parts: 3rd party interpretation of >> email address local parts for validation or key discovery is a bad idea >> * Start: 11 Mar 16 >> * Issues: RFC5321 stats only MTA may interpret the local part; MUA UI >> poorly does key management; key structures i.e. key discovery is difficult >> * Proposal: Modernize email address to enable validation; IETF should get >> into standardizing UI particularly for key management; Key discovery via >> oracle >> >> >> e2e email security (stephen farrell) >> * Start: 12 Mar 16 >> * Issues: No MUA development; email environment is centralized; mail >> headers not protected; e2e may prevent anti-spam technology >> * Proposal: allow experimentation >> >> >> Key lookup service via draft-bhjl-x509-srv-00 >> * Start 22 Mar 16 >> * Proposal: Use the draft for key lookup; provides means to do initial >> certificate discovery; authoritative; certificate renewal; oracle for new >> email name variants; >> * Issues: Key management is hard; security risk for automated key >> re-enrollment; security issues with a centralized key directory; handling >> ownership of multiple mailbox; >> * Draft: draft-bhjl-x509-srv-00 >> >> >> BCP proposal: regular expressions for Internet Mail identifiers >> * Start: 22 Mar 16 >> * Proposal: Standardize regex for email addresses >> >> >> S/MIME Mailing List >> >> >> Message takeover attacks against S/MIME >> * Start: 27 Jan 16 >> * Proposal: Adding authenticated encryption to S/MIME; >> * Issues: S/MIME doesnt keep headers private; MUA dont understand >> message/rfc822; attack via signed-then-encrypted message into >> encrypted-then-signed using attackers identity and replies will leak the >> original content >> >> >> Is this enough to re-charter the S/MIME WG? >> * Start: 8 Mar 16 (from housley on Message takeover attacks against >> S/MIME) >> * several folks willing to help; AEAD: AES-CCM, AES-GCM, ChaCha20-Poly1305; >> domain signing; Curve25519 and Curve448, CFRG ECC curves; automated cert >> enrollment; protect mail headers; standardize on RFC5753 i.e.ECC away from >> informational; updated RFC documentation e.g. RFC 4134; drop old ciphers >> e.g. md5, sha1; prevent signature stripping attacks >> * Draft: draft-melnikov-smime-msa-to-mda-04 >> >> >> General S/MIME issues / solutions >> * Start: 29 Jan 16 (from phill on: Message takeover attacks against S/MIME) >> * Proposal: merge PGP and S/MIME; publish consistent modern crypto suit in >> CURDLE; make it work with WebMail; configuration must be painless >> >> >> ---------- Forwarded message ---------- >> From: Stephen Farrell >> Date: Thu, Mar 24, 2016 at 5:28 AM >> Subject: Re: [pkix] possible new pkix and/or smime work >> To: pkix >> >> >> >> I got a couple of volunteers, Wei Chuang and John Levine >> (thanks both!) who're aiming to produce us a summary of >> the recent list discussion we can ponder in a few days. >> >> Cheers, >> S. >> >> On 23/03/16 20:35, Stephen Farrell wrote: >>> Folks, >>> >>> I'm finding it hard to evaluate the discussion as to whether >>> there's new work folks want to do here that'd justify forming >>> a (coherent) WG and that'd result in likely implementation and >>> deployment. I expect others may be similarly uncertain. >>> >>> Would someone be willing to volunteer to act in a slightly >>> chair-like manner and try to summarise the discussion in a >>> way that might help us judge the above? >>> >>> I think that might help us to e.g. organise a bit of a bar >>> BoF or collective chat amongst those interested while a bunch >>> of us are in B-A and on the list prior to that. >>> >>> Thanks, >>> S. >>> >>> PS; If you are willing to do that but shy, feel free to send to >>> me offlist and I can pretend I did the work:-) >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Massimiliano Pala, PhD Director at OpenCA Labs twitter: @openca --------------090500070000030402070105 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi all,

I really welcome this initiative - I think there are items that should be worked on and the closing of the pkix prevented any real advancement in the PKIX workspace that definitely impacted the deployment of PKIs and strong authentication (especially client-side). I added some work items that were discussed at the time the WG was closed in the form of comments in the GDocs document. Although I think this could tackle the issue of having "Trust Lists" in applications (e.g., browsers, etc.) - I refrain to add some work items to the document that might be perceived as "boil the pki ocean" (e.g., an infrastructure for discoverability of Internet PKIs - http://dl.acm.org/citation.cfm?id=1750404) at this time and do not want this good initiative to fail because of this...

Stephen: thanks for being open to this possibility and start the discussion :-D

Looking forward to the meeting later.

Cheers,
Max

On 3/31/16 4:08 PM, Stephen Farrell wrote:
Thanks for doing that.

What I'm most interested in for now is who would implement and/or
deploy which bits of possible work. So if you can annotate Wei's
document with that kind of information or otherwise make that
clear on the list, that'd be very useful. (Please note that I am
much much more interested if someone says they'd implement,
compared to someone just expressing interest or wishing that
someone else would implement.)

And separately, I'd like to try get interested folks who'll be
at IETF95 together for a chat if we can. At the moment, either
Monday lunch or Thursday about 8pm (during bits'n'bytes) seem
like they'd work for me. If you'd come along please send a mail
to me, Wei and John Levine and we can see what's likely best.
(If you really like to be involved in that but are remote, do
say so. I'm not sure having many remote folks will work so well
for this kind of discussion but we can try if need be.)

Cheers,
S.

PS: I'll be travelling from tomorrow so offline a good bit,
but please keep the discussion going on the list.

On 31/03/16 19:59, Wei Chuang wrote:

Hi all,

I've created a Google Docs of the potential work items and discussion
summary (associated with my personal email account).  This will make it
easy to take comments on the document and incorporate them into the
document easily.  The following link goes to the document:
https://goo.gl/xXbBoc (i.e.
https://docs.google.com/document/d/1bZ9BHiw1FvTj1HKEWlfUqe4811KroY_Ottzl3fye-eE/edit?usp=sharing
which might get split by some email clients)

Here's a link to the help center on how to make a comment in the docs:
https://support.google.com/docs/answer/65129?co=GENIE.
Platform%3DDesktop&hl=en

For those who prefer a text document, I've inlined it below.  Please use
the above Google Doc link, because it automates making changes to document.

thanks,
-Wei

----------

IETF PKIX / S/MIME Feb-Mar 2016
Work Items
Potential work list:


Short term:
1. EKU for intermediate CA certificate
2. Manufacturer Usage Description URI certificate extension
3. Certificate i18n email address support
4. Non authoritative key lookup (see bhjl draft)
5. Solving incomplete certificate chains and handing expired certificates
cleanly on clients
6. Adding new S/MIME crypto: AEAD: AES-CCB, AES-GCM,
AES-CCChaCha20-Poly1305, CRFG ECC Curves
7. Deprecate old ciphers e.g. md5, sha1
8. Support for PGP keys in CMS
9. Update RFC4134 i.e. S/MIME examples
10. drafts
   1. draft-lear-ietf-pkix-mud-extension-00
   2. draft-lbaudoin-iemax-02
   3. draft-ietf-pkix-eai-addresses-00
   4. draft-bhjl-x509-srv-00
   5. Draft-melnikov-smime-msa-to-mda-04


Long term
1. Certificate discovery and reenrollment
2. Solving email address canonicalization (perhaps via bhjl oracle)
3. Header privacy
4. Prevent signature stripping attack
5. Painless client configuration


Even longer term
1. Supporting Webmail
2. Preventing Spam
3. Combining PGP S/MIME
4. Email identity


________________


Opinions


PKIX Mailing List


Strings in certificates: Want clarifications in 5280 regarding strings
* Date: 18 Jan 16
* Issue: Deprecating types; interpretation for DisplayText; Unicode
normalization; Control Characters; Unicode for rfc882Name
* Discussion: See X.520 and other documentation


EKU for intermediate certificates: Allow EKU in intermediate CA cert to
allow technical constraints as specified by CABF
* Start: 4 Feb 16
* Issue: Worry significant change since EKU wasnt meant to impact path
validation; Implementers havent been following path constraints very well;
Interoperability challenge due to different standards
* Proposal: New extension; New interpretation; Follow policy OID; other
answers in archive


Is it time for a pkix extensions (or similar) wg?
* Start: 5 Feb 16
* Proposals: Manufacturer cert extension (see lear draft); i18n for cert
rfc822Name (see lbaudoin, eai-addresses drafts) spawned address discussion
noted below; S/MIME name matching selector in SignerInfo: case,
normalization?  What about S/MIME WG (stephen farrell)?
* Issue: S/MIME: biggest problem how to tell senders what they should
do; successor to S/MIME and PGP?; Enough work for two working group? Or
just one working group?
* Drafts:  draft-lear-ietf-pkix-mud-extension-00; draft-lbaudoin-iemax-02;
draft-ietf-pkix-eai-addresses-00.txt


Email address matching rules (was Re: Is it time for a pkix extensions (or
similar) wg?)
* Start: 6 Feb 16
* Issue: email address local part normalization is against RFC5321; Sec 7
of RFC5280 needs updating; Security model
* Proposal: Sender should normalize (see 5750); define rules in DKIM or
DNS; define OTHER-NAME in cert SAN/IAN in UTF8String with encoding of
matching rules; Regex SAN/IAN; Formalize security model; Sender does cert
lookup to find alternate address variant certificate;
* Note: large discussion by SMTP folks noted below in: Another attempt to
canonicalize local parts
* Drafts: draft-bhjl-x509-srv-00


Support for email address internationalization in RFC5280 certificates
* Start: 4 Feb 16
* Draft: draft-lbaudoin-iemax-02.txt (see also
draft-ietf-pkix-eai-addresses-00)
* Counter proposal: Consider instead redefining Rfc822Name as CHOICE
including UTF8String


key identities
* Start: 14 Mar 16 (from tmiller on: why you shouldn't even try to
canonicalize local parts)
* Proposal: Verify signature and cert path, TOFU the address FROM/SENDER
address and remember public key;  identify by public key SKID, subsequently
only verify the signature from the public key; Key roll over
* Issue: signing?; a priori discovery?; human comprehensible notion of
identity or name


Summary of S/MIME Problems/Issues
* Start: 11 Mar 16 (from mrex on: another attempt to canonicalize local
parts)
* Issues: Incomplete chains; Mail archival problems when certificates
expire i.e. revalidating signature or decryption due to MUA certificate and
timestamp management, and lack of help from CAs


Another attempt to canonicalize local parts: 3rd party interpretation of
email address local parts for validation or key discovery  is a bad idea
* Start: 11 Mar 16
* Issues: RFC5321 stats only MTA may interpret the local part; MUA UI
poorly does key management; key structures i.e. key discovery is difficult
* Proposal: Modernize email address to enable validation; IETF should get
into standardizing UI particularly for key management; Key discovery via
oracle


e2e email security (stephen farrell)
* Start: 12 Mar 16
* Issues: No MUA development; email environment is centralized; mail
headers not protected; e2e may prevent anti-spam technology
* Proposal: allow experimentation


Key lookup service via draft-bhjl-x509-srv-00
* Start 22 Mar 16
* Proposal: Use the draft for key lookup; provides means to do initial
certificate discovery; authoritative; certificate renewal; oracle for new
email name variants;
* Issues: Key management is hard; security risk for automated key
re-enrollment; security issues with a centralized key directory; handling
ownership of multiple mailbox;
* Draft: draft-bhjl-x509-srv-00


BCP proposal: regular expressions for Internet Mail identifiers
* Start: 22 Mar 16
* Proposal: Standardize regex for email addresses


S/MIME Mailing List


Message takeover attacks against S/MIME
* Start: 27 Jan 16
* Proposal: Adding authenticated encryption to S/MIME;
* Issues: S/MIME doesnt keep headers private; MUA dont understand
message/rfc822; attack via signed-then-encrypted message into
encrypted-then-signed using attackers identity and replies will leak the
original content


Is this enough to re-charter the S/MIME WG?
* Start: 8 Mar 16 (from housley on Message takeover attacks against
S/MIME)
* several folks willing to help; AEAD: AES-CCM, AES-GCM, ChaCha20-Poly1305;
domain signing; Curve25519 and Curve448, CFRG ECC curves;  automated cert
enrollment; protect mail headers; standardize on RFC5753  i.e.ECC away from
informational; updated RFC documentation e.g. RFC 4134; drop old ciphers
e.g. md5, sha1; prevent signature stripping attacks
* Draft: draft-melnikov-smime-msa-to-mda-04


General S/MIME issues / solutions
* Start: 29 Jan 16 (from phill on: Message takeover attacks against S/MIME)
* Proposal: merge PGP and S/MIME; publish consistent modern crypto suit in
CURDLE; make it work with WebMail; configuration must be painless


---------- Forwarded message ----------
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Thu, Mar 24, 2016 at 5:28 AM
Subject: Re: [pkix] possible new pkix and/or smime work
To: pkix <pkix@ietf.org>



I got a couple of volunteers, Wei Chuang and John Levine
(thanks both!) who're aiming to produce us a summary of
the recent list discussion we can ponder in a few days.

Cheers,
S.

On 23/03/16 20:35, Stephen Farrell wrote:

Folks,

I'm finding it hard to evaluate the discussion as to whether
there's new work folks want to do here that'd justify forming
a (coherent) WG and that'd result in likely implementation and
deployment. I expect others may be similarly uncertain.

Would someone be willing to volunteer to act in a slightly
chair-like manner and try to summarise the discussion in a
way that might help us judge the above?

I think that might help us to e.g. organise a bit of a bar
BoF or collective chat amongst those interested while a bunch
of us are in B-A and on the list prior to that.

Thanks,
S.

PS; If you are willing to do that but shy, feel free to send to
me offlist and I can pretend I did the work:-)




_______________________________________________
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




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



-- 
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca
--------------090500070000030402070105-- From nobody Thu Apr 7 14:44:52 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B3212D719 for ; Thu, 7 Apr 2016 14:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.106 X-Spam-Level: X-Spam-Status: No, score=-0.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_NAME_DR=1, HTML_MESSAGE=0.001, RDNS_NONE=0.793] 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 PWV3pXlFR_bt for ; Thu, 7 Apr 2016 14:44:45 -0700 (PDT) Received: from mail.katezarealty.com (unknown [IPv6:2607:5501:1000:1ff::87c4]) by ietfa.amsl.com (Postfix) with ESMTP id 45F9C12D10C for ; Thu, 7 Apr 2016 14:44:45 -0700 (PDT) Received: from iMassi.local (unknown [IPv6:2001:67c:1231:998:e441:1876:7519:1b0a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 2FF973743B8F for ; Thu, 7 Apr 2016 17:44:39 -0400 (EDT) To: pkix@ietf.org References: <028101d18f60$dd6262e0$982728a0$@augustcellars.com> From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <5706D4C6.5080003@openca.org> Date: Thu, 7 Apr 2016 18:44:38 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <028101d18f60$dd6262e0$982728a0$@augustcellars.com> Content-Type: multipart/alternative; boundary="------------010901020704010300010700" Archived-At: Subject: Re: [pkix] [smime] Support for email address internationalization in RFC5280 certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:44:48 -0000 This is a multi-part message in MIME format. --------------010901020704010300010700 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit +1 On 4/5/16 2:30 PM, 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. > > 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 > > -- > Massimiliano Pala, PhD > Director at OpenCA Labs > twitter: @openca --------------010901020704010300010700 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit +1

On 4/5/16 2:30 PM, 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.

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:

#4Extend 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.)

#5Change 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 aCHOICE {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


-- 
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca
--------------010901020704010300010700-- From nobody Fri Apr 8 08:11:29 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678FC12D901 for ; Fri, 8 Apr 2016 08:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HK_NAME_FM_DR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcprmZldjGAD for ; Fri, 8 Apr 2016 08:11:25 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::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 69CA9127058 for ; Fri, 8 Apr 2016 08:11:25 -0700 (PDT) Received: by mail-qg0-x22b.google.com with SMTP id j35so92690931qge.0 for ; Fri, 08 Apr 2016 08:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version; bh=3eFFFLstAEd1iHlXQzrTkkwOx64alnEU6rhOhUkU69o=; b=y4C36qk0seA6R9Pgt+SCu2ryMcS02eZSWS3ZQTsjdaExgC9IWyYzGfpLf4UnOATpE9 l985r61ljvNXU5H2VZ2XAcWGKLK3i4ncbXGEwYTV4Fwh5atOXaXdE7hfzTyl7W+TguQE jF4EPV5G68ywhRAfi0q+VxVTymlWvzJYoayP70uSLfxpV69OXETa4i8JTm3fgp7btmDQ SoOWop8itjhyNtg1HZvbB3Q2oGcvDk+1DeS2RPiqw6sLfWcdAzZjlWVXYOJqMfVqNKGp 4j2AJyGV7LxNhiOw5BUgHa02GOpralRQ4MYZmXjz8pFTIpMMOCnWF//J2whwEL2zh86C m1Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=3eFFFLstAEd1iHlXQzrTkkwOx64alnEU6rhOhUkU69o=; b=Kuq/vHmNJACZV/Kp7BxQjCxSJgd7TkoL8saPgto/2rYDYynsK5+xsTuGleOBeofAPB jhDE27IIw7/e8Zi46IaiSlQhmzfwKlJYxU/9OO3fatCFXQZgR0FJ+tdYuKt2/DCW4h/a WDDnemGHBo8wfJ4qmRMSBlWJoDKCq39PIRBqiesULpjztTD4ce+jIVKYdg3xX+UF7rAI ixasHQBPcBK51SMjaM9tS1VV+sLKcbFf7OF80PcIx2sCNopdthozF3t38PZco87WR4Mq o/6U59OGvmZ7f3HLlYgbgBXqXe2/RA1huc0ZjE1NY0tl76QkLjba5eZbIuIEINkUcAaW k7NA== X-Gm-Message-State: AD7BkJLPrU1UIoANwtbgi3/PTveB3hXrVRr7tH3y01ktyppy9ambpjJOtNx2OTwcummwOg== X-Received: by 10.140.144.132 with SMTP id 126mr12392654qhq.102.1460128284568; Fri, 08 Apr 2016 08:11:24 -0700 (PDT) Received: from dhcp-abd4.meeting.ietf.org ([2001:67c:370:168:2497:4b17:4497:6e52]) by smtp.googlemail.com with ESMTPSA id s188sm5616904qhc.35.2016.04.08.08.11.23 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 08:11:24 -0700 (PDT) To: "pkix@ietf.org" From: "Dr. Massimiliano Pala" Message-ID: <5707CA1D.40201@gmail.com> Date: Fri, 8 Apr 2016 12:11:25 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------030208080904000806030504" Archived-At: Subject: [pkix] spasm work item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 15:11:28 -0000 This is a multi-part message in MIME format. --------------030208080904000806030504 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, as suggested by Wei - and as discussed with Stephen, I just want to propose a possible short-term work item about publishing OCSP responses in DNS RR. This should be a short work item as we do not change any format for the revocation information. Here's the reference to the I-D: * https://datatracker.ietf.org/doc/draft-pala-odin/ For a longer term work item (if the SPASM WG will succeed in the short-term agenda), I would like to propose revising the OCSP format to allow for more compact per-certificate revocation information to be available to client (sort of Lightweight Revocation Tokens). Cheers, Max --------------030208080904000806030504 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi all,

as suggested by Wei - and as discussed with Stephen, I just want to propose a possible short-term work item about publishing OCSP responses in DNS RR. This should be a short work item as we do not change any format for the revocation information.

Here's the reference to the I-D:
For a longer term work item (if the SPASM WG will succeed in the short-term agenda), I would like to propose revising the OCSP format to allow for more compact per-certificate revocation information to be available to client (sort of Lightweight Revocation Tokens).

Cheers,
Max

--------------030208080904000806030504-- From nobody Fri Apr 8 08:11:42 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8436E12D93B for ; Fri, 8 Apr 2016 08:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.106 X-Spam-Level: X-Spam-Status: No, score=-0.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_NAME_DR=1, HTML_MESSAGE=0.001, RDNS_NONE=0.793] 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 ESD431X-j8Xe for ; Fri, 8 Apr 2016 08:11:38 -0700 (PDT) Received: from mail.katezarealty.com (unknown [IPv6:2607:5501:1000:1ff::87c4]) by ietfa.amsl.com (Postfix) with ESMTP id 81AF612D548 for ; Fri, 8 Apr 2016 08:11:38 -0700 (PDT) Received: from dhcp-abd4.meeting.ietf.org (unknown [IPv6:2001:67c:370:168:2497:4b17:4497:6e52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id EEF6B3740F57 for ; Fri, 8 Apr 2016 11:11:37 -0400 (EDT) To: "pkix@ietf.org" From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <5707CA2B.4060603@openca.org> Date: Fri, 8 Apr 2016 12:11:39 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------050808000609070708080909" Archived-At: Subject: [pkix] spasm work item X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 15:11:41 -0000 This is a multi-part message in MIME format. --------------050808000609070708080909 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, as suggested by Wei - and as discussed with Stephen, I just want to propose a possible short-term work item about publishing OCSP responses in DNS RR. This should be a short work item as we do not change any format for the revocation information. Here's the reference to the I-D: * https://datatracker.ietf.org/doc/draft-pala-odin/ For a longer term work item (if the SPASM WG will succeed in the short-term agenda), I would like to propose revising the OCSP format to allow for more compact per-certificate revocation information to be available to client (sort of Lightweight Revocation Tokens). Cheers, Max --------------050808000609070708080909 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi all,

as suggested by Wei - and as discussed with Stephen, I just want to propose a possible short-term work item about publishing OCSP responses in DNS RR. This should be a short work item as we do not change any format for the revocation information.

Here's the reference to the I-D:
For a longer term work item (if the SPASM WG will succeed in the short-term agenda), I would like to propose revising the OCSP format to allow for more compact per-certificate revocation information to be available to client (sort of Lightweight Revocation Tokens).

Cheers,
Max

--------------050808000609070708080909-- From nobody Wed Apr 13 04:19:43 2016 Return-Path: X-Original-To: pkix@ietf.org Delivered-To: pkix@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC65C12D712; Wed, 13 Apr 2016 04:19:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160413111939.6027.79032.idtracker@ietfa.amsl.com> Date: Wed, 13 Apr 2016 04:19:39 -0700 Archived-At: Subject: [pkix] New Version Notification - draft-wallace-est-alt-challenge-08.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 11:19:40 -0000 A new version (-08) has been submitted for draft-wallace-est-alt-challenge: https://www.ietf.org/internet-drafts/draft-wallace-est-alt-challenge-08.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-wallace-est-alt-challenge/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-wallace-est-alt-challenge-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Thu Apr 14 12:16:57 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFB612DB2C for ; Thu, 14 Apr 2016 12:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dunlop-lello-uk.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 Ocx1rmvoLi_a for ; Thu, 14 Apr 2016 12:16:53 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 ACE5F12DABF for ; Thu, 14 Apr 2016 12:16:52 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id e190so120804506lfe.0 for ; Thu, 14 Apr 2016 12:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dunlop-lello-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=PfAWtCH7c8KfKKHQ9Cc9TRC6WtsIjpMa1sEZM4kWP78=; b=0IkJ7Kt5Sz8hz67QjaSItZ2YUp0jAHzUimTC/GtqnMcUyLN8qR+x3LyK3kKqN7pP2g 4hmAW+7B+HCCWEZocIWKkOSC2Ewcadym6c1H1xgfm9Uu5npuTdESj1DtecXiYUmSzR34 UsQwztxvDwyfhOhCnanD5tC0V4EYzUFfQsvkSxp5MMy5Tb/Vcz2Llx+7lgFmGEbjROzw dUH4tETYu9rz7hhlKCdKo+gk4n8UHAtr0YmHC+i2c/PEdgRQnUTWtpfkWt2Xut9j2X8h ManXEqD28wHdWL21DIUGkJNqx/o+ivNCfbkvElHhRPxf6aOweGdwqIxmdbpi44mNk9j+ q8BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=PfAWtCH7c8KfKKHQ9Cc9TRC6WtsIjpMa1sEZM4kWP78=; b=QI9msyl5HojRaomLd6rIcbCifYNLGzkK2kTzEhbdhtE++j6yiRLymIvH42OhtBjEFr O5kc6X2FBHKh1cFqdrZ+NSa5pLhZgKgCV3TPxAR2GdFNFD414ua8LyGX30Y2BxKU0XId 1CZlTpXaO6nctWm9aQIUbxrYpe1K7vrqip3ppyrQIDJueMVqFp2/p9UDtJTl04ob71dO ElHrnNVVi9KivccxbACb2M1E76SDx12uD7uwpxHkobRd0z0ZoawBDB/NCfb0j8JDOb+X Tgl2Po7hRWRVMjWqBrAUR7gn1RqdWfgbqAsc8qcK1baim/WR3m14xVrx+wsOVPNKLekg GWHA== X-Gm-Message-State: AOPr4FWAOGn4+REYxLxx//aa1lqkVd7bEObn75Wii3pI1tpNS6dFvQsPbzp4L95K8uUqdLIH88OJabY06rQHBpWw MIME-Version: 1.0 X-Received: by 10.25.165.140 with SMTP id o134mr7517538lfe.35.1460661410809; Thu, 14 Apr 2016 12:16:50 -0700 (PDT) Received: by 10.25.27.16 with HTTP; Thu, 14 Apr 2016 12:16:50 -0700 (PDT) Date: Thu, 14 Apr 2016 20:16:50 +0100 Message-ID: From: Phil Lello To: pkix@ietf.org Content-Type: multipart/alternative; boundary=001a11410a0e877012053076bc42 Archived-At: Subject: [pkix] Support for delegate certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 19:16:56 -0000 --001a11410a0e877012053076bc42 Content-Type: text/plain; charset=UTF-8 Hi all, Not sure if this has already been discussed (I couldn't find it), or indeed if this is the most appropriate list, but I have a variation on certificate chains I'd like considered. I have a couple of scenarios in mind where it could be useful for the holder of a certificate, say for *.example.com to act as a CA for issuing certificate to delegates. Examples include: - *.example.com issues a certificate to project1.example.com (to reduce number of admins trusted with wildcard cert) - *.example.com issues a certificate to server.altsvc.com (to support HTTP's Alt-Svc) - *.example.com issues a certificate to J.Smith@example.com, who issues a certificate to www.randompublisher.net The basic principle is that the certificate (as vetted by a public CA) identifies the party responsible for the signed content, but allows generation of certificates for alternate distribution points (or individuals who can do so). This would require explicit changes for libraries supporting protocols such as TLS (assuming the chain verification isn't hopelessly broken) to provide a notification to the client to identify who's behalf the certificate was issued on. I'd like to avoid adding any extra metadata to the delegating certificate, as that would seem to serve no techincal purpose, and simply be an excuse for a public CA to charge more. Does this sound feasible/desirable? The TLS use-case should probably define extra handshake options to guide the server on selecting an appropriate cert/logging a useful error. Best wishes, Phil Lello --001a11410a0e877012053076bc42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi = all,

Not sure if this has already been discussed (I couldn'= ;t find it), or indeed if this is the most appropriate list, but I have a v= ariation on certificate chains I'd like considered.

I have= a couple of scenarios in mind where it could be useful for the holder of a= certificate, say for *.example.com to a= ct as a CA for issuing certificate to delegates. Examples include:

<= /div>=C2=A0 - *.example.com issues a cer= tificate to project1.example.com (to reduce number of admins trusted with wildcard cert)
=C2=A0 -= *.example.com issues a certificate to <= a href=3D"http://server.altsvc.com">server.altsvc.com (to support HTTP&= #39;s Alt-Svc)
=C2=A0 - *.example.c= om issues a certificate to J.Smi= th@example.com, who issues a certificate to www.randompublisher.net

The basic principl= e is that the certificate (as vetted by a public CA) identifies the party r= esponsible for the signed content, but allows generation of certificates fo= r alternate distribution points (or individuals who can do so).

This would require explicit changes for libraries supporting protocols su= ch as TLS (assuming the chain verification isn't hopelessly broken) to = provide a notification to the client to identify who's behalf the certi= ficate was issued on.

I'd like to avoid adding any extra m= etadata to the delegating certificate, as that would seem to serve no techi= ncal purpose, and simply be an excuse for a public CA to charge more.
Does this sound feasible/desirable? The TLS use-case should probabl= y define extra handshake options to guide the server on selecting an approp= riate cert/logging a useful error.

Best wishes,

P= hil Lello
--001a11410a0e877012053076bc42-- From nobody Thu Apr 14 12:53:32 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F1612E2E2 for ; Thu, 14 Apr 2016 12:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.105 X-Spam-Level: X-Spam-Status: No, score=-0.105 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HK_NAME_DR=1, HTML_MESSAGE=0.001, RDNS_NONE=0.793] 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 kIS1ILOlGF8A for ; Thu, 14 Apr 2016 12:53:29 -0700 (PDT) Received: from mail.katezarealty.com (unknown [IPv6:2607:5501:1000:1ff::87c4]) by ietfa.amsl.com (Postfix) with ESMTP id E356F12E2E0 for ; Thu, 14 Apr 2016 12:53:28 -0700 (PDT) Received: from iMassi.local (unknown [63.88.3.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 5237137423E8 for ; Thu, 14 Apr 2016 15:53:28 -0400 (EDT) To: pkix@ietf.org References: From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <570FF537.9090004@openca.org> Date: Thu, 14 Apr 2016 15:53:27 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030807010509000403020606" Archived-At: Subject: Re: [pkix] Support for delegate certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 19:53:30 -0000 This is a multi-part message in MIME format. --------------030807010509000403020606 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Well, we do have two possible solutions for that that would also apply to the case for delegating the use of EV certs in CDN (see the lurk bof @ ietf95): * attribute certificates(https://datatracker.ietf.org/doc/rfc3820/) * proxy certificates (https://datatracker.ietf.org/doc/rfc5755/) both of them have very good practical usages. I would say that the easiest would be the use of Proxy Certificates since it does not require an additional authority. The way I would enforce the check it would be that only the base URL from the EE certificate (e.g., example.com) can be extended. For example, valid URL would be: www.example.com, smtp.example.com, imap.example.com - non valid names would be anything that does not match /\.example\.com$/. For Apache (since it uses OpenSSL) you might be able to set the trust by using an ENV variable to enable validation of proxy certificates - the problem remains the browsers which do not support that out of the box (details in the paper linked below). Actually, I did manage (some time ago) to have a client certificate to be trusted on Firefox by installing the certificate and set it trusted via a simple extension (it seems that the trust flags take precedence - deails in the paper linked below). Take a look at Proxy Certificates - that is probably what you would end-up using (added benefit is that you can have short-lived certificates that use a different key-pair than the original one). Check out this paper we published some (looooong) time ago: * http://cs.dartmouth.edu/~sws/pubs/pss10.pdf Cheers, Max On 4/14/16 3:16 PM, Phil Lello wrote: > Hi all, > > Not sure if this has already been discussed (I couldn't find it), or > indeed if this is the most appropriate list, but I have a variation on > certificate chains I'd like considered. > > I have a couple of scenarios in mind where it could be useful for the > holder of a certificate, say for *.example.com to > act as a CA for issuing certificate to delegates. Examples include: > > - *.example.com issues a certificate to > project1.example.com (to reduce number > of admins trusted with wildcard cert) > - *.example.com issues a certificate to > server.altsvc.com (to support HTTP's Alt-Svc) > - *.example.com issues a certificate to > J.Smith@example.com , who issues a > certificate to www.randompublisher.net > > The basic principle is that the certificate (as vetted by a public CA) > identifies the party responsible for the signed content, but allows > generation of certificates for alternate distribution points (or > individuals who can do so). > > This would require explicit changes for libraries supporting protocols > such as TLS (assuming the chain verification isn't hopelessly broken) > to provide a notification to the client to identify who's behalf the > certificate was issued on. > > I'd like to avoid adding any extra metadata to the delegating > certificate, as that would seem to serve no techincal purpose, and > simply be an excuse for a public CA to charge more. > > Does this sound feasible/desirable? The TLS use-case should probably > define extra handshake options to guide the server on selecting an > appropriate cert/logging a useful error. > > Best wishes, > > Phil Lello > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > -- > Massimiliano Pala, PhD > Director at OpenCA Labs > twitter: @openca --------------030807010509000403020606 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Well,

we do have two possible solutions for that that would also apply to the case for delegating the use of EV certs in CDN (see the lurk bof @ ietf95):

both of them have very good practical usages. I would say that the easiest would be the use of Proxy Certificates since it does not require an additional authority. The way I would enforce the check it would be that only the base URL from the EE certificate (e.g., example.com) can be extended. For example, valid URL would be: www.example.com, smtp.example.com, imap.example.com - non valid names would be anything that does not match /\.example\.com$/.

For Apache (since it uses OpenSSL) you might be able to set the trust by using an ENV variable to enable validation of proxy certificates - the problem remains the browsers which do not support that out of the box (details in the paper linked below).

Actually, I did manage (some time ago) to have a client certificate to be trusted on Firefox by installing the certificate and set it trusted via a simple extension (it seems that the trust flags take precedence - deails in the paper linked below).

Take a look at Proxy Certificates - that is probably what you would end-up using (added benefit is that you can have short-lived certificates that use a different key-pair than the original one).

Check out this paper we published some (looooong) time ago:

Cheers,
Max


On 4/14/16 3:16 PM, Phil Lello wrote:
Hi all,

Not sure if this has already been discussed (I couldn't find it), or indeed if this is the most appropriate list, but I have a variation on certificate chains I'd like considered.

I have a couple of scenarios in mind where it could be useful for the holder of a certificate, say for *.example.com to act as a CA for issuing certificate to delegates. Examples include:

- *.example.com issues a certificate to project1.example.com (to reduce number of admins trusted with wildcard cert)
- *.example.com issues a certificate to server.altsvc.com (to support HTTP's Alt-Svc)
- *.example.com issues a certificate to J.Smith@example.com, who issues a certificate to www.randompublisher.net

The basic principle is that the certificate (as vetted by a public CA) identifies the party responsible for the signed content, but allows generation of certificates for alternate distribution points (or individuals who can do so).

This would require explicit changes for libraries supporting protocols such as TLS (assuming the chain verification isn't hopelessly broken) to provide a notification to the client to identify who's behalf the certificate was issued on.

I'd like to avoid adding any extra metadata to the delegating certificate, as that would seem to serve no techincal purpose, and simply be an excuse for a public CA to charge more.

Does this sound feasible/desirable? The TLS use-case should probably define extra handshake options to guide the server on selecting an appropriate cert/logging a useful error.

Best wishes,

Phil Lello


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


-- 
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca
--------------030807010509000403020606-- From nobody Thu Apr 14 20:04:55 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A003612D110 for ; Thu, 14 Apr 2016 20:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObCsguEX7YU9 for ; Thu, 14 Apr 2016 20:04:53 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC35D12D6AF for ; Thu, 14 Apr 2016 20:04:52 -0700 (PDT) Received: by mail-pa0-x229.google.com with SMTP id fs9so32000022pac.2 for ; Thu, 14 Apr 2016 20:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=gW6yVu/5Cv6gwUHgClO01dPEckWmelKp0XnsU1O98lg=; b=WGkz4IPruwlgY3yqBiZzcJIg81jPyal4ZElF3d3D9xJoEIpRfzvMI/37vTobB5Q7XT piRe5/2qWbzfh0YilePclxCCAH7xXNhklMnYiP+Hz1z8vWS4WhJfJkrp3leU2V1RB6KH x9P+qKem8M0m3lGoLYHxFKfaLeugjuVLgIWWbNp2pFYPPaIS+oIYiFkpk23Yt6eAcfkz MRWKV137c3M6/3sPzP4tdIn9POmqf0M0MTD65A9aIkJ4N2+PpzabislyIRfDIqivqM/u o6UbVZQmLjHNCDUMPIY1FJHEHTcb8dAnArxH2eK7FmssT8/avs++f/9ra3qy4SSZC7HE BKRw== 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=gW6yVu/5Cv6gwUHgClO01dPEckWmelKp0XnsU1O98lg=; b=mNixxRo66O+RcpsNPrZgCiZeyR6BqPhKflKogvYic+BX2YFBtsvab6YUdbACkzfJDy /1HRylAWxj/vf8myDV6lrlfFmxQUuPjUrrbDUqXih+vFkuTR4axNHAC9MHxcifQHGlkC C3WONH9vK9+m9UKlGFEKtYhMuxcUB/0x7qIoDZupopfQgcyMFcG2fW06zhomIVsPYrNC u9mVmZ56cy6Qx5AAFnblB0vfATQekLpf+2OjrZIrfcGEZsw+ftUzGcmCfRFRHMijAQZm ipxfqKLbUHc1L+L4TVUl8V5XeI4ZZsegOChJOG3u3dQ8MQq5gyElxWls/sOoOSXYw4KX 6n6w== X-Gm-Message-State: AOPr4FWYsMe3q4J45d7TWOdqYZhXiAl5D8DWrAgj8Jhod9N92wdkb8PX56ARQG9MubzpQG6cwIjvKuH9na12Uw== MIME-Version: 1.0 X-Received: by 10.66.160.201 with SMTP id xm9mr25996336pab.68.1460689492502; Thu, 14 Apr 2016 20:04:52 -0700 (PDT) Received: by 10.66.74.39 with HTTP; Thu, 14 Apr 2016 20:04:52 -0700 (PDT) In-Reply-To: References: Date: Thu, 14 Apr 2016 20:04:52 -0700 Message-ID: From: Peter Bowen To: Phil Lello Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [pkix] Support for delegate certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 03:04:54 -0000 On Thu, Apr 14, 2016 at 12:16 PM, Phil Lello wrote: > Not sure if this has already been discussed (I couldn't find it), or indeed > if this is the most appropriate list, but I have a variation on certificate > chains I'd like considered. > > I have a couple of scenarios in mind where it could be useful for the holder > of a certificate, say for *.example.com to act as a CA for issuing > certificate to delegates. Examples include: > > - *.example.com issues a certificate to project1.example.com (to reduce > number of admins trusted with wildcard cert) > - *.example.com issues a certificate to server.altsvc.com (to support > HTTP's Alt-Svc) > - *.example.com issues a certificate to J.Smith@example.com, who issues a > certificate to www.randompublisher.net > > The basic principle is that the certificate (as vetted by a public CA) > identifies the party responsible for the signed content, but allows > generation of certificates for alternate distribution points (or individuals > who can do so). > > This would require explicit changes for libraries supporting protocols such > as TLS (assuming the chain verification isn't hopelessly broken) to provide > a notification to the client to identify who's behalf the certificate was > issued on. This concept already exists today in the form of name constraints (https://tools.ietf.org/html/rfc5280#section-4.2.1.10). Name constraints provide namespace (e.g. example.com) and only allow issuance to subtrees of that name. They are defined to work with DNS names, email addresses, IP addresses, SRV names, and other name forms, so almost everything you propose could work. Have you looked at name constraints? Thanks, Peter From nobody Thu Apr 14 23:11:47 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A97E12D885 for ; Thu, 14 Apr 2016 23:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dunlop-lello-uk.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 dAaBZPP2a1WO for ; Thu, 14 Apr 2016 23:11:41 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 E7B1D12D65A for ; Thu, 14 Apr 2016 23:11:40 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id c126so133870878lfb.2 for ; Thu, 14 Apr 2016 23:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dunlop-lello-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=qBBxYBFZ3wLnKy4Lwe7iv7FDHG4Zgu50bqpBc4sUKas=; b=TDy/GBp1mDq0YeQR4oF1CGnrqFoUtYaUjFx3IFaapFQ2b/0a9boc44M7KLA3NF885N JgXxTVWwAGOIpruwTQ2W9h867SSkyzDNfqlJi4vC+e6e/HDH2p6T7EiShM/t3GYvt5/l kQtBv+mF2hjFUwN/ON5+N6GDUruHWCa7ytxlT5INdHTdjDk0sWH+ijihgD8+tl4iAbbE lpyu73envbK0VsgBKQoijM3fUmejBspjW0/BOAPskYPSwW0HMdk42daBWlqkCxJYtzXq mH3Nf4nwPzBoMWsOgjKAhq8xO8SU01wEDXprvPwxs9EEiGkukoTQ2cLBPK7QWHK1UxbW vIow== 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; bh=qBBxYBFZ3wLnKy4Lwe7iv7FDHG4Zgu50bqpBc4sUKas=; b=BEjy25GLloeQeepuDFJikCsHDEW2hJwVxUox55cRx7yKF7j9PbnQVbbOqN+GJd2co3 MjJeV/x8tW0mARYIpNe1r9HzZVtfH77KcdR+BlltGMeyb8J239r4WCeA3yDWK0Mnpa6O /OX1XcwR6phz58lyfKVV8XJp7XwVoNYsc9y9yQtU6V9snlgrlyhmLoCc8nQQACPd4EXm O6DcjMCWxFjt8WLzmbUwgo8zDP/OYMxS2LeTqUgHYjR6yMTFJBOn19UJHx9npDaE9vLR poNFstCpwsC9DEay8s22IOt7v/cfwepCMRfp+p/90jQlLKSGHBFv3t2wR1MdGACCHt06 hkJQ== X-Gm-Message-State: AOPr4FVdmKjiC9nhoIGksOVNJcmPhrISl2zJxQ5bHeHZU4r5fqZ+5bSxGCIQMUAEx1ZI3ajjOXty+hLvNuTyElbJ MIME-Version: 1.0 X-Received: by 10.25.205.146 with SMTP id d140mr8716813lfg.109.1460700698966; Thu, 14 Apr 2016 23:11:38 -0700 (PDT) Received: by 10.25.27.16 with HTTP; Thu, 14 Apr 2016 23:11:38 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Apr 2016 07:11:38 +0100 Message-ID: From: Phil Lello To: "" Content-Type: multipart/alternative; boundary=001a114128ca491c9305307fe2d0 Archived-At: Subject: Re: [pkix] Support for delegate certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 06:11:44 -0000 --001a114128ca491c9305307fe2d0 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 15, 2016 at 4:04 AM, Peter Bowen wrote: > On Thu, Apr 14, 2016 at 12:16 PM, Phil Lello wrote: > > Not sure if this has already been discussed (I couldn't find it), or > indeed > > if this is the most appropriate list, but I have a variation on > certificate > > chains I'd like considered. > > > > I have a couple of scenarios in mind where it could be useful for the > holder > > of a certificate, say for *.example.com to act as a CA for issuing > > certificate to delegates. Examples include: > > > > - *.example.com issues a certificate to project1.example.com (to > reduce > > number of admins trusted with wildcard cert) > > - *.example.com issues a certificate to server.altsvc.com (to support > > HTTP's Alt-Svc) > > - *.example.com issues a certificate to J.Smith@example.com, who > issues a > > certificate to www.randompublisher.net > > > > The basic principle is that the certificate (as vetted by a public CA) > > identifies the party responsible for the signed content, but allows > > generation of certificates for alternate distribution points (or > individuals > > who can do so). > > > > This would require explicit changes for libraries supporting protocols > such > > as TLS (assuming the chain verification isn't hopelessly broken) to > provide > > a notification to the client to identify who's behalf the certificate was > > issued on. > > This concept already exists today in the form of name constraints > (https://tools.ietf.org/html/rfc5280#section-4.2.1.10). Name > constraints provide namespace (e.g. example.com) and only allow > issuance to subtrees of that name. They are defined to work with DNS > names, email addresses, IP addresses, SRV names, and other name forms, > so almost everything you propose could work. > > Have you looked at name constraints? > I don't think name constraints are suitable for the sub-domain use-case, since I want to support generation of sub-domain certs from a CA-issued certificate with "Certificate Basic Constraints" of "Is not a Certificate Authority", which should reliably be checked and enforced in current use-cases - as far as I'm aware, Name Constraints aren't correctly/widely enforced (although I may be referring to old information), so there's a significant risk of a name-constrained CA certificate from a public CA chain being treated as a general-purpose CA certificate by older libraries. Further, I explicity need cross-domain functionality for a protocol I'm designing - I'm envisaging a cache for signed content that generates signed content in some scenarios (for example, an optimised image, upstream-unavailable message, or adding headers for virus-scan results on a download). In this case, the client should want to know: - Where the original content came from (certificate signature) - Where the cache-generated content came from (delegated certificate signature) - That the cache had permission to generate content (delegated certificate issuer) The cross-domain functionality may also be an appropriate mechanism for HTTP's Alt-Svc (RFC7838), where Host and Alt-Used are on different domains. RFC7838 gives an example of GET /thing HTTP/1.1 Host: origin.example.com Alt-Used: alternate.example.net RFC7838 s2.1 specifies For example, if the origin's host is "www.example.com" and an alternative is offered on "other.example.com" with the "h2" protocol, and the certificate offered is valid for "www.example.com", the client can use the alternative. Phil --001a114128ca491c9305307fe2d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 15, 2016 at 4:04 AM, Peter Bowen <pzbowen@gma= il.com> wrote:
On Thu, Apr 14, 2016 at 12:16 PM, Phil Lello <phil@dunlop-lello.uk> wrote:
> Not sure if this has already been discussed (I couldn't find it), = or indeed
> if this is the most appropriate list, but I have a variation on certif= icate
> chains I'd like considered.
>
> I have a couple of scenarios in mind where it could be useful for the = holder
> of a certificate, say for *.example.com to act as a CA for issuing
> certificate to delegates. Examples include:
>
>=C2=A0 =C2=A0- *.example.com issues a certificate to project1.example.co= m (to reduce
> number of admins trusted with wildcard cert)
>=C2=A0 =C2=A0- *.example.com issues a certificate to server.altsvc.com = (to support
> HTTP's Alt-Svc)
>=C2=A0 =C2=A0- *.example.com issues a certificate to J.Smith@example.com, who issues a
> certificate to www.randompublisher.net
>
> The basic principle is that the certificate (as vetted by a public CA)=
> identifies the party responsible for the signed content, but allows > generation of certificates for alternate distribution points (or indiv= iduals
> who can do so).
>
> This would require explicit changes for libraries supporting protocols= such
> as TLS (assuming the chain verification isn't hopelessly broken) t= o provide
> a notification to the client to identify who's behalf the certific= ate was
> issued on.

This concept already exists today in the form of name constraints (https://tools.ietf.org/html/rfc5280#section-4.2= .1.10).=C2=A0 Name
constraints provide namespace (e.g. example.com) and only allow
issuance to subtrees of that name.=C2=A0 They are defined to work with DNS<= br> names, email addresses, IP addresses, SRV names, and other name forms,
so almost everything you propose could work.

Have you looked at name constraints?

I = don't think name constraints are suitable for the sub-domain use-case, = since I want to support generation of sub-domain certs from a CA-issued cer= tificate with "Certificate Basic Constraints" of "Is not a C= ertificate Authority", which should reliably be checked and enforced i= n current use-cases - as far as I'm aware, Name Constraints aren't = correctly/widely enforced (although I may be referring to old information),= so there's a significant risk of a name-constrained CA certificate fro= m a public CA chain being treated as a general-purpose CA certificate by ol= der libraries.

Further, I explicity need cross-domain functionality= for a protocol I'm designing - I'm envisaging a cache for signed c= ontent that generates signed content in some scenarios (for example, an opt= imised image, upstream-unavailable message, or adding headers for virus-sca= n results on a download). In this case, the client should want to know:
=
=C2=A0 - Where the original content came from (certificate s= ignature)
=C2=A0 - Where the cache-generated content came fro= m (delegated certificate signature)
=C2=A0 - That the cache h= ad permission to generate content (delegated certificate issuer)

The cross-domain functionality may also be an appropriate mechanism= for HTTP's Alt-Svc (RFC7838), where Host and Alt-Used are on different= domains. RFC7838 gives an example of 
     GET /thing H=
TTP/1.1
     Host: origin.example.com
     Alt-Used: alternate.example.n=
et
RFC7838 s2.1 specifies
   For example, if th=
e origin's host is "www.example=
.com" and an
   alternative is offered on "oth=
er.example.com" with the "h2" protocol,
   and the certificate offered is valid for "www.example.com", the
   client can use the alternative.

Phil
--001a114128ca491c9305307fe2d0-- From nobody Fri Apr 15 07:17:14 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0293F12E0C7 for ; Fri, 15 Apr 2016 07:17:13 -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 FdrIIwv7c6Go for ; Fri, 15 Apr 2016 07:17:11 -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 68AB712E05B for ; Fri, 15 Apr 2016 07:17:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E3993BE3F for ; Fri, 15 Apr 2016 15:17:09 +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 fxIIEjglCqKo for ; Fri, 15 Apr 2016 15:17:08 +0100 (IST) Received: from [10.87.49.100] (unknown [86.42.21.187]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5E57EBE25 for ; Fri, 15 Apr 2016 15:17:07 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1460729827; bh=it3+OZLYtjVDHz0lbmp9qRt/bDz0yr6EpfqNe7j3LAg=; h=Subject:References:To:From:Date:In-Reply-To:From; b=aw8524CLS65gceYDqAYPzlsIaJKf+5ZEh2RG8vroaDEp74cqoBv/B7Aqmz4eBuRkw LqFpZAcYYHJ2fqYb3qVoIQT9yoLhTj0RIPXxZTgHdg3KQCbRXv/BOHv+4DXGbmj+wB kT/n5Rb9ZAozOKYxXiaQ6mDeMKcPOJaZkm74ZuKk= References: <5710F7A0.8020108@cs.tcd.ie> To: pkix From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <5710F7A0.8020108@cs.tcd.ie> Message-ID: <5710F7E3.2000703@cs.tcd.ie> Date: Fri, 15 Apr 2016 15:17:07 +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="------------ms070003090005040304040108" Archived-At: Subject: [pkix] Fwd: [Spasm] side meeting at IETF95 on possible PKIX/SMIME work (and new spasm list) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 14:17:13 -0000 This is a cryptographically signed message in MIME format. --------------ms070003090005040304040108 Content-Type: multipart/mixed; boundary="------------020901090503050600090509" This is a multi-part message in MIME format. --------------020901090503050600090509 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 --------------020901090503050600090509 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== --------------020901090503050600090509-- --------------ms070003090005040304040108 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 NDE3MDdaMC8GCSqGSIb3DQEJBDEiBCDcbgk/VonxbCRNwIU/177+G5U+3ozKMFiOuDTCTHJx wDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQA3Uf2mOlgN60L7j+3hpKG/qnUDYV7bu8qbNmLwn0bvVHE3B5UB+FRb c3VYmD1tbS99co5iSVGmHhdBZG9C8db1unwWnIlzcdcfGBEUhLBJTfLHARkHKUb/pUcWPrNn Y5nN6Z1zPP9HlzGiTKTtY1I01v5Y54Wod2uDYCN3vVJIoqGpByWW+DV/54El6fMxxSXO9zty wPue/gT9ffTrV+zTJl8H9TlcaEwzQwE2mKaNGi/iiz+KukMTCDiq3U8QxXBXHZBs5X6gmKRE KygeTbttBaGuCSD0IoaXBYLWTsG8UQwfuLpZi9+6lMH9X+zH4oi3b3nbyTbMczWFqDlOpHXd AAAAAAAA --------------ms070003090005040304040108-- From nobody Wed Apr 20 11:32:24 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AB312E339 for ; Wed, 20 Apr 2016 11:32:23 -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 F9eegdDDfjc3 for ; Wed, 20 Apr 2016 11:32:22 -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 CA23912E2EF for ; Wed, 20 Apr 2016 11:32:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 98D27BE56 for ; Wed, 20 Apr 2016 19:32:20 +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 7qeyoHy8NBZo for ; Wed, 20 Apr 2016 19:32:19 +0100 (IST) Received: from [10.87.49.100] (unknown [86.46.28.69]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 877D6BE54 for ; Wed, 20 Apr 2016 19:32:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1461177139; bh=3YANaN4/jHL4TU2b4NMuhG2Vx2BUGJQbx2iBkuSgpV8=; h=From:Subject:To:References:Date:In-Reply-To:From; b=yy4fvgEBU8qyoNgmN9q36fyZbwA2dkWQqUNyAaWNlHmt9cMFomLMZYMqxtmjWryj3 HLncpJdemY4tDutKRIaoYl1VdDBDKINdyAKwQoDA5PdDJ4teP2nUDEweIQqVtBJoQY mwXJQ/mee5oIFCAt5uQbiNHB0JS8Nagbpbn68V+I= From: Stephen Farrell To: pkix References: <5710F7A0.8020108@cs.tcd.ie> <5710F815.3020900@cs.tcd.ie> Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5717CB32.4090607@cs.tcd.ie> Date: Wed, 20 Apr 2016 19:32:18 +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="------------ms040705040005050304050500" Archived-At: Subject: Re: [pkix] [saag] Fwd: [Spasm] side meeting at IETF95 on possible PKIX/SMIME work (and new spasm list) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 18:32:23 -0000 This is a cryptographically signed message in MIME format. --------------ms040705040005050304050500 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 --------------ms040705040005050304050500 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 ODMyMThaMC8GCSqGSIb3DQEJBDEiBCCV7GlVCfXmwIvStok8BVOEQd/Rpop/tq+/5Spsvoya 0DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQB0CJw+E9103V81ielxuxGu1nAbV+pFKa9fkN0HcOOKWWj39DW1QZu6 p08YY61XvqiFQy6ZrGIVRh2GbVq8gm3iFn+V3WIZFo8+NEjWCrQXbnEiAQUA3Gg1nwxEQUW3 GsRyB0qUlunAhc1nj/B46envx6cUlb8iD66pjVtpHFgjp3WlCQSQabWmkYWUAxN67ExCJGuS yMWhxfgJD2JkCsaLSZE++qOJFRMmeABBS3Sp8tETNqS3eME8vlhLFdnyH8OrK5nmHFnR9hPP bQxH9CdrBZa34VhRtHDQL4RUqAqCi+eBouX9YN2Sh/GoHRvRc7gDih0ZWA3wCCdLCbM2wT/h AAAAAAAA --------------ms040705040005050304050500-- From nobody Thu Apr 28 10:45:22 2016 Return-Path: X-Original-To: pkix@ietf.org Delivered-To: pkix@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6335D12D1DA; Thu, 28 Apr 2016 10:45:21 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160428174521.5461.93050.idtracker@ietfa.amsl.com> Date: Thu, 28 Apr 2016 10:45:21 -0700 Archived-At: Cc: draft-wallace-est-alt-challenge@ietf.org, The IESG , pkix@ietf.org, rfc-editor@rfc-editor.org Subject: [pkix] Protocol Action: 'Alternative Challenge Password Attributes for Enrollment over Secure Transport' to Proposed Standard (draft-wallace-est-alt-challenge-08.txt) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 17:45:21 -0000 The IESG has approved the following document: - 'Alternative Challenge Password Attributes for Enrollment over Secure Transport' (draft-wallace-est-alt-challenge-08.txt) as Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Stephen Farrell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-wallace-est-alt-challenge/ Technical Summary The document defines a new set of attributes to disambiguate overloaded using of the PKCS #9 challengePassword attribute. The new attributes retain the structure of the existing attribute but are identified by new object identifiers. Working Group Summary The document was discussed on the PKIX mailing list. Since the PKIX working group is no longer active, this document is proceeding as an individual submission. Document Quality There are no fielded implementations yet, but at least one is in development. Other vendors have expressed interest. The lack of existing implementations is not a cause for concern due to the nature of the document, which is essentially defining a few new object identifiers. The Document Shepherd is Russ Housley. The responsible Area Director is Stephen Farrell. From nobody Thu Apr 28 11:05:26 2016 Return-Path: X-Original-To: pkix@ietf.org Delivered-To: pkix@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE41712B047; Thu, 28 Apr 2016 11:05:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160428180525.21263.98556.idtracker@ietfa.amsl.com> Date: Thu, 28 Apr 2016 11:05:25 -0700 From: IETF Secretariat Archived-At: Subject: [pkix] ID Tracker State Update Notice: X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.17 List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 18:05:26 -0000 IANA action state changed to In Progress ID Tracker URL: https://datatracker.ietf.org/doc/draft-wallace-est-alt-challenge/