From nobody Tue May 1 06:01:10 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B5212E8A9 for ; Tue, 1 May 2018 06:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eyqq8EGuw2YI for ; Tue, 1 May 2018 06:01:02 -0700 (PDT) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (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 6D8C312E8E2 for ; Tue, 1 May 2018 06:01:02 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id n1-v6so12846388otf.7 for ; Tue, 01 May 2018 06:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Gpo2uXYdExFiwoNFEido59AVFb8ALejAEJLhJOs4hZw=; b=kFFKV1lY6PPGEsjdnmPAnmfaMnauid7L84f8WhdNIrjh+5xKXmFnfMDinrwD1znKRi R5GkV0n6bUGEUGGm9eZwzU5v85eVnYl3kqLfiA77w3ME3Z3zHeWyLB3Tfavi1XFAGpBn jt8WnAEr7oyrZ/BLvnnaU6G60ATbAA6JILZlQGmPL215wuXehfo+ZvmYQ2bw/f3DOxQG 4mLRC/sScoHQmQjCYbBusLDb9XMNkKe8RPXKpeliix5LZ1IMFbAhd2gg5DjQGJfVW5ne 2EhPdkwp6aLC9EPutB8Dh1BYUKt6P9xLW2dHO3ZP3NUXiAPEdghemDgZrKvWuUSRk59v wrIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Gpo2uXYdExFiwoNFEido59AVFb8ALejAEJLhJOs4hZw=; b=YAXaVQNjeNDnQsUybmoaUe0XWvNd3AuwtosdwO4dZaDMMlcI8qGvstfIc9n33kk/bR Pjfv5SPIwR/sYcrXSogcCenN6cVy1enayGQwIsvph70xx70GtGmd7LTwrskEa2J7G3fG JK1XzIa7HOFYy91cAyz5BavJasDbk7v3VnmB+iqDHt4V9QsN+jxP32ArWZIvdzv3HzZc 9Lh73gyFXefgD9VOhKVBA22gv6cZAJ6XRSCxCfU+5Vume8io1zfy79gvdGPAnjBkOWS6 vTp2j1Yat8mkDqdSNiXUNpNPF8p7m8qaWLndiMt+PBB9+zF4z2HhEt+5xhj3Da7cuPYy RCJQ== X-Gm-Message-State: ALQs6tDy3XCJgYSzLbvIDSDfWFyKuUlt+JP9PDGYYo8+LhH3S7UVwPB+ gfxm1IgNkNF3TJ5rCDyNlKM0o25j7UxVTpAJn57G5VBE1Y8= X-Google-Smtp-Source: AB8JxZrXONdZ5l8afthxxriRNve+nXPAz7jL3l0karkuppeXFTtzBr8syRZIJAuE/gbfVSYHPH6YAZxKjLvHM4PnkgU= X-Received: by 2002:a9d:1055:: with SMTP id o21-v6mr10509810oto.371.1525179661586; Tue, 01 May 2018 06:01:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Tue, 1 May 2018 06:00:21 -0700 (PDT) From: Eric Rescorla Date: Tue, 1 May 2018 06:00:21 -0700 Message-ID: To: SPASM Content-Type: multipart/alternative; boundary="000000000000f2a907056b248f47" Archived-At: Subject: [lamps] New LAMPS co-chair: Tim Hollabeek X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 13:01:09 -0000 --000000000000f2a907056b248f47 Content-Type: text/plain; charset="UTF-8" I am pleased to announce that Tim Hollabeek will be the new co-chair of LAMPS, effective immediately. Russ Housley will continue as the other co-chair. Thanks to everyone who offered to serve. -Ekr [for the Security ADs] --000000000000f2a907056b248f47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am pleased to announce that Tim Hollabeek will be t= he new co-chair of LAMPS,
effective immediately. Russ Housley wil= l continue as the other co-chair.

Thanks to ev= eryone who offered to serve.

-Ekr [for the Securit= y ADs]

--000000000000f2a907056b248f47-- From nobody Tue May 1 06:07:41 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3671712762F for ; Tue, 1 May 2018 06:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 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_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fInWy-ZiCezO for ; Tue, 1 May 2018 06:07:39 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 EC07312706D for ; Tue, 1 May 2018 06:07:38 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id n65-v6so10016108oig.6 for ; Tue, 01 May 2018 06:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=2EMt8ywuAC+DYI5mK9NqLKPEwdGOJLmX8LKzVrMq3A8=; b=u/h+IrJekH/Pt6kO0JYw/90s3NjfJXK4ucpeTv8p6Ul5HVSbHcDH8CFtD7I5rdrqr4 hy4VuIbu0vTQrQsEN4qpUi/sKR/8LuoKYPa+30EunZotpEV0j/P/DmbDhRO5Oy5qEWve 92p0mKDIL8Nl2SK0Ms/E2Yd1tj3rqNQKVlHq1or6QdkdEGQKIZTxzU1VODdqjGlo1ZQK RziFspt2HPMaQoRIWGfpQ0xcsFjj3bdpzJhv1Ba/dsVEMZ5HkrazFRU76krr2Nm6XM38 0CrBu1IJi6icC5QicQuSLDGdgcXRFREDUZ05o8AfWZH5OQi+lJgg3H/ox67WejOcY5bl qh5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=2EMt8ywuAC+DYI5mK9NqLKPEwdGOJLmX8LKzVrMq3A8=; b=Vo4krTrnV62i2DDNgpfSSZmEaTp2pjpeyZbhAC0B3bYGjlj6ZXH6xFPnCF+vKEEiqD Z7A7Y5YWSrlOhMayYaC0eG3tlC5j0qC8sHq6EmYt0XOtqo5Y6mXvdu9RxcxQK84v24j4 Hul6QB5FcYuiz7XZD6CH5JR5jgmcZxq39gLKJstqglfmuNg2lEVFMj/gR85TP8EkFYW/ W0i1bdhnngmmPj7GoItV5v6NwbYst8+9Ufjx95Yqt77qPAZPvcs9uACnyNEBAWiRh29N iIBZPnScxHUJ0Lf4wPlIMBfmh9u2MuL2SBDmY5RQa5o1bjhFeLcvXXwD7ZTE2enGmNYu zZWA== X-Gm-Message-State: ALQs6tAwpSkawNBV+rPJlFKWv29InaV0RTkjRF2tU7+xVcS91UlDq6jk 57n2Ew1xiWndi7C5W1yzDkBVAxj/WubGhewpH2PTBrTX X-Google-Smtp-Source: AB8JxZpoiYTHdlGGDizyWlUtm4vXj3oEYYuyx9Lz2iWh2vboj6Q1PEC1p18WNMOr92x9DQr2JFFASqT7rLHk+E4OGzg= X-Received: by 2002:aca:ea46:: with SMTP id i67-v6mr9923448oih.174.1525180058164; Tue, 01 May 2018 06:07:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Tue, 1 May 2018 06:06:57 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 1 May 2018 06:06:57 -0700 Message-ID: To: SPASM Content-Type: multipart/alternative; boundary="00000000000095f54e056b24a7ff" Archived-At: Subject: Re: [lamps] New LAMPS co-chair: Tim Hollabeek X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 13:07:40 -0000 --00000000000095f54e056b24a7ff Content-Type: text/plain; charset="UTF-8" Apologies: Tim Hollebeek. No a! -Ekr On Tue, May 1, 2018 at 6:00 AM, Eric Rescorla wrote: > I am pleased to announce that Tim Hollabeek will be the new co-chair of > LAMPS, > effective immediately. Russ Housley will continue as the other co-chair. > > Thanks to everyone who offered to serve. > > -Ekr [for the Security ADs] > > --00000000000095f54e056b24a7ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies: Tim Hollebeek. No a!

-Ekr


On Tue, May 1, 2018 at 6:00 AM, Eric Rescorla <ekr@rtfm.c= om> wrote:
I am pleased to announce that Tim Hollabeek will be the new co-chair = of LAMPS,
effective immediately. Russ Housley will continue as th= e other co-chair.

Thanks to everyone who offer= ed to serve.

-Ekr [for the Security ADs]

=

--00000000000095f54e056b24a7ff-- From nobody Wed May 2 07:41:49 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF6512D881 for ; Wed, 2 May 2018 07:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 7mAENRxqZTNc for ; Wed, 2 May 2018 07:41:45 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8127F120726 for ; Wed, 2 May 2018 07:41:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6475C300596 for ; Wed, 2 May 2018 10:41:43 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LRMnrHoZIF36 for ; Wed, 2 May 2018 10:41:41 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 2018230048E for ; Wed, 2 May 2018 10:41:41 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_6CED63CB-11E3-49C0-8217-45720ECC6A34" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 2 May 2018 10:41:44 -0400 References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> To: LAMPS In-Reply-To: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> Message-Id: <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 14:41:48 -0000 --Apple-Mail=_6CED63CB-11E3-49C0-8217-45720ECC6A34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Based on the discussion in London and the "Potential Topics for LAMPS = Recharter" mail thread. We propose the attached charter text. Please = review and comment. Russ & Tim =3D =3D =3D =3D =3D =3D =3D =3D =3D The PKIX and S/MIME Working Groups have been closed for some time. Some updates have been proposed to the X.509 certificate documents produced=20= by the PKIX Working Group and the electronic mail security documents=20 produced by the S/MIME Working Group. The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working=20 Group is chartered to make updates where there is a known constituency=20= interested in real deployment and there is at least one sufficiently=20 well specified approach to the update so that the working group can=20 sensibly evaluate whether to adopt a proposal. The LAMPS WG is now tackling these topics: 1. Specify a discovery mechanism for CAA records to replace the one described in RFC 6844. Implementation experience has demonstrated an ambiguity in the handling of CNAME and DNAME records during discovery in RFC 6844, and subsequent discussion has suggested that a different discovery approach would resolve limitations inherent in that approach. 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. Unlike the previous hashing standards, the SHA-3 family of functions are the outcome of an open competition. They have a clear design rationale and have received a lot of public analysis, giving great confidence that the SHA-3 family of functions are secure. Also, since SHA-3 uses a very different construction from SHA-2, the SHA-3 family of functions offers an excellent alternative. In particular, SHAKE128/256 and SHAKE256/512 offer security and performance benefits. 3. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information, as a result revoking them pointless. 4. Specify the use of a pre-shared key (PSK) along with other key=20 management techniques with supported by the Cryptographic Message Syntax (CMS) as a near-term mechanism to protect present day communication from the future invention of a large-scale quantum computer. The invention of a such a quantum computer would pose a serious challenge for the key management algorithms that are widely deployed, especially the key transport and key agreement algorithms used today with the CMS to protect S/MIME messages. 5. Specify the use of hash-based signatures with the Cryptographic Message Syntax (CMS). A hash-based signature uses small private and public keys, and it has low computational cost; however, the signature values are quite large. For this reason they will probably not be used for signing X.509 certificates or S/MIME messages, but they are secure even if a large-scale quantum computer is invented. These properties make hash-based signatures useful in some environments, such a the distribution of software updates. 6. Specifies a certificate extension that is carried in a self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate, to identify the next public key that will be used by the trust anchor. In addition, the LAMPS WG may investigate other updates to documents produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt any of these potential work items without rechartering. MILESTONES Mar 2018: Adopt a draft for rfc6844bis Apr 2018: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512 Apr 2018: Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512 Jun 2018: Adopt a draft for short-lived certificate conventions Jun 2018: Adopt a draft for the CMS with PSK=20 Jun 2018: Adopt a draft for hash-based signatures with the CMS Jun 2018: Adopt a draft for root key rollover certificate extension=20 Jul 2018: rfc6844bis sent to IESG for standards track publication Aug 2018: Root key rollover certificate extension sent to IESG for informational publication Sep 2018: SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for standards track publication Sep 2018: SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for standards track publication Oct 2018: Short-lived certificate conventions sent to IESG for BCP publication Oct 2018: The CMS with PSK sent to IESG for standards track publication Dec 2018: Hash-based signatures with the CMS sent to IESG for standards track publication --Apple-Mail=_6CED63CB-11E3-49C0-8217-45720ECC6A34 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Based on the discussion in London and the "Potential Topics for LAMPS Recharter" mail thread.  We = propose the attached charter text.  Please review and = comment.

Russ & Tim

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

The PKIX and S/MIME Working Groups have been = closed for some time. Some
updates have been proposed to = the X.509 certificate documents produced 
by the PKIX = Working Group and the electronic mail security documents 
produced by the S/MIME Working Group.

The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) = Working 
Group is chartered to make updates where = there is a known constituency 
interested in real = deployment and there is at least one sufficiently 
well= specified approach to the update so that the working group can 
sensibly evaluate whether to adopt a proposal.

The LAMPS WG is now tackling these topics:

1. Specify a discovery mechanism for CAA = records to replace the one
described in RFC 6844. =  Implementation experience has demonstrated an
ambiguity in the handling of CNAME and DNAME records during = discovery
in RFC 6844, and subsequent discussion has = suggested that a different
discovery approach would = resolve limitations inherent in that approach.

2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX = and S/MIME.
Unlike the previous hashing standards, the = SHA-3 family of functions are
the outcome of an open = competition.  They have a clear design rationale
and = have received a lot of public analysis, giving great confidence that
the SHA-3 family of functions are secure.  Also, since = SHA-3 uses a very
different construction from SHA-2, the = SHA-3 family of functions offers
an excellent alternative. =  In particular, SHAKE128/256 and SHAKE256/512
offer = security and performance benefits.

3. = Specify the use of short-lived X.509 certificates for which no
revocation information is made available by the Certification = Authority.
Short-lived certificates have a lifespan that = is shorter than the time
needed to detect, report, and = distribute revocation information, as a
result revoking = them pointless.

4. Specify the use of a = pre-shared key (PSK) along with other key 
management = techniques with supported by the Cryptographic Message
Syntax (CMS) as a near-term mechanism to protect present = day
communication from the future invention of a = large-scale quantum
computer.  The invention of a = such a quantum computer would pose a
serious challenge for = the key management algorithms that are widely
deployed, = especially the key transport and key agreement algorithms
used today with the CMS to protect S/MIME messages.

5. Specify the use of hash-based signatures = with the Cryptographic
Message Syntax (CMS).  A = hash-based signature uses small private and
public keys, = and it has low computational cost; however, the signature
values are quite large.  For this reason they will = probably not be used
for signing X.509 certificates or = S/MIME messages, but they are secure
even if a large-scale = quantum computer is invented.  These properties
make = hash-based signatures useful in some environments, such a the
distribution of software updates.

6. Specifies a certificate extension that is carried in a = self-signed
certificate for a trust anchor, which is often = called a Root
Certification Authority (CA) certificate, to = identify the next
public key that will be used by the = trust anchor.

In addition, the LAMPS WG may = investigate other updates to documents
produced by the = PKIX and S/MIME WGs, but the LAMPS WG shall not adopt
any = of these potential work items without rechartering.

MILESTONES

Mar 2018: Adopt a = draft for rfc6844bis
Apr 2018: Adopt a PKIX draft for = SHAKE128/256 and SHAKE256/512
Apr 2018: Adopt a S/MIME = draft for SHAKE128/256 and SHAKE256/512
Jun 2018: Adopt a = draft for short-lived certificate conventions
Jun 2018: = Adopt a draft for the CMS with PSK 
Jun 2018: Adopt a = draft for hash-based signatures with the CMS
Jun 2018: = Adopt a draft for root key rollover certificate extension 
Jul 2018: rfc6844bis sent to IESG for standards track = publication
Aug 2018: Root key rollover certificate = extension sent to IESG for
          &nb= sp; informational publication
Sep 2018: SHAKE128/256 = and SHAKE256/512 for PKIX sent to IESG for
          &nb= sp; standards track publication
Sep 2018: = SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for
          &nb= sp; standards track publication
Oct 2018: Short-lived = certificate conventions sent to IESG for BCP
          &nb= sp; publication
Oct 2018: The CMS with PSK sent to = IESG for standards track publication
Dec 2018: Hash-based = signatures with the CMS sent to IESG for standards
          &nb= sp; track publication
= --Apple-Mail=_6CED63CB-11E3-49C0-8217-45720ECC6A34-- From nobody Wed May 2 11:54:53 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B282F126C22; Wed, 2 May 2018 11:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63pxZu3KbehS; Wed, 2 May 2018 11:54:31 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C07E12DA0A; Wed, 2 May 2018 11:54:28 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 2 May 2018 11:51:53 -0700 From: Jim Schaad To: 'Zitao Wang' , CC: , , References: <152385923510.20981.12612336145725004062@ietfa.amsl.com> In-Reply-To: <152385923510.20981.12612336145725004062@ietfa.amsl.com> Date: Wed, 2 May 2018 11:54:22 -0700 Message-ID: <052001d3e246$fdfbc4c0$f9f34e40$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGVTOIpwFEyO1muP1gGUK18Ogb2GKSYgsyA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Opsdir last call review of draft-ietf-lamps-rfc5751-bis-07 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 18:54:34 -0000 I have published a -08 with these changes. > -----Original Message----- > From: Zitao Wang > Sent: Sunday, April 15, 2018 11:14 PM > To: ops-dir@ietf.org > Cc: spasm@ietf.org; ietf@ietf.org; = draft-ietf-lamps-rfc5751-bis.all@ietf.org > Subject: Opsdir last call review of draft-ietf-lamps-rfc5751-bis-07 >=20 > Reviewer: Zitao Wang > Review result: Has Nits >=20 > I have reviewed this document as part of the Operational = directorate=E2=80=99s > ongoing effort to review all IETF documents being processed by the = IESG. > These comments were written with the intent of improving the = operational > aspects of the IETF drafts. Comments that are not addressed in last = call may > be included in AD reviews during the IESG review. Document editors = and > WG chairs should treat these comments just like any other last call > comments. >=20 > Document reviewed: draft-ietf-lamps-rfc5751-bis-07 >=20 > Summary: >=20 > This document defines Secure/Multipurpose Internet Mail Extensions > (S/MIME) version 4.0. S/MIME provides a consistent way to send and > receive secure MIME data. Digital signatures provide authentication, > message integrity, and non-repudiation with proof of origin. = Encryption > provides data confidentiality. > Compression can be used to reduce data size. This document obsoletes = RFC > 5751. >=20 > Firstly, this document list a set of encryption algorithm, but a lot = of them miss > references, it difficult to understanding, especially for the reader = who may > lack of the encryption knowledges. For example: >=20 > Section 1.5: >=20 > s/key wrapping algorithm/key wrapping algorithm[rfc3394] >=20 > s/Diffie-Hellman (DH) algorithm/Diffie-Hellman (DH) algorithm = [rfc2631] >=20 > s/RSA public key algorithm/RSA public key algorithm [RFC3447] = Section 2.2: >=20 > s/RSA PKCS#1 v1.5/RSA PKCS#1 v1.5 [RFC2313] All except the first is done. I think that the text is sufficiently = descriptive. >=20 > And there are some terminologies or abbreviations which are used = without > explaining, especially for some first appear. For example: >=20 > Section 2.2. >=20 > s/ECDSA/Elliptic Curve Digital Signature Algorithm (ECDSA) This is on the RFC abbreviation list >=20 > s/EdDSA/Edwards-curve Digital Signature Algorithm (EdDSA) Changed, although I left DSA along as it is on the RFC list. >=20 > Other nits: >=20 > Obsolete normative reference: RFC 2138 (Obsoleted by RFC 2865) Should have been 2183 >=20 > Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838 Fixed Jim From nobody Wed May 2 11:55:19 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0271F12DA0A; Wed, 2 May 2018 11:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VhURo-VozRy; Wed, 2 May 2018 11:55:02 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF1D112E03A; Wed, 2 May 2018 11:54:47 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 2 May 2018 11:52:12 -0700 From: Jim Schaad To: 'David Schinazi' , CC: , , References: <152480069184.6083.13015201919417586774@ietfa.amsl.com> In-Reply-To: <152480069184.6083.13015201919417586774@ietfa.amsl.com> Date: Wed, 2 May 2018 11:54:42 -0700 Message-ID: <052101d3e247$09dd2680$1d977380$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQETQ5fYDEoS+2SNPNrfePGEcactRaWclNBA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-rfc5751-bis-07 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 18:55:12 -0000 I have published a -08 with these changes. > -----Original Message----- > From: David Schinazi > Sent: Thursday, April 26, 2018 8:45 PM > To: gen-art@ietf.org > Cc: spasm@ietf.org; ietf@ietf.org; = draft-ietf-lamps-rfc5751-bis.all@ietf.org > Subject: Genart last call review of draft-ietf-lamps-rfc5751-bis-07 >=20 > Reviewer: David Schinazi > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area = Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG = for > the IETF Chair. Please treat these comments just like any other last = call > comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-lamps-rfc5751-bis-07 > Reviewer: David Schinazi > Review Date: 2018-04-26 > IETF LC End Date: 2018-04-27 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: > This document is clearly written and does a nice job of explaining = the > rationale and historical context of the decisions it made. >=20 > Major issues: > None noticed during this review >=20 > Minor issues: > I was slightly confused by the description of AuthEnvelopedData in = 2.4.4: > it seems to describe data protected by a symmetric AEAD but then > mentions > asymmetric keys. But this could be due to my lack of expertise in = S/MIME. I have tried to clear this up. The following sentence has been added In order to distribute the symmetric key, a sender needs to = have access to a public key for each intended message recipient to use this service. >=20 > Nits/editorial comments: > I believe the RFC2119 reference should also mention RFC8174. Done Jim From nobody Wed May 2 11:55:52 2018 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 052CA12DA0A; Wed, 2 May 2018 11:55:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152528734695.11146.7349430691287696550@ietfa.amsl.com> Date: Wed, 02 May 2018 11:55:47 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc5751-bis-08.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 18:55:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification Authors : Jim Schaad Blake Ramsdell Sean Turner Filename : draft-ietf-lamps-rfc5751-bis-08.txt Pages : 58 Date : 2018-05-02 Abstract: This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-08 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5751-bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5751-bis-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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 2 11:56:41 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DC412DA11; Wed, 2 May 2018 11:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeYRK19MCF0w; Wed, 2 May 2018 11:56:24 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7AC512DA1A; Wed, 2 May 2018 11:56:14 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 2 May 2018 11:52:38 -0700 From: Jim Schaad To: 'Daniel Migault' , CC: , , References: <152485706488.6011.12980717250490137013@ietfa.amsl.com> In-Reply-To: <152485706488.6011.12980717250490137013@ietfa.amsl.com> Date: Wed, 2 May 2018 11:55:08 -0700 Message-ID: <052201d3e247$19431b20$4bc95160$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGKQIh8Fnl9XoAAnVF7fk1Lowwoi6SoQLLQ Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Secdir last call review of draft-ietf-lamps-rfc5751-bis-07 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 18:56:27 -0000 I have published a -08 with these changes. > -----Original Message----- > From: Daniel Migault > Sent: Friday, April 27, 2018 12:24 PM > To: secdir@ietf.org > Cc: spasm@ietf.org; ietf@ietf.org; = draft-ietf-lamps-rfc5751-bis.all@ietf.org > Subject: Secdir last call review of draft-ietf-lamps-rfc5751-bis-07 >=20 > Reviewer: Daniel Migault > Review result: Has Nits >=20 > Hi, >=20 >=20 > I have reviewed this document as part of the security directorate's = ongoing > effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security = area > directors. Document editors and WG chairs should treat these comments > just like any other last call comments. >=20 > The summary of the review is Has Minor Nits >=20 >=20 > Please find my comments while reading the draft. >=20 > Yours, >=20 > Daniel >=20 >=20 > 1. Introduction >=20 > As a supplementary service, S/MIME provides for message > compression. >=20 > maybe : > As a supplementary service, S/MIME provides message > compression. >=20 Done >=20 > 1.3. Conventions Used in This Document >=20 > The term RSA in this document almost always refers to the PKCS#1 v1.5 > RSA signature or encryption algorithms even when not qualified as > such. >=20 > I am not sure format would not be more appropriated than algorithm, so > maybe: >=20 > The term RSA in this document almost always refers to the PKCS#1 v1.5 > RSA signature or encryption *format* even when not qualified as > such. Interesting observation. In all of the work that I have ever done I = have always referred to the difference between PKCS #v1.5 signature, = PKCS #v1.5 encryption, OAEP, PSS and KEM and different encryption = algorithms rather than just saying that the formats are different. = Saying format would make a degree of sense between the two different 1.5 = algorithms, however if you compare v1.5 signature and PSS then more than = just the format of the data can be thought of as being involved. I don't think that this makes sense. >=20 >=20 > 2.3. KeyEncryptionAlgorithmIdentifier >=20 > When ECDH ephemeral-static is used, a key wrap algorithm is also > specified in the KeyEncryptionAlgorithmIdentifier [RFC5652]. The > underlying encryption functions for the key wrap and content > encryption algorithm ([RFC3370] and [RFC3565]) and the key sizes = for > the two algorithms MUST be the same (e.g., AES-128 key wrap = algorithm > with AES-128 content encryption algorithm). >=20 > I understand the recommendation for a sending agent, but it seems that > additional text should be provided in order to describe the behavior = of the > receiver. I am wondering if the receiver is expected to reject the = message or > whether it should assume the associated protection is the least of the = two. > Maybe specifying this is only for sending agent may also clarify this. This probably falls under the category of "I don't care", the object is = to make sending agents do the right thing. However, I have added test = about security strengths for reciepents. >=20 > 2.4.4. AuthEnvelopedData Content Type >=20 > This content type does not provide > authentication or non-repudiation. >=20 > is a really helpful clarification ;-) Maybe it could be helpful to use = the same > formulation for section 2.4.2. SignedData Content Type by > replacing: >=20 > Applying a > signature to a message provides authentication, message integrity, > and non-repudiation of origin. >=20 >=20 > This content type provides provides authentication, message integrity, = and > non-repudiation of origin. A sender signs the message with its own = private > key and shares public part of it with the recipient to validate the = signature. I don't think this necessary for the other content types. The problem = is that many people think that AED algorithms automatically provide = authentication. There are some situations where this is true, but they = are not met when doing S/MIME. >=20 > 2.5. Attributes and the SignerInfo Type >=20 > It would probably ease the reading and clarifying the purpose of the > SignerInfo's attribute. Typically, some of them might necessary to = validate > the received message, while others are informational in prevision of a > response. This is clarified later in the document but could be = introduced > here. I also believe that would be good to also include that there is = a > bootstrapping issue that is solved by the compliance of the = implementations > in supporting the recommended algorithms. >=20 > A reference to section 2.7 may be useful as this section clarifies how = the > sending agent uses these information - at least for the encryption. I have added the following sentence to the first paragraph These attributes can be required for processing of message (i.e. Message = Digest), information the signer supplied (i.e. SMIME Capabilities) that = should be processed, or attributes which are not relevant in the current = situation (i.e. mlExpansionList for mail = viewers). I don't think a forward reference to 2.7 would be useful at this point. >=20 > 2.5.1. Signing Time Attribute >=20 > The message originator has not been specified before, it may be good = to > clarify how it differs from the sender. It may also be good to specify = how this > value is being used - against replay attacks. section 2.7.1 provides = some > indications of the expected usage of the signing time attribute but it = seems > more associated to the capabilities. Replaced message originator with signer. >=20 > 2.5.2. SMIME Capabilities Attribute >=20 > A client does not have to list every capability it > supports, and need not list all its capabilities so that the > capabilities list doesn't get too long. >=20 > It might be worth providing a recommendation on what too long means, > especially as a resulting list of capabilities is (expected) to be = relatively short > compared to the message itself - but I might be wrong. > My reading of this attribute - and again I might be wrong - is that it = would be > useless if implementations would follow the cryptographic > recommendations. It is mostly useful to have non updated senders to > received responses from up-to-date responders. In addition, this > information is likely cached and as such may not be unnecessarily be > repeated. Wouldn't a MAY be more appropriated ? I don't really want to try and quantify what long means because for = different clients it can mean different things. In some considerations = one could consider listing 3 encryption algorithms to be long while in = other situations it might be 30 encryption algorithms that is too long. = If I want to send you a message and need to be sure that there is a = common enabled language then 30 encryption algorrithms is better. On = the other hand trying to figure out a common algorithm for a message = going to 100 recipients where each has a different set of algorithms and = in a different ranking order and come up with the best one means even 3 = can feel really long. The problem is not byte count as even 30 items at 10 bytes apiece is = only 300 bytes which relative to the rest of a signed MIME message is = pretty small. The problem is the question of how to make a decision and = the parameters are different based on how that algorithm is implemented. While the information can be cached, I don't know that it can be assured = to be cached. Additionally this might put a greater burden on the = sender as it would need to know if the current configuration has been = sent to a recipient. It is easier to just always send the list. = However I cannot see that there is any requirements on the document on = having sending the attribute just on receiving it. >=20 > Note also that while we have some cryptographic recommendations for = RSA, > I would have expected a table summarizing the cryptographic > recommendations with other algorithms than RSA. I don't know that adding a table is going to be useful. Much of this = information is not really designed to be put into a table unless you are = going to footnote the heck out of it which kind of defeats the process. = This information is scattered through out the document, but it tries to = be in the right place for a specific field. >=20 > 2.5.3. Encryption Key Preference Attribute >=20 > This attribute is designed to > enhance behavior for interoperating with those clients that use > separate keys for encryption and signing. >=20 > Maybe that would be good to position this attribute versus the = keyusage > when certificate are used to split the usage of each keys. I am = wondering if a > recommendation could be state on whether one or both means should be > used and if one overwrite the other. A preference may still be useful = to > indicate a preference when multiple keys for a given role are = available. Is key > management a relevant usage for preference ? >=20 > I understand that Signing Time is being used to update the preferred > keys as one way to performed key roll over. While there is some similarity between key usage and this attribute, the = attribute is more general and allows for things which are not = necessarily mentioned here. As an example, one could send different = certificates with different algorithms or key sizes and express a = preference on which certificate to use. It may be that the names = between the signing certificate and encryption key certificate are not = the same, in that case which should be used. I think that this is = covered in the introduction and a reference to key usage is not really = helpful. >=20 >=20 > 3.1. Preparing the MIME Entity for Signing, Enveloping, or = Compressing >=20 > A MIME entity can be a sub- > part, sub-parts of a message, or the whole message with all its = sub- > parts. >=20 > I am wondering if "a subpart, many subparts or ..." would not be = clearer. I don't see this as being clearer. >=20 > I understand that "message" in the first paragraph is used as the MIME > message and in other words, the message is not designating the mail. I = am > reading message as MIME multi-part message and the MIME entities as a > subset of MIME headers and parts of MIME multi-part message. Similarly > MIME body would be the MIME multi-part message. Is that correct ? I > believe the terminology paragraph could be clarified. There is no requirement that message be multi-part, it could be a = single-part message such as text/plain. However that is generally = correct. How do you believe that the text can be clarified. Specific = text would be helpful. >=20 >=20 > It is > RECOMMENDED that a distinction be made between the location of the > header. >=20 > I believe the purpose is to make a distinction between "protected" and > 'unprotected' to the end user. I would thus keep this distinction even = though > this translates into 'inner' / 'outer'. The problem of how to do this has been a topic of many discussions = without ever getting to a conclusion. One of the problems is that = protected can mean some different things depending on how you protect = the headers. For example, one could have a multipart/mixed message with = two sections each of which consists of an encrypted message. If each of = those has different protected headers in them then, while the difference = between inner and outer makes sense as that is part of the tree = structure, which set of protected headers now needs to be dealt with. >=20 >=20 > 3.3. Creating an Enveloped-Only Message >=20 >=20 > A sample message would be: >=20 > Content-Type: application/pkcs7-mime; name=3Dsmime.p7m; > smime-type=3Denveloped-data >=20 > Shouldn't we use an OID instead of data for the example ? I don't know what you are trying to ask here. =20 >=20 >=20 >=20 > 3.4. Creating an Authenticated Enveloped-Only Message >=20 > I believe the word "proof" is missing. >=20 > It is important to note that > sending authenticated enveloped messages does not provide for > origination when using S/MIME. >=20 > Maybe we should specify that this is especially true when multiple = recipients > are involved. done >=20 > 3.5.3. Signing Using the multipart/signed Format >=20 > The first part contains > the MIME entity that is signed; the second part contains the > "detached signature" CMS SignedData object in which the > encapContentInfo eContent field is absent. >=20 > I believe it would be good to specify parts are ordered as this is not = always > the case of parts. What is unclear to me is why the second part is = separated > by a boundary usually used to separate parts. It seems boundary can = also be > used as boundary inside a part which seems to make part parsing = harder. The order is part of the definition of multipart/signed. In the definition of multipart/*, the rules require that the boundary = string not exist within any of the different child body parts. This = means that it can be used to uniquely distinguish the boundaries. >=20 >=20 >=20 > 3.5.3.2. Creating a multipart/signed Message >=20 > Algorithm Value Used > MD5 md5 > SHA-1 sha-1 > SHA-224 sha-224 > SHA-256 sha-256 > SHA-384 sha-384 > SHA-512 sha-512 > Any other (defined separately in algorithm profile or "unknown" if > not defined) >=20 >=20 > Should we have any recommendations on the hash algorithm to be used by > sender / receivers ? Is that possible to deprecate MD5, SHA-1 and > SHA-224 for senders ? The recommendations on which algorithms to use is part of the signature = algorithm recommendations. This is a different table and removing items = would be potentially harmful.=20 >=20 >=20 > 3.7. Multiple Operations >=20 > Would it be recommended to have signed clear text than encrypted and > then signed encrypted ? This seems to address all security concerns. There are a large number of security concerns that have been uncovered = with each of the different orders of operations. Part of the question = is going to be what concern are you trying to address and what are the = informal rules about this. I don't think at this point we can really = give an order, however RFC 2634 does have some guidance. >=20 > 3.9. Registration Requests >=20 > Should we mention DANE rfc8162 as a way to register you public key ? I don't think so, we don=E2=80=99t ever talk about how to find keys in = the document. >=20 > 4. Certificate Processing >=20 > EdDSA Signatures recommendations for curve25519 and curve448 seems to > be missing in the key pair generating , signature section. Are there = any > reasons not to consider these curves ? >=20 > May be useful to have the following references: > [1] = https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/ > [2] https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ Should have had [1] as a reference, the reference was there but not the = pointer to it. The second would be referenced in rfc5750-bis not here. >=20 > 6. Security Considerations >=20 > I am wondering if any considerations should be provided for data at = rest. > Does the email needs to be archived encrypted or not and whether = S/MIME > can be used to store encrypted content. I believe that email should = not be > stored encrypted and as such S/MIME is only intended to > protect mails in transit.... but I might be wrong. I believe you to be wrong. There are no problems w/ using S/MIME as a = data at rest protection scheme. The question of storing messages as = encrypted or not is something that different clients have dealt with in = different ways. The client I use leaves things encrypted which I = consider to be the correct answer. >=20 > As a general comment I would have like a table that summarizes or = explicitly > mention what crypto is recommended for encrypting / signing. > RSA is being discussed, but ECDSA EdDSA, ECDH, hash... are not. I = believe > such tables should be updated regularly to deprecate and introduce = new > algorithms while leaving S/MIME unchanged. To do this would require that the algorithms be maintained in a separate = document. As above, I don't think a separate table adds to clarity as = it duplicates information and would be hard to write. >=20 > There are a lot of double space in the text. >=20 Jim From nobody Wed May 2 12:22:27 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6DC12DA09 for ; Wed, 2 May 2018 12:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5XiTwa2ndFs for ; Wed, 2 May 2018 12:22:24 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D1ED124D68 for ; Wed, 2 May 2018 12:22:24 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 2 May 2018 12:19:49 -0700 From: Jim Schaad To: References: <152528734695.11146.7349430691287696550@ietfa.amsl.com> In-Reply-To: <152528734695.11146.7349430691287696550@ietfa.amsl.com> Date: Wed, 2 May 2018 12:22:19 -0700 Message-ID: <052501d3e24a$e4a719d0$adf54d70$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHJvOak6JfMxBpjBxccmLVMYWdYjaQxG82A Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [lamps] FW: I-D Action: draft-ietf-lamps-rfc5751-bis-08.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 19:22:26 -0000 This draft addresses the last call comments and the sector reviews that have come in so far Jim -----Original Message----- From: Spasm On Behalf Of internet-drafts@ietf.org Sent: Wednesday, May 2, 2018 11:56 AM To: i-d-announce@ietf.org Cc: spasm@ietf.org Subject: [lamps] I-D Action: draft-ietf-lamps-rfc5751-bis-08.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification Authors : Jim Schaad Blake Ramsdell Sean Turner Filename : draft-ietf-lamps-rfc5751-bis-08.txt Pages : 58 Date : 2018-05-02 Abstract: This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-08 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5751-bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5751-bis-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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Wed May 2 13:36:26 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C92A12DA23 for ; Wed, 2 May 2018 13:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ZYspQSeblPd1 for ; Wed, 2 May 2018 13:36:22 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4315412DA19 for ; Wed, 2 May 2018 13:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16449; q=dns/txt; s=iport; t=1525293382; x=1526502982; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=fbqgIt3655hI0wb0ZSpNlkjQu9eJl4D2kfEBUfEs0Ok=; b=m2p0kHwUGSeqewjio633ycm7qOmRs3rvzZyDVU1oNMGYMpEp3tnjIrWu BDrAJrkvfUAg6bAtTS9tQ+VG1VszmW1LON33frUpJB6QLcnpwsZlcprdz h2dpmr4sHiNvr0nnmg8UGRxlOHNPmXV6wp7eBs3GiAhL7a5KvcVb1Fxsl w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DWAAAAIOpa/5JdJa1SChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGCTUcvYRdjKAqLZYxvgXR1Go4qhHAUgWQLgXeCdQKDAyE?= =?us-ascii?q?0GAECAQEBAQEBAmwohSgBAQEBAy06IgIBCBEEAQEoBzIUCQgCBAESCBOEEGS?= =?us-ascii?q?rXIg/gkKIG4FUP4EPglY1hDcJAQcEBAICAVSFHgKYFAgCiDSGDYE9g2CGMoE?= =?us-ascii?q?Rgi2FEYhaAhETAYEkARw4YXFwFYJ+gh8YjhdvjX8oAoEEgRgBAQ?= X-IronPort-AV: E=Sophos;i="5.49,354,1520899200"; d="scan'208,217";a="389498877" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2018 20:36:20 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w42KaKbD026005 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 May 2018 20:36:20 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 2 May 2018 15:36:19 -0500 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1320.000; Wed, 2 May 2018 15:36:19 -0500 From: "Panos Kampanakis (pkampana)" To: Russ Housley , LAMPS Thread-Topic: [lamps] Draft LAMPS Recharter Thread-Index: AQHT4iO4lXvBuNLFt0WqtxjiqculPqQcmsPA Date: Wed, 2 May 2018 20:36:19 +0000 Message-ID: References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> In-Reply-To: <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.108.5] Content-Type: multipart/alternative; boundary="_000_ade6bc1e860a4739b3e271f4e4752683XCHALN010ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 20:36:25 -0000 --_000_ade6bc1e860a4739b3e271f4e4752683XCHALN010ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Russ, Looks great. One minor correction: s/they will probably not be used for signing X.509 certificates or S/MIME m= essages,/they might not be used for signing X.509 certificates or S/MIME me= ssages, And one question about 4. I think I didn't see many comments on this one in= the recharter email thread. I have a concern that draft-housley-cms-mix-wi= th-psk will not see great deployment. draft-ietf-ipsecme-qr-ikev2 is simila= r, but given the existing IKEv2 wide deployment, draft-ietf-ipsecme-qr-ikev= 2 had to exist as temporary solution in order to prevent downgrades to IKEv= 1 because of QC concerns. I don't see the same issue for CMS. And given the= challenge with establishing the PSK, it will likely not see wide adoption = before the NIST PQ Project standardizes on PQ algorithms that can go into C= MS. Rgs, Panos From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley Sent: Wednesday, May 02, 2018 10:42 AM To: LAMPS Subject: [lamps] Draft LAMPS Recharter Based on the discussion in London and the "Potential Topics for LAMPS Recha= rter" mail thread. We propose the attached charter text. Please review an= d comment. Russ & Tim =3D =3D =3D =3D =3D =3D =3D =3D =3D The PKIX and S/MIME Working Groups have been closed for some time. Some updates have been proposed to the X.509 certificate documents produced by the PKIX Working Group and the electronic mail security documents produced by the S/MIME Working Group. The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working Group is chartered to make updates where there is a known constituency interested in real deployment and there is at least one sufficiently well specified approach to the update so that the working group can sensibly evaluate whether to adopt a proposal. The LAMPS WG is now tackling these topics: 1. Specify a discovery mechanism for CAA records to replace the one described in RFC 6844. Implementation experience has demonstrated an ambiguity in the handling of CNAME and DNAME records during discovery in RFC 6844, and subsequent discussion has suggested that a different discovery approach would resolve limitations inherent in that approach. 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. Unlike the previous hashing standards, the SHA-3 family of functions are the outcome of an open competition. They have a clear design rationale and have received a lot of public analysis, giving great confidence that the SHA-3 family of functions are secure. Also, since SHA-3 uses a very different construction from SHA-2, the SHA-3 family of functions offers an excellent alternative. In particular, SHAKE128/256 and SHAKE256/512 offer security and performance benefits. 3. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information, as a result revoking them pointless. 4. Specify the use of a pre-shared key (PSK) along with other key management techniques with supported by the Cryptographic Message Syntax (CMS) as a near-term mechanism to protect present day communication from the future invention of a large-scale quantum computer. The invention of a such a quantum computer would pose a serious challenge for the key management algorithms that are widely deployed, especially the key transport and key agreement algorithms used today with the CMS to protect S/MIME messages. 5. Specify the use of hash-based signatures with the Cryptographic Message Syntax (CMS). A hash-based signature uses small private and public keys, and it has low computational cost; however, the signature values are quite large. For this reason they will probably not be used for signing X.509 certificates or S/MIME messages, but they are secure even if a large-scale quantum computer is invented. These properties make hash-based signatures useful in some environments, such a the distribution of software updates. 6. Specifies a certificate extension that is carried in a self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate, to identify the next public key that will be used by the trust anchor. In addition, the LAMPS WG may investigate other updates to documents produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt any of these potential work items without rechartering. MILESTONES Mar 2018: Adopt a draft for rfc6844bis Apr 2018: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512 Apr 2018: Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512 Jun 2018: Adopt a draft for short-lived certificate conventions Jun 2018: Adopt a draft for the CMS with PSK Jun 2018: Adopt a draft for hash-based signatures with the CMS Jun 2018: Adopt a draft for root key rollover certificate extension Jul 2018: rfc6844bis sent to IESG for standards track publication Aug 2018: Root key rollover certificate extension sent to IESG for informational publication Sep 2018: SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for standards track publication Sep 2018: SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for standards track publication Oct 2018: Short-lived certificate conventions sent to IESG for BCP publication Oct 2018: The CMS with PSK sent to IESG for standards track publication Dec 2018: Hash-based signatures with the CMS sent to IESG for standards track publication --_000_ade6bc1e860a4739b3e271f4e4752683XCHALN010ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Russ,


Looks great. One minor correction:

s/they will probably not be us= ed for signing X.509 certificates or S/MIME messages,/they might not be used for signing X.509 certificates or S/MIME messages,

 

And one question about 4. I think I d= idn’t see many comments on this one in the recharter email thread. I = have a concern that draft-housley-cms-mix-with-psk will not see great deployment. draft-ietf-ipsecme-qr-ikev2 is similar, but give= n the existing IKEv2 wide deployment, draft-ietf-ipsecme-qr-ikev2 had to ex= ist as temporary solution in order to prevent downgrades to IKEv1 because o= f QC concerns. I don’t see the same issue for CMS. And given the challenge with establishing the PSK, it will = likely not see wide adoption before the NIST PQ Project standardizes on PQ = algorithms that can go into CMS.

 

Rgs,

Panos

 

From: Spasm [mailto:spasm-bounces@ie= tf.org] On Behalf Of Russ Housley
Sent: Wednesday, May 02, 2018 10:42 AM
To: LAMPS <spasm@ietf.org>
Subject: [lamps] Draft LAMPS Recharter

 

Based on the discussion in London and the "Potential Topics f= or LAMPS Recharter" mail thread.  We propose the attached charter= text.  Please review and comment.


Russ & Tim

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

The PKIX and S/MIME Working Groups have been closed for some time. Some
updates have been proposed to the X.509 certificate documents produced = ;
by the PKIX Working Group and the electronic mail security documents <= br> produced by the S/MIME Working Group.

The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working <= br> Group is chartered to make updates where there is a known constituency = ;
interested in real deployment and there is at least one sufficiently <= br> well specified approach to the update so that the working group can  sensibly evaluate whether to adopt a proposal.

The LAMPS WG is now tackling these topics:

1. Specify a discovery mechanism for CAA records to replace the one
described in RFC 6844.  Implementation experience has demonstrated an<= br> ambiguity in the handling of CNAME and DNAME records during discovery
in RFC 6844, and subsequent discussion has suggested that a different
discovery approach would resolve limitations inherent in that approach.

2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. Unlike the previous hashing standards, the SHA-3 family of functions are the outcome of an open competition.  They have a clear design rational= e
and have received a lot of public analysis, giving great confidence that the SHA-3 family of functions are secure.  Also, since SHA-3 uses a ve= ry
different construction from SHA-2, the SHA-3 family of functions offers
an excellent alternative.  In particular, SHAKE128/256 and SHAKE256/51= 2
offer security and performance benefits.

3. Specify the use of short-lived X.509 certificates for which no
revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan that is shorter than the time
needed to detect, report, and distribute revocation information, as a
result revoking them pointless.

4. Specify the use of a pre-shared key (PSK) along with other key 
management techniques with supported by the Cryptographic Message
Syntax (CMS) as a near-term mechanism to protect present day
communication from the future invention of a large-scale quantum
computer.  The invention of a such a quantum computer would pose a
serious challenge for the key management algorithms that are widely
deployed, especially the key transport and key agreement algorithms
used today with the CMS to protect S/MIME messages.

5. Specify the use of hash-based signatures with the Cryptographic
Message Syntax (CMS).  A hash-based signature uses small private and public keys, and it has low computational cost; however, the signature
values are quite large.  For this reason they will probably not be use= d
for signing X.509 certificates or S/MIME messages, but they are secure
even if a large-scale quantum computer is invented.  These properties<= br> make hash-based signatures useful in some environments, such a the
distribution of software updates.

6. Specifies a certificate extension that is carried in a self-signed
certificate for a trust anchor, which is often called a Root
Certification Authority (CA) certificate, to identify the next
public key that will be used by the trust anchor.

In addition, the LAMPS WG may investigate other updates to documents
produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt
any of these potential work items without rechartering.

MILESTONES

Mar 2018: Adopt a draft for rfc6844bis
Apr 2018: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512
Apr 2018: Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512
Jun 2018: Adopt a draft for short-lived certificate conventions
Jun 2018: Adopt a draft for the CMS with PSK 
Jun 2018: Adopt a draft for hash-based signatures with the CMS
Jun 2018: Adopt a draft for root key rollover certificate extension  Jul 2018: rfc6844bis sent to IESG for standards track publication
Aug 2018: Root key rollover certificate extension sent to IESG for
            inf= ormational publication
Sep 2018: SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for
            sta= ndards track publication
Sep 2018: SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for
            sta= ndards track publication
Oct 2018: Short-lived certificate conventions sent to IESG for BCP
            pub= lication
Oct 2018: The CMS with PSK sent to IESG for standards track publication
Dec 2018: Hash-based signatures with the CMS sent to IESG for standards
            tra= ck publication

--_000_ade6bc1e860a4739b3e271f4e4752683XCHALN010ciscocom_-- From nobody Wed May 2 13:45:31 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1791242F7 for ; Wed, 2 May 2018 13:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 TIpCEwWMl1_K for ; Wed, 2 May 2018 13:45:26 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6146012DA23 for ; Wed, 2 May 2018 13:45:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 451B3300A43 for ; Wed, 2 May 2018 16:45:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ir7CIwvBSfvm for ; Wed, 2 May 2018 16:45:22 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id C4421300A3E; Wed, 2 May 2018 16:45:22 -0400 (EDT) From: Russ Housley Message-Id: <1E6A89B6-82C7-4D8F-8E36-7FF9B2106293@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D460871A-260E-4C78-A4FA-2C5016503193" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 2 May 2018 16:45:23 -0400 In-Reply-To: Cc: LAMPS To: Panos Kampanakis References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 20:45:28 -0000 --Apple-Mail=_D460871A-260E-4C78-A4FA-2C5016503193 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 2, 2018, at 4:36 PM, Panos Kampanakis (pkampana) = wrote: >=20 > Hi Russ, >=20 > Looks great. One minor correction:=20 > s/they will probably not be used for signing X.509 certificates or = S/MIME messages,/they might not be used for signing X.509 certificates = or S/MIME messages, Sure. > =20 > And one question about 4. I think I didn=E2=80=99t see many comments = on this one in the recharter email thread. I have a concern that = draft-housley-cms-mix-with-psk will not see great deployment. = draft-ietf-ipsecme-qr-ikev2 is similar, but given the existing IKEv2 = wide deployment, draft-ietf-ipsecme-qr-ikev2 had to exist as temporary = solution in order to prevent downgrades to IKEv1 because of QC concerns. = I don=E2=80=99t see the same issue for CMS. And given the challenge with = establishing the PSK, it will likely not see wide adoption before the = NIST PQ Project standardizes on PQ algorithms that can go into CMS. I asked our AD about this, and he felt that a near-term CMS solution was = worth discussing. The IKE environment is somewhat different, and it is = worth discussing the size of the group that would need access to the PSK = for this to be viable. Obviously, it is not a PSK if everyone on the = public Internet has access to it. Russ --Apple-Mail=_D460871A-260E-4C78-A4FA-2C5016503193 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On May 2, 2018, at 4:36 PM, Panos Kampanakis (pkampana) = <pkampana@cisco.com> wrote:

Hi Russ,

Looks great. One minor = correction: 
s/they will probably not be used = for signing X.509 certificates or S/MIME messages,/they might not be used for signing = X.509 certificates or S/MIME = messages,

Sure.

 
And one question about = 4. I think I didn=E2=80=99t see many comments on this one in the = recharter email thread. I have a concern that = draft-housley-cms-mix-with-psk will not see great deployment. = draft-ietf-ipsecme-qr-ikev2 is similar, but given the existing IKEv2 = wide deployment, draft-ietf-ipsecme-qr-ikev2 had to exist as temporary = solution in order to prevent downgrades to IKEv1 because of QC concerns. = I don=E2=80=99t see the same issue for CMS. And given the challenge with = establishing the PSK, it will likely not see wide adoption before the = NIST PQ Project standardizes on PQ algorithms that can go into = CMS.

I = asked our AD about this, and he felt that a near-term CMS solution was = worth discussing.  The IKE environment is somewhat different, and = it is worth discussing the size of the group that would need access to = the PSK for this to be viable.  Obviously, it is not a PSK if = everyone on the public Internet has access to it.

Russ

= --Apple-Mail=_D460871A-260E-4C78-A4FA-2C5016503193-- From nobody Wed May 2 14:06:23 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2023412DA23 for ; Wed, 2 May 2018 14:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 vY-0H4X05X0M for ; Wed, 2 May 2018 14:06:20 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669BC12420B for ; Wed, 2 May 2018 14:06:20 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id E5C7820051C39 for ; Wed, 2 May 2018 14:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=9MforRsQ6QEDEqWtQnuKwEd6OCw=; b= k8ArDHqpdPCBXWtP7KMoTIicfMHRrsOG7iwqdOQLTQKoLmhzSjlvA+c61FZP9QJr mT3IAk0wg8egX/uxmyygj+qQ4z6+nriCMzP5UxgChU0zgK7m5mnJy8+rNXVoZLoc muFxe7va3xcx+Rq9o0WmRXYpeK4+Ms5zA50jXRTZpHw= Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id D691920051C36 for ; Wed, 2 May 2018 14:06:19 -0700 (PDT) Received: by mail-io0-f176.google.com with SMTP id t23-v6so19155036ioc.10 for ; Wed, 02 May 2018 14:06:19 -0700 (PDT) X-Gm-Message-State: ALQs6tCaGe4NbgZXoiBiiglZTM0nRM/HIirTV0iKSrmLbUQA7XOXEGB7 +mcg085roLYH+GIdrOL7GyA4eOXvufLtCbLHYjk= X-Google-Smtp-Source: AB8JxZoXAUpvCzGbMW3MjTv8KN7Tz5aAV2J8WYkRl+d+bamFp61L6grZl895g3YqLiKnx+IZiWIc6HE6dtLDSRSg3lQ= X-Received: by 2002:a6b:d312:: with SMTP id s18-v6mr18736792iob.284.1525295179291; Wed, 02 May 2018 14:06:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:985a:0:0:0:0:0 with HTTP; Wed, 2 May 2018 14:06:18 -0700 (PDT) In-Reply-To: <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> From: Ryan Sleevi Date: Wed, 2 May 2018 17:06:18 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Russ Housley Cc: LAMPS Content-Type: multipart/alternative; boundary="00000000000056eade056b3f7533" Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 21:06:22 -0000 --00000000000056eade056b3f7533 Content-Type: text/plain; charset="UTF-8" On Wed, May 2, 2018 at 10:41 AM, Russ Housley wrote: > Based on the discussion in London and the "Potential Topics for LAMPS > Recharter" mail thread. We propose the attached charter text. Please > review and comment. > > Russ & Tim > > = = = = = = = = = > > 3. Specify the use of short-lived X.509 certificates for which no > revocation information is made available by the Certification Authority. > Short-lived certificates have a lifespan that is shorter than the time > needed to detect, report, and distribute revocation information, as a > result revoking them pointless. > I didn't see much discussion on the list in support for this, but apologies, I missed the discussion in SECDISPATCH when this draft was discussed. Is this being envisioned for the use in the PKI typically called the "Web PKI", or is this being seen as a draft for private use cases? I have read the draft, and do not feel this was clearly and unambiguously answered. I ask because, for various policy reasons, I would expect that undertaking this work may result in policies that explicitly prohibit it from being deployed on the Web PKI. As a practical matter, the draft acknowledges an alternative design (namely, OCSP stapling), but its two objections to this work do not hold. As a consequence, I have concerns about the motivations for and the alternatives considered, and thus don't think LAMPS needs to consider such work in scope at this time. --00000000000056eade056b3f7533 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 2, 2018 at 10:41 AM, Russ Housley <housley@vigilsec.com= > wrote:
Based on the discussion in London and the "Poten= tial Topics for LAMPS Recharter" mail thread.=C2=A0 We propose the att= ached charter text.=C2=A0 Please review and comment.

Russ &a= mp; Tim

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

3. Specify the us= e of short-lived X.509 certificates for which no
revocation information = is made available by the Certification Authority.
Short-lived certificat= es have a lifespan that is shorter than the time
needed to detect, repor= t, and distribute revocation information, as a
result revoking them poin= tless.

I didn't see muc= h discussion on the list in support for this, but apologies, I missed the d= iscussion in SECDISPATCH when this draft was discussed.

Is this being envisioned for the use in the PKI typically called the = "Web PKI", or is this being seen as a draft for private use cases= ? I have read the draft, and do not feel this was clearly and unambiguously= answered.

I ask because, for various policy reaso= ns, I would expect that undertaking this work may result in policies that e= xplicitly prohibit it from being deployed on the Web PKI.

As a practical matter, the draft acknowledges an alternative design= (namely, OCSP stapling), but its two objections to this work do not hold. = As a consequence, I have concerns about the motivations for and the alterna= tives considered, and thus don't think LAMPS needs to consider such wor= k in scope at this time.
--00000000000056eade056b3f7533-- From nobody Wed May 2 14:13:23 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5962612DA19 for ; Wed, 2 May 2018 14:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 S1_fVkph0tof for ; Wed, 2 May 2018 14:13:20 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 993A5120721 for ; Wed, 2 May 2018 14:13:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 88B08300558 for ; Wed, 2 May 2018 17:13:18 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6xlGecHkXxoC for ; Wed, 2 May 2018 17:13:17 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 0F9543004FE; Wed, 2 May 2018 17:13:17 -0400 (EDT) From: Russ Housley Message-Id: <9010C483-64C0-40DB-B9EB-57FC77BD0795@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_55156075-BB6A-4B4F-B017-6B2C45F6D47B" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 2 May 2018 17:13:17 -0400 In-Reply-To: Cc: LAMPS To: Ryan Sleevi References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 21:13:22 -0000 --Apple-Mail=_55156075-BB6A-4B4F-B017-6B2C45F6D47B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 2, 2018, at 5:06 PM, Ryan Sleevi wrote: >=20 >=20 >=20 > On Wed, May 2, 2018 at 10:41 AM, Russ Housley > wrote: > Based on the discussion in London and the "Potential Topics for LAMPS = Recharter" mail thread. We propose the attached charter text. Please = review and comment. >=20 > Russ & Tim >=20 > =3D =3D =3D =3D =3D =3D =3D =3D =3D >=20 > 3. Specify the use of short-lived X.509 certificates for which no > revocation information is made available by the Certification = Authority. > Short-lived certificates have a lifespan that is shorter than the time > needed to detect, report, and distribute revocation information, as a > result revoking them pointless. >=20 > I didn't see much discussion on the list in support for this, but = apologies, I missed the discussion in SECDISPATCH when this draft was = discussed. >=20 > Is this being envisioned for the use in the PKI typically called the = "Web PKI", or is this being seen as a draft for private use cases? I = have read the draft, and do not feel this was clearly and unambiguously = answered. >=20 > I ask because, for various policy reasons, I would expect that = undertaking this work may result in policies that explicitly prohibit it = from being deployed on the Web PKI. >=20 > As a practical matter, the draft acknowledges an alternative design = (namely, OCSP stapling), but its two objections to this work do not = hold. As a consequence, I have concerns about the motivations for and = the alternatives considered, and thus don't think LAMPS needs to = consider such work in scope at this time. I was in the room for the SECDISPATCH discussion. I'll share my view at = the end of that discussion. Many people were interested in short-lived = certificates, and not just for the Web PKI. Some people understood that = the Web PKI might not be able to use short-lived certificates right = away, but if this work isn't done, then the Web PKI will not ever be = able to use them. So, other PKI environments might be able to make = immediate use of short-lived certificates, and the Web PKI might also = make use of them someday. Russ --Apple-Mail=_55156075-BB6A-4B4F-B017-6B2C45F6D47B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On May 2, 2018, at 5:06 PM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:



On Wed, May 2, 2018 at 10:41 AM, Russ Housley = <housley@vigilsec.com> = wrote:
Based on the discussion in = London and the "Potential Topics for LAMPS Recharter" mail thread.  We = propose the attached charter text.  Please review and = comment.

Russ & Tim

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

3. Specify the use of short-lived X.509 = certificates for which no
revocation information is made = available by the Certification Authority.
Short-lived = certificates have a lifespan that is shorter than the time
needed to detect, report, and distribute revocation = information, as a
result revoking them pointless.

I didn't see much discussion on the = list in support for this, but apologies, I missed the discussion in = SECDISPATCH when this draft was discussed.

Is this being envisioned for the use in = the PKI typically called the "Web PKI", or is this being seen as a draft = for private use cases? I have read the draft, and do not feel this was = clearly and unambiguously answered.

I ask because, for various policy = reasons, I would expect that undertaking this work may result in = policies that explicitly prohibit it from being deployed on the Web = PKI.

As a = practical matter, the draft acknowledges an alternative design (namely, = OCSP stapling), but its two objections to this work do not hold. As a = consequence, I have concerns about the motivations for and the = alternatives considered, and thus don't think LAMPS needs to consider = such work in scope at this time.

I was in the = room for the SECDISPATCH discussion.  I'll share my view at the end = of that discussion.  Many people were interested in short-lived = certificates, and not just for the Web PKI.  Some people understood = that the Web PKI might not be able to use short-lived certificates right = away, but if this work isn't done, then the Web PKI will not ever be = able to use them.  So, other PKI environments might be able to make = immediate use of short-lived certificates, and the Web PKI might also = make use of them someday.

Russ

= --Apple-Mail=_55156075-BB6A-4B4F-B017-6B2C45F6D47B-- From nobody Wed May 2 14:20:51 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A58912DA23 for ; Wed, 2 May 2018 14:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wa5nrYogCTJt for ; Wed, 2 May 2018 14:20:48 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::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 AA571120721 for ; Wed, 2 May 2018 14:20:47 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id o2-v6so12549539wrj.13 for ; Wed, 02 May 2018 14:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=veFpqqOWH1NsvWymKoEh/2jg+g3zuW9Vwkd4VBf6y3w=; b=teSdSIajbg+HX2fXeOQFOk+CAqhsorxJwVlYuAQ/i9eKXX4cds+GwEqKpCp3KKv5Yk go6os5whW6MFi4GE/P1VK9bdKsTb8WZzrGoN8DndUHiQYyxk7HE50+AjKw2Rrs23UdH2 ap2GwbIJNkXHN5m2dYjYIR+0bWJKtxiIF0njgbkNzDnstdBR/YPuVDNPelvtqhLYLf3I vze7oKs7yMF+v0QwgdlKl3/WpnFnnMc4sH7aJMQ4u9nl4j2c4uHyQg6Jf8g1OFaUCdSQ Nysh5kuoS7YdmoLalRM/NPUKhXYmIQX+Roj0urwd3Vm1OD9BoPcoUwSFiwNCVAFUpBK3 KX/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=veFpqqOWH1NsvWymKoEh/2jg+g3zuW9Vwkd4VBf6y3w=; b=SPLk+Zhnhhh2oetThaeWVpy5xMgIOcoUo7CltxWdTxu7H7VpCl9YPif+KYOqRPEToA JC6Nbkjwvh3/RM4YSgtxCbPUH31LcCYXaPtr8LSWGJoXa4S1rnhEUam91B7s1jdgWfwC vo1ZB059vRkwxd2NsojWi4XCKwDq42Kjk0exnnRBnF6ppeTFMaUlikyNMZcAbkL94bUq jrYPUgzvGFQMBYwni/tXAfAqiwlXSX2krcWa/D0TrbFYfUwwd/A00Fz7enx9ad6fIadX lgTx8uG5wbOKn6xmHS6kblk7J+mC+3YDrSwlU1kjuFyCOrK1/cQIvhEFrbEYWofLmtFE 1xcw== X-Gm-Message-State: ALQs6tAdAgmVozioIWGqcF7iLwasfj3ttPRLtPhCYgVvaG9ibOSo4GHW 9uARv5FBliWtc5gr4n/hpOc= X-Google-Smtp-Source: AB8JxZqCb8bOwVr/tnknb3KrXc/hjJQ2rv87o1jcnQGioyWxlVHHIMaun/SKclg4GhuH8UWG1kHWHQ== X-Received: by 2002:adf:a3c7:: with SMTP id m7-v6mr15050332wrb.208.1525296046075; Wed, 02 May 2018 14:20:46 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id l53-v6sm34127970wrc.80.2018.05.02.14.20.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 May 2018 14:20:45 -0700 (PDT) From: Yoav Nir Message-Id: <64CD1067-8639-4C2C-A8EC-ED5FBC14F633@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_89532A0A-AA07-4511-96D6-F3798856A398" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 3 May 2018 00:20:42 +0300 In-Reply-To: Cc: Russ Housley , LAMPS To: Ryan Sleevi References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 21:20:50 -0000 --Apple-Mail=_89532A0A-AA07-4511-96D6-F3798856A398 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 3 May 2018, at 0:06, Ryan Sleevi wrote: >=20 >=20 >=20 > On Wed, May 2, 2018 at 10:41 AM, Russ Housley > wrote: > Based on the discussion in London and the "Potential Topics for LAMPS = Recharter" mail thread. We propose the attached charter text. Please = review and comment. >=20 > Russ & Tim >=20 > =3D =3D =3D =3D =3D =3D =3D =3D =3D >=20 > 3. Specify the use of short-lived X.509 certificates for which no > revocation information is made available by the Certification = Authority. > Short-lived certificates have a lifespan that is shorter than the time > needed to detect, report, and distribute revocation information, as a > result revoking them pointless. >=20 > I didn't see much discussion on the list in support for this, but = apologies, I missed the discussion in SECDISPATCH when this draft was = discussed. >=20 > Is this being envisioned for the use in the PKI typically called the = "Web PKI", or is this being seen as a draft for private use cases? I = have read the draft, and do not feel this was clearly and unambiguously = answered. >=20 > I ask because, for various policy reasons, I would expect that = undertaking this work may result in policies that explicitly prohibit it = from being deployed on the Web PKI. >=20 > As a practical matter, the draft acknowledges an alternative design = (namely, OCSP stapling), but its two objections to this work do not = hold. As a consequence, I have concerns about the motivations for and = the alternatives considered, and thus don't think LAMPS needs to = consider such work in scope at this time. Hi, Ryan. The main motivation for me is things other than the Web PKI. There is = nothing in the draft that makes it not work for the Web PKI, but I would = like to leave it to the group to decide whether the Web PKI is = explicitly excluded. There is a short-term certificate document that *is* for the Web PKI. It = is in the ACME working group. https://tools.ietf.org/html/draft-ietf-acme-star-03 = Despite having some authors in common, the use cases are different. HTH Yoav= --Apple-Mail=_89532A0A-AA07-4511-96D6-F3798856A398 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 3 May 2018, at 0:06, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:



On Wed, May 2, 2018 at 10:41 AM, Russ Housley = <housley@vigilsec.com> = wrote:
Based on the discussion in = London and the "Potential Topics for LAMPS Recharter" mail thread.  We = propose the attached charter text.  Please review and = comment.

Russ & Tim

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

3. Specify the use of short-lived X.509 = certificates for which no
revocation information is made = available by the Certification Authority.
Short-lived = certificates have a lifespan that is shorter than the time
needed to detect, report, and distribute revocation = information, as a
result revoking them pointless.

I didn't see much discussion on the = list in support for this, but apologies, I missed the discussion in = SECDISPATCH when this draft was discussed.

Is this being envisioned for the use in = the PKI typically called the "Web PKI", or is this being seen as a draft = for private use cases? I have read the draft, and do not feel this was = clearly and unambiguously answered.

I ask because, for various policy = reasons, I would expect that undertaking this work may result in = policies that explicitly prohibit it from being deployed on the Web = PKI.

As a = practical matter, the draft acknowledges an alternative design (namely, = OCSP stapling), but its two objections to this work do not hold. As a = consequence, I have concerns about the motivations for and the = alternatives considered, and thus don't think LAMPS needs to consider = such work in scope at this = time.

Hi, Ryan.

The main motivation for me is things other than the Web PKI. = There is nothing in the draft that makes it not work for the Web PKI, = but I would like to leave it to the group to decide whether the Web PKI = is explicitly excluded.

There is a short-term certificate document that *is* for the = Web PKI. It is in the ACME working group.
https://tools.ietf.org/html/draft-ietf-acme-star-03

Despite having some = authors in common, the use cases are different.

HTH

Yoav
= --Apple-Mail=_89532A0A-AA07-4511-96D6-F3798856A398-- From nobody Wed May 2 17:01:33 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4441126DED; Wed, 2 May 2018 17:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hQ7tR_OfoNr; Wed, 2 May 2018 17:01:23 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E46126BF6; Wed, 2 May 2018 17:01:23 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 2 May 2018 16:58:44 -0700 From: Jim Schaad To: 'Matthew Miller' , CC: , , References: <152432458128.20660.6956595430755199355@ietfa.amsl.com> In-Reply-To: <152432458128.20660.6956595430755199355@ietfa.amsl.com> Date: Wed, 2 May 2018 17:01:14 -0700 Message-ID: <054301d3e271$dc22db10$94689130$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIiXucpxcMduUMNivilcG+pvhU0KKOAJOiA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Secdir last call review of draft-ietf-lamps-rfc5750-bis-05 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 00:01:26 -0000 > -----Original Message----- > From: Matthew Miller > Sent: Saturday, April 21, 2018 8:30 AM > To: secdir@ietf.org > Cc: spasm@ietf.org; draft-ietf-lamps-rfc5750-bis.all@ietf.org; = ietf@ietf.org > Subject: Secdir last call review of draft-ietf-lamps-rfc5750-bis-05 >=20 > Reviewer: Matthew Miller > Review result: Has Nits >=20 > I have reviewed this document as part of the security directorate's = ongoing > effort to review all IETF documents being processed by the IESG. = These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments > just like any other last call comments. >=20 > Document: draft-ietf-lamps-rfc5750-bis-05 > Reviewer: Matthew A. Miller > Review Date: 2018-04-21 > IETF LC End Date: 2018-04-27 > IESG Telechat date: N/A >=20 > Summary: >=20 > This document is ready, but there is one nit around PKCS #6 handling = that > might benefit from explanation. >=20 > This document describes the certificate handling expectations for = senders > and receivers of S/MIME 4.0. It obsoletes RFC 5750, adding = requirements to > support internationalized email addresses, increase RSA minimum key = sizes, > and support ECDSA using P-256 and Ed25519; older algorithms such as = DSA, > MD5, and SHA-1 are relegated to historical. >=20 > Major Issues: N/A >=20 > Minor Issues: N/A >=20 > Nits: >=20 > Section 2.2.1. "Historical Note about CMS Certificates" is almost = entired > unchanged, but added a requirement that receivers MUST be able to = process > PCKS #6 extended certificates. This almost seems at odds with the = rest of > the paragraph that precedes this MUST, noting PKCS #6 has little use = and > PKIX is functionally equivalent. > A short explanation of why this additional handling requirement would = seem > helpful. How about the following which is just a description of what we are = looking for in terms of behavior. Receiving agents MUST be able to parser and process a message = containing PKCS #6 extended certificates although ignoring those = certificates is expected behavior. From nobody Wed May 2 17:02:02 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A1A12E854; Wed, 2 May 2018 17:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_2PNBtvr-n1; Wed, 2 May 2018 17:01:26 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6B20126BF6; Wed, 2 May 2018 17:01:25 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 2 May 2018 16:58:50 -0700 From: Jim Schaad To: 'Ines Robles' , CC: , , References: <152482849638.5933.11114167602347254978@ietfa.amsl.com> In-Reply-To: <152482849638.5933.11114167602347254978@ietfa.amsl.com> Date: Wed, 2 May 2018 17:01:22 -0700 Message-ID: <054401d3e271$dfad1340$9f0739c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQF0tXZOTkM/NbIKrujpOyIMJklna6TbSJTA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-rfc5750-bis-05 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 00:01:30 -0000 > -----Original Message----- > From: Ines Robles > Sent: Friday, April 27, 2018 4:28 AM > To: gen-art@ietf.org > Cc: spasm@ietf.org; draft-ietf-lamps-rfc5750-bis.all@ietf.org; = ietf@ietf.org > Subject: Genart last call review of draft-ietf-lamps-rfc5750-bis-05 >=20 > Reviewer: Ines Robles > Review result: Ready with Issues >=20 > Hello, >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area = Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG = for > the IETF Chair. Please treat these comments just like any other last = call > comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-lamps-rfc5750-bis-05 > Reviewer: Ines Robles > Review Date: 27-04-2018 > IETF LC End Date: 27-04-2018 > IESG Telechat date: --- >=20 > Summary: >=20 > I believe the draft is technically good. This document is well written = and clear > to understand. Some minor concerns are mentioned that should be = resolved > before publication. >=20 > Major issues: No major issues found. >=20 > Minor issues: >=20 > Section 1.6: >=20 > It would be nice to start the section with some text like "This = document > obsoletes 5750 due to the addition of the following = information...." This is missing information, however I think it should go into section 1 = - Introduction and not be buried here. The new text does point to this = section. >=20 > Section 2.3: >=20 > "but SHOULD use some other mechanism to determine ...." =3D> It = would be > nice > to mention some examples of the other mechanism >=20 > "...but SHOULD use some other mechanism (such as ....) to = determine..." I am not sure that this would be a useful addition. I can see two = different outcomes from this which neither of which is helpful. * People will complain about implementations which do not implement all = of the items in the list * People will complain that something should not be implemented because = it is not on the list One of the problems is that this will be a list that is not very useful. = Items can range anywhere from use the set of trust points you already = have and don't let it be expanded to call the other person up and get = them to read you a hash value to look at various trusted locations for = root certificates, including some types of transparency logs. I cannot = really say that any of these is what I would recommend. The knowledge = of how trust configuration is handed is an extremely application and = implementation specific function. >=20 > Section 4: >=20 > Related to this: > "Another method under consideration by the IETF is to provide = certificate > retrieval services as part of the existing Domain Name System = (DNS)" >=20 > - This text seems to be out of the date (since belongs as well to = RFC5750 > (2010)), maybe it would be nice to re-write it (e.g. method under > consideration =3D> method approved) and add a reference of the = proposed > methods. Would it be RFC 8162 [1] a good reference for this topic? >=20 > [1] https://tools.ietf.org/html/rfc8162: Using Secure DNS to = Associate > Certificates with Domain Names for S/MIME This was raised during the rfc5751-bis review as well. I have replaced = that sentence with a pointer to the experimental DANE draft. >=20 > Nits/editorial comments: >=20 > Section 2.3: CertificateSet --> Certificate Set >=20 > Section 4.4.1: basicConstraints --> basic Constraints >=20 > Thanks for this document! >=20 > Ines. >=20 From nobody Wed May 2 17:02:47 2018 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD14126DED; Wed, 2 May 2018 17:02:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152530576561.4375.14981340513854475387@ietfa.amsl.com> Date: Wed, 02 May 2018 17:02:45 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc5750-bis-06.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 00:02:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 4.0 Certificate Handling Authors : Jim Schaad Blake Ramsdell Sean Turner Filename : draft-ietf-lamps-rfc5750-bis-06.txt Pages : 26 Date : 2018-05-02 Abstract: This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 5750. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc5750-bis-06 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5750-bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5750-bis-06 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 2 18:31:53 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF4412D777 for ; Wed, 2 May 2018 18:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=H6RJfvxl; dkim=pass (1536-bit key) header.d=taugh.com header.b=kb6j9BCH 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 nRMeNpnwB5wL for ; Wed, 2 May 2018 18:31:50 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 A5DD4127599 for ; Wed, 2 May 2018 18:31:50 -0700 (PDT) Received: (qmail 16437 invoked from network); 3 May 2018 01:31:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=4032.5aea6685.k1805; bh=c0B7wRt8CzBMm07bOdvmpqG7SNxzT9Ss3dg06XxIPmY=; b=H6RJfvxlc7elJFfSrqvdMdU6SQzda64KfgWAxEQjl0YzzqXZGb42IUAJppoIS7RLS6whZUcgclXAt8R+k4QCnjXLP+wqfGNEDbbJtbvmkgukZKxSgiqqbF+WzucPMbcmV+0GfVXjc3iUF5zIfVdi9Rrj/cs4Iymdz5UzZkQYAjzJI/qhsHSlpef4gSSiGaNehmaHVZSyaWB3wr55s0exy7wz14pyJjyAksyzE0z+2PhcB7pekqAK7SgMnjearOaf DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=4032.5aea6685.k1805; bh=c0B7wRt8CzBMm07bOdvmpqG7SNxzT9Ss3dg06XxIPmY=; b=kb6j9BCHrAfr/7b0tqjLeGUYjz9o66pVj7Nf1VbYO0gW9aOiZR6GIZfBApI8YbDdHMAdV09T/chD0pNgwVqK1a7atJJYlpd0XfzJ8J+bPbSRL+SuZSjGEO1HUHjrNYFmLuXjWmUbnB8aDENExqextaFZaQBNkEAbRAXZ97mM/C4C9cYsqR9N9tdC8Gt6QYTgOAELtppIiDr8icQ7zcD3ugJQuCArJSqs52lLU9YskstbwK6V1SyaKuMPfZ5NjfMX Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 03 May 2018 01:31:49 -0000 Received: by ary.qy (Postfix, from userid 501) id 5C4B025CE95C; Wed, 2 May 2018 21:31:49 -0400 (EDT) Date: 2 May 2018 21:31:49 -0400 Message-Id: <20180503013149.5C4B025CE95C@ary.qy> From: "John Levine" To: spasm@ietf.org Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: [lamps] Semi-OT: crypto code in RFCs X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 01:31:52 -0000 For reasons anyone familiar with US law can probably guess, I'm trying to collect all of the RFCs that include cryptographic source code. RFC 8032 has python code for EC signing and verification. Any others I should put on the list? R's, John PS: Please do not tell us how silly the US rules about crypto software export are. We know. From nobody Wed May 2 18:43:45 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D189812D77B for ; Wed, 2 May 2018 18:43:43 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 ZxtNzoT50axT for ; Wed, 2 May 2018 18:43:42 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 1F0A9127599 for ; Wed, 2 May 2018 18:43:42 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w431bR5a003791; Thu, 3 May 2018 02:43:41 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Uj13f1gKtjt+ZyQWwc+WjZGqUSvfVE1hEzKFpxmR17M=; b=KYjoZTi63NzHC5HXlmMv1G3TuHZ0VUIe9d+0M3DcUnGNbqymSVHtKCyDHhEv8Nip/555 +NfLc0nlTNVx4q7BpDmd+J6zV3l/yWDBk/ECWjDiCk5Cz2XpewVnPlAzpEQ8LRt9i8jZ bfHpPlt/d5E50UGNdt/SFLH9aMHLtlWHMJcizFtKNfwV5uSqu2YuwWqsoDYd6WyIOwN5 4XE4dS+Ha8POIFqQa0H6sP4NnDF9mSv8gRFeS2XYm1P+QxCj5ypsT5U7HFYxktSc7axw lGb2j8VXFhijb0q7lQyBeUevS2tLbixiRymX1zVccpAqxpgJz5ovW//+lKBDasCULhMu hg== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2hq4snjsy7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 May 2018 02:43:41 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w431f5uI023002; Wed, 2 May 2018 21:43:40 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint2.akamai.com with ESMTP id 2hmm9v41wk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 02 May 2018 21:43:39 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 2 May 2018 21:43:39 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Wed, 2 May 2018 21:43:39 -0400 From: "Salz, Rich" To: John Levine , "spasm@ietf.org" Thread-Topic: [lamps] Semi-OT: crypto code in RFCs Thread-Index: AQHT4n6GZGc/052ZzkSj1BAI1nsrOaQdO1MA Date: Thu, 3 May 2018 01:43:38 +0000 Message-ID: References: <20180503013149.5C4B025CE95C@ary.qy> In-Reply-To: <20180503013149.5C4B025CE95C@ary.qy> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.c.0.180410 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.28] Content-Type: text/plain; charset="utf-8" Content-ID: <8C0C9A62B6019449A3329C78700BDE32@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-03_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805030012 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-03_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805030012 Archived-At: Subject: Re: [lamps] Semi-OT: crypto code in RFCs X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 01:43:44 -0000 SSBiZWxpZXZlIHRoYXQgQmVybnN0ZWluIHYgVVMgc2hvd2VkIHRoYXQgZG9jdW1lbnRzIGFyZSBw cm90ZWN0ZWQsIGV2ZW4gaW4gdGhlIFVTDQoNCu+7v09uIDUvMi8xOCwgOTozMSBQTSwgIkpvaG4g TGV2aW5lIiA8am9obmxAdGF1Z2guY29tPiB3cm90ZToNCg0KICAgIEZvciByZWFzb25zIGFueW9u ZSBmYW1pbGlhciB3aXRoIFVTIGxhdyBjYW4gcHJvYmFibHkgZ3Vlc3MsIEknbSB0cnlpbmcNCiAg ICB0byBjb2xsZWN0IGFsbCBvZiB0aGUgUkZDcyB0aGF0IGluY2x1ZGUgY3J5cHRvZ3JhcGhpYyBz b3VyY2UgY29kZS4NCiAgICBSRkMgODAzMiBoYXMgcHl0aG9uIGNvZGUgZm9yIEVDIHNpZ25pbmcg YW5kIHZlcmlmaWNhdGlvbi4gIEFueSBvdGhlcnMNCiAgICBJIHNob3VsZCBwdXQgb24gdGhlIGxp c3Q/DQogICAgDQogICAgUidzLA0KICAgIEpvaG4NCiAgICANCiAgICBQUzogUGxlYXNlIGRvIG5v dCB0ZWxsIHVzIGhvdyBzaWxseSB0aGUgVVMgcnVsZXMgYWJvdXQgY3J5cHRvIHNvZnR3YXJlDQog ICAgZXhwb3J0IGFyZS4gIFdlIGtub3cuDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBTcGFzbSBtYWlsaW5nIGxpc3QNCiAgICBT cGFzbUBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3Bhc20NCiAgICANCg0K From nobody Wed May 2 19:20:04 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F147127599 for ; Wed, 2 May 2018 19:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 EF90hft0rUXz for ; Wed, 2 May 2018 19:19:59 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBE21274D2 for ; Wed, 2 May 2018 19:19:59 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id BFC8F6800CD08 for ; Wed, 2 May 2018 19:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=rlXLX28bBKXtXqFDfbdZnxXMaXQ=; b= oVjHwMXqNMT2CETzSRYY3n0in+j04IAbyOmKL77iSecfhzI6kvj3opxl/wscd3xL NMPJa3e27fiSf2nUKhzyuRTyHAqp+j+LIMxPH6KgOWI1N3xbpHKYHBuVE+/Q67Ea OOg4n8Y0k7//PDagIhvwnuy5KQhtc7q+McTym8G6CFs= Received: from mail-it0-f45.google.com (mail-it0-f45.google.com [209.85.214.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id 868056800CD02 for ; Wed, 2 May 2018 19:19:58 -0700 (PDT) Received: by mail-it0-f45.google.com with SMTP id q4-v6so11566045ite.3 for ; Wed, 02 May 2018 19:19:58 -0700 (PDT) X-Gm-Message-State: ALQs6tDHFz+x3Q7n+KEyD/9H8eV6RaJSUu+/jdLyTPHrgyaIBE58zodT 8tuUWnppwIunkRUbChP/68Z/cgKmwWBBC9kl1vQ= X-Google-Smtp-Source: AB8JxZpxv21pBBLVQNgdzY5Viig5TKL7yLkdmwrekgWx6BNCa2xEVgpw/mUSjAUCxNdohZZuJnPm6uD+UV4hrgENjBg= X-Received: by 2002:a24:fa4b:: with SMTP id v72-v6mr22135686ith.148.1525313997852; Wed, 02 May 2018 19:19:57 -0700 (PDT) MIME-Version: 1.0 References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> <64CD1067-8639-4C2C-A8EC-ED5FBC14F633@gmail.com> In-Reply-To: <64CD1067-8639-4C2C-A8EC-ED5FBC14F633@gmail.com> From: Ryan Sleevi Date: Thu, 03 May 2018 02:19:47 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Yoav Nir Cc: LAMPS , Russ Housley , Ryan Sleevi Content-Type: multipart/alternative; boundary="000000000000035c3f056b43d79d" Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 02:20:02 -0000 --000000000000035c3f056b43d79d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 2, 2018 at 5:20 PM Yoav Nir wrote: > > > On 3 May 2018, at 0:06, Ryan Sleevi wrote: > > > > On Wed, May 2, 2018 at 10:41 AM, Russ Housley > wrote: > >> Based on the discussion in London and the "Potential Topics for LAMPS >> Recharter" mail thread. We propose the attached charter text. Please >> review and comment. >> >> Russ & Tim >> >> =3D =3D =3D =3D =3D =3D =3D =3D =3D >> >> 3. Specify the use of short-lived X.509 certificates for which no >> revocation information is made available by the Certification Authority. >> Short-lived certificates have a lifespan that is shorter than the time >> needed to detect, report, and distribute revocation information, as a >> result revoking them pointless. >> > > I didn't see much discussion on the list in support for this, but > apologies, I missed the discussion in SECDISPATCH when this draft was > discussed. > > Is this being envisioned for the use in the PKI typically called the "Web > PKI", or is this being seen as a draft for private use cases? I have read > the draft, and do not feel this was clearly and unambiguously answered. > > I ask because, for various policy reasons, I would expect that undertakin= g > this work may result in policies that explicitly prohibit it from being > deployed on the Web PKI. > > As a practical matter, the draft acknowledges an alternative design > (namely, OCSP stapling), but its two objections to this work do not hold. > As a consequence, I have concerns about the motivations for and the > alternatives considered, and thus don't think LAMPS needs to consider suc= h > work in scope at this time. > > > Hi, Ryan. > > The main motivation for me is things other than the Web PKI. There is > nothing in the draft that makes it not work for the Web PKI, but I would > like to leave it to the group to decide whether the Web PKI is explicitly > excluded. > > There is a short-term certificate document that *is* for the Web PKI. It > is in the ACME working group. > https://tools.ietf.org/html/draft-ietf-acme-star-03 > > > Despite having some authors in common, the use cases are different. > I=E2=80=99m curious to understand more of these use cases, as to understand= the presumed implementors for the running code. I=E2=80=99m guessing that, give= n the goal just presented, these are going to be locally managed CAs and/or for server-to-server mutual auth scenarios? My biggest qualm is that the draft seems predicated on two statements about why existing technology is insufficient: 1) OCSP Stapling requires servers to support Stapling 2) Client certs cannot staple There doesn=E2=80=99t seem to be any explanation as to why #1 doesn=E2=80= =99t equally apply (if not moreso?) to this use case, given the need to replace the certificates frequently due to their short lifetime. The efforts towards ACME-STAR are illustrative of exactly that - a need for new management capabilities. With regard to #2, I=E2=80=99m trying to understand how this compares to TL= S1.3=E2=80=99s restructuring of the Certificate message, which seems like it will have a significantly broader adoption and a lower barrier to adoption, especially in the case of client certs. While presented as specific examples, I think they more generally speak to a lack of definition as to the problem space or audience within the current draft, thus making it difficult to see how adoption, implementation, or consensus will emerge. While personally skeptical of the idea, I fully accept that there may be some non-WebPKI use cases for this that could benefit from this work, but it seems like nailing those down and identifying them should be encouraged as a prerequisite for adoption. In particular, it seems like fleshing how this is meaningfully different in use case or deployment from existing technologies such as OCSP Stapling seems good, so as to prevent an unnecessarily proliferation of ways to solve the same basic problem. --000000000000035c3f056b43d79d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, May 2, 2018 a= t 5:20 PM Yoav Nir <ynir.ietf@gma= il.com> wrote:


On 3 May 2018, at 0:06, Ryan Sleevi <ryan-ietf@sleevi.com> wr= ote:



On Wed,= May 2, 2018 at 10:41 AM, Russ Housley <housley@vigilsec.com> wrote:<= br>
Based= on the discussion in London and the "Potential Topics for LAMPS Recharter" mail thre= ad.=C2=A0 We propose the attached charter text.=C2=A0 Please review and com= ment.

Russ & Tim

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

3. Specify the use of short-lived X.509 certificates for which n= o
revocation information is made available by the Certification Authorit= y.
Short-lived certificates have a lifespan that is shorter than the tim= e
needed to detect, report, and distribute revocation information, as a<= br>result revoking them pointless.

I didn't see much discussion on the list in support for this, b= ut apologies, I missed the discussion in SECDISPATCH when this draft was di= scussed.

Is this being envisioned for the use in t= he PKI typically called the "Web PKI", or is this being seen as a= draft for private use cases? I have read the draft, and do not feel this w= as clearly and unambiguously answered.

I ask becau= se, for various policy reasons, I would expect that undertaking this work m= ay result in policies that explicitly prohibit it from being deployed on th= e Web PKI.

As a practical matter, the draft acknow= ledges an alternative design (namely, OCSP stapling), but its two objection= s to this work do not hold. As a consequence, I have concerns about the mot= ivations for and the alternatives considered, and thus don't think LAMP= S needs to consider such work in scope at this time.

Hi, Ryan.

The main = motivation for me is things other than the Web PKI. There is nothing in the= draft that makes it not work for the Web PKI, but I would like to leave it= to the group to decide whether the Web PKI is explicitly excluded.

There is a short-term certificate document that *is* for = the Web PKI. It is in the ACME working group.

Despite having some= authors in common, the use cases are different.

I=E2=80=99m curious to understa= nd more of these use cases, as to understand the presumed implementors for = the running code. I=E2=80=99m guessing that, given the goal just presented,= these are going to be locally managed CAs and/or for server-to-server mutu= al auth scenarios?

My bi= ggest qualm is that the draft seems predicated on two statements about why = existing technology is insufficient:
1) OCSP Staplin= g requires servers to support Stapling
2) Client cer= ts cannot staple

There d= oesn=E2=80=99t seem to be any explanation as to why #1 doesn=E2=80=99t equa= lly apply (if not moreso?) to this use case, given the need to replace the = certificates frequently due to their short lifetime. The efforts towards AC= ME-STAR are illustrative of exactly that - a need for new management capabi= lities.

With regard to #= 2, I=E2=80=99m trying to understand how this compares to TLS1.3=E2=80=99s r= estructuring of the Certificate message, which seems like it will have a si= gnificantly broader adoption and a lower barrier to adoption, especially in= the case of client certs.

While presented as specific examples, I think they more generally speak = to a lack of definition as to the problem space or audience within the curr= ent draft, thus making it difficult to see how adoption, implementation, or= consensus will emerge. While personally skeptical of the idea, I fully acc= ept that there may be some non-WebPKI use cases for this that could benefit= from this work, but it seems like nailing those down and identifying them = should be encouraged as a prerequisite for adoption. In particular, it seem= s like fleshing how this is meaningfully different in use case or deploymen= t from existing technologies such as OCSP Stapling seems good, so as to pre= vent an unnecessarily proliferation of ways to solve the same basic problem= .

<= /blockquote> --000000000000035c3f056b43d79d-- From nobody Wed May 2 21:11:03 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04B412E874 for ; Wed, 2 May 2018 21:10:56 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 lDLUY7DyNdzz for ; Wed, 2 May 2018 21:10:53 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA3F8127869 for ; Wed, 2 May 2018 21:10:52 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 2 May 2018 21:08:16 -0700 From: Jim Schaad To: References: <152530576577.4375.9433092341074831480.idtracker@ietfa.amsl.com> In-Reply-To: <152530576577.4375.9433092341074831480.idtracker@ietfa.amsl.com> Date: Wed, 2 May 2018 21:10:46 -0700 Message-ID: <054e01d3e294$b7e2d610$27a88230$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI3RG4sZynWfiinq0QwCSJw12W0tKNWoGfw Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [lamps] FW: New Version Notification for draft-ietf-lamps-rfc5750-bis-06.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 04:10:57 -0000 This document has been updated with last call and sector review comment = response. -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Wednesday, May 2, 2018 5:03 PM To: Jim Schaad ; Blake Ramsdell = ; Sean Turner Subject: New Version Notification for = draft-ietf-lamps-rfc5750-bis-06.txt A new version of I-D, draft-ietf-lamps-rfc5750-bis-06.txt has been successfully submitted by Jim Schaad and posted to the IETF = repository. Name: draft-ietf-lamps-rfc5750-bis Revision: 06 Title: Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version = 4.0 Certificate Handling Document date: 2018-05-02 Group: lamps Pages: 26 URL: = https://www.ietf.org/internet-drafts/draft-ietf-lamps-rfc5750-bis-06.txt Status: = https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ Htmlized: = https://tools.ietf.org/html/draft-ietf-lamps-rfc5750-bis-06 Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5750-bis Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-rfc5750-bis-06 Abstract: This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 5750. = =20 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. The IETF Secretariat From nobody Thu May 3 04:47:10 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA1812D875 for ; Thu, 3 May 2018 04:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 f48ozifLGQ2y for ; Thu, 3 May 2018 04:47:05 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 027BA124E15 for ; Thu, 3 May 2018 04:47:05 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id t27-v6so15776590oij.9 for ; Thu, 03 May 2018 04:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=S1DksWtnDF6KuWFEtHkBcFSzeu6cIm63HAL9imhsMV0=; b=OuYl1vtKiB35Qoqfmzy/tMgj9S70pRflr0LKSxXT2IgI94kzTYw+v+Mn+N/WO09dXx gg/x8Bz7uqAcZbc8n5S/Sga1xFntmzMHwNYmZmnWNOOd8tMUpnMVSePu6PZ898huEapc GqqBGkpXnRgJ00nD/EIGkofhxJMe1yuAN4hSIQlfY/cH0ryqaApQc7vfMsafnJFeWPGW 9uyDqKJZCqoma4kUXB4eeMYYGmBt0MQIl/qSrwon/8hyryLh0Te5AXI5CrsRvTIcnRm3 QmRD92sBmlggO5iTcnEsD/uxqOfh+YmP6oJFAIpNM8dHw27i3N2czOfaj14iOkUT95T7 cTqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=S1DksWtnDF6KuWFEtHkBcFSzeu6cIm63HAL9imhsMV0=; b=Ak8XVVQumltAVzQ9YauKXZDXidtOPKbrDgVfNpT+j/8PZJqHgr3sF/vkNqPP5WSD9f eQ+izYID5+KFKo0eAwvv/AuTafkt+KQn8XHga1xAKoM8Qgh7p0WzInIJFN8xn6KNOdjR 1gh93rgz35cNNU6C/6Y9boNEUvZXhhqmgKjwrQNaXse27bF3P9G3him2lbbjvBiSnfEO 4BIJ+2X6i69FtOaE4S+G/SPt5oJZ6XW66azgzfmlSftJY6FzS0VmezbleIBl1E1ZdGnM ByMCz6D+dXW4VkFxMQFb3vGsiA6ZpJ0Mn4g7e3fIGxbVJaDm9vaaRHNA2bWlC0Xa4Cpe stgw== X-Gm-Message-State: ALQs6tB1ODTR3RTG+sR2EUU1S6QqqgSI6Ifzvfa78zlUDpOMkUFy6ais M/rq5Ay+w1pD+gJhyUbff5ihsv1S/rsaod6q8oU= X-Google-Smtp-Source: AB8JxZrH7msDeEib1EQqp7HJZPhayPrd9y5DsG/xBaab9BaZyLxVzNsVL6IEL+OT4T4TNq7mfmVj54tc5cV385rr+io= X-Received: by 2002:aca:6257:: with SMTP id w84-v6mr2789331oib.26.1525348024239; Thu, 03 May 2018 04:47:04 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:3283:0:0:0:0:0 with HTTP; Thu, 3 May 2018 04:47:03 -0700 (PDT) In-Reply-To: References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> <64CD1067-8639-4C2C-A8EC-ED5FBC14F633@gmail.com> From: Phillip Hallam-Baker Date: Thu, 3 May 2018 07:47:03 -0400 X-Google-Sender-Auth: RGys-LLgZ5J_rLf0jMGWvJcv8G4 Message-ID: To: Ryan Sleevi Cc: Yoav Nir , LAMPS , Russ Housley Content-Type: multipart/alternative; boundary="00000000000024cc06056b4bc3ca" Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 11:47:08 -0000 --00000000000024cc06056b4bc3ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 2, 2018 at 10:19 PM, Ryan Sleevi wrote: > > On Wed, May 2, 2018 at 5:20 PM Yoav Nir wrote: > >> >> >> On 3 May 2018, at 0:06, Ryan Sleevi wrote: >> >> >> >> On Wed, May 2, 2018 at 10:41 AM, Russ Housley >> wrote: >> >>> Based on the discussion in London and the "Potential Topics for LAMPS >>> Recharter" mail thread. We propose the attached charter text. Please >>> review and comment. >>> >>> Russ & Tim >>> >>> =3D =3D =3D =3D =3D =3D =3D =3D =3D >>> >>> 3. Specify the use of short-lived X.509 certificates for which no >>> revocation information is made available by the Certification Authority= . >>> Short-lived certificates have a lifespan that is shorter than the time >>> needed to detect, report, and distribute revocation information, as a >>> result revoking them pointless. >>> >> >> I didn't see much discussion on the list in support for this, but >> apologies, I missed the discussion in SECDISPATCH when this draft was >> discussed. >> >> Is this being envisioned for the use in the PKI typically called the "We= b >> PKI", or is this being seen as a draft for private use cases? I have rea= d >> the draft, and do not feel this was clearly and unambiguously answered. >> >> I ask because, for various policy reasons, I would expect that >> undertaking this work may result in policies that explicitly prohibit it >> from being deployed on the Web PKI. >> >> As a practical matter, the draft acknowledges an alternative design >> (namely, OCSP stapling), but its two objections to this work do not hold= . >> As a consequence, I have concerns about the motivations for and the >> alternatives considered, and thus don't think LAMPS needs to consider su= ch >> work in scope at this time. >> >> >> Hi, Ryan. >> >> The main motivation for me is things other than the Web PKI. There is >> nothing in the draft that makes it not work for the Web PKI, but I would >> like to leave it to the group to decide whether the Web PKI is explicitl= y >> excluded. >> >> There is a short-term certificate document that *is* for the Web PKI. It >> is in the ACME working group. >> https://tools.ietf.org/html/draft-ietf-acme-star-03 >> > >> >> Despite having some authors in common, the use cases are different. >> > > I=E2=80=99m curious to understand more of these use cases, as to understa= nd the > presumed implementors for the running code. I=E2=80=99m guessing that, gi= ven the > goal just presented, these are going to be locally managed CAs and/or for > server-to-server mutual auth scenarios? > > My biggest qualm is that the draft seems predicated on two statements > about why existing technology is insufficient: > 1) OCSP Stapling requires servers to support Stapling > 2) Client certs cannot staple > > There doesn=E2=80=99t seem to be any explanation as to why #1 doesn=E2=80= =99t equally > apply (if not moreso?) to this use case, given the need to replace the > certificates frequently due to their short lifetime. The efforts towards > ACME-STAR are illustrative of exactly that - a need for new management > capabilities. > > With regard to #2, I=E2=80=99m trying to understand how this compares to = TLS1.3=E2=80=99s > restructuring of the Certificate message, which seems like it will have a > significantly broader adoption and a lower barrier to adoption, especiall= y > in the case of client certs. > > While presented as specific examples, I think they more generally speak t= o > a lack of definition as to the problem space or audience within the curre= nt > draft, thus making it difficult to see how adoption, implementation, or > consensus will emerge. While personally skeptical of the idea, I fully > accept that there may be some non-WebPKI use cases for this that could > benefit from this work, but it seems like nailing those down and > identifying them should be encouraged as a prerequisite for adoption. In > particular, it seems like fleshing how this is meaningfully different in > use case or deployment from existing technologies such as OCSP Stapling > seems good, so as to prevent an unnecessarily proliferation of ways to > solve the same basic problem.. > =E2=80=8BThe reason to move to short term certs is simple and has nothing t= o do with insufficiency: It is simply more efficient. Once you automate the process of certificate management, the move to short lived certs is inevitable and obvious because then the server only needs to cope with a single data object rather than two equivalent data objects. With a long lived cert plus OCSP: * The server has to update its cert every X days and update its OCSP token, a different code path, every day. * The client has to process the cert and then process the OCSP token, each of which has a separate trust path. With a short lived cert: * The server has to update its cert every days. * The client has to process the cert. I do not understand where client certificates come into the argument. Obviously, the same approach may be applied to client certs but why would anyone bother when the browser UI for client auth is so utterly useless? I don't want to get into business models but I will observe that my employer is making good money by adding back features some folk have dissed over the years. --00000000000024cc06056b4bc3ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Ma= y 2, 2018 at 10:19 PM, Ryan Sleevi <ryan-ietf@sleevi.com>= wrote:

On Wed, May 2, 2018 at 5:20 PM Yoav N= ir <ynir.ietf@g= mail.com> wrote:


On 3 May 2018, at 0:06, Ryan Sleevi <ryan-ietf@sleevi.com>= wrote:



On Wed, May 2, 2018 at 10:41 AM, Russ Housley <housley@vigilsec.co= m> wrote:
Based on the discussion in London and the "Potential Topics for LAMPS R= echarter" mail thread.=C2=A0 We propose the attached charter text.=C2= =A0 Please review and comment.

Russ & Tim

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

3. Specify the use of short-lived X.509= certificates for which no
revocation information is made available by t= he Certification Authority.
Short-lived certificates have a lifespan tha= t is shorter than the time
needed to detect, report, and distribute revo= cation information, as a
result revoking them pointless.
=

I didn't see much discussion on the li= st in support for this, but apologies, I missed the discussion in SECDISPAT= CH when this draft was discussed.

Is this being en= visioned for the use in the PKI typically called the "Web PKI", o= r is this being seen as a draft for private use cases? I have read the draf= t, and do not feel this was clearly and unambiguously answered.
<= br>
I ask because, for various policy reasons, I would expect tha= t undertaking this work may result in policies that explicitly prohibit it = from being deployed on the Web PKI.

As a practical= matter, the draft acknowledges an alternative design (namely, OCSP staplin= g), but its two objections to this work do not hold. As a consequence, I ha= ve concerns about the motivations for and the alternatives considered, and = thus don't think LAMPS needs to consider such work in scope at this tim= e.

Hi, Ryan.
The main motivation for me is things other than the Web PKI= . There is nothing in the draft that makes it not work for the Web PKI, but= I would like to leave it to the group to decide whether the Web PKI is exp= licitly excluded.

There is a short-term certificat= e document that *is* for the Web PKI. It is in the ACME working group.

=
Despite having some authors in common, the use cases are differe= nt.

I=E2=80=99m curious to understand more of these use cases, as to unde= rstand the presumed implementors for the running code. I=E2=80=99m guessing= that, given the goal just presented, these are going to be locally managed= CAs and/or for server-to-server mutual auth scenarios?

My biggest qualm is that the draft seems pr= edicated on two statements about why existing technology is insufficient:
1) OCSP Stapling requires servers to support Stapling=
2) Client certs cannot staple

There doesn=E2=80=99t seem to be any explanat= ion as to why #1 doesn=E2=80=99t equally apply (if not moreso?) to this use= case, given the need to replace the certificates frequently due to their s= hort lifetime. The efforts towards ACME-STAR are illustrative of exactly th= at - a need for new management capabilities.

With regard to #2, I=E2=80=99m trying to understand ho= w this compares to TLS1.3=E2=80=99s restructuring of the Certificate messag= e, which seems like it will have a significantly broader adoption and a low= er barrier to adoption, especially in the case of client certs.

While presented as specific example= s, I think they more generally speak to a lack of definition as to the prob= lem space or audience within the current draft, thus making it difficult to= see how adoption, implementation, or consensus will emerge. While personal= ly skeptical of the idea, I fully accept that there may be some non-WebPKI = use cases for this that could benefit from this work, but it seems like nai= ling those down and identifying them should be encouraged as a prerequisite= for adoption. In particular, it seems like fleshing how this is meaningful= ly different in use case or deployment from existing technologies such as O= CSP Stapling seems good, so as to prevent an unnecessarily proliferation of= ways to solve the same basic problem..
=
=E2= =80=8BThe reason to move to short term certs is simple and has nothing to d= o with insufficiency: It is simply more efficient.

Once you automate the process of certificate mana= gement, the move to short lived certs is inevitable and obvious because the= n the server only needs to cope with a single data object rather than two e= quivalent data objects.

W= ith a long lived cert plus OCSP:

* The server has to update its cert every X days and update its OCS= P token, a different code path, every day.=C2=A0
* The client has to process the cert and = then process the OCSP token, each of which has a separate trust path.
=


With a short lived cert:

* The server has = to update its cert every days.
* The client has= to process the cert.

I do not understand where client certificates come into the argument. Ob= viously, the same approach may be applied to client certs but why would any= one bother when the browser UI for client auth is so utterly useless?
=


I don't want to get into busin= ess models but I will observe that my employer is making good money by addi= ng back features some folk have dissed over the years.
--00000000000024cc06056b4bc3ca-- From nobody Thu May 3 05:48:47 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DE9126C83 for ; Thu, 3 May 2018 05:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QndcnWWc8HeQ for ; Thu, 3 May 2018 05:48:44 -0700 (PDT) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 4A83C12426E for ; Thu, 3 May 2018 05:48:44 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id i5-v6so8767665otf.1 for ; Thu, 03 May 2018 05:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TyMziyleRzN9mKcIx+GLAluJfrS6KaG/J5InWwOCIg4=; b=Cg8XHz7mJsmMnxweMXcQBhavt7vvFOFwXZTgjxaAAJput2ub9LDGmOzt31pJ4JvLSd F/9sPiUpzhz+4PFV+QLl4/FCfzRS4oD5gZQTuEn5gfRspEXKOs8m1w/uCxQ4c3ZJIOlW ZIzdMYw4oXIhTzd3vbpQ04P+Q21BNo0a8uZ4O9DrWiEIFV+essVBul8TeTL+ybn7czPI GsIrpkEWObG9EXi+Hmfb3Ho3ePlkD8HF5bkhBxeuRDjbs0IIbqnG3XgyM0b0ui9wMI2E 1lnEHPjWP9/2lcj2GvY6EeOwkNdvNyEnCV/nS0q5jzSK6P57yacN/CP3TpSJu0D77VJE sEWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TyMziyleRzN9mKcIx+GLAluJfrS6KaG/J5InWwOCIg4=; b=r1VAQLSttV0MDU/weAVNuB93Sln0gV5Uh903ZDt2GGD4/DQHcJLF/ir4QC2NAiRslR l7N4yd3KOYh3sOOMFQskrmzpm3cIKhPaa/kUic64QGowBu1okgsd/cRCfcUmJYN3FKhy Lb+d/qeWMB/Al0SObsPXwMuC+qrbTi45N7EFEqQHf4KBbSbERAcfSAsSDjRSEOQcDu7n xB3NvcyQgRfSXs4bJcqod/wK80hbr7J1DB+z8WEJhREB3gjJSzjsuy2fFg28naE+VXKi SmOxZMUiO2lvbMzBasfDHXZ2vFPiPVNLMIKh2Xew3AL58gW9mtmHulKtnbX5oQgAiDpl 7iWg== X-Gm-Message-State: ALQs6tA4bTUSx7+7645zYanXxXsM24r1VF2x8TP9y6EWPZtPwPYjbW+Y XogD8DsvRtyw5Tl94fhmcAuVMwi4WB7cPzYyM23/rc6C X-Google-Smtp-Source: AB8JxZo4pgYo1Rahx2QFDfSUmO/vi8+mGhx9l8ndYlsTengCtj607owuFIW7qkz98jFTaG74ZsTLEgmES98IwPsKZx4= X-Received: by 2002:a9d:1055:: with SMTP id o21-v6mr16359491oto.371.1525351723716; Thu, 03 May 2018 05:48:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Thu, 3 May 2018 05:48:03 -0700 (PDT) In-Reply-To: <20180503013149.5C4B025CE95C@ary.qy> References: <20180503013149.5C4B025CE95C@ary.qy> From: Eric Rescorla Date: Thu, 3 May 2018 05:48:03 -0700 Message-ID: To: John Levine Cc: SPASM Content-Type: multipart/alternative; boundary="000000000000a662b5056b4c9ff0" Archived-At: Subject: Re: [lamps] Semi-OT: crypto code in RFCs X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 12:48:46 -0000 --000000000000a662b5056b4c9ff0 Content-Type: text/plain; charset="UTF-8" 1321 has an MD5 implementation. -Ekr On Wed, May 2, 2018 at 6:31 PM, John Levine wrote: > For reasons anyone familiar with US law can probably guess, I'm trying > to collect all of the RFCs that include cryptographic source code. > RFC 8032 has python code for EC signing and verification. Any others > I should put on the list? > > R's, > John > > PS: Please do not tell us how silly the US rules about crypto software > export are. We know. > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --000000000000a662b5056b4c9ff0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
1321 has an MD5 implementation.

<= div>-Ekr


On Wed, May 2, 2018 at 6:31 PM, John Levine <johnl@taugh.c= om> wrote:
For reasons anyo= ne familiar with US law can probably guess, I'm trying
to collect all of the RFCs that include cryptographic source code.
RFC 8032 has python code for EC signing and verification.=C2=A0 Any others<= br> I should put on the list?

R's,
John

PS: Please do not tell us how silly the US rules about crypto software
export are.=C2=A0 We know.

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

--000000000000a662b5056b4c9ff0-- From nobody Thu May 3 05:50:49 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3DBA126C83 for ; Thu, 3 May 2018 05:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCOkvWqKFgFo for ; Thu, 3 May 2018 05:50:46 -0700 (PDT) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 845FB12426E for ; Thu, 3 May 2018 05:50:46 -0700 (PDT) Received: by mail-ot0-x233.google.com with SMTP id t1-v6so20435250ott.13 for ; Thu, 03 May 2018 05:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0Qvi1XJVV4yKctHePopiJE6WhcYZ5T90ImrssscZBLc=; b=alG0qO+KdYRS3ggTvEgzHtM1/xy/KJHrnR/xSbWoKft0dXVuikCPJDPSSCZTV/aG9F uW7dAmR8XRgX1AMcVaKZMYyLPxITpXLQw4Wl56UG04Kl106UM9lN8u5sUiCRqUHOhBpi L+TQ6nvOsymBpviQ2OtkJyg9otZhxuJ5MipQzMIO1bZ3tFJqhocWCxQYiGQsaUZWUMKT lNTlEeXZZIlh0B/u4Ciq9u5S+/CDNLVvlaxiOay7EctJVg2PLENz6O1TKrFr/RdIuy6R WbPvtpQ0LzmF7PSQFELaPfFeWM1TabJRsHxlbEFA9QWAmLc3MeneharhPzYMWwnQVfUv oseA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0Qvi1XJVV4yKctHePopiJE6WhcYZ5T90ImrssscZBLc=; b=BAYpZmrdvG1V5cNSdyiSHDpdXGtdObs43XkNh6ML8RB4Lsy6EtmgLS27uLD6qtIywB Z6Gbr4uctPIkYWP1RfnqmaNI8ETuy1aR3aFguVNA1RU0sREBLbkAlSvYiVlTeNstfOE2 SRQQjMvuwz6bqXL5JHJ0aO0J/3J61k3q1ptmIZGbHxLebkgmbC1FJHNSx+Jg/YO1ONhh jOwtcGFN304AfbXWOTD+nSxljG+FF6I4MOi6sWQWLnj/p+MkFjEchmcrO43eGLmuyquS boBN0G5/A9jsQ4sXyWZKeKDhzonOGBoZcqh8jacDR41FggD01XZgkczTYLw4pSc+IzbX NVtA== X-Gm-Message-State: ALQs6tCbME8TOjw/k3EhGkSD4dZG0GJRlFsr7724IMTUg7cAWXpX+2k5 uxu2+u6U0HY/ZK6oGt5l838cVHSgzw+n/iCz7CRDIMYs X-Google-Smtp-Source: AB8JxZqFi9zc1elUhMVoNJU+sLl4q7dtbV8PBtTcu048arz4cBjmKZl7ylE6K4eQ2GKSKPBcbnoSAECcYZpgnBPSJ54= X-Received: by 2002:a9d:1055:: with SMTP id o21-v6mr16364353oto.371.1525351845916; Thu, 03 May 2018 05:50:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Thu, 3 May 2018 05:50:05 -0700 (PDT) In-Reply-To: References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> From: Eric Rescorla Date: Thu, 3 May 2018 05:50:05 -0700 Message-ID: To: Ryan Sleevi Cc: Russ Housley , LAMPS Content-Type: multipart/alternative; boundary="000000000000eef9f6056b4ca6eb" Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 12:50:49 -0000 --000000000000eef9f6056b4ca6eb Content-Type: text/plain; charset="UTF-8" On Wed, May 2, 2018 at 2:06 PM, Ryan Sleevi wrote: > > > On Wed, May 2, 2018 at 10:41 AM, Russ Housley > wrote: > >> Based on the discussion in London and the "Potential Topics for LAMPS >> Recharter" mail thread. We propose the attached charter text. Please >> review and comment. >> >> Russ & Tim >> >> = = = = = = = = = >> >> 3. Specify the use of short-lived X.509 certificates for which no >> revocation information is made available by the Certification Authority. >> Short-lived certificates have a lifespan that is shorter than the time >> needed to detect, report, and distribute revocation information, as a >> result revoking them pointless. >> > > I didn't see much discussion on the list in support for this, but > apologies, I missed the discussion in SECDISPATCH when this draft was > discussed. > > Is this being envisioned for the use in the PKI typically called the "Web > PKI", or is this being seen as a draft for private use cases? I have read > the draft, and do not feel this was clearly and unambiguously answered. > > I ask because, for various policy reasons, I would expect that undertaking > this work may result in policies that explicitly prohibit it from being > deployed on the Web PKI. > Ryan, Do you think you could elaborate on this point? Thanks, -Ekr > As a practical matter, the draft acknowledges an alternative design > (namely, OCSP stapling), but its two objections to this work do not hold. > As a consequence, I have concerns about the motivations for and the > alternatives considered, and thus don't think LAMPS needs to consider such > work in scope at this time. > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > --000000000000eef9f6056b4ca6eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 2, 2018 at 2:06 PM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:

On Wed, May 2, 2018 at 10:41 AM, Russ Housley <housley@vigilsec.com> wrote:
Based on the discussion in London an= d the "Potential Topics for LAMPS Recharter" mail thread.=C2= =A0 We propose the attached charter text.=C2=A0 Please review and comment.<= /span>

Russ & Tim

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

3. Specify the use o= f short-lived X.509 certificates for which no
revocation information is = made available by the Certification Authority.
Short-lived certificates = have a lifespan that is shorter than the time
needed to detect, report, = and distribute revocation information, as a
result revoking them pointle= ss.

I didn't see= much discussion on the list in support for this, but apologies, I missed t= he discussion in SECDISPATCH when this draft was discussed.

<= /div>
Is this being envisioned for the use in the PKI typically called = the "Web PKI", or is this being seen as a draft for private use c= ases? I have read the draft, and do not feel this was clearly and unambiguo= usly answered.

I ask because, for various policy r= easons, I would expect that undertaking this work may result in policies th= at explicitly prohibit it from being deployed on the Web PKI.



Thanks,

<= div>=C2=A0

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


--000000000000eef9f6056b4ca6eb-- From nobody Thu May 3 06:25:55 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157661205F0 for ; Thu, 3 May 2018 06:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 qsIR5p7IPiL9 for ; Thu, 3 May 2018 06:25:51 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 114D2120454 for ; Thu, 3 May 2018 06:25:50 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 623B9A00492C for ; Thu, 3 May 2018 06:25:50 -0700 (PDT) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 354BFA00492A for ; Thu, 3 May 2018 06:25:50 -0700 (PDT) Received: by mail-it0-f54.google.com with SMTP id n202-v6so21164211ita.1 for ; Thu, 03 May 2018 06:25:50 -0700 (PDT) X-Gm-Message-State: ALQs6tCsgrv+ewBxA1WalVFgGVfNc12iYUlxVqUikjxkYnBlzJixiHL/ /MVv8MwgBZGGXD9YpFP3ZZYIgtGDylie3IYeQwM= X-Google-Smtp-Source: AB8JxZqNnU846jK9//qJDr7Vsm+auV3635EZGxwisNHf1OtgUwCtSMx8+bqob2cnE9LQUTKz4TbwACDH8x434vZz6lg= X-Received: by 2002:a24:d88b:: with SMTP id b133-v6mr23523629itg.119.1525353949492; Thu, 03 May 2018 06:25:49 -0700 (PDT) MIME-Version: 1.0 References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> <64CD1067-8639-4C2C-A8EC-ED5FBC14F633@gmail.com> In-Reply-To: From: Ryan Sleevi Date: Thu, 03 May 2018 13:25:38 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Phillip Hallam-Baker Cc: LAMPS , Russ Housley , Ryan Sleevi , Yoav Nir Content-Type: multipart/alternative; boundary="00000000000050ffcb056b4d24a6" Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 13:25:54 -0000 --00000000000050ffcb056b4d24a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 3, 2018 at 7:47 AM Phillip Hallam-Baker wrote: > On Wed, May 2, 2018 at 10:19 PM, Ryan Sleevi wrote= : > >> On Wed, May 2, 2018 at 5:20 PM Yoav Nir wrote: >> >>> >>> >>> On 3 May 2018, at 0:06, Ryan Sleevi wrote: >>> >>> >>> >>> On Wed, May 2, 2018 at 10:41 AM, Russ Housley >>> wrote: >>> >>>> Based on the discussion in London and the "Potential Topics for LAMPS >>>> Recharter" mail thread. We propose the attached charter text. Please >>>> review and comment. >>>> >>>> Russ & Tim >>>> >>>> =3D =3D =3D =3D =3D =3D =3D =3D =3D >>>> >>>> 3. Specify the use of short-lived X.509 certificates for which no >>>> revocation information is made available by the Certification Authorit= y. >>>> Short-lived certificates have a lifespan that is shorter than the time >>>> needed to detect, report, and distribute revocation information, as a >>>> result revoking them pointless. >>>> >>> >>> I didn't see much discussion on the list in support for this, but >>> apologies, I missed the discussion in SECDISPATCH when this draft was >>> discussed. >>> >>> Is this being envisioned for the use in the PKI typically called the >>> "Web PKI", or is this being seen as a draft for private use cases? I ha= ve >>> read the draft, and do not feel this was clearly and unambiguously answ= ered. >>> >>> I ask because, for various policy reasons, I would expect that >>> undertaking this work may result in policies that explicitly prohibit i= t >>> from being deployed on the Web PKI. >>> >>> As a practical matter, the draft acknowledges an alternative design >>> (namely, OCSP stapling), but its two objections to this work do not hol= d. >>> As a consequence, I have concerns about the motivations for and the >>> alternatives considered, and thus don't think LAMPS needs to consider s= uch >>> work in scope at this time. >>> >>> >>> Hi, Ryan. >>> >>> The main motivation for me is things other than the Web PKI. There is >>> nothing in the draft that makes it not work for the Web PKI, but I woul= d >>> like to leave it to the group to decide whether the Web PKI is explicit= ly >>> excluded. >>> >>> There is a short-term certificate document that *is* for the Web PKI. I= t >>> is in the ACME working group. >>> https://tools.ietf.org/html/draft-ietf-acme-star-03 >>> >> >>> >>> Despite having some authors in common, the use cases are different. >>> >> >> I=E2=80=99m curious to understand more of these use cases, as to underst= and the >> presumed implementors for the running code. I=E2=80=99m guessing that, g= iven the >> goal just presented, these are going to be locally managed CAs and/or fo= r >> server-to-server mutual auth scenarios? >> >> My biggest qualm is that the draft seems predicated on two statements >> about why existing technology is insufficient: >> 1) OCSP Stapling requires servers to support Stapling >> 2) Client certs cannot staple >> >> There doesn=E2=80=99t seem to be any explanation as to why #1 doesn=E2= =80=99t equally >> apply (if not moreso?) to this use case, given the need to replace the >> certificates frequently due to their short lifetime. The efforts towards >> ACME-STAR are illustrative of exactly that - a need for new management >> capabilities. >> >> With regard to #2, I=E2=80=99m trying to understand how this compares to= TLS1.3=E2=80=99s >> restructuring of the Certificate message, which seems like it will have = a >> significantly broader adoption and a lower barrier to adoption, especial= ly >> in the case of client certs. >> >> While presented as specific examples, I think they more generally speak >> to a lack of definition as to the problem space or audience within the >> current draft, thus making it difficult to see how adoption, >> implementation, or consensus will emerge. While personally skeptical of = the >> idea, I fully accept that there may be some non-WebPKI use cases for thi= s >> that could benefit from this work, but it seems like nailing those down = and >> identifying them should be encouraged as a prerequisite for adoption. In >> particular, it seems like fleshing how this is meaningfully different in >> use case or deployment from existing technologies such as OCSP Stapling >> seems good, so as to prevent an unnecessarily proliferation of ways to >> solve the same basic problem.. >> > > =E2=80=8BThe reason to move to short term certs is simple and has nothing= to do > with insufficiency: It is simply more efficient. > > Once you automate the process of certificate management, the move to shor= t > lived certs is inevitable and obvious because then the server only needs = to > cope with a single data object rather than two equivalent data objects. > > With a long lived cert plus OCSP: > > * The server has to update its cert every X days and update its OCSP > token, a different code path, every day. > * The client has to process the cert and then process the OCSP token, eac= h > of which has a separate trust path. > To make sure I understand this claim: Is the view that adding yet another method, which is not as expressive and with a host of trade offs, will somehow payoff at some point in the future in which clients and servers no longer have to implement or care about revocation data? I would rather like to think =E2=80=9Cthe spec is prettier if we do it this= way=E2=80=9D is a poor justification for taking on work, so I was hoping a bit more substance to a reply. With a short lived cert: > > * The server has to update its cert every days. > * The client has to process the cert. > > I do not understand where client certificates come into the argument. > Obviously, the same approach may be applied to client certs but why would > anyone bother when the browser UI for client auth is so utterly useless? > It=E2=80=99s unclear: you read the draft and are disagreeing with it, or di= d you read me reply and weren=E2=80=99t aware I was referencing the draft? The me= ntion of browsers leads me to believe the latter, because the message I was replying to identified this work was not for the Web PKI, but if the former, I=E2=80= =99m hoping to bring a bit more clarity to the position. I don't want to get into business models but I will observe that my > employer is making good money by adding back features some folk have diss= ed > over the years. > I=E2=80=99m not sure how this furthers the discussion on the merits. Perhap= s you could elaborate how it fits with what we=E2=80=99re discussing? Or was this= an unrelated non sequitor you were calling out as such before making anyways? I had a bit of trouble parsing. > --00000000000050ffcb056b4d24a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, May 3, 2018 a= t 7:47 AM Phillip Hallam-Baker <phill@hallambaker.com> wrote:
On Wed, May 2= , 2018 at 10:19 PM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
On Wed, May 2, 2018 at 5:20 PM Yoav Nir <ynir.ietf@gmail.com> wrote:
<= /div>


On 3 = May 2018, at 0:06, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:



On Wed, May 2, 2018 at 10:41 AM, Russ Housley <housley@vigilsec.com><= /span> wrote:
Based on the discussion in London and the "Potential Topics for LAMPS Recharter&q= uot; mail thread.=C2=A0 We propose the attached charter text.=C2=A0 Please = review and comment.

Russ & Tim

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

3. Specify the use of short-lived X.509 certific= ates for which no
revocation information is made available by the Certif= ication Authority.
Short-lived certificates have a lifespan that is shor= ter than the time
needed to detect, report, and distribute revocation in= formation, as a
result revoking them pointless.

I didn't see much discussion on the list in sup= port for this, but apologies, I missed the discussion in SECDISPATCH when t= his draft was discussed.

Is this being envisioned = for the use in the PKI typically called the "Web PKI", or is this= being seen as a draft for private use cases? I have read the draft, and do= not feel this was clearly and unambiguously answered.

=
I ask because, for various policy reasons, I would expect that underta= king this work may result in policies that explicitly prohibit it from bein= g deployed on the Web PKI.

As a practical matter, = the draft acknowledges an alternative design (namely, OCSP stapling), but i= ts two objections to this work do not hold. As a consequence, I have concer= ns about the motivations for and the alternatives considered, and thus don&= #39;t think LAMPS needs to consider such work in scope at this time.
<= /div>

Hi, Ryan.

The main motivation for me is things other than the Web PKI. There= is nothing in the draft that makes it not work for the Web PKI, but I woul= d like to leave it to the group to decide whether the Web PKI is explicitly= excluded.

There is a short-term certificate docum= ent that *is* for the Web PKI. It is in the ACME working group.
<= a href=3D"https://tools.ietf.org/html/draft-ietf-acme-star-03" target=3D"_b= lank">https://tools.ietf.org/html/draft-ietf-acme-star-03

D= espite having some authors in common, the use cases are different.

I=E2= =80=99m curious to understand more of these use cases, as to understand the= presumed implementors for the running code. I=E2=80=99m guessing that, giv= en the goal just presented, these are going to be locally managed CAs and/o= r for server-to-server mutual auth scenarios?

My biggest qualm is that the draft seems predicated o= n two statements about why existing technology is insufficient:
1) OCSP Stapling requires servers to support Stapling
2) Client certs cannot staple

There doesn=E2=80=99t seem to be any explanation as to = why #1 doesn=E2=80=99t equally apply (if not moreso?) to this use case, giv= en the need to replace the certificates frequently due to their short lifet= ime. The efforts towards ACME-STAR are illustrative of exactly that - a nee= d for new management capabilities.

With regard to #2, I=E2=80=99m trying to understand how this com= pares to TLS1.3=E2=80=99s restructuring of the Certificate message, which s= eems like it will have a significantly broader adoption and a lower barrier= to adoption, especially in the case of client certs.

=
While presented as specific ex= amples, I think they more generally speak to a lack of definition as to the= problem space or audience within the current draft, thus making it difficu= lt to see how adoption, implementation, or consensus will emerge. While per= sonally skeptical of the idea, I fully accept that there may be some non-We= bPKI use cases for this that could benefit from this work, but it seems lik= e nailing those down and identifying them should be encouraged as a prerequ= isite for adoption. In particular, it seems like fleshing how this is meani= ngfully different in use case or deployment from existing technologies such= as OCSP Stapling seems good, so as to prevent an unnecessarily proliferati= on of ways to solve the same basic problem..
=

= =E2=80=8BThe reason to move to short term certs is simple and has nothing t= o do with insufficiency: It is simply more efficient.

Once you automate the process of certificate m= anagement, the move to short lived certs is inevitable and obvious because = then the server only needs to cope with a single data object rather than tw= o equivalent data objects.

With a long lived cert plus OCSP:

* The server has to update its cert every X days and update its = OCSP token, a different code path, every day.=C2=A0
* The client has to process the cert a= nd then process the OCSP token, each of which has a separate trust path.

To make sure I understand this claim: Is the view that adding ye= t another method, which is not as expressive and with a host of trade offs,= will somehow payoff at some point in the future in which clients and serve= rs no longer have to implement or care about revocation data?

I would rather like to think =E2=80= =9Cthe spec is prettier if we do it this way=E2=80=9D is a poor justificati= on for taking on work, so I was hoping a bit more substance to a reply.

With a short lived cert:

* The server has to up= date its cert every days.
* The client has to p= rocess the cert.

I = do not understand where client certificates come into the argument. Obvious= ly, the same approach may be applied to client certs but why would anyone b= other when the browser UI for client auth is so utterly useless?

It=E2=80=99s unclear: you read the draft and are disagreeing with it, or= did you read me reply and weren=E2=80=99t aware I was referencing the draf= t? The mention of browsers leads me to believe the latter, because the mess= age I was replying to identified this work was not for the Web PKI, but if = the former, I=E2=80=99m hoping to bring a bit more clarity to the position.=

I don't want to get into business models= but I will observe that my employer is making good money by adding back fe= atures some folk have dissed over the years.

I=E2=80=99m not sure ho= w this furthers the discussion on the merits. Perhaps you could elaborate h= ow it fits with what we=E2=80=99re discussing? Or was this an unrelated non= sequitor you were calling out as such before making anyways? I had a bit o= f trouble parsing.
--00000000000050ffcb056b4d24a6-- From nobody Thu May 3 06:34:37 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4C9124C27 for ; Thu, 3 May 2018 06:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 y5mdtQ7yEUak for ; Thu, 3 May 2018 06:34:33 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96971120454 for ; Thu, 3 May 2018 06:34:33 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 06A839000C3F for ; Thu, 3 May 2018 06:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=ae2NvR/uaoojfOt3VrDeFb3kMk4=; b= goz5nm3UiCvOjELD696WYZRunlixGKu34eo3PYlcD/1CXIuxZW1zslngf7TeiI+W /A1BCsqQzDrefmDNYXZ6l4y+EasYG2P9PkHXbsWBHtbfce4eD9W14C5THMQaEnqh eM9wYLF0DBPwZ1u0h+MDI/hbBoUrTnxMqS8mwI4mWpI= Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id BC2B59000C3B for ; Thu, 3 May 2018 06:34:32 -0700 (PDT) Received: by mail-io0-f169.google.com with SMTP id e20-v6so21636026iof.4 for ; Thu, 03 May 2018 06:34:32 -0700 (PDT) X-Gm-Message-State: ALQs6tDMOv2hRp/MtFuQT42HtBvnWUTtX8vPeEnFxPpGuu3qtdQsdkAx KjPjtH1QOmU8FW9c7qNHaiiFXJWSbx48XhZ0Q94= X-Google-Smtp-Source: AB8JxZq2fURjySCzfIEu95LVRzsgRz5Y6cL9BOKmkBuNaA5ob8ZnoYi8A3IbNTI/NmMR0r4ygxHNtwSKtN6pV8uhxG4= X-Received: by 2002:a6b:1248:: with SMTP id a69-v6mr26227906ioj.159.1525354471768; Thu, 03 May 2018 06:34:31 -0700 (PDT) MIME-Version: 1.0 References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> In-Reply-To: From: Ryan Sleevi Date: Thu, 03 May 2018 13:34:21 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Cc: LAMPS , Russ Housley , Ryan Sleevi Content-Type: multipart/alternative; boundary="000000000000725c9c056b4d4334" Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 13:34:35 -0000 --000000000000725c9c056b4d4334 Content-Type: text/plain; charset="UTF-8" On Thu, May 3, 2018 at 8:50 AM Eric Rescorla wrote: > On Wed, May 2, 2018 at 2:06 PM, Ryan Sleevi wrote: > >> >> >> On Wed, May 2, 2018 at 10:41 AM, Russ Housley >> wrote: >> >>> Based on the discussion in London and the "Potential Topics for LAMPS >>> Recharter" mail thread. We propose the attached charter text. Please >>> review and comment. >>> >>> Russ & Tim >>> >>> = = = = = = = = = >>> >>> 3. Specify the use of short-lived X.509 certificates for which no >>> revocation information is made available by the Certification Authority. >>> Short-lived certificates have a lifespan that is shorter than the time >>> needed to detect, report, and distribute revocation information, as a >>> result revoking them pointless. >>> >> >> I didn't see much discussion on the list in support for this, but >> apologies, I missed the discussion in SECDISPATCH when this draft was >> discussed. >> >> Is this being envisioned for the use in the PKI typically called the "Web >> PKI", or is this being seen as a draft for private use cases? I have read >> the draft, and do not feel this was clearly and unambiguously answered. >> >> I ask because, for various policy reasons, I would expect that >> undertaking this work may result in policies that explicitly prohibit it >> from being deployed on the Web PKI. >> > > Ryan, > > Do you think you could elaborate on this point? > It seems a bit less germane to discuss potential root store policy here in the IETF, but there are already policies around lifetimes - such as maximum certificate lifetimes or minimum OCSP response validity durations. Despite being technically capable of issuance, I fully anticipate minimum lifetimes being required for certificate validity. Validity merely externalizes cost to PKI participants - too long a validity, for example, carries greater risk of both key compromise and information staleness. Models such as revocation try to remediate that, but shift more burden onto relying parties. Actions such as too short validity also shifts burden onto clients and the ecosystem - notably in terms of client clock issues, by increasing the precision and accuracy necessary. As it relates to the draft, however, it has further flaws in the design assumptions, similar to these concerns. For example, suggesting that CAs would be able to use shorter-lived certificates to no longer keep track of what they issue is fundamentally incompatible with a Web PKI in which every CA is accountable for what it issues: presently, for between five to seven years from issuance. This is orthogonal to things like Certificate Transparency, and is about operational requirements. I expect the floor for certificates to bottom out at around 21-30 days for publicly trusted certificates for the next decade, which potentially would be mandated by requirements on issuance policy. > --000000000000725c9c056b4d4334 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, May 3, 2018 a= t 8:50 AM Eric Rescorla <ekr@rtfm.com> wrote:
On Wed, May 2, 2018 at 2:06 PM, Ryan S= leevi <r= yan-ietf@sleevi.com> wrote:


O= n Wed, May 2, 2018 at 10:41 AM, Russ Housley <housley@vigilsec.com> w= rote:
Based on the discussion in London and the "Potenti= al Topics for LAMPS Recharter" mail thread.=C2=A0 We propose the attac= hed charter text.=C2=A0 Please review and comment.
=
Russ & Tim

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

3. Specify the use of short-lived X.509 certificates for which norevocation information is made available by the Certification Authority.Short-lived certificates have a lifespan that is shorter than the timeneeded to detect, report, and distribute revocation information, as a
r= esult revoking them pointless.

=
I didn't see much discussion on the list in support for this= , but apologies, I missed the discussion in SECDISPATCH when this draft was= discussed.

Is this being envisioned for the use i= n the PKI typically called the "Web PKI", or is this being seen a= s a draft for private use cases? I have read the draft, and do not feel thi= s was clearly and unambiguously answered.

I ask be= cause, for various policy reasons, I would expect that undertaking this wor= k may result in policies that explicitly prohibit it from being deployed on= the Web PKI.

Rya= n,

Do you think you could elaborate on this point?= =C2=A0

It seems a bit less germane to discuss potential root store p= olicy here in the IETF, but there are already policies around lifetimes - s= uch as maximum certificate lifetimes or minimum OCSP response validity dura= tions. Despite being technically capable of issuance, I fully anticipate mi= nimum lifetimes being required for certificate validity.

Validity merely externalizes cost to PKI p= articipants - too long a validity, for example, carries greater risk of bot= h key compromise and information staleness. Models such as revocation try t= o remediate that, but shift more burden onto relying parties. Actions such = as too short validity also shifts burden onto clients and the ecosystem - n= otably in terms of client clock issues, by increasing the precision and acc= uracy necessary.

As it r= elates to the draft, however, it has further flaws in the design assumption= s, similar to these concerns. For example, suggesting that CAs would be abl= e to use shorter-lived certificates to no longer keep track of what they is= sue is fundamentally incompatible with a Web PKI in which every CA is accou= ntable for what it issues: presently, for between five to seven years from = issuance. This is orthogonal to things like Certificate Transparency, and i= s about operational requirements.

I expect the floor for certificates to bottom out at around 21-30= days for publicly trusted certificates for the next decade, which potentia= lly would be mandated by requirements on issuance policy.
--000000000000725c9c056b4d4334-- From nobody Thu May 3 07:00:58 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E677612E047 for ; Thu, 3 May 2018 07:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5eoAf4GT6yQ for ; Thu, 3 May 2018 07:00:52 -0700 (PDT) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 67AD312E03E for ; Thu, 3 May 2018 07:00:52 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id m11-v6so14559262otf.3 for ; Thu, 03 May 2018 07:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kRlr6UAcs8q2B8DHUgOBTOfNEkkFStJfgd1lFZwURKQ=; b=Rtv9UYfUub7ztss63HI74h5c/OHooX7gv+ZNpMVPZQONtUrGram9dG7hQxavzf81xq 9HjT3hJlHOycXzqNO7u2z7RWxsdKd6LmaXiEfk7ZhKEuGlUYKv74R3MkXfPYdwQFlad+ JuTOfaLicfwLEtRW8IijCeyBz/VzRoQ9129nSB+VIEyFJRVJbkF34D/Yl3Unj+5aCduh OhzpQV6BSKGl4X+lxA3p3QSHzaY5Z7WX+MqRuDMqVzlzIAK9VaZW1hH13kyp7O4XM9C5 1NkhP/d+bFLYLHtVWR3Gei8moHMzwsTaitmmBn6J6vsEGS1vMzOySYFXU4pehH39ulSe T14g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kRlr6UAcs8q2B8DHUgOBTOfNEkkFStJfgd1lFZwURKQ=; b=P2l8F6knAyahNrj08DtagRK23bT/VgrZJeIOKBT4uU97Asi/9fm9KRG4UZEH/blDZm 8InigjhQb1v2SbMxvfjA1HzfFISnde6Z+S5KwavcLLGwGXbKLJL8nQL02wlRYQjOjGvR fj0CY0TnQRjVBI2W2Wg/LAGcKfG2rHMUWGkI3FfPWbyAy9TLwDGmW3y2RJpTxEaV2UVx U+BxNNoVAJWhwrF3C6JUElGh0wuFAfQ5t/aDFSL6FyPebPXBD4d1BIOCABX5X8FWYg+j twnV57F3e4wlT8jnDfqWG21Q7nKKPke/EOPnrtEc2mctSYfesoZoScjnI756zy5p6cpY SBcQ== X-Gm-Message-State: ALQs6tC98Fe+YJvRET4OfsWiyRgt1n2bwJNEznC/ssP9VaqwyECytQU7 84KYtzzIW98/MnOqZJCAtK4YWD+0wdd7+vCKDKY= X-Google-Smtp-Source: AB8JxZoX1H+coOCmS8V+hlm5XPRK8JWwAriVi/l5EjKBH2gYbE+RBRaE5qiELFBY59xSNHiFXpdglrH2/FcBHVL2O68= X-Received: by 2002:a9d:2083:: with SMTP id x3-v6mr509454ota.338.1525356051398; Thu, 03 May 2018 07:00:51 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:3283:0:0:0:0:0 with HTTP; Thu, 3 May 2018 07:00:50 -0700 (PDT) In-Reply-To: References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> <64CD1067-8639-4C2C-A8EC-ED5FBC14F633@gmail.com> From: Phillip Hallam-Baker Date: Thu, 3 May 2018 10:00:50 -0400 X-Google-Sender-Auth: Yww1XkFJURpxpduJdx5zT7-lcd8 Message-ID: To: Ryan Sleevi Cc: LAMPS , Russ Housley , Yoav Nir Content-Type: multipart/alternative; boundary="000000000000998618056b4da1f1" Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 14:00:55 -0000 --000000000000998618056b4da1f1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 3, 2018 at 9:25 AM, Ryan Sleevi wrote: > > On Thu, May 3, 2018 at 7:47 AM Phillip Hallam-Baker > wrote: > >> >> =E2=80=8BThe reason to move to short term certs is simple and has nothin= g to do >> with insufficiency: It is simply more efficient. >> >> Once you automate the process of certificate management, the move to >> short lived certs is inevitable and obvious because then the server only >> needs to cope with a single data object rather than two equivalent data >> objects. >> >> With a long lived cert plus OCSP: >> >> * The server has to update its cert every X days and update its OCSP >> token, a different code path, every day. >> * The client has to process the cert and then process the OCSP token, >> each of which has a separate trust path. >> > > To make sure I understand this claim: Is the view that adding yet another > method, which is not as expressive and with a host of trade offs, will > somehow payoff at some point in the future in which clients and servers n= o > longer have to implement or care about revocation data? > Short lived certs are exactly as expressive as long term plus OCSP with pre-generated validity tokens. While the intent of the original OCSP proposal (which I wrote the draft for and can thus speak with authority) was to enable insurance of individual transactions, I am not aware of any use of OCSP for that purpose. Nor do I expect any such use to arrive in the future as we subsequently developed the TAXI (Trust Assertion XML Infrastructure) for that purpose which is now known as SAML. I would rather like to think =E2=80=9Cthe spec is prettier if we do it this= way=E2=80=9D is > a poor justification for taking on work, so I was hoping a bit more > substance to a reply. > =E2=80=8BSimpler is better. =E2=80=8B Changing practice in the browser world is certainly possible but has a long payback time as it takes quite a while for browsers to update. Instituting best practice for Web Services is a totally different matter as there are new services being deployed every day and those that exist are often kept up to date very aggressively. > With a short lived cert: >> >> * The server has to update its cert every days. >> * The client has to process the cert. >> >> I do not understand where client certificates come into the argument. >> Obviously, the same approach may be applied to client certs but why woul= d >> anyone bother when the browser UI for client auth is so utterly useless? >> > > It=E2=80=99s unclear: you read the draft and are disagreeing with it, or = did you > read me reply and weren=E2=80=99t aware I was referencing the draft? The = mention of > browsers leads me to believe the latter, because the message I was replyi= ng > to identified this work was not for the Web PKI, but if the former, I=E2= =80=99m > hoping to bring a bit more clarity to the position. > =E2=80=8BAt this point in time, PKIX has established itself as a mechanism = =E2=80=8Bfor supporting server authentication. PKIX has not established itself as a mechanism for user authentication. SAML has been vastly more successful in that role. And I do not see that changing. TLS Client auth is not very useful as a means of authenticating users in a Web browser but it is very widely used as a means of authenticating Services to other Services. The distinction between 'client' and 'server' is not very useful here because all a 'client' is, is the party that initiates a transaction. PKIX is for authenticating services whether to users or to other services and regardless of whether it is the initiator or responder in a transaction. Of course we need to move to short lived certs for services because in the modern deployment, a service typically lives on a particular host for a matter of a few days or even hours. Generating keys valid for up to 2 years and then churning them round a data center simply means that every machine in that data center is a potential point of compromise. An obvious control to help mitigate this problem is to limit cert validity to the length of time we expect the service to remain on a particular machine and to generate new keying material every time the service moves to a new host. --000000000000998618056b4da1f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Ma= y 3, 2018 at 9:25 AM, Ryan Sleevi <ryan-ietf@sleevi.com> = wrote:

On Thu, May 3, 2018 at 7:47 AM P= hillip Hallam-Baker <phill@hallambaker.com> wrote:

=
=E2=80=8BThe reason to move to short te= rm certs is simple and has nothing to do with insufficiency: It is simply m= ore efficient.

Once you automate the process of certificate management, t= he move to short lived certs is inevitable and obvious because then the ser= ver only needs to cope with a single data object rather than two equivalent= data objects.

With a long lived cert plus OCSP:

* The server has to up= date its cert every X days and update its OCSP token, a different code path= , every day.=C2=A0
* The client has to = process the cert and then process the OCSP token, each of which has a separ= ate trust path.

To make sure I understand this cla= im: Is the view that adding yet another method, which is not as expressive = and with a host of trade offs, will somehow payoff at some point in the fut= ure in which clients and servers no longer have to implement or care about = revocation data?

Short lived certs are exactl= y as expressive as long term plus OCSP with pre-generated validity tokens.<= /div>

While the intent of the o= riginal OCSP proposal (which I wrote the draft for and can thus speak with = authority) was to enable insurance of individual transactions, I am not awa= re of any use of OCSP for that purpose. Nor do I expect any such use to arr= ive in the future as we subsequently developed the TAXI (Trust Assertion XM= L Infrastructure) for that purpose which is now known as SAML.
<= div>

=
I would rather like to think =E2=80=9Cthe spec is prettier if we do i= t this way=E2=80=9D is a poor justification for taking on work, so I was ho= ping a bit more substance to a reply.
=E2=80= =8BSimpler is better. =E2=80=8B

Changing practice in the browser world is certainly possible b= ut has a long payback time as it takes quite a while for browsers to update= .=C2=A0

Instituting best = practice for Web Services is a totally different matter as there are new se= rvices being deployed every day and those that exist are often kept up to d= ate very aggressively.=C2=A0
=C2=A0
With a short lived cert:

* The server h= as to update its cert every days.
* The client has to process the cert.=

I do not understand where client certificates come into the argume= nt. Obviously, the same approach may be applied to client certs but why wou= ld anyone bother when the browser UI for client auth is so utterly useless?=

It=E2=80=99s unclear: you read the draft and are disag= reeing with it, or did you read me reply and weren=E2=80=99t aware I was re= ferencing the draft? The mention of browsers leads me to believe the latter= , because the message I was replying to identified this work was not for th= e Web PKI, but if the former, I=E2=80=99m hoping to bring a bit more clarit= y to the position.

=E2=80=8BAt this point in = time, PKIX has established itself as a mechanism =E2=80=8Bfor supporting se= rver authentication. PKIX has not established itself as a mechanism for use= r authentication. SAML has been vastly more successful in that role. And I = do not see that changing.

TLS Client auth is not very useful as a means of authenticating users in a= Web browser but it is very widely used as a means of authenticating Servic= es to other Services.

The= distinction between 'client' and 'server' is not very usef= ul here because all a 'client' is, is the party that initiates a tr= ansaction. PKIX is for authenticating services whether to users or to other= services and regardless of whether it is the initiator or responder in a t= ransaction.
Of course we = need to move to short lived certs for services because in the modern deploy= ment, a service typically lives on a particular host for a matter of a few = days or even hours. Generating keys valid for up to 2 years and then churni= ng them round a data center simply means that every machine in that data ce= nter is a potential point of compromise.=C2=A0

An obvious control to help mitigate this problem is t= o limit cert validity to the length of time we expect the service to remain= on a particular machine and to generate new keying material every time the= service moves to a new host.

--000000000000998618056b4da1f1-- From nobody Thu May 3 07:41:30 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E19E12E89C for ; Thu, 3 May 2018 07:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 f_xwVXgzfMGB for ; Thu, 3 May 2018 07:41:26 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68A0612E8A0 for ; Thu, 3 May 2018 07:41:26 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id B96154000100C for ; Thu, 3 May 2018 07:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=rH2kSdxTKp5aG0y2ry0tKeqau3E=; b= RLOnVZUYMDFjl2XhcQRm+Jg0czZL8Sg0ewWEz/XhAaokZNO9U+tcndL8Il8NUJNl iGtiBc4Yy+AKHza5hSfN5/C1JdQBu+MRk67IhzlDkw2Lsk/z6Tz05DeQJHLdRHoc Yg54u/Mwwu8WN2MYH38SNo/6I05v3KU4LBHEtbauktw= Received: from mail-it0-f46.google.com (mail-it0-f46.google.com [209.85.214.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id D742940001008 for ; Thu, 3 May 2018 07:41:24 -0700 (PDT) Received: by mail-it0-f46.google.com with SMTP id f65-v6so18121123itd.3 for ; Thu, 03 May 2018 07:41:24 -0700 (PDT) X-Gm-Message-State: ALQs6tA7ui6JNyPCTLcoQxnZb2qlYIYwirJ9072GXmYfxbLWMS+GQLUl kSu/p0pIUg6QCuBXPoqs4w+8iYN15kWXp28257s= X-Google-Smtp-Source: AB8JxZrHMmkc6BMKkg09nFAayfg1WoMAfGRbvO8tmy+fVZ/5z3E3TOA7TMsIGbnWJfKH2c1VDQ+ZKbUXp19JcasC3xo= X-Received: by 2002:a24:d88b:: with SMTP id b133-v6mr23839815itg.119.1525358484281; Thu, 03 May 2018 07:41:24 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:985a:0:0:0:0:0 with HTTP; Thu, 3 May 2018 07:41:23 -0700 (PDT) In-Reply-To: References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> <64CD1067-8639-4C2C-A8EC-ED5FBC14F633@gmail.com> From: Ryan Sleevi Date: Thu, 3 May 2018 10:41:23 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Phillip Hallam-Baker Cc: Ryan Sleevi , LAMPS , Russ Housley , Yoav Nir Content-Type: multipart/alternative; boundary="0000000000009c62b4056b4e3245" Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 14:41:29 -0000 --0000000000009c62b4056b4e3245 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 3, 2018 at 10:00 AM, Phillip Hallam-Baker wrote: > > > On Thu, May 3, 2018 at 9:25 AM, Ryan Sleevi wrote: > >> >> On Thu, May 3, 2018 at 7:47 AM Phillip Hallam-Baker < >> phill@hallambaker.com> wrote: >> >>> >>> =E2=80=8BThe reason to move to short term certs is simple and has nothi= ng to do >>> with insufficiency: It is simply more efficient. >>> >>> Once you automate the process of certificate management, the move to >>> short lived certs is inevitable and obvious because then the server onl= y >>> needs to cope with a single data object rather than two equivalent data >>> objects. >>> >>> With a long lived cert plus OCSP: >>> >>> * The server has to update its cert every X days and update its OCSP >>> token, a different code path, every day. >>> * The client has to process the cert and then process the OCSP token, >>> each of which has a separate trust path. >>> >> >> To make sure I understand this claim: Is the view that adding yet anothe= r >> method, which is not as expressive and with a host of trade offs, will >> somehow payoff at some point in the future in which clients and servers = no >> longer have to implement or care about revocation data? >> > > Short lived certs are exactly as expressive as long term plus OCSP with > pre-generated validity tokens. > > While the intent of the original OCSP proposal (which I wrote the draft > for and can thus speak with authority) was to enable insurance of > individual transactions, I am not aware of any use of OCSP for that > purpose. Nor do I expect any such use to arrive in the future as we > subsequently developed the TAXI (Trust Assertion XML Infrastructure) for > that purpose which is now known as SAML. > > I would rather like to think =E2=80=9Cthe spec is prettier if we do it th= is way=E2=80=9D >> is a poor justification for taking on work, so I was hoping a bit more >> substance to a reply. >> > > =E2=80=8BSimpler is better. =E2=80=8B > > Changing practice in the browser world is certainly possible but has a > long payback time as it takes quite a while for browsers to update. > > Instituting best practice for Web Services is a totally different matter > as there are new services being deployed every day and those that exist a= re > often kept up to date very aggressively. > While we may disagree as to whether this work is simpler - the draft I think demonstrates that it's not, in practice, for any party involved (relying party, CA, or service operator). However, I think there's something to your point here which gets to the heart of whether LAMPS should be undertaking this work. This is now the second message that you've referenced the "browser world". While the initial replies suggested non-browser/non-WebPKI case, which may be perfectly reasonable, I'm trying to fully understand your position: Is it that this work is intended for the browser case? If browsers explicitly prohibit the use of such work, or reject implementation, does that undermine or devalue the work and implementation experience? Because I do not see this being supported in browsers, and I think it's extremely likely of being explicitly forbidden. I highlight this in order to make sure there's consensus on what the draft is for - since the draft itself leaves it ambiguous - and whether or not there's a representative sample of implementors for that target use case. The nature of this question is what plagued PKIX, and if we're trying to ensure that LAMPS does not succumb to the overbroad, unadopted, zombie effort that WGs can succumb to, then my $.02 we should make sure that the goal and uses are as crisp as possible before adopting that work as a WG. We can (and should) work out the "How" as a WG document, but the "Why" seems like it should be addressed before adopting and incorporating into the charter. --0000000000009c62b4056b4e3245 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, May 3, 2018 at 10:00 AM, Phillip Hallam-Baker <phill@halla= mbaker.com> wrote:


On Thu, May 3, 2018 at 9:= 25 AM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:

<= div class=3D"m_5849513107002665015h5">
On= Thu, May 3, 2018 at 7:47 AM Phillip Hallam-Baker <phill@hallambaker.com> wrote:<= br>

=
=E2=80=8BThe reason to move to short term certs is simple an= d has nothing to do with insufficiency: It is simply more efficient.
<= div style=3D"font-size:small">
Once= you automate the process of certificate management, the move to short live= d certs is inevitable and obvious because then the server only needs to cop= e with a single data object rather than two equivalent data objects.
<= div style=3D"font-size:small">
With= a long lived cert plus OCSP:

* The server has to update its cert every X= days and update its OCSP token, a different code path, every day.=C2=A0
* The client has to process the cert and = then process the OCSP token, each of which has a separate trust path.
=

To make sure I understand this = claim: Is the view that adding yet another method, which is not as expressi= ve and with a host of trade offs, will somehow payoff at some point in the = future in which clients and servers no longer have to implement or care abo= ut revocation data?

Short lived certs are exactly as expressiv= e as long term plus OCSP with pre-generated validity tokens.

While the in= tent of the original OCSP proposal (which I wrote the draft for and can thu= s speak with authority) was to enable insurance of individual transactions,= I am not aware of any use of OCSP for that purpose. Nor do I expect any su= ch use to arrive in the future as we subsequently developed the TAXI (Trust= Assertion XML Infrastructure) for that purpose which is now known as SAML.=

=
I would rather like to think =E2=80=9Cthe spec is prettier if w= e do it this way=E2=80=9D is a poor justification for taking on work, so I = was hoping a bit more substance to a reply.
<= div>
=E2=80=8BSimpler i= s better. =E2=80=8B

Changing practice in the browser world is certa= inly possible but has a long payback time as it takes quite a while for bro= wsers to update.=C2=A0

Instituting best practice for Web Services is a to= tally different matter as there are new services being deployed every day a= nd those that exist are often kept up to date very aggressively.=C2=A0

While we may disagree a= s to whether this work is simpler - the draft I think demonstrates that it&= #39;s not, in practice, for any party involved (relying party, CA, or servi= ce operator). However, I think there's something to your point here whi= ch gets to the heart of whether LAMPS should be undertaking this work. This= is now the second message that you've referenced the "browser wor= ld". While the initial replies suggested non-browser/non-WebPKI case, = which may be perfectly reasonable, I'm trying to fully understand your = position: Is it that this work is intended for the browser case? If browser= s explicitly prohibit the use of such work, or reject implementation, does = that undermine or devalue the work and implementation experience? Because I= do not see this being supported in browsers, and I think it's extremel= y likely of being explicitly forbidden.

I highligh= t this in order to make sure there's consensus on what the draft is for= - since the draft itself leaves it ambiguous - and whether or not there= 9;s a representative sample of implementors for that target use case. The n= ature of this question is what plagued PKIX, and if we're trying to ens= ure that LAMPS does not succumb to the overbroad, unadopted, zombie effort = that WGs can succumb to, then my $.02 we should make sure that the goal and= uses are as crisp as possible before adopting that work as a WG.

We can (and should) work out the "How" as a WG do= cument, but the "Why" seems like it should be addressed before ad= opting and incorporating into the charter.
--0000000000009c62b4056b4e3245-- From nobody Thu May 3 07:47:05 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAA912E8C2 for ; Thu, 3 May 2018 07:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] 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 hqBUESCJwJT7 for ; Thu, 3 May 2018 07:46:50 -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 2676D12E8C4 for ; Thu, 3 May 2018 07:46:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 21102BE38; Thu, 3 May 2018 15:46:46 +0100 (IST) 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 SaIp6FYDv2nJ; Thu, 3 May 2018 15:46:46 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AB137BE24; Thu, 3 May 2018 15:46:45 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1525358805; bh=2+xxTW6daze+EWT8zteXCBlL+zyDDakwZ0MHPQiQJCk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=GAX3kuOOwrV6qDX0LENRPQiNf1gbrK8IpVE/0dPSfS11KG/28E6WijDUW5achY+F3 Au/Gmca3ZFbd1S3OW0NH7aFfEWLxxcEOYddGA10+zKtSRV6LN1f/vijRyEV+vocnmA 3devKwEYpEvpcfXkIU85xxHJoFzvIQXe7+y1pTo8= To: Ryan Sleevi , Phillip Hallam-Baker Cc: LAMPS , Russ Housley , Yoav Nir References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> <64CD1067-8639-4C2C-A8EC-ED5FBC14F633@gmail.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <2696d841-c5bf-d0b4-5ef1-c4a0839bba94@cs.tcd.ie> Date: Thu, 3 May 2018 15:46:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YH8m11LGXRmU1bd5bCQE8uxDEOJQasZvE" Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 14:47:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --YH8m11LGXRmU1bd5bCQE8uxDEOJQasZvE Content-Type: multipart/mixed; boundary="95x6eu9yN0R9wCwLMjegMjRv35VWQoqnB"; protected-headers="v1" From: Stephen Farrell To: Ryan Sleevi , Phillip Hallam-Baker Cc: LAMPS , Russ Housley , Yoav Nir Message-ID: <2696d841-c5bf-d0b4-5ef1-c4a0839bba94@cs.tcd.ie> Subject: Re: [lamps] Draft LAMPS Recharter References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> <64CD1067-8639-4C2C-A8EC-ED5FBC14F633@gmail.com> In-Reply-To: --95x6eu9yN0R9wCwLMjegMjRv35VWQoqnB Content-Type: multipart/mixed; boundary="------------A5270FDD0247C9BBED3A3F81" Content-Language: en-GB This is a multi-part message in MIME format. --------------A5270FDD0247C9BBED3A3F81 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don't have a position on the draft in question but... On 03/05/18 15:41, Ryan Sleevi wrote: > The nature of this question is what plagued PKIX, and if we're trying t= o > ensure that LAMPS does not succumb to the overbroad, unadopted, zombie > effort that WGs can succumb to, then my $.02 we should make sure that t= he > goal and uses are as crisp as possible before adopting that work as a W= G. =2E.. that certainly resonates with me;-) I hope lamps does stick with the "only adopt if we think it's really quite likely to be used" aspect of the charter. S. --------------A5270FDD0247C9BBED3A3F81 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6 UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM 1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/ lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9 lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/ VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3DTOQn -----END PGP PUBLIC KEY BLOCK----- --------------A5270FDD0247C9BBED3A3F81-- --95x6eu9yN0R9wCwLMjegMjRv35VWQoqnB-- --YH8m11LGXRmU1bd5bCQE8uxDEOJQasZvE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlrrINQACgkQWrL68XsX K+qlfQ/+KRI3UJgTSZESWSFB2jJv7up6c2iyjd0lhtE3/dmqrK4J+UCePN+kZ+Ea cksOyUhBfndAs/vp3TMmjh9DjiRjRCxGt4913iVd7orCJd4WWbE8Mn/VDSIErhZk 36qCuSntRp+rP0ElVPenjSA8SD0T1KdHeq9gXF4lXnZ9HDHmhKK848TE31QXaWWx r+w4h/Tvo7X21yMUvHVw64spzRxHayCQ/JZ1Yc2MmvXK4iR3nSW9MsWwanRYymxb 0GFzQ1vm3tDaZrPUvOY3r1iqMHDKYI6IlJO6exBHnqkc0/fp6WZ05uSEIbDPNaS0 J53wOBgz8BgU1FiZguliNYY9lncZ/1xRiHIWn2RgAPFW5w2nSO1qFYVfYoC9Kpae paMiTv18s8NkE0+J44TLFcrpHsusYvqBlHSjMdzo4CjHblGrsJ1NeEe9Ss/gYb1E WOTMQ5eVzIOXzw1W4hVWlhCAITkIJrJcOzGtAbCcwNhRry1WuqdlyxjjwmR4keTO pic5ud43kAtECN1ZaoLg25jYqF28U/HKUZeTVzBbP8KiAl5znOYDu8Tnh/mCPV3i WfqT9Lwcg5va25oCKMinZ/RFPEPnRpEVa2xUdp4Bzo4QqH7NNWyVvu12pAofMLmi xUEI42etb7ptUBK+/IG/gshr/QKNULYRPPsZwGarOQhG2Tq4Uks= =6bD1 -----END PGP SIGNATURE----- --YH8m11LGXRmU1bd5bCQE8uxDEOJQasZvE-- From nobody Thu May 3 07:47:39 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD8E12E8A0; Thu, 3 May 2018 07:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.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 wHrmLMqoqC1F; Thu, 3 May 2018 07:47:36 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311E712E89C; Thu, 3 May 2018 07:47:36 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id g14-v6so18251830ioc.7; Thu, 03 May 2018 07:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=12ZwvSW+NkbMobU7t2Zb7QJdyNCEdh5lrmJGdLZbaI0=; b=ASlZR3uHXozz7FcpgbcTOXpHDfrqGzq+MxSlCNlDGVOi4jEmGjGWCbgfNDFa8KlGnq Y6x9LBaC+Gzv//4LZLjSt4nQbv4UzdbN40s9+qfkt/FI7c3Lf4IbwD1IVhR0H16MLHVV zo9mIKaE3sjzE0WSXykUu9G72AM0Jyc1KtpDfGyg8HlbFljDWs+w/kWBfnbFfuqa5wv6 IG1G1hlxvIOFh6uGzY0pjcLCEvoXQYgqQhLtQ6XSiH7ZY7X89hIVKkI0CTIeW7JAV8Ze bqCaMXDsbvYA3sQEHEWVCB8s4g8LvygoMIiuZF37BqNqZddJnxlKlkCd4CSUGJpXVSrk iRvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=12ZwvSW+NkbMobU7t2Zb7QJdyNCEdh5lrmJGdLZbaI0=; b=iXSVqVCedDWW6paTEmb/tnO5fDQsPHpKO5UqxIzz2U8G5T5Vyavd9jOiSTyu0feGZE pjczK4eg+gCzzT3fG09ofQd2zgp9tsn1L3pfCEQQyFKraMVAGP40feS9gab7+rI1GbRd QW80Vv4QSQR3f0ITOS6PvfAMbWkioB5vDDhxMQP/CGk7POpGIRgMjm4hJucqTbEOjg1l CMw44TJU1gO7kSWsux0vYA9Koy7s5D9maLsIrSGI4vUmPRPbP2XG1lVBZR13tBZC8ybR d0PVy3MT1mW3trwIH7uzmRsejyj2ePYpbSvhfz7DwQRKq3YsGLyHEQuiWI2PuPdivgpW UPGQ== X-Gm-Message-State: ALQs6tC9uCGRA4ThzLQ2l5wah6hHmhp0ztRVlo/Vy3+IhJ0pr41pZHb5 jhN4E2bWL+EhxYw2Z79P3Fu8QZjiC66AoQPn0PA= X-Google-Smtp-Source: AB8JxZplgsPG2AjNE24hgiHRjE4YGc0jxBBSc0O6y5U7Sj/PqAdOdb3X3KAOmeBEmv5cltXz/ub93Rq8B2YT6Q+DKH0= X-Received: by 2002:a6b:5010:: with SMTP id e16-v6mr24886231iob.274.1525358855316; Thu, 03 May 2018 07:47:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:e595:0:0:0:0:0 with HTTP; Thu, 3 May 2018 07:47:34 -0700 (PDT) In-Reply-To: References: <152482849638.5933.11114167602347254978@ietfa.amsl.com> From: Ines Robles Date: Thu, 3 May 2018 17:47:34 +0300 Message-ID: To: Russ Housley Cc: IETF Gen-ART , LAMPS , draft-ietf-lamps-rfc5750-bis.all@ietf.org, IETF Content-Type: multipart/alternative; boundary="000000000000b9ebf8056b4e4843" Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-rfc5750-bis-05 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 14:47:38 -0000 --000000000000b9ebf8056b4e4843 Content-Type: text/plain; charset="UTF-8" Yes, right, Thank you for the corrections 2018-04-27 19:45 GMT+03:00 Russ Housley : > These are references to ASN.1 definitions, so they should not be changed > as indicated. > > Russ > > > On Apr 27, 2018, at 7:28 AM, Ines Robles > wrote: > > Section 2.3: CertificateSet --> Certificate Set > > Section 4.4.1: basicConstraints --> basic Constraints > > > --000000000000b9ebf8056b4e4843 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, right, Thank you for the corrections

2018-04-27 19:45 GMT+03:00 = Russ Housley <housley@vigilsec.com>:
These are references to A= SN.1 definitions, so they should not be changed as indicated.

Russ


<= div>On Apr 27, 2018, at 7:28 AM, Ines Robles <mariainesrobles@googlemail.c= om> wrote:

Section 2.3: Certificate= Set --> Certificate Set

Section= 4.4.1: basicConstraints --> basic Constraints
=


--000000000000b9ebf8056b4e4843-- From nobody Thu May 3 07:48:34 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619DE12E8C4; Thu, 3 May 2018 07:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.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 JEYVIQG58hnx; Thu, 3 May 2018 07:48:22 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 14E8512E89C; Thu, 3 May 2018 07:48:22 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id e12-v6so21939031iob.8; Thu, 03 May 2018 07:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ukv5Dk4y7guqsUoP66nSri4g9t4GVs1hul+dZy5ww3Q=; b=lGEHXsuDz8kjS/1Np9YLL1ynJEbswq70ea2KNaoKifsYum/azDve9INxknaEpvJUh9 Nh0pNPgB1bLtYElsUGv7kKhQeqzGAukaDur4ynMnmw3H1QfpwqxKivfjJ9qAqyNi+CAK uoNMSXTbWb6eLJPJTFRq77P7k9hX3hUgfa771NT9RIMQwNTD54B4j/Nz39wfa1QBbdga +kxNPJ1HQOwrzBzfWKnNg8HMiBQuai2/AXTliyGigVll3SN+0UtKAiO1bbT8XDLRnJX3 tZ3OHPJHf8wkGZxVj/0HRun0E2FTEDP0MzTfd2MMqY3sUuVyRCyYwRMYwYvIQ27GmEGK rxSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ukv5Dk4y7guqsUoP66nSri4g9t4GVs1hul+dZy5ww3Q=; b=BbM96sTuDEYTW5vbjoieanbQudxlNuHew0BUI/rqH8RQQ7OwPB6Bke7+xox56CT8W3 w+/vAUBpGuM0ILnf0bo0Y2n9tGf9UVS7YolSHOgXo1nrfXwhWuQcW2iRW+dsd5v2Bp7V 4tGwSfeSPW4MH/zb1LIaSKif97alFyhF/HZb/EfeYLQ2JYDoEJIR8wFW0JMjqLGe7GLr yqGotzBrs+IQB24xJwKGsgRWJarKaVg/unnduBzBIi9diN+NbMo8ne2/pBueAB5LoJaS tm2SromX+HHKME5WjldQmaDN4RECUg2TMjAJgpFp9YQ6UId1BHOhzNA0uBSAAmbVaxYc IHzA== X-Gm-Message-State: ALQs6tA2Jj7ARmayHbakY9ULAJpNi0yYRfzsYPu8ZspIiiRHHdhOOoAF V4wM/z8B/L3IQHY2z8x47ejic3q+wwkFAsTjYGE= X-Google-Smtp-Source: AB8JxZoVaICK1PWFT2e1Y9by/4cy95TgkkDVB52Q4Zwr1K1YK64HH5QE/ypzbULUa4rD7Aa+6lvjCDyD5wI1B3w4MmI= X-Received: by 2002:a6b:5010:: with SMTP id e16-v6mr24889174iob.274.1525358901238; Thu, 03 May 2018 07:48:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:e595:0:0:0:0:0 with HTTP; Thu, 3 May 2018 07:48:20 -0700 (PDT) In-Reply-To: <054401d3e271$dfad1340$9f0739c0$@augustcellars.com> References: <152482849638.5933.11114167602347254978@ietfa.amsl.com> <054401d3e271$dfad1340$9f0739c0$@augustcellars.com> From: Ines Robles Date: Thu, 3 May 2018 17:48:20 +0300 Message-ID: To: Jim Schaad Cc: IETF Gen-ART , LAMPS , draft-ietf-lamps-rfc5750-bis.all@ietf.org, ietf Content-Type: multipart/alternative; boundary="00000000000076a046056b4e4be4" Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-rfc5750-bis-05 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 14:48:29 -0000 --00000000000076a046056b4e4be4 Content-Type: text/plain; charset="UTF-8" Ok, Thanks for the feedback. Best, Ines. 2018-05-03 3:01 GMT+03:00 Jim Schaad : > > > > -----Original Message----- > > From: Ines Robles > > Sent: Friday, April 27, 2018 4:28 AM > > To: gen-art@ietf.org > > Cc: spasm@ietf.org; draft-ietf-lamps-rfc5750-bis.all@ietf.org; > ietf@ietf.org > > Subject: Genart last call review of draft-ietf-lamps-rfc5750-bis-05 > > > > Reviewer: Ines Robles > > Review result: Ready with Issues > > > > Hello, > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review > > Team (Gen-ART) reviews all IETF documents being processed by the IESG for > > the IETF Chair. Please treat these comments just like any other last > call > > comments. > > > > For more information, please see the FAQ at > > > > . > > > > Document: draft-ietf-lamps-rfc5750-bis-05 > > Reviewer: Ines Robles > > Review Date: 27-04-2018 > > IETF LC End Date: 27-04-2018 > > IESG Telechat date: --- > > > > Summary: > > > > I believe the draft is technically good. This document is well written > and clear > > to understand. Some minor concerns are mentioned that should be resolved > > before publication. > > > > Major issues: No major issues found. > > > > Minor issues: > > > > Section 1.6: > > > > It would be nice to start the section with some text like "This > document > > obsoletes 5750 due to the addition of the following information...." > > This is missing information, however I think it should go into section 1 - > Introduction and not be buried here. The new text does point to this > section. > > > > > Section 2.3: > > > > "but SHOULD use some other mechanism to determine ...." => It would > be > > nice > > to mention some examples of the other mechanism > > > > "...but SHOULD use some other mechanism (such as ....) to > determine..." > > I am not sure that this would be a useful addition. I can see two > different outcomes from this which neither of which is helpful. > > * People will complain about implementations which do not implement all > of the items in the list > * People will complain that something should not be implemented because > it is not on the list > > One of the problems is that this will be a list that is not very useful. > Items can range anywhere from use the set of trust points you already have > and don't let it be expanded to call the other person up and get them to > read you a hash value to look at various trusted locations for root > certificates, including some types of transparency logs. I cannot really > say that any of these is what I would recommend. The knowledge of how > trust configuration is handed is an extremely application and > implementation specific function. > > > > > Section 4: > > > > Related to this: > > "Another method under consideration by the IETF is to provide > certificate > > retrieval services as part of the existing Domain Name System (DNS)" > > > > - This text seems to be out of the date (since belongs as well to > RFC5750 > > (2010)), maybe it would be nice to re-write it (e.g. method under > > consideration => method approved) and add a reference of the proposed > > methods. Would it be RFC 8162 [1] a good reference for this topic? > > > > [1] https://tools.ietf.org/html/rfc8162: Using Secure DNS to Associate > > Certificates with Domain Names for S/MIME > > This was raised during the rfc5751-bis review as well. I have replaced > that sentence with a pointer to the experimental DANE draft. > > > > > Nits/editorial comments: > > > > Section 2.3: CertificateSet --> Certificate Set > > > > Section 4.4.1: basicConstraints --> basic Constraints > > > > Thanks for this document! > > > > Ines. > > > > > --00000000000076a046056b4e4be4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok,=C2=A0

Thanks for the feedback.

Best,

Ines.

2018-05-03 3:01 GMT+03:= 00 Jim Schaad <ietf@augustcellars.com>:


> -----Original Message-----
> From: Ines Robles <mariainesrobles@googlemail.com>
> Sent: Friday, April 27, 2018 4:28 AM
> To: gen-art@ietf.org
> Cc: spasm@ietf.org; draft-ietf-lamps-rfc5750-b= is.all@ietf.org; ietf@ietf.org
> Subject: Genart last call review of draft-ietf-lamps-rfc5750-bis-= 05
>
> Reviewer: Ines Robles
> Review result: Ready with Issues
>
> Hello,
>
> I am the assigned Gen-ART reviewer for this draft. The General Area Re= view
> Team (Gen-ART) reviews all IETF documents being processed by the IESG = for
> the IETF Chair.=C2=A0 Please treat these comments just like any other = last call
> comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenAr= tfaq>.
>
> Document: draft-ietf-lamps-rfc5750-bis-05
> Reviewer: Ines Robles
> Review Date: 27-04-2018
> IETF LC End Date:=C2=A0 27-04-2018
> IESG Telechat date: ---
>
> Summary:
>
> I believe the draft is technically good. This document is well written= and clear
> to understand. Some minor concerns are mentioned that should be resolv= ed
> before publication.
>
> Major issues: No major issues found.
>
> Minor issues:
>
> Section 1.6:
>
>=C2=A0 =C2=A0 =C2=A0It would be nice to start the section with some tex= t like "This document
>=C2=A0 =C2=A0 =C2=A0obsoletes 5750 due to the addition of the following= information...."

This is missing information, however I think it should go into = section 1 - Introduction and not be buried here.=C2=A0 The new text does po= int to this section.

>
> Section 2.3:
>
>=C2=A0 =C2=A0 =C2=A0"but SHOULD use some other mechanism to determ= ine ...." =3D> It would be
> nice
>=C2=A0 =C2=A0 =C2=A0to mention some examples of the other mechanism
>
>=C2=A0 =C2=A0 =C2=A0"...but SHOULD use some other mechanism (such = as ....) to determine..."

I am not sure that this would be a useful addition.=C2=A0 I can see = two different outcomes from this which neither of which is helpful.

*=C2=A0 People will complain about implementations which do not implement a= ll of the items in the list
*=C2=A0 People will complain that something should not be implemented becau= se it is not on the list

One of the problems is that this will be a list that is not very useful.=C2= =A0 Items can range anywhere from use the set of trust points you already h= ave and don't let it be expanded to call the other person up and get th= em to read you a hash value to look at various trusted locations for root c= ertificates, including some types of transparency logs.=C2=A0 I cannot real= ly say that any of these is what I would recommend.=C2=A0 The knowledge of = how trust configuration is handed is an extremely application and implement= ation specific function.

>
> Section 4:
>
>=C2=A0 =C2=A0 =C2=A0Related to this:
>=C2=A0 =C2=A0 =C2=A0"Another method under consideration by the IET= F is to provide certificate
>=C2=A0 =C2=A0 =C2=A0retrieval services as part of the existing Domain N= ame System (DNS)"
>
>=C2=A0 =C2=A0 =C2=A0- This text seems to be out of the date (since belo= ngs as well to RFC5750
>=C2=A0 =C2=A0 =C2=A0(2010)), maybe it would be nice to re-write it (e.g= . method under
>=C2=A0 =C2=A0 =C2=A0consideration =3D> method approved) and add a re= ference of the proposed
>=C2=A0 =C2=A0 =C2=A0methods. Would it be RFC 8162 [1] a good reference = for this topic?
>
> [1] https://tools.ietf.org/html/rfc8162:=C2=A0 Usin= g Secure DNS to Associate
> Certificates with Domain Names for S/MIME

This was raised during the rfc5751-bis review as well.=C2=A0 I have = replaced that sentence with a pointer to the experimental DANE draft.

>
> Nits/editorial comments:
>
> Section 2.3: CertificateSet --> Certificate Set
>
> Section 4.4.1: basicConstraints --> basic Constraints
>
> Thanks for this document!
>
> Ines.
>



--00000000000076a046056b4e4be4-- From nobody Thu May 3 13:10:29 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B5812EAC3 for ; Thu, 3 May 2018 13:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id la4XpZHUcl42 for ; Thu, 3 May 2018 13:10:25 -0700 (PDT) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38ADB12EA6A for ; Thu, 3 May 2018 13:10:25 -0700 (PDT) Received: by mail-ot0-x236.google.com with SMTP id g7-v6so22079361otj.11 for ; Thu, 03 May 2018 13:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ifwy6LmQHSiPe6ZARXCskgT/4cOQH+5uPxlycgYbG1A=; b=TvIfYLvkkNx1iZXuus/isyicn+g4n3c3XCwBD5S+5INeB9nHW5ucbgkomhHl78g5MR xzG1du7vLt4y/PS5y/J+H8BzQ4Jgu/p2RKSrJvy22G6AJbR9+wL8s3/gjEF/9a7yBUHI xDgt6dTZbbpb7N+9szbHj4mthG0tII4maIFq7Sb87De1PGQuWOqzkQEoCRiAv8vEliYc pEO8JNy6YtsyyDzdvYOdxusoNGz4YXLzdoE1gqxolEOatk4Ha27H5ocBsICtv4YpK7Rw 1OEFdn2YbCOvBVGofiEDGLfyiC2SfRYO+gQ75RxNjSSrJJA5ZnNhy+WWsaA81/RdNRYg RZxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ifwy6LmQHSiPe6ZARXCskgT/4cOQH+5uPxlycgYbG1A=; b=ihE+Tp4e+GKi0W0BgrlY3U5R1l7BcFVk1nBvA4X0psRHQxI5vjRypGfUVaHU0gwl2A BVHIdWIcqR+nHPVCzEv1IhJPUedjf2YD/hkj3aehz/T+NwkpiP+N9GLPifLgx39E35Wm O4htNKIjwmXSNv31i0Dwj9YqQljjyHnvICq5X+bzOhRnn3t5GVgIBqoKJ3y70HrJHQVD Lq3Wa8hphByylXUTmqC5uoqLLa0WLx4sqsHIDMDPNM7ajNBvzy2/XvefPd48V9oGv1+P OAsYCk6Vs1OYy/Hqspx15pFhyrrA926Mv2d+zTTvzG8n6WviJ6zqRJEGEk20ufDtLuDD +Yqw== X-Gm-Message-State: ALQs6tAOWw3oj1I0e9qEnJHyv3xikbucrcC1Em2WXqVc9XvXBw54b11g uaPjcMRF2etmbVZHjxWUocvSSvq7SBY7ufe5no2X8g== X-Google-Smtp-Source: AB8JxZrJBqPpgNK0wOv4Zy6HNYPfdlz9AAK9xXn0e4k7fp3c6R5GHgMdMHj/Qo4OthspUdKppR2EF1f3tTKqv0F1Bnk= X-Received: by 2002:a9d:72c6:: with SMTP id d6-v6mr4674037otk.392.1525378224556; Thu, 03 May 2018 13:10:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Thu, 3 May 2018 13:09:43 -0700 (PDT) In-Reply-To: <054301d3e271$dc22db10$94689130$@augustcellars.com> References: <152432458128.20660.6956595430755199355@ietfa.amsl.com> <054301d3e271$dc22db10$94689130$@augustcellars.com> From: Eric Rescorla Date: Thu, 3 May 2018 13:09:43 -0700 Message-ID: To: Jim Schaad Cc: Matthew Miller , secdir@ietf.org, SPASM , draft-ietf-lamps-rfc5750-bis.all@ietf.org, IETF discussion list Content-Type: multipart/alternative; boundary="000000000000391e5f056b52cb77" Archived-At: Subject: Re: [lamps] Secdir last call review of draft-ietf-lamps-rfc5750-bis-05 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 20:10:27 -0000 --000000000000391e5f056b52cb77 Content-Type: text/plain; charset="UTF-8" probably "parse" not "parser" On Wed, May 2, 2018 at 5:01 PM, Jim Schaad wrote: > > > > -----Original Message----- > > From: Matthew Miller > > Sent: Saturday, April 21, 2018 8:30 AM > > To: secdir@ietf.org > > Cc: spasm@ietf.org; draft-ietf-lamps-rfc5750-bis.all@ietf.org; > ietf@ietf.org > > Subject: Secdir last call review of draft-ietf-lamps-rfc5750-bis-05 > > > > Reviewer: Matthew Miller > > Review result: Has Nits > > > > I have reviewed this document as part of the security directorate's > ongoing > > effort to review all IETF documents being processed by the IESG. These > > comments were written primarily for the benefit of the security area > > directors. Document editors and WG chairs should treat these comments > > just like any other last call comments. > > > > Document: draft-ietf-lamps-rfc5750-bis-05 > > Reviewer: Matthew A. Miller > > Review Date: 2018-04-21 > > IETF LC End Date: 2018-04-27 > > IESG Telechat date: N/A > > > > Summary: > > > > This document is ready, but there is one nit around PKCS #6 handling that > > might benefit from explanation. > > > > This document describes the certificate handling expectations for senders > > and receivers of S/MIME 4.0. It obsoletes RFC 5750, adding requirements > to > > support internationalized email addresses, increase RSA minimum key > sizes, > > and support ECDSA using P-256 and Ed25519; older algorithms such as DSA, > > MD5, and SHA-1 are relegated to historical. > > > > Major Issues: N/A > > > > Minor Issues: N/A > > > > Nits: > > > > Section 2.2.1. "Historical Note about CMS Certificates" is almost entired > > unchanged, but added a requirement that receivers MUST be able to process > > PCKS #6 extended certificates. This almost seems at odds with the rest > of > > the paragraph that precedes this MUST, noting PKCS #6 has little use and > > PKIX is functionally equivalent. > > A short explanation of why this additional handling requirement would > seem > > helpful. > > How about the following which is just a description of what we are looking > for in terms of behavior. > > Receiving agents MUST be able to parser and process a message > containing PKCS #6 extended certificates although ignoring those > certificates is expected behavior. > > > > --000000000000391e5f056b52cb77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
probably "parse" not "parser"


On Wed, May 2, 2018 at 5:01 PM, Jim Schaad <ietf@augustcellars.= com> wrote:


> -----Original Message-----
> From: Matthew Miller <linuxwolf+ietf@outer-planes.net>
> Sent: Saturday, April 21, 2018 8:30 AM
> To: secdir@ietf.org
> Cc: spasm@ietf.org; draft-ietf-lamps-rfc5750-b= is.all@ietf.org; ietf@ietf.org
> Subject: Secdir last call review of draft-ietf-lamps-rfc5750-bis-= 05
>
> Reviewer: Matthew Miller
> Review result: Has Nits
>
> I have reviewed this document as part of the security directorate'= s ongoing
> effort to review all IETF documents being processed by the IESG.=C2=A0= These
> comments were written primarily for the benefit of the security area > directors.=C2=A0 Document editors and WG chairs should treat these com= ments
> just like any other last call comments.
>
> Document: draft-ietf-lamps-rfc5750-bis-05
> Reviewer: Matthew A. Miller
> Review Date: 2018-04-21
> IETF LC End Date: 2018-04-27
> IESG Telechat date: N/A
>
> Summary:
>
> This document is ready, but there is one nit around PKCS #6 handling t= hat
> might benefit from explanation.
>
> This document describes the certificate handling expectations for send= ers
> and receivers of S/MIME 4.0.=C2=A0 It obsoletes RFC 5750, adding requi= rements to
> support internationalized email addresses, increase RSA minimum key si= zes,
> and support ECDSA using P-256 and Ed25519; older algorithms such as DS= A,
> MD5, and SHA-1 are relegated to historical.
>
> Major Issues: N/A
>
> Minor Issues: N/A
>
> Nits:
>
> Section 2.2.1. "Historical Note about CMS Certificates" is a= lmost entired
> unchanged, but added a requirement that receivers MUST be able to proc= ess
> PCKS #6 extended certificates.=C2=A0 This almost seems at odds with th= e rest of
> the paragraph that precedes this MUST, noting PKCS #6 has little use a= nd
> PKIX is functionally equivalent.
> A short explanation of why this additional handling requirement would = seem
> helpful.

How about the following which is just a description of what we = are looking for in terms of behavior.

=C2=A0 =C2=A0Receiving agents MUST be able to parser and process a message = containing PKCS #6 extended certificates although ignoring those certificat= es is expected behavior.




--000000000000391e5f056b52cb77-- From nobody Thu May 3 13:55:39 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5985126CC7; Thu, 3 May 2018 13:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Rff_k7FD2UMI; Thu, 3 May 2018 13:55:26 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1A51201F2; Thu, 3 May 2018 13:55:26 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 3 May 2018 13:52:49 -0700 From: Jim Schaad To: 'Eric Rescorla' CC: 'Matthew Miller' , , 'SPASM' , , 'IETF discussion list' References: <152432458128.20660.6956595430755199355@ietfa.amsl.com> <054301d3e271$dc22db10$94689130$@augustcellars.com> In-Reply-To: Date: Thu, 3 May 2018 13:55:20 -0700 Message-ID: <05b801d3e321$0e2a8590$2a7f90b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05B9_01D3E2E6.61CE6CB0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIiXucpxcMduUMNivilcG+pvhU0KAJBwpJPAYBUCgejY3OCgA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Secdir last call review of draft-ietf-lamps-rfc5750-bis-05 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 20:55:32 -0000 ------=_NextPart_000_05B9_01D3E2E6.61CE6CB0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It was spelled correctly =E2=80=93 yes done locally. =20 From: Eric Rescorla =20 Sent: Thursday, May 3, 2018 1:10 PM To: Jim Schaad Cc: Matthew Miller ; secdir@ietf.org; = SPASM ; draft-ietf-lamps-rfc5750-bis.all@ietf.org; IETF = discussion list Subject: Re: Secdir last call review of draft-ietf-lamps-rfc5750-bis-05 =20 probably "parse" not "parser" =20 =20 On Wed, May 2, 2018 at 5:01 PM, Jim Schaad > wrote: > -----Original Message----- > From: Matthew Miller > > Sent: Saturday, April 21, 2018 8:30 AM > To: secdir@ietf.org =20 > Cc: spasm@ietf.org ; = draft-ietf-lamps-rfc5750-bis.all@ietf.org = ; ietf@ietf.org = =20 > Subject: Secdir last call review of draft-ietf-lamps-rfc5750-bis-05 >=20 > Reviewer: Matthew Miller > Review result: Has Nits >=20 > I have reviewed this document as part of the security directorate's = ongoing > effort to review all IETF documents being processed by the IESG. = These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments > just like any other last call comments. >=20 > Document: draft-ietf-lamps-rfc5750-bis-05 > Reviewer: Matthew A. Miller > Review Date: 2018-04-21 > IETF LC End Date: 2018-04-27 > IESG Telechat date: N/A >=20 > Summary: >=20 > This document is ready, but there is one nit around PKCS #6 handling = that > might benefit from explanation. >=20 > This document describes the certificate handling expectations for = senders > and receivers of S/MIME 4.0. It obsoletes RFC 5750, adding = requirements to > support internationalized email addresses, increase RSA minimum key = sizes, > and support ECDSA using P-256 and Ed25519; older algorithms such as = DSA, > MD5, and SHA-1 are relegated to historical. >=20 > Major Issues: N/A >=20 > Minor Issues: N/A >=20 > Nits: >=20 > Section 2.2.1. "Historical Note about CMS Certificates" is almost = entired > unchanged, but added a requirement that receivers MUST be able to = process > PCKS #6 extended certificates. This almost seems at odds with the = rest of > the paragraph that precedes this MUST, noting PKCS #6 has little use = and > PKIX is functionally equivalent. > A short explanation of why this additional handling requirement would = seem > helpful. How about the following which is just a description of what we are = looking for in terms of behavior. Receiving agents MUST be able to parser and process a message = containing PKCS #6 extended certificates although ignoring those = certificates is expected behavior. =20 ------=_NextPart_000_05B9_01D3E2E6.61CE6CB0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

It was = spelled correctly =E2=80=93 yes done locally.

 

From: Eric = Rescorla <ekr@rtfm.com>
Sent: Thursday, May 3, 2018 = 1:10 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: Matthew Miller = <linuxwolf+ietf@outer-planes.net>; secdir@ietf.org; SPASM = <spasm@ietf.org>; draft-ietf-lamps-rfc5750-bis.all@ietf.org; IETF = discussion list <ietf@ietf.org>
Subject: Re: Secdir last = call review of = draft-ietf-lamps-rfc5750-bis-05

 

probably "parse" not = "parser"

 

 

On Wed, = May 2, 2018 at 5:01 PM, Jim Schaad <ietf@augustcellars.com> = wrote:



> -----Original Message-----
> From: = Matthew Miller <linuxwolf+ietf@outer-pl= anes.net>
> Sent: Saturday, April 21, 2018 8:30 AM
> = To: secdir@ietf.org
> Cc: = spasm@ietf.org; draft-ietf-lamp= s-rfc5750-bis.all@ietf.org; ietf@ietf.org
> Subject: Secdir = last call review of draft-ietf-lamps-rfc5750-bis-05
> =

> Reviewer: Matthew Miller
> = Review result: Has Nits
>
> I have reviewed this document = as part of the security directorate's ongoing
> effort to review = all IETF documents being processed by the IESG.  These
> = comments were written primarily for the benefit of the security = area
> directors.  Document editors and WG chairs should = treat these comments
> just like any other last call = comments.
>
> Document: = draft-ietf-lamps-rfc5750-bis-05
> Reviewer: Matthew A. = Miller
> Review Date: 2018-04-21
> IETF LC End Date: = 2018-04-27
> IESG Telechat date: N/A
>
> = Summary:
>
> This document is ready, but there is one nit = around PKCS #6 handling that
> might benefit from = explanation.
>
> This document describes the certificate = handling expectations for senders
> and receivers of S/MIME = 4.0.  It obsoletes RFC 5750, adding requirements to
> support = internationalized email addresses, increase RSA minimum key = sizes,
> and support ECDSA using P-256 and Ed25519; older = algorithms such as DSA,
> MD5, and SHA-1 are relegated to = historical.
>
> Major Issues: N/A
>
> Minor = Issues: N/A
>
> Nits:
>
> Section 2.2.1. = "Historical Note about CMS Certificates" is almost = entired
> unchanged, but added a requirement that receivers MUST = be able to process
> PCKS #6 extended certificates.  This = almost seems at odds with the rest of
> the paragraph that = precedes this MUST, noting PKCS #6 has little use and
> PKIX is = functionally equivalent.
> A short explanation of why this = additional handling requirement would seem
> = helpful.

How about the following which is just a = description of what we are looking for in terms of = behavior.

   Receiving agents MUST be able to parser = and process a message containing PKCS #6 extended certificates although = ignoring those certificates is expected = behavior.


 

------=_NextPart_000_05B9_01D3E2E6.61CE6CB0-- From nobody Thu May 3 15:01:16 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FC112DA27 for ; Thu, 3 May 2018 15:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 D_sx2nJLF6dH for ; Thu, 3 May 2018 15:01:07 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.201]) (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 D02A91267BB for ; Thu, 3 May 2018 15:01:06 -0700 (PDT) Received: from [216.82.241.100] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-9.bemta-8.messagelabs.com id 43/15-15733-1A68BEA5; Thu, 03 May 2018 22:01:05 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTe0xTVxzHe+69vffqqDmUKr/VV1bnYzVFNNl opsYXf9QMjVmyORmJ3sq1vdgW7K2K0QW10SiY4IMGKZYSxT0QzSQsPhAz0WKKMaBR0FlCGEQG hdjZEXAYtt7e+vrvc87nm/P93ZNzWVI9RmtZvtDFOx2cTUdPptrSzqkN1YfD2en3K5YZB/96y hhPRCqR8WS3DxmrOrYay5s6GOP5lgixkjZdLHlMm655uxhT+4URwlRT84owuRsbKVNt6B/lBj pbKTjM+YVblNZudx8quJBZeOqncWI/OrCqGE1mKfyCAF/4GSMt1PgUAUdOPCfkRReC602VZDG axNI4HTqa7saFBh9E4HVHGEmQeAuMRq8pJU7BevjTc4eWWIMXwunjEwnOg189VYTEFP4U2n6+ GT9UhXMgGugl5bbXFLRXuJEkJuHl0NnyIl6A8DQYba0j5LJU+KPPH2fAGuh5cI+WeSoM9E4o5 XwO+KLNiX0dXBoKJfIz4aG/BEllgBsIOD9SopSFASIeDymL3xEM9f+XEHpoKG+NMRvj7VA6+o 28/SXU3B5n5PxvJBx7foaRxQzwTfySaCiloW60npKEGudCWa00kiR6ERRX1jHyhWmh69FRdBz pve99njeWI7EfQWDgMOmNX1QyBCv6KDmkB8/FwQTPhivDZ0iZl8Lpf2/RMn8CZSU9jMyfQzjw N6pGbC1aIPLOXbzTsOSLNLNTsFhddk6wGRanG9PsvChyFt7GmcW0rfn2ehR7hUUKBbqKXvata 0Yfs4Ruqmr+xnC2eoo5P3ePlROtm507bbzYjGawrA5UmYdiLtnJW/jCbYIt9pTfaGCTdBqVVt IqsYCzi4JFVq3IwIYaTh4j1ZQj38FrU1VZUghLIetOx9sj3vwQD9FMbYoKKRQKdVIB77QLrg/ 9IEplkS5FtUk6JUlwuN42DcaGIGJDREf6pSFc3Dul3Y+W+Y8s7yZw5rZns23frlwdXrF+DufP utxZf/nrvLG1SwydPy543T7Wdttn5u7uyNswp7qof025Zp84j1HuiUw5a90VFa5+NRx8GfTPn R4YCA0tasmsuHErK/Rd9Q5bsFT4rNFVhDMu7f4hY8Sd0xH+aO+sXEuPIVj1JPDqe/347rIMHS VaucV60ily/wMcm1QTCwQAAA== X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-2.tower-220.messagelabs.com!1525384864!179058683!1 X-Originating-IP: [207.46.163.18] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22546 invoked from network); 3 May 2018 22:01:04 -0000 Received: from mail-dm3nam03lp0018.outbound.protection.outlook.com (HELO NAM03-DM3-obe.outbound.protection.outlook.com) (207.46.163.18) by server-2.tower-220.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 3 May 2018 22:01:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nLyv3upGDxxcTQ4BFqxRVDUydTgYzbtKzirnlNZfq8Y=; b=OKu9uGz0AJjFzz/hN0jmtrR2Ed4cxX9I+nOlA79ryPyNGxwyGRsAqIb304r2Uay7+sNS0txSHQ3FbDV7zK/blxB/ydCzU89r9iFbL+WXpmkbOFXHBW59ipYZZuHI/enidCMyQFUaGmF7dswXRUzn+B7XEKJNCrp7d5y3v8VrM+w= Received: from DM5PR14MB1116.namprd14.prod.outlook.com (10.173.131.10) by DM5PR14MB1500.namprd14.prod.outlook.com (10.173.224.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.715.18; Thu, 3 May 2018 22:01:03 +0000 Received: from DM5PR14MB1116.namprd14.prod.outlook.com ([fe80::1907:795:e104:1cf1]) by DM5PR14MB1116.namprd14.prod.outlook.com ([fe80::1907:795:e104:1cf1%17]) with mapi id 15.20.0715.024; Thu, 3 May 2018 22:01:03 +0000 From: Tim Hollebeek To: Stephen Farrell , Ryan Sleevi , Phillip Hallam-Baker CC: LAMPS , Russ Housley , Yoav Nir Thread-Topic: [lamps] Draft LAMPS Recharter Thread-Index: AQHT4iO4XCAxwA/3hUqSDHZXOfUBwaQc7owAgAAEBgCAAFOQgIAAnn6AgAAbiwCAAAnWAIAAC1SAgAABfwCAAHbucA== Date: Thu, 3 May 2018 22:01:03 +0000 Message-ID: References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> <64CD1067-8639-4C2C-A8EC-ED5FBC14F633@gmail.com> <2696d841-c5bf-d0b4-5ef1-c4a0839bba94@cs.tcd.ie> In-Reply-To: <2696d841-c5bf-d0b4-5ef1-c4a0839bba94@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [98.111.253.132] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR14MB1500; 7:hWx7GrDH5+n/Htxj8eKxc0KF27y/qlVmFeNjVQ1depQwT6Ki4nj4h1SwIuLknyvSEjLCzBnXEldp/89P281IkRjuLf1KWahAvyraN7J0RfixaGJNLXcqCCmbK/x3yS01nAjkZIV6wuXJKSxabrez6kM9IzOriTvhrUXElSRFqS8VOWrVDJdAFi8ppXzGgdbmMRXtcxobAvu0JKBHJ7HuF2RupFtsEa24eUH518iBqwWohQBlCoiD8RkRIqFBO19t x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:DM5PR14MB1500; x-ms-traffictypediagnostic: DM5PR14MB1500: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(3002001)(6041310)(20161123560045)(20161123564045)(201703131423095)(201703031522075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR14MB1500; BCL:0; PCL:0; RULEID:; SRVR:DM5PR14MB1500; x-forefront-prvs: 066153096A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(366004)(376002)(346002)(396003)(199004)(189003)(13464003)(86362001)(6506007)(66066001)(99286004)(446003)(53546011)(5250100002)(106356001)(316002)(99936001)(44832011)(25786009)(7696005)(105586002)(11346002)(76176011)(486006)(296002)(476003)(229853002)(97736004)(39060400002)(4326008)(55016002)(6436002)(9686003)(53936002)(68736007)(6246003)(3846002)(93886005)(33656002)(110136005)(478600001)(8936002)(81166006)(102836004)(2906002)(186003)(2900100001)(54906003)(7736002)(26005)(8676002)(3280700002)(305945005)(3660700001)(74316002)(5660300001)(14454004)(6116002)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR14MB1500; H:DM5PR14MB1116.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: buP6o0BtiDPc6E/Jy+KGQD2S7Ymv0wtB9qPtLRN5gO5r+F3pr1tnFKNsLjx+bJkED3i/TPLY6qMnxAG+ntBhrHF1tAORO2bgIj3vFkrFIa1KOfOxkyxUYgr8Re74Xiis97wsxoA5120d+ATJNxubEzgMUB9cC4YuKeX/1hXcO5Acc6Kkbujmj0y7rVbR19Y/ spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0144_01D3E308.B28F0FC0" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 301377ec-461d-490c-868a-08d5b1415d24 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 301377ec-461d-490c-868a-08d5b1415d24 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2018 22:01:03.5677 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR14MB1500 Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 22:01:13 -0000 ------=_NextPart_000_0144_01D3E308.B28F0FC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit (chair hat off) I was at SECDISPATCH in London. I'm in favor of short-lived certificates in general, but as I stated in London, I have many serious problems with this draft, which include the problems Ryan mentioned, and many more. It's going to need a lot of work before we can consider adopting it. That said, it's a draft, and it was pretty clear that SECDISPATCH wanted LAMPS to re-charter and consider it. And I actually agree with that. I think the issues with the draft that people have raised deserve discussion, and I hope Yoav understands that these serious concerns will need to be addressed before the document can be adopted. But I support changing the LAMPS charter so that LAMPS can discuss the draft. -Tim > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Thursday, May 3, 2018 10:47 AM > To: Ryan Sleevi ; Phillip Hallam-Baker > > Cc: LAMPS ; Russ Housley ; Yoav Nir > > Subject: Re: [lamps] Draft LAMPS Recharter > > > I don't have a position on the draft in question but... > > On 03/05/18 15:41, Ryan Sleevi wrote: > > The nature of this question is what plagued PKIX, and if we're trying > > to ensure that LAMPS does not succumb to the overbroad, unadopted, > > zombie effort that WGs can succumb to, then my $.02 we should make > > sure that the goal and uses are as crisp as possible before adopting that > > work > as a WG. > > ... that certainly resonates with me;-) > > I hope lamps does stick with the "only adopt if we think it's really quite > likely to > be used" aspect of the charter. > > S. ------=_NextPart_000_0144_01D3E308.B28F0FC0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwNTAzMjIwMTAxWjAvBgkqhkiG9w0BCQQxIgQgpSNEfAHwLUdZc2XW7OoRbwYi3ib9 WrbNPdelvig3OwYwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBACC9h2YKtbdsE0qEq8bmuiBC7UqaSlkSofFNfI8ONA2J1ZYj2ur+ubGOcxE25mctTAQx6BhF 4u/1UbCa4KEF4ZFkM0gHA7fwQ9Cu6d7Ok9kJVDbL9SN730Xje+h2h/+IUEvWk6DhEoPzccXnzO1t 0Mq7YRclZoDULOqXZFMOa5qEaVG9FM8DuPrDTONxBe/py27fiWQfsEsHAF2R1MvQPeJnLnSzRPMH f01UlS9U3AM4KN6i4N4fDLPMc1eWYr+ScjpB66YZexwGUOqDMWdBMg1qmNoZIRmQ6RMFvvsQsKyw PmeNEbDzjiXIcRHFqrxis2riVUkScvIKKduQVkM+GlMAAAAAAAA= ------=_NextPart_000_0144_01D3E308.B28F0FC0-- From nobody Fri May 4 05:19:05 2018 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4FA126BF0; Fri, 4 May 2018 05:18:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke?= To: Cc: spasm@ietf.org, draft-ietf-lamps-rfc5750-bis.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152543633033.11713.14519946575146524568@ietfa.amsl.com> Date: Fri, 04 May 2018 05:18:50 -0700 Archived-At: Subject: [lamps] Opsdir last call review of draft-ietf-lamps-rfc5750-bis-06 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 12:18:50 -0000 Reviewer: Éric Vyncke Review result: Ready Reviewer: Eric Vyncke Review result: Ready I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document reviewed: draft-ietf-lamps-rfc5750-bis-06 Intended Status: Standards Track As the title indicates, this document is about how certificates are to be handled by a S/MIME client; both for sending and receiving. It is well written and clear. Section 1.3 to 1.6 are explicitly about compatibility and interoperation with previous version of the S/MIME specification. Section 4 is about the provisioning of the certificates of other parties. In the absence of a protocol for this purpose, the proposed technique is archaic and manual; far from being easy for operations but I am afraid that there is no other choice. Section 4.3 specifies key lengths, which also means that another RFC will have to be authored when those key lengths will become too weak. In case of trouble or invalid certificates, the only specified action is to inform the end user; which is again the usual procedure when dealing with certificates. From nobody Tue May 8 00:02:16 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2240C127137 for ; Tue, 8 May 2018 00:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WM63DlkzjVOp for ; Tue, 8 May 2018 00:02:13 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 157BD1270A7 for ; Tue, 8 May 2018 00:02:13 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id c5-v6so13332003itj.1 for ; Tue, 08 May 2018 00:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=UbHT0Z75xgUhuwPQ9mInDGxf82czQbXBx3bSmxJmgps=; b=NOg0pGVt3AtNfDG9NNQeS19YyhvZUUAURPbjDAyu3XdYA9EDm8paFwm6gLKKnwG8Pr w/uouSacdmUyxMXJSh5vvKBipzqIunOpqOkOE/Wdc78GrBPJSwEkOSyYCj5CRtAukC5J lWbNqinLhRjiAh/H3M6UV09stnb45gKl2+V5vnEoCqsbNkPOpcq0LJYgBLvFssw5piva wh44taQB4h/uGyUrtN9Z11aoIuiLe29q/4UikayOIuxoNmvBbWcRWU9lKaGYS8gQvMy+ 9+F5kbznuemz6DKAzqs+YpA+gWLUzjdF+0jllrwKD2XdJUfkKF2oCLWMXtG1XuMckoBW I8/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UbHT0Z75xgUhuwPQ9mInDGxf82czQbXBx3bSmxJmgps=; b=anBgwbMovDQh1VtMyqha6ggG8OX0Dovr3wm8+DEqlQ8M4mkKgNrrvNW8xjS2iED7yK aON9Z/UY0G2HNNPIJDnzYhWVJo7Y0rej1R+deuwe9LWcJADYlsVtVAHEqbbNIslRVK4Y gjlqWktouapyhnYOaZvwX75VBikseCqynNBd3EYM1NSazNkN0UFIQtPsn1o/BwMN4tvC imhrOEkvZLfqJ4rdksoLpNlLbr5/5KHM6jMKm3vqUW1p5ABfuUFjDRu2Tusf2wblkR5G OHZsdDpOGgqnnsJ8lp3OE2VleACJGqvOmoVcpW9Aarxm5txkM2r+tWGhXMg3HKqd/6hl XJ1A== X-Gm-Message-State: ALKqPwcixhs75D6541ElAzKe/aSycRXgZx1d+qpbhkwt9VXqwufRvolV 7Rt1na0Nplk4t04qEBh6eShfPfiYf6viVENz3lQP15rfLQs= X-Google-Smtp-Source: AB8JxZp+AyCz8csyZtbB2buH8tptwNk3bHVOn3Q0HpE5tXCEzzBs0ruSM69zMWiKguv+VVXxHxpl6vx8Bm3gfSI4qWg= X-Received: by 2002:a24:de07:: with SMTP id d7-v6mr4916820itg.93.1525762931689; Tue, 08 May 2018 00:02:11 -0700 (PDT) MIME-Version: 1.0 From: Wei Chuang Date: Tue, 08 May 2018 07:02:00 +0000 Message-ID: To: LAMPS Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000009739b8056bac5de5" Archived-At: Subject: [lamps] Logo carrying certificate profile for email` draft X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 07:02:15 -0000 --0000000000009739b8056bac5de5 Content-Type: multipart/alternative; boundary="0000000000008ebef0056bac5df5" --0000000000008ebef0056bac5df5 Content-Type: text/plain; charset="UTF-8" Hi all, I've posted a draft https://datatracker.ietf.org/doc/draft-chuang-bimi-certificate/ regarding a logo carrying certificate for authenticated email using domain based methods (DKIM and SPF). In particular this draft calls for a new Extended Key Usage for these certificates to help distinguish this usage from other profiles such as S/MIME. Can this draft be considered for the LAMPS rechartering? This work is being done by a Brand Indicator for Message Identification (BIMI) working group. An early version of the overall protocol can be seen at https://authindicators.github.io/rfc-brand-indicators-for-message-identification/ though that version doesn't include changes that include X.509 certificates. thanks, -Wei --0000000000008ebef0056bac5df5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I've posted a draft=C2= =A0https://datatracker.ietf.org/doc/draft-chuang-bimi-certificate/ reg= arding a logo carrying certificate for authenticated email using domain bas= ed methods (DKIM and SPF).=C2=A0 In particular this draft calls for a new E= xtended Key Usage for these certificates to help distinguish this usage fro= m other profiles such as S/MIME.=C2=A0 Can this draft be considered for the= LAMPS rechartering?=C2=A0=C2=A0This work is being done = by a Brand Indicator for Message Identification (BIMI) working group.=C2=A0= An early version of the overall protocol can be seen at https://authindicators.github.io/rfc-brand-indicators-for-message-identifi= cation/ though that version doesn't include changes that include X.= 509 certificates.=C2=A0=C2=A0

thanks,
=
-Wei=C2=A0
--0000000000008ebef0056bac5df5-- --0000000000009739b8056bac5de5 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMYKpa6SINwoLGQXUgMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDExOTE4NDI1MVoXDTE4MDcx ODE4NDI1MVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC0xH6rq6JX6ckhX0CIaSEowE6QOIiGkrqCHW5huLmJvpTEafUz 0rlXHZCh4aJVU59ByZavVB5iKNphEUJKY91aG65S5e2TbJKRqxU3cXGZe1Ol0VjQZ6cgXa0spJXY oG6jZe7QQWtHLwV8Pm3xxAXqagWvYKW5RYa/9S0Ab5YpJtCiLCR0c+OhRAWV+UKsP3B71AD0kC8l 8ug3Irx+81/hQkx1u35BvOP1D79rOZh4zquem5luip6CSg1xlRVGG6FP5Cj2Et0pUAjBP3K2hu9S zmBghizN03vlAzFX/WWVmChKpqf81jUKnXG+Muv9E4Si838BQvnlERsWIHOnUOIZAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFCAGe6s17mfun3rE/l40dXgd9FU9MB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCyR6ITTdELc7OY1Z/3 OnkUrwCVfjWq4Uq+apV0oGja88w4X/P+a/avsMx1aK525Rxy9VuWSQCzTsGyE71USOjutTl3c+2u pDEr18aE2sRYQvu4h7zs0zHGVe60cJl+cRZ20ggTnltfbFrU9wvTVBmynL4eznCA4c2AjrREk0v9 ORQz0GuQJfO2O4YUuVVIERWKrcciSm+DaQ93OyfJ1FX+MDSaJgnDPvIUPqnpqcCyCtcQBvYVrvNn OVhzQInUukIiVuVRMcsYVbwAQOlX+WlpXZw78LcUxREr6eFyfmx8eHEOC0EP7jTbOsY2qr/e4J3t VdgC0xqFqcmv46MxC4pVMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMYKpa6SIN woLGQXUgMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCD6wh2LIinwmlvg++PLF9AK /IfTMj+K/9HE6xUp3u2gPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA1MDgwNzAyMTJaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAqY6sr/noOUBnEc90KEMnbPPZyYJL6yYDZLWrkK05 uRlRKaosxQodFyk/ke/1cijSX89NKoefaSUBybZ6Cr16Wbr0SpZCsyMo6yNI6RAayhDk/68jjdbc 4VKe1RPTcSXD7i4EA6+pVzu6MrRC28EaxYS76aE/54IqMmAhN65sDvTKeAUKDuWctw+uO/ZRrFra 33zV80MapV1hxcI8jg062PQL74/+0a+w/C0aVPoLu2B2t6s61FEII3Lps+4E/G3NLYCrtk1rQ4a5 samSO2tpk0NRtGM0x1iWpvp4EJNH3c3eaJYvMmFeCS/Fy0nVc4tUl6mlShR2K7Wrq5Bjq+O2OQ== --0000000000009739b8056bac5de5-- From nobody Tue May 8 11:25:51 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F420E12E88A for ; Tue, 8 May 2018 11:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 Umm_Ec4U-GYG for ; Tue, 8 May 2018 11:25:48 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E84F1277BB for ; Tue, 8 May 2018 11:25:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 16515300A03 for ; Tue, 8 May 2018 14:25:46 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 51xA321XqT6O for ; Tue, 8 May 2018 14:25:44 -0400 (EDT) Received: from [5.5.33.66] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 0F24B3002C1; Tue, 8 May 2018 14:25:43 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_42E04D56-C1E2-4359-989E-577E528DBA1A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 8 May 2018 14:25:44 -0400 In-Reply-To: Cc: LAMPS To: Wei Chuang References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Logo carrying certificate profile for email` draft X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 18:25:50 -0000 --Apple-Mail=_42E04D56-C1E2-4359-989E-577E528DBA1A Content-Type: multipart/alternative; boundary="Apple-Mail=_CF09DB1C-6636-4057-9A9A-D96FD0D13501" --Apple-Mail=_CF09DB1C-6636-4057-9A9A-D96FD0D13501 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Wei: In the future, please use TBD for numbers in IANA registries. Authors = do not make assignments. That is left to the IANA staff. I have asked the IANA staff to reserve this value to ensure that a = collision is avoided. Russ > On May 8, 2018, at 3:02 AM, Wei Chuang wrote: >=20 > Hi all, >=20 > I've posted a draft = https://datatracker.ietf.org/doc/draft-chuang-bimi-certificate/ = = regarding a logo carrying certificate for authenticated email using = domain based methods (DKIM and SPF). In particular this draft calls for = a new Extended Key Usage for these certificates to help distinguish this = usage from other profiles such as S/MIME. Can this draft be considered = for the LAMPS rechartering? This work is being done by a Brand = Indicator for Message Identification (BIMI) working group. An early = version of the overall protocol can be seen at = https://authindicators.github.io/rfc-brand-indicators-for-message-identifi= cation/ = though that version doesn't include changes that include X.509 = certificates. =20 >=20 > thanks, > -Wei=20 >=20 --Apple-Mail=_CF09DB1C-6636-4057-9A9A-D96FD0D13501 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Wei:

In = the future, please use TBD for numbers in IANA registries.  Authors = do not make assignments.  That is left to the IANA staff.

I have asked the IANA = staff to reserve this value to ensure that a collision is = avoided.

Russ


On May 8, 2018, at 3:02 AM, Wei Chuang <weihaw@google.com> = wrote:

Hi all,

I've posted a draft https://datatracker.ietf.org/doc/draft-chuang-bimi-certificate/= regarding a logo carrying certificate for authenticated email using = domain based methods (DKIM and SPF).  In particular this draft = calls for a new Extended Key Usage for these certificates to help = distinguish this usage from other profiles such as S/MIME.  Can = this draft be considered for the LAMPS rechartering?  This work is being done by a Brand = Indicator for Message Identification (BIMI) working group.  An = early version of the overall protocol can be seen at https://authindicators.github.io/rfc-brand-indicators-for-messa= ge-identification/ though that version doesn't include changes that = include X.509 certificates.  

thanks,
-Wei 


= --Apple-Mail=_CF09DB1C-6636-4057-9A9A-D96FD0D13501-- --Apple-Mail=_42E04D56-C1E2-4359-989E-577E528DBA1A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILIjCCBTQw ggQcoAMCAQICEQDIHZ6qwvcH7jiYFMEiEbJQMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzA1MTAwMDAwMDBaFw0xODA1MTAyMzU5NTla MCUxIzAhBgkqhkiG9w0BCQEWFGhvdXNsZXlAdmlnaWxzZWMuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAroV+/72Xt1SEBOTXto/xHu2dgWiBTFyBQOu5dnTYBOeJJAJjw4WMIUaR 2hmJjErRdYT1wWGVnm9obCwb/DZ1yd/4HCnNAeJYUmdu+LNHF+yQM//g1huB8aZoTHYbd7gYbyb4 hxgG1LNdKv/QJ/V8wYMxM2uDqh5ar12cq20PV4pyI3IAvqT2DJobY4fdgAJGWBSqwUBjKfBABUS0 kI/f12pD9B1kNbZh/Gp1ICe1qDCz3HvPbB07xqjsNpnSk3O7ubHUBq3e8Tqzu0MF1ku7QhPUt+Uk DENnbnOm1xICLHZ00nLWUYQdXGhZL6x4mo7RopTKTDS4Qw6HRKZibIoUNwIDAQABo4IB6jCCAeYw HwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFNZtFJiqcCBgGjek+HA0 X10pQomAMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwME BgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIB AQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYD VR0RBBgwFoEUaG91c2xleUB2aWdpbHNlYy5jb20wDQYJKoZIhvcNAQELBQADggEBAGmZ7Y4dC5C7 ivwLDTERwMrzxjNGteSBdmKZFvZvE50MlbG6Oxs5GQyThGXSDGJwXLBM/Ea0dSyXSy4MlXGo8bGX o82/1Lpq5DHnzKjhJuZMIXYgkKGsxyQo67YwO7E+4u2gqQHge7nBLk+8mpwkkNFE7WSl/43Sg+FB KPesaP0eYLdnjhVI8OoojAwjMx8QlFJJS3dY1LQ3NtvBLTYHzZ5E7LCc12zU0D8yd3qjGFah1BBG u7hQiHubXXkEvHGfOpHg9rmcfa/BtA9ynJNdmReMnsf27m/AlhBbBcfCxWRMQ7pbo1xug+uSyCPB wLK5LpW6iu7Obi2GJK16z8O+cGUwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JWMA0GCSqG SIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09N T0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0yODAxMDky MzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RP IFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9Olg+nKcx Lqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXCA6RQyDMq VaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+KQWWCo63 OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720YpMPJQaDa ElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUCAwEAAaOC ATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSCr2yM+MX+ lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09N T0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsGCCsGAQUF BzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQB4XLKB KDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE7HtoSmR8 09AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGkSDU7I5Px +TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFrjAF4o50Y JafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5aVyu6t99 p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F29QIhhmi NOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCPUpwv9mj2 PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj7fIvxqit h7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9cbm/vOYR UM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6EjGCA7ow ggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMgdnqrC 9wfuOJgUwSIRslAwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTgwNTA4MTgyNTQ0WjAjBgkqhkiG9w0BCQQxFgQU12azC6hUdZSyHWU6icFt 1EyEXFowgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEQDIHZ6qwvcH7jiYFMEiEbJQMIHABgsqhkiG9w0BCRACCzGBsKCBrTCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDIHZ6qwvcH7jiYFMEiEbJQMA0GCSqG SIb3DQEBAQUABIIBABEnCU/2eAn6TK82Yd7Umb4qZz2JQnELQfMuCiUqFt3SM2pQIUGcEOL58dks J6vs1jaWtQ7xCH8AteAnDpo0vLhok7Qs5zbWrmAeDFux2ciIgf5Pp+z2K5B7WwEPM7LMu7lnvg/+ RYwM+cjiM2L0swybl0BoHLZpcnQJuHM4TIXFFJZucmlhafs+9lQzjz+9H3CIbf4F62nDOguSmtiT KHRipykmGVjVuyyiA+NIBjjHA7qARLGlIPx6ELGVJRNmg0PxqyBVrcbIg9w85HNcabQM42kZf8Gl igdBAjcDHgVoG1jlQ9eqg9tmLg6Cd3/o7fnJlZOazlHWM3RG4X+Sv9gAAAAAAAA= --Apple-Mail=_42E04D56-C1E2-4359-989E-577E528DBA1A-- From nobody Wed May 9 12:09:17 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998411274D2 for ; Wed, 9 May 2018 12:09:15 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 Fg6oXFOGZSJ6 for ; Wed, 9 May 2018 12:09:14 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C68012778E for ; Wed, 9 May 2018 12:09:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3BAF0300A03 for ; Wed, 9 May 2018 15:09:12 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WyMFgYm-Y6TL for ; Wed, 9 May 2018 15:09:11 -0400 (EDT) Received: from [5.5.33.75] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 4858B3005AE for ; Wed, 9 May 2018 15:09:11 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 9 May 2018 15:09:10 -0400 References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> <64CD1067-8639-4C2C-A8EC-ED5FBC14F633@gmail.com> To: LAMPS In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 19:09:16 -0000 Based on the I-D that Wei recently posted, do people think we should add = a work item: 7. Specify new extended key usage identifiers when there is a significant constituency that will make use of certificates that include that new identifier. Russ From nobody Wed May 9 12:49:55 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB33C127863 for ; Wed, 9 May 2018 12:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kzc34VuS5Wix for ; Wed, 9 May 2018 12:49:52 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A21127909 for ; Wed, 9 May 2018 12:49:52 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 9 May 2018 12:47:11 -0700 From: Jim Schaad To: 'Russ Housley' , 'LAMPS' References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> <64CD1067-8639-4C2C-A8EC-ED5FBC14F633@gmail.com> In-Reply-To: Date: Wed, 9 May 2018 12:49:42 -0700 Message-ID: <003901d3e7ce$e0faac00$a2f00400$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEb84RaDFSXoIcBGFWBOtDhOCt5FQJPW+/VAa1emooCGgdVaQLfUoctAks58bICurG6HQIN46Q3AYVI+0UCeIrojaT3eNCg Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 19:49:54 -0000 I am unsure that this is a good use of the WG time. I think that this can be done just as easily through the Independent Submissions stream. Jim > -----Original Message----- > From: Spasm On Behalf Of Russ Housley > Sent: Wednesday, May 9, 2018 12:09 PM > To: LAMPS > Subject: Re: [lamps] Draft LAMPS Recharter > > Based on the I-D that Wei recently posted, do people think we should add a > work item: > > 7. Specify new extended key usage identifiers when there is a significant > constituency that will make use of certificates that include that new > identifier. > > Russ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Wed May 9 13:23:02 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F3912D77C for ; Wed, 9 May 2018 13:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 AB072sHNFEpb for ; Wed, 9 May 2018 13:22:59 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 88B79128896 for ; Wed, 9 May 2018 13:22:59 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w49KHXjx012744; Wed, 9 May 2018 21:22:57 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=7NDRoQU0yTkdX1EjXHqN4rvh90uTxJtqjyn0UiYUwKY=; b=RdKcsznnENLQbliBBpGhnHw1r7ZWnn044ZlyMGg8NHfbUpB+FM164M43AWUYBowy1MAs QTx5XxTe+Evz+w2i9pLPt+gT9GCyodL3BiTWbE/bMGZAyf7GU6iy3q+YuYV3XqhRUjgX 0Xft3H7KgzgLxiLkkPxPq+Di1D3o9WfsVSp5BeINOncEwXCiORRNrLXwq3/6JAW9PGDm mJtmmmPTmvJOfscPidbpkZpZiXmdZRT5Ip+i0J2H6DVl7QlBUTURaeLJWXKsCP9oQP/q fW+XTONDwZs5O6dSFZ8SFS9ASo/fV/ei20pRdX9dmOs2FH/8FF//XeSDCO98DhI0GGab Fw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050102.ppops.net-00190b01. with ESMTP id 2hv1s492yg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 May 2018 21:22:57 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w49KLgfd017973; Wed, 9 May 2018 16:22:57 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2hs7xwgetp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 09 May 2018 16:22:57 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 9 May 2018 16:22:56 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Wed, 9 May 2018 16:22:55 -0400 From: "Salz, Rich" To: Russ Housley , LAMPS Thread-Topic: [lamps] Draft LAMPS Recharter Thread-Index: AQHT4iO3hgj5Ub4+IEuWyTIn2bKBvqQdMZoAgAAEBgCAAFOQgIAAnn6AgAAbiwCAAAnWAIAAC1SAgAm4zwD//9F/AA== Date: Wed, 9 May 2018 20:22:55 +0000 Message-ID: <8872737F-AE42-4CDD-8990-BBB46A4AFF8F@akamai.com> References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> <94C70910-6BA3-4364-BE43-3316AE1E51C6@vigilsec.com> <64CD1067-8639-4C2C-A8EC-ED5FBC14F633@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.c.0.180410 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.239] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-09_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=750 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805090190 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-09_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=673 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805090189 Archived-At: Subject: Re: [lamps] Draft LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 20:23:00 -0000 PiAgICA3LiBTcGVjaWZ5IG5ldyBleHRlbmRlZCBrZXkgdXNhZ2UgaWRlbnRpZmllcnMgd2hlbiB0 aGVyZSBpcyBhDQogICAgc2lnbmlmaWNhbnQgY29uc3RpdHVlbmN5IHRoYXQgd2lsbCBtYWtlIHVz ZSBvZiBjZXJ0aWZpY2F0ZXMgdGhhdA0KICAgIGluY2x1ZGUgdGhhdCBuZXcgaWRlbnRpZmllci4N CiAgDQpZZXMuICBGaWd1cmluZyBvdXQgaWYgdGhhdCdzIHRydWUgd2lsbCBiZSBoYXJkLCBidXQg dGhhdCdzIHdoeSB3ZSBnZXQgcGFpZCB0aGUgYmlnIGJ1Y2tzLiA6KQ0KDQo= From nobody Thu May 10 09:55:10 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D344126DFB for ; Thu, 10 May 2018 09:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 T1J3ePkx3u9L for ; Thu, 10 May 2018 09:55:07 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5EAA12EBD9 for ; Thu, 10 May 2018 09:55:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CD1A9300A26 for ; Thu, 10 May 2018 12:55:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HZHkz5__sd4T for ; Thu, 10 May 2018 12:55:02 -0400 (EDT) Received: from [5.5.33.83] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 2D6153004D6; Thu, 10 May 2018 12:55:00 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_BC37F12C-0662-42B5-88DA-D0A05D5D1100"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 10 May 2018 12:54:59 -0400 In-Reply-To: Cc: LAMPS To: Wei Chuang References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Logo carrying certificate profile for email` draft X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 16:55:09 -0000 --Apple-Mail=_BC37F12C-0662-42B5-88DA-D0A05D5D1100 Content-Type: multipart/alternative; boundary="Apple-Mail=_AF4F3814-E02A-4410-A950-F50F3132706A" --Apple-Mail=_AF4F3814-E02A-4410-A950-F50F3132706A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Wei: I think that an Independent stream document is sufficient to get the = code point assignments. Russ > On May 8, 2018, at 3:02 AM, Wei Chuang wrote: >=20 > Hi all, >=20 > I've posted a draft = https://datatracker.ietf.org/doc/draft-chuang-bimi-certificate/ = = regarding a logo carrying certificate for authenticated email using = domain based methods (DKIM and SPF). In particular this draft calls for = a new Extended Key Usage for these certificates to help distinguish this = usage from other profiles such as S/MIME. Can this draft be considered = for the LAMPS rechartering? This work is being done by a Brand = Indicator for Message Identification (BIMI) working group. An early = version of the overall protocol can be seen at = https://authindicators.github.io/rfc-brand-indicators-for-message-identifi= cation/ = though that version doesn't include changes that include X.509 = certificates. =20 >=20 > thanks, > -Wei=20 >=20 --Apple-Mail=_AF4F3814-E02A-4410-A950-F50F3132706A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Wei:

I = think that an Independent stream document is sufficient to get the code = point assignments.

Russ


On May 8, 2018, at 3:02 AM, Wei Chuang <weihaw@google.com> = wrote:

Hi all,

I've posted a draft https://datatracker.ietf.org/doc/draft-chuang-bimi-certificate/= regarding a logo carrying certificate for authenticated email using = domain based methods (DKIM and SPF).  In particular this draft = calls for a new Extended Key Usage for these certificates to help = distinguish this usage from other profiles such as S/MIME.  Can = this draft be considered for the LAMPS rechartering?  This work is being done by a Brand = Indicator for Message Identification (BIMI) working group.  An = early version of the overall protocol can be seen at https://authindicators.github.io/rfc-brand-indicators-for-messa= ge-identification/ though that version doesn't include changes that = include X.509 certificates.  

thanks,
-Wei 


= --Apple-Mail=_AF4F3814-E02A-4410-A950-F50F3132706A-- --Apple-Mail=_BC37F12C-0662-42B5-88DA-D0A05D5D1100 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILIjCCBTQw ggQcoAMCAQICEQDIHZ6qwvcH7jiYFMEiEbJQMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzA1MTAwMDAwMDBaFw0xODA1MTAyMzU5NTla MCUxIzAhBgkqhkiG9w0BCQEWFGhvdXNsZXlAdmlnaWxzZWMuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAroV+/72Xt1SEBOTXto/xHu2dgWiBTFyBQOu5dnTYBOeJJAJjw4WMIUaR 2hmJjErRdYT1wWGVnm9obCwb/DZ1yd/4HCnNAeJYUmdu+LNHF+yQM//g1huB8aZoTHYbd7gYbyb4 hxgG1LNdKv/QJ/V8wYMxM2uDqh5ar12cq20PV4pyI3IAvqT2DJobY4fdgAJGWBSqwUBjKfBABUS0 kI/f12pD9B1kNbZh/Gp1ICe1qDCz3HvPbB07xqjsNpnSk3O7ubHUBq3e8Tqzu0MF1ku7QhPUt+Uk DENnbnOm1xICLHZ00nLWUYQdXGhZL6x4mo7RopTKTDS4Qw6HRKZibIoUNwIDAQABo4IB6jCCAeYw HwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFNZtFJiqcCBgGjek+HA0 X10pQomAMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwME BgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIB AQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMw UTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYD VR0RBBgwFoEUaG91c2xleUB2aWdpbHNlYy5jb20wDQYJKoZIhvcNAQELBQADggEBAGmZ7Y4dC5C7 ivwLDTERwMrzxjNGteSBdmKZFvZvE50MlbG6Oxs5GQyThGXSDGJwXLBM/Ea0dSyXSy4MlXGo8bGX o82/1Lpq5DHnzKjhJuZMIXYgkKGsxyQo67YwO7E+4u2gqQHge7nBLk+8mpwkkNFE7WSl/43Sg+FB KPesaP0eYLdnjhVI8OoojAwjMx8QlFJJS3dY1LQ3NtvBLTYHzZ5E7LCc12zU0D8yd3qjGFah1BBG u7hQiHubXXkEvHGfOpHg9rmcfa/BtA9ynJNdmReMnsf27m/AlhBbBcfCxWRMQ7pbo1xug+uSyCPB wLK5LpW6iu7Obi2GJK16z8O+cGUwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JWMA0GCSqG SIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09N T0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0yODAxMDky MzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RP IFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9Olg+nKcx Lqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXCA6RQyDMq VaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+KQWWCo63 OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720YpMPJQaDa ElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUCAwEAAaOC ATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSCr2yM+MX+ lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09N T0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsGCCsGAQUF BzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQB4XLKB KDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE7HtoSmR8 09AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGkSDU7I5Px +TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFrjAF4o50Y JafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5aVyu6t99 p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F29QIhhmi NOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCPUpwv9mj2 PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj7fIvxqit h7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9cbm/vOYR UM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6EjGCA7ow ggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMgdnqrC 9wfuOJgUwSIRslAwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTgwNTEwMTY1NDYwWjAjBgkqhkiG9w0BCQQxFgQUMBYFi4wcVTabw7BoDSb+ K5ehQvcwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEQDIHZ6qwvcH7jiYFMEiEbJQMIHABgsqhkiG9w0BCRACCzGBsKCBrTCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDIHZ6qwvcH7jiYFMEiEbJQMA0GCSqG SIb3DQEBAQUABIIBAFTryrb+T970plbRsaPfn754daPUZPHzwcKFm43si6fRVIP1lHpX4+sXt+1D jo3JGHB+MTi/dtL9ihhjOOlb4Kzjgv44Ob0zRHWJOirkoWCTkRdndahbHD/BDwkPiF25Q251p5DS NUIZAa+k6TMMzWJmrDjlPNGG756AzLAX97L0oe9guocBarqDru6QXGMY06OBjEMr/P9sa8ZiHVRP 3GHlEoJUbdBRwFkVTmsiZaHy3TNeoD6n1CQyuNsis+X4lQDYg1PQX6JISVanm5t82mGWvTzjdKaW 2YkbDLjLeYscoqsCHz0JTz3wzMriLvSvO/DrWg/nwmedkvfoh5a1SzAAAAAAAAA= --Apple-Mail=_BC37F12C-0662-42B5-88DA-D0A05D5D1100-- From nobody Thu May 10 10:00:24 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533FA124B17 for ; Thu, 10 May 2018 10:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.209 X-Spam-Level: X-Spam-Status: No, score=-18.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 dehnzkyiTy-b for ; Thu, 10 May 2018 10:00:21 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 82F08126DFB for ; Thu, 10 May 2018 10:00:21 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id e20-v6so3827111iof.4 for ; Thu, 10 May 2018 10:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+FXH+Tqm8IvGIZcSBUgK2Fu6D92lX9wuRMv39nhT61E=; b=C1Mkyoyr3feTSxznBEiLfdJ4FBusgD9XtQ+lFxnZmGW+6uopjQQPsQQ7p5y8NXqFUo qo3gnE7G4zmH0/bmxftKeyrvac/ZeS8x40rQJ95uYLgWnwP/78YwkaX9RdnBDMBdTLXs V1M9zSlvhZKpOcwBMkRgATLRyZwdZMNdqwjte1ZHsu2o54rcgrEf0lz3bhjo0MMqOFQe a/f+hFoiuChJQGvQd8xUJHa3b7SAWUY7r+1VnqcnEn0N+tkOqEzJJ33Pwg9ELlz5xBVB Wyx8wN54mO4i9tWl/ry50lucyAIr7+/IlSO9hSEOVaBYbsLg/vq6gPkZNPnR/GrAI25Y Hc3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+FXH+Tqm8IvGIZcSBUgK2Fu6D92lX9wuRMv39nhT61E=; b=sBRmKBWvyt//DS72SbSu/Lp4kMSUE3pDi+U2MK/0RT0IyUpDVfEf9eM0T60HEFw+TB 9b4jK9rmkZ1eV5f5jPfVVLsb2onzv/30O+OSwVXTO53kD6+7dOqWGZx+HUcLcSSs11Me tjkfWlA+NTwX5a4Yknr5tSU3qBE94YJejPiRWLglrpAVEoFP+qlO8Hh9Ln9hAKr0P7uK ZtSF4Xm3ANHoKYntXEWcnxNn0ZW9+AQtXT0glLiWjRjaxxTmCIyo9ObrciC6Duh+2AH5 J1I/cQ/c7AlgXp83NWy6ZxiJh7kcwoQxsDmvy0Lt5gcbmZ21bu1hZaPOaegmebPiHdCw SydA== X-Gm-Message-State: ALKqPwfBGjFP1RqzdRBtHCJlaOo4+Kodm1EWp1Lc2RtaLdBBegywcFJC JjYm/UcCuBbNZCoaoQjCMYFRr6q1JpETLYBNwVoezu+6 X-Google-Smtp-Source: AB8JxZoziCyLzoZ/J4n5XVbigETgDZEVozczLv/lIuUrXHtjuSUN357bJnejSrnCEhmoZbbdrXuo5IUJyx1Q2wYGaGQ= X-Received: by 2002:a6b:6b16:: with SMTP id g22-v6mr2334949ioc.20.1525971620402; Thu, 10 May 2018 10:00:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Wei Chuang Date: Thu, 10 May 2018 10:00:05 -0700 Message-ID: To: Russ Housley Cc: SPASM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000697f6d056bdcf4c7" Archived-At: Subject: Re: [lamps] Logo carrying certificate profile for email` draft X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 17:00:23 -0000 --000000000000697f6d056bdcf4c7 Content-Type: multipart/alternative; boundary="0000000000005fd712056bdcf41b" --0000000000005fd712056bdcf41b Content-Type: text/plain; charset="UTF-8" I'm fine with that. I was checking with the author of the other likely IETF document (BIMI assertion records) whether he intended his document to be standards track to make sure that's aligned (likely it should be). -Wei On Thu, May 10, 2018 at 9:55 AM Russ Housley wrote: > Wei: > > I think that an Independent stream document is sufficient to get the code > point assignments. > > Russ > > > On May 8, 2018, at 3:02 AM, Wei Chuang wrote: > > Hi all, > > I've posted a draft > https://datatracker.ietf.org/doc/draft-chuang-bimi-certificate/ regarding > a logo carrying certificate for authenticated email using domain based > methods (DKIM and SPF). In particular this draft calls for a new Extended > Key Usage for these certificates to help distinguish this usage from other > profiles such as S/MIME. Can this draft be considered for the LAMPS > rechartering? This work is being done by a Brand Indicator for Message > Identification (BIMI) working group. An early version of the overall > protocol can be seen at > https://authindicators.github.io/rfc-brand-indicators-for-message-identification/ > though that version doesn't include changes that include X.509 > certificates. > > thanks, > -Wei > > > --0000000000005fd712056bdcf41b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm fine with that.=C2=A0 I was checking with the auth= or of the other likely IETF document (BIMI assertion records) whether he in= tended his document to be standards track to make sure that's aligned (= likely it should be).

-Wei

On Thu, May 10, 2018 at 9:55 AM Russ Hous= ley <housley@vigilsec.com>= ; wrote:
Wei:

I think that an Independent stream docume= nt is sufficient to get the code point assignments.

Russ


On = May 8, 2018, at 3:02 AM, Wei Chuang <weihaw@google.com> wrote:

Hi all,<= br>

I've posted a draft=C2=A0http= s://datatracker.ietf.org/doc/draft-chuang-bimi-certificate/ regarding a= logo carrying certificate for authenticated email using domain based metho= ds (DKIM and SPF).=C2=A0 In particular this draft calls for a new Extended = Key Usage for these certificates to help distinguish this usage from other = profiles such as S/MIME.=C2=A0 Can this draft be considered for the LAMPS r= echartering?=C2=A0=C2=A0This work is being done by a Bra= nd Indicator for Message Identification (BIMI) working group.=C2=A0 An earl= y version of the overall protocol can be seen at https://authindicators.github.io/rfc-brand-indicators-for-messa= ge-identification/ though that version doesn't include changes that= include X.509 certificates.=C2=A0=C2=A0

th= anks,
-Wei=C2=A0


--0000000000005fd712056bdcf41b-- --000000000000697f6d056bdcf4c7 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMYKpa6SINwoLGQXUgMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDExOTE4NDI1MVoXDTE4MDcx ODE4NDI1MVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC0xH6rq6JX6ckhX0CIaSEowE6QOIiGkrqCHW5huLmJvpTEafUz 0rlXHZCh4aJVU59ByZavVB5iKNphEUJKY91aG65S5e2TbJKRqxU3cXGZe1Ol0VjQZ6cgXa0spJXY oG6jZe7QQWtHLwV8Pm3xxAXqagWvYKW5RYa/9S0Ab5YpJtCiLCR0c+OhRAWV+UKsP3B71AD0kC8l 8ug3Irx+81/hQkx1u35BvOP1D79rOZh4zquem5luip6CSg1xlRVGG6FP5Cj2Et0pUAjBP3K2hu9S zmBghizN03vlAzFX/WWVmChKpqf81jUKnXG+Muv9E4Si838BQvnlERsWIHOnUOIZAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFCAGe6s17mfun3rE/l40dXgd9FU9MB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCyR6ITTdELc7OY1Z/3 OnkUrwCVfjWq4Uq+apV0oGja88w4X/P+a/avsMx1aK525Rxy9VuWSQCzTsGyE71USOjutTl3c+2u pDEr18aE2sRYQvu4h7zs0zHGVe60cJl+cRZ20ggTnltfbFrU9wvTVBmynL4eznCA4c2AjrREk0v9 ORQz0GuQJfO2O4YUuVVIERWKrcciSm+DaQ93OyfJ1FX+MDSaJgnDPvIUPqnpqcCyCtcQBvYVrvNn OVhzQInUukIiVuVRMcsYVbwAQOlX+WlpXZw78LcUxREr6eFyfmx8eHEOC0EP7jTbOsY2qr/e4J3t VdgC0xqFqcmv46MxC4pVMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMYKpa6SIN woLGQXUgMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDHusbr27oP3WlFeXqF7zUx x9xOczWBVeCEu83+FhNsHDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA1MTAxNzAwMjFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAI9iFzqOuRSV/glqK7sduGE9LmyeQPJwPMcxGZneW a3WWv89psK1LhCwMFMPDPkeYOSWfQfdxHyW/txQp4Du7Qq9DLQoTR82VyDJz5ucvZAYh+gBc+LQj Y8egrXW30+PAjpc/UvNCiu6C7cl3vBxMPlyd9EzH26QFEGanu188PXPjcK1aG4EfWqQLNuCsA0nu 1qmaillWtCR4dgLzWQiddzsRyPOF75o2qK+iiDfQ5reDt18zSnSSA6I/TS2sKJ7eJ1+9Gi0OaqIU wNbkRAvlQHRGXkL6xOsQS0qX2uhBYx4NcTnPvPCRQqwxTJcRh5V8tNqK7gVoY7jI/eTjfRvXAA== --000000000000697f6d056bdcf4c7-- From nobody Fri May 11 08:51:27 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9041312EAEE; Fri, 11 May 2018 08:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXyj-5cG3m-X; Fri, 11 May 2018 08:50:57 -0700 (PDT) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (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 0798312EAF7; Fri, 11 May 2018 08:50:57 -0700 (PDT) Received: by mail-lf0-x243.google.com with SMTP id r2-v6so8599721lff.4; Fri, 11 May 2018 08:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/Utcay9ANfxXBPlrLudnx4FgPG4MIGu/4E/JQ+zn+2I=; b=dRGuhKa4ooaab289fyIwMn+RUhLq0U/N3v18r6GHydg1EZe9s/ao2QIqynXSgx6Txp wVzwx+BKdpOHOli09C0DkbY6DDRC5I8RKslfniZU6OUV8c0PqAqshW6XTOo2zNoOfirA 7Wny5GGn5C2jZjJJGkQ3VbQAPvv70J7Ih22PCx4q0GDdCbfn7HC9siJskxqM+ajcHrjQ 57uqM1V64APYKbTythXwCe2SQRPfCqf4TSb1uVHp6ius9ZpOjBhphAxd5tmEijMaWEr5 HS798FVWAv4HOaQdIBY50tMbCJlrRO0OJk8b7QyEd41BfK9TQtAa/qZbye55tfW2Ql2D 7CWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/Utcay9ANfxXBPlrLudnx4FgPG4MIGu/4E/JQ+zn+2I=; b=gs3o2jpI9KBClS0t5zcsh07pP4Kl82QGuf/9fed6VVore0HO5DqejropmglKVG9IIf k+8LljWNJE//At0On2W7qTZMzOXpXPuCIHWB7AvtoIW/pV6NY6mC/ogx8saYrJh+N9PP /UXYNpahgayV4EDc10B24+slbhAVRghPt9J/JPQNp98PHqZiWjN+oifShpPbAJ7EGOXp uXFQwavbUo4JnJnOjTixni11RWXhPlf1GYF+MkPgiSKGzBXZ/nULUE0WqKU1QygCa/UN V1E2mZUWqoaE0LULCO6zMLjUjXG3/T2wAIVRVgZM20KyHKZh/SUbuj5ngxb8qotJF0sJ r+xQ== X-Gm-Message-State: ALKqPwdQ6zyclpV30ygnoED5q4NhVSSh9KbAvJ+JhAOnBb+8wqMvfNvu +/V7F36VS+qe1kz1i84ysC+EDmENpCTQLo2qcmSo5g== X-Google-Smtp-Source: AB8JxZoJPAQCTahGmmQ0KI8rc5i+weFgxz9FL4sGE+h9UH1ANTvX4UBfOwL6j2Jdo+MA8CTdud9FCPHn1I8ovy1exTc= X-Received: by 2002:a19:2143:: with SMTP id h64-v6mr1865250lfh.73.1526053855198; Fri, 11 May 2018 08:50:55 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.158.88 with HTTP; Fri, 11 May 2018 08:50:54 -0700 (PDT) In-Reply-To: <052201d3e247$19431b20$4bc95160$@augustcellars.com> References: <152485706488.6011.12980717250490137013@ietfa.amsl.com> <052201d3e247$19431b20$4bc95160$@augustcellars.com> From: Daniel Migault Date: Fri, 11 May 2018 11:50:54 -0400 X-Google-Sender-Auth: G5Fi-cACOSEOFW2F-2PJliiK4C8 Message-ID: To: Jim Schaad Cc: secdir@ietf.org, spasm@ietf.org, ietf@ietf.org, draft-ietf-lamps-rfc5751-bis.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000f284ee056bf019b1" Archived-At: Subject: Re: [lamps] Secdir last call review of draft-ietf-lamps-rfc5751-bis-07 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 15:51:06 -0000 --000000000000f284ee056bf019b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jim, Thanks you for the clarifications. Please see my comments inline. Yours, Daniel On Wed, May 2, 2018 at 2:55 PM, Jim Schaad wrote: > I have published a -08 with these changes. > > > -----Original Message----- > > From: Daniel Migault > > Sent: Friday, April 27, 2018 12:24 PM > > To: secdir@ietf.org > > Cc: spasm@ietf.org; ietf@ietf.org; draft-ietf-lamps-rfc5751-bis.a > ll@ietf.org > > Subject: Secdir last call review of draft-ietf-lamps-rfc5751-bis-07 > > > > Reviewer: Daniel Migault > > Review result: Has Nits > > > > Hi, > > > > > > I have reviewed this document as part of the security directorate's > ongoing > > effort to review all IETF documents being processed by the IESG. > > These comments were written primarily for the benefit of the security > area > > directors. Document editors and WG chairs should treat these comments > > just like any other last call comments. > > > > The summary of the review is Has Minor Nits > > > > > > Please find my comments while reading the draft. > > > > Yours, > > > > Daniel > > > > > > 1. Introduction > > > > As a supplementary service, S/MIME provides for message > > compression. > > > > maybe : > > As a supplementary service, S/MIME provides message > > compression. > > > > Done > > > > > 1.3. Conventions Used in This Document > > > > The term RSA in this document almost always refers to the PKCS#1 v1.5 > > RSA signature or encryption algorithms even when not qualified as > > such. > > > > I am not sure format would not be more appropriated than algorithm, so > > maybe: > > > > The term RSA in this document almost always refers to the PKCS#1 v1.5 > > RSA signature or encryption *format* even when not qualified as > > such. > > Interesting observation. In all of the work that I have ever done I have > always referred to the difference between PKCS #v1.5 signature, PKCS #v1.= 5 > encryption, OAEP, PSS and KEM and different encryption algorithms rather > than just saying that the formats are different. Saying format would mak= e > a degree of sense between the two different 1.5 algorithms, however if yo= u > compare v1.5 signature and PSS then more than just the format of the data > can be thought of as being involved. > > I don't think that this makes sense. > This comment was just mentioned as potential nits. I am fine with protocol and understand the reasons. Thanks for the explanation. I cannot find where I found the use of "format" and RFC8017 seems to use "scheme". > > > > > > 2.3. KeyEncryptionAlgorithmIdentifier > > > > When ECDH ephemeral-static is used, a key wrap algorithm is also > > specified in the KeyEncryptionAlgorithmIdentifier [RFC5652]. The > > underlying encryption functions for the key wrap and content > > encryption algorithm ([RFC3370] and [RFC3565]) and the key sizes for > > the two algorithms MUST be the same (e.g., AES-128 key wrap algorith= m > > with AES-128 content encryption algorithm). > > > > I understand the recommendation for a sending agent, but it seems that > > additional text should be provided in order to describe the behavior of > the > > receiver. I am wondering if the receiver is expected to reject the > message or > > whether it should assume the associated protection is the least of the > two. > > Maybe specifying this is only for sending agent may also clarify this. > > This probably falls under the category of "I don't care", the object is t= o > make sending agents do the right thing. However, I have added test about > security strengths for reciepents. > Thanks. > > > > > 2.4.4. AuthEnvelopedData Content Type > > > > This content type does not provide > > authentication or non-repudiation. > > > > is a really helpful clarification ;-) Maybe it could be helpful to use > the same > > formulation for section 2.4.2. SignedData Content Type by > > replacing: > > > > Applying a > > signature to a message provides authentication, message integrity, > > and non-repudiation of origin. > > > > > > This content type provides provides authentication, message integrity, > and > > non-repudiation of origin. A sender signs the message with its own > private > > key and shares public part of it with the recipient to validate the > signature. > > I don't think this necessary for the other content types. The problem is > that many people think that AED algorithms automatically provide > authentication. There are some situations where this is true, but they a= re > not met when doing S/MIME. > > I agree. My comment was only to mention that 2.4.2 and 2.4.4 could use similar formulation. > > > 2.5. Attributes and the SignerInfo Type > > > > It would probably ease the reading and clarifying the purpose of the > > SignerInfo's attribute. Typically, some of them might necessary to > validate > > the received message, while others are informational in prevision of a > > response. This is clarified later in the document but could be introduc= ed > > here. I also believe that would be good to also include that there is a > > bootstrapping issue that is solved by the compliance of the > implementations > > in supporting the recommended algorithms. > > > > A reference to section 2.7 may be useful as this section clarifies how > the > > sending agent uses these information - at least for the encryption. > > I have added the following sentence to the first paragraph > > These attributes can be required for processing of message (i.e. Message > Digest), information the signer supplied (i.e. SMIME Capabilities) that > should be processed, or attributes which are not relevant in the current > situation (i.e. mlExpansionList for mail viewe= rs). > > I don't think a forward reference to 2.7 would be useful at this point. > I think that helps the reading. Thank you. > > > > > 2.5.1. Signing Time Attribute > > > > The message originator has not been specified before, it may be good to > > clarify how it differs from the sender. It may also be good to specify > how this > > value is being used - against replay attacks. section 2.7.1 provides > some > > indications of the expected usage of the signing time attribute but it > seems > > more associated to the capabilities. > > Replaced message originator with signer. > ok > > > > > 2.5.2. SMIME Capabilities Attribute > > > > A client does not have to list every capability it > > supports, and need not list all its capabilities so that the > > capabilities list doesn't get too long. > > > > It might be worth providing a recommendation on what too long means, > > especially as a resulting list of capabilities is (expected) to be > relatively short > > compared to the message itself - but I might be wrong. > > My reading of this attribute - and again I might be wrong - is that it > would be > > useless if implementations would follow the cryptographic > > recommendations. It is mostly useful to have non updated senders to > > received responses from up-to-date responders. In addition, this > > information is likely cached and as such may not be unnecessarily be > > repeated. Wouldn't a MAY be more appropriated ? > > I don't really want to try and quantify what long means because for > different clients it can mean different things. In some considerations o= ne > could consider listing 3 encryption algorithms to be long while in other > situations it might be 30 encryption algorithms that is too long. If I > want to send you a message and need to be sure that there is a common > enabled language then 30 encryption algorrithms is better. On the other > hand trying to figure out a common algorithm for a message going to 100 > recipients where each has a different set of algorithms and in a differen= t > ranking order and come up with the best one means even 3 can feel really > long. > > The problem is not byte count as even 30 items at 10 bytes apiece is only > 300 bytes which relative to the rest of a signed MIME message is pretty > small. The problem is the question of how to make a decision and the > parameters are different based on how that algorithm is implemented. > > While the information can be cached, I don't know that it can be assured > to be cached. Additionally this might put a greater burden on the sender > as it would need to know if the current configuration has been sent to a > recipient. It is easier to just always send the list. However I cannot > see that there is any requirements on the document on having sending the > attribute just on receiving it. > > I got it, but my point was that by having a mandatory to implement cryptography document, would enable to have inter operable cryptographic primitives that evolve over time. Such document will provide the necessary overlaps. This is how we proceed with IKEv2 / IPsec... but S/MIME may have different deployment considerations. I see your last comment you do not think that is useful. I am fine as long as I am sure you got my purpose.. > > > > > Note also that while we have some cryptographic recommendations for RSA= , > > I would have expected a table summarizing the cryptographic > > recommendations with other algorithms than RSA. > > I don't know that adding a table is going to be useful. Much of this > information is not really designed to be put into a table unless you are > going to footnote the heck out of it which kind of defeats the process. > This information is scattered through out the document, but it tries to b= e > in the right place for a specific field. > > I agree with you point. However, I believe that a mandatory to implement guidance section or document would be helpful to specify which crypto is mandatory and the status of the other algorithms. Evolution of the crypto may address another scope than the protocol description and might be another document. Again this is addressed by your last comment. > > > > 2.5.3. Encryption Key Preference Attribute > > > > This attribute is designed to > > enhance behavior for interoperating with those clients that use > > separate keys for encryption and signing. > > > > Maybe that would be good to position this attribute versus the keyusage > > when certificate are used to split the usage of each keys. I am > wondering if a > > recommendation could be state on whether one or both means should be > > used and if one overwrite the other. A preference may still be useful = to > > indicate a preference when multiple keys for a given role are available= . > Is key > > management a relevant usage for preference ? > > > > I understand that Signing Time is being used to update the preferred > > keys as one way to performed key roll over. > > While there is some similarity between key usage and this attribute, the > attribute is more general and allows for things which are not necessarily > mentioned here. As an example, one could send different certificates wit= h > different algorithms or key sizes and express a preference on which > certificate to use. It may be that the names between the signing > certificate and encryption key certificate are not the same, in that case > which should be used. I think that this is covered in the introduction > and a reference to key usage is not really helpful. > > The response clarifies my question thanks. > > > > > > 3.1. Preparing the MIME Entity for Signing, Enveloping, or Compressing > > > > A MIME entity can be a sub- > > part, sub-parts of a message, or the whole message with all its sub- > > parts. > > > > I am wondering if "a subpart, many subparts or ..." would not be cleare= r. > > I don't see this as being clearer. > > > > > I understand that "message" in the first paragraph is used as the MIME > > message and in other words, the message is not designating the mail. I = am > > reading message as MIME multi-part message and the MIME entities as a > > subset of MIME headers and parts of MIME multi-part message. Similarly > > MIME body would be the MIME multi-part message. Is that correct ? I > > believe the terminology paragraph could be clarified. > > There is no requirement that message be multi-part, it could be a > single-part message such as text/plain. However that is generally > correct. How do you believe that the text can be clarified. Specific te= xt > would be helpful. > I believe that replacing message by MIME message would clarify the difference between the message of the email. Then clarifying that MIME message is composed of MIME entities. Here is what I would propose: S/MIME is used to secure MIME entities. A MIME message is composed of a MIME header and a MIME body, which both can be constituted of a single part or of multiple parts. Any of these parts is designated as a MIME message part. A MIME entity can be a sub- part, sub-parts of a MIME message, or the whole Mime message with all its sub- parts. A MIME entity that is the whole MIME message includes only the MIME message headers and MIME body, and does not include the RFC-822 header. Note that S/MIME can also be used to secure MIME entities used in applications other than Internet mail. If protection of the RFC-822 header is required, the use of the message/rfc822 media type is explained later in this section. > > > > > > > It is > > RECOMMENDED that a distinction be made between the location of the > > header. > > > > I believe the purpose is to make a distinction between "protected" and > > 'unprotected' to the end user. I would thus keep this distinction even > though > > this translates into 'inner' / 'outer'. > > The problem of how to do this has been a topic of many discussions withou= t > ever getting to a conclusion. One of the problems is that protected can > mean some different things depending on how you protect the headers. For > example, one could have a multipart/mixed message with two sections each = of > which consists of an encrypted message. If each of those has different > protected headers in them then, while the difference between inner and > outer makes sense as that is part of the tree structure, which set of > protected headers now needs to be dealt with. > > Thanks for the explanation. I agree. > > > > > > 3.3. Creating an Enveloped-Only Message > > > > > > A sample message would be: > > > > Content-Type: application/pkcs7-mime; name=3Dsmime.p7m; > > smime-type=3Denveloped-data > > > > Shouldn't we use an OID instead of data for the example ? > > I don't know what you are trying to ask here. > I though of specifying an OID instead of using data, but I agree that data is preferred. > > > > > > > > > 3.4. Creating an Authenticated Enveloped-Only Message > > > > I believe the word "proof" is missing. > > > > It is important to note that > > sending authenticated enveloped messages does not provide for > > origination when using S/MIME. > > > > Maybe we should specify that this is especially true when multiple > recipients > > are involved. > > done > > > > > 3.5.3. Signing Using the multipart/signed Format > > > > The first part contains > > the MIME entity that is signed; the second part contains the > > "detached signature" CMS SignedData object in which the > > encapContentInfo eContent field is absent. > > > > I believe it would be good to specify parts are ordered as this is not > always > > the case of parts. What is unclear to me is why the second part is > separated > > by a boundary usually used to separate parts. It seems boundary can als= o > be > > used as boundary inside a part which seems to make part parsing harder. > > The order is part of the definition of multipart/signed. > > In the definition of multipart/*, the rules require that the boundary > string not exist within any of the different child body parts. This mean= s > that it can be used to uniquely distinguish the boundaries. > Agree. Thanks for the clarification. > > > > > > > > > 3.5.3.2. Creating a multipart/signed Message > > > > Algorithm Value Used > > MD5 md5 > > SHA-1 sha-1 > > SHA-224 sha-224 > > SHA-256 sha-256 > > SHA-384 sha-384 > > SHA-512 sha-512 > > Any other (defined separately in algorithm profile or "unknown" if > > not defined) > > > > > > Should we have any recommendations on the hash algorithm to be used by > > sender / receivers ? Is that possible to deprecate MD5, SHA-1 and > > SHA-224 for senders ? > > The recommendations on which algorithms to use is part of the signature > algorithm recommendations. This is a different table and removing items > would be potentially harmful. > > I am reading this as new implementations should still implement MD5. If so, I believe an explanation might be useful. > > > > > > 3.7. Multiple Operations > > > > Would it be recommended to have signed clear text than encrypted and > > then signed encrypted ? This seems to address all security concerns. > > There are a large number of security concerns that have been uncovered > with each of the different orders of operations. Part of the question is > going to be what concern are you trying to address and what are the > informal rules about this. I don't think at this point we can really giv= e > an order, however RFC 2634 does have some guidance. > Correct. Maybe it would be useful the section references ESS for further recommendations. But I agree the reference has been mentioned earlier. > > > > > 3.9. Registration Requests > > > > Should we mention DANE rfc8162 as a way to register you public key ? > > I don't think so, we don=E2=80=99t ever talk about how to find keys in th= e > document. > Agree ;-) > > > > > 4. Certificate Processing > > > > EdDSA Signatures recommendations for curve25519 and curve448 seems to > > be missing in the key pair generating , signature section. Are there an= y > > reasons not to consider these curves ? > > > > May be useful to have the following references: > > [1] https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa > -signatures/ > > [2] https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ > > Should have had [1] as a reference, the reference was there but not the > pointer to it. > The second would be referenced in rfc5750-bis not here. > > > > > 6. Security Considerations > > > > I am wondering if any considerations should be provided for data at res= t. > > Does the email needs to be archived encrypted or not and whether S/MIME > > can be used to store encrypted content. I believe that email should not > be > > stored encrypted and as such S/MIME is only intended to > > protect mails in transit.... but I might be wrong. > > I believe you to be wrong. There are no problems w/ using S/MIME as a > data at rest protection scheme. The question of storing messages as > encrypted or not is something that different clients have dealt with in > different ways. The client I use leaves things encrypted which I conside= r > to be the correct answer. > > I see why... if there are no clear rules, it might be better to leave it as it is. I agree. > > > > As a general comment I would have like a table that summarizes or > explicitly > > mention what crypto is recommended for encrypting / signing. > > RSA is being discussed, but ECDSA EdDSA, ECDH, hash... are not. I belie= ve > > such tables should be updated regularly to deprecate and introduce new > > algorithms while leaving S/MIME unchanged. > > To do this would require that the algorithms be maintained in a separate > document. As above, I don't think a separate table adds to clarity as it > duplicates information and would be hard to write. > > > > > There are a lot of double space in the text. > > > > > Jim > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --000000000000f284ee056bf019b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jim,

Thanks you for the cl= arifications. Please see my comments inline.

Yours,=C2=A0
Daniel

On Wed, May 2, 2018 at 2:55 PM, Jim Schaad <ietf@= augustcellars.com> wrote:
I= have published a -08 with these changes.

> -----Original Message-----
> From: Daniel Migault <daniel.migault@ericsson.com>
> Sent: Friday, April 27, 2018 12:24 PM
> To: secdir@ietf.o= rg
> Cc: spasm@ietf.org= ; ietf@ietf.org;= draft-ietf-lamps-rfc5751-bis.all@ietf.org
> Subject: Secdir last call review of draft-ietf-lamps-rfc5751-bis-07
>
> Reviewer: Daniel Migault
> Review result: Has Nits
>
> Hi,
>
>
> I have reviewed this document as part of the security directorate'= s ongoing
> effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security = area
> directors.=C2=A0 Document editors and WG chairs should treat these com= ments
> just like any other last call comments.
>
> The summary of the review is Has Minor Nits
>
>
> Please find my comments while reading the draft.
>
> Yours,
>
> Daniel
>
>
> 1.=C2=A0 Introduction
>
> As a supplementary service, S/MIME provides for message
>=C2=A0 =C2=A0 compression.
>
> maybe :
> As a supplementary service, S/MIME provides message
>=C2=A0 =C2=A0 compression.
>

Done

>
> 1.3.=C2=A0 Conventions Used in This Document
>
> The term RSA in this document almost always refers to the PKCS#1 v1.5<= br> >=C2=A0 =C2=A0 RSA signature or encryption algorithms even when not qual= ified as
>=C2=A0 =C2=A0 such.
>
> I am not sure format would not be more appropriated than algorithm, so=
> maybe:
>
> The term RSA in this document almost always refers to the PKCS#1 v1.5<= br> >=C2=A0 =C2=A0 RSA signature or encryption *format* even when not qualif= ied as
>=C2=A0 =C2=A0 such.

Interesting observation.=C2=A0 In all of the work that I have ever d= one I have always referred to the difference between PKCS #v1.5 signature, = PKCS #v1.5 encryption, OAEP, PSS and KEM and different encryption algorithm= s rather than just saying that the formats are different.=C2=A0 Saying form= at would make a degree of sense between the two different 1.5 algorithms, h= owever if you compare v1.5 signature and PSS then more than just the format= of the data can be thought of as being involved.

I don't think that this makes sense.

This comment was just mentioned as=C2=A0 potential nits. I am fine with p= rotocol and understand the reasons. Thanks for the explanation. I cannot fi= nd where I found the use of "format" and RFC8017 seems to use &qu= ot;scheme".
=C2=A0=C2=A0
>
>
> 2.3.=C2=A0 KeyEncryptionAlgorithmIdentifier
>
> When ECDH ephemeral-static is used, a key wrap algorithm is also
>=C2=A0 =C2=A0 specified in the KeyEncryptionAlgorithmIdentifier [R= FC5652].=C2=A0 The
>=C2=A0 =C2=A0 underlying encryption functions for the key wrap and cont= ent
>=C2=A0 =C2=A0 encryption algorithm ([RFC3370] and [RFC3565]) and the ke= y sizes for
>=C2=A0 =C2=A0 the two algorithms MUST be the same (e.g., AES-128 key wr= ap algorithm
>=C2=A0 =C2=A0 with AES-128 content encryption algorithm).
>
> I understand the recommendation for a sending agent, but it seems that=
> additional text should be provided in order to describe the behavior o= f the
> receiver. I am wondering if the receiver is expected to reject the mes= sage or
> whether it should assume the associated protection is the least of the= two.
> Maybe specifying this is only for sending agent may also clarify this.=

This probably falls under the category of "I don't care&quo= t;, the object is to make sending agents do the right thing.=C2=A0 However,= I have added test about security strengths for reciepents.

Thanks.
=C2=A0

>
> 2.4.4.=C2=A0 AuthEnvelopedData Content Type
>
> This content type does not provide
>=C2=A0 =C2=A0 authentication or non-repudiation.
>
> is a really helpful clarification ;-) Maybe it could be helpful to use= the same
> formulation for section 2.4.2.=C2=A0 SignedData Content Type by
> replacing:
>
> Applying a
>=C2=A0 =C2=A0 signature to a message provides authentication, message i= ntegrity,
>=C2=A0 =C2=A0 and non-repudiation of origin.
>
>
> This content type provides provides authentication, message integrity,= and
> non-repudiation of origin. A sender signs the message with its own pri= vate
> key and shares public part of it with the recipient to validate the si= gnature.

I don't think this necessary for the other content types.=C2=A0 = The problem is that many people think that AED algorithms automatically pro= vide authentication.=C2=A0 There are some situations where this is true, bu= t they are not met when doing S/MIME.

I agree. My comment was only to mention = that 2.4.2 and 2.4.4 could use similar formulation.

>
> 2.5.=C2=A0 Attributes and the SignerInfo Type
>
> It would probably ease the reading and clarifying the purpose of the > SignerInfo's attribute. Typically, some of them might necessary to= validate
> the received message, while others are informational in prevision of a=
> response. This is clarified later in the document but could be introdu= ced
> here. I also believe that would be good to also include that there is = a
> bootstrapping issue that is solved by the compliance of the implementa= tions
> in supporting the recommended algorithms.
>
> A reference to section 2.7 may be useful as this section clarifies how= the
> sending agent uses these information - at least for the encryption.
I have added the following sentence to the first paragraph

These attributes can be required for processing of message (i.e. Message Di= gest), information the signer supplied (i.e. SMIME Capabilities) that shoul= d be processed, or attributes which are not relevant in the current situati= on (i.e. mlExpansionList <xref target=3D"RFC2634"/> for mai= l viewers).

I don't think a forward reference to 2.7 would be useful at this point.=

I think that helps the reading. Thank = you.=C2=A0

>
> 2.5.1.=C2=A0 Signing Time Attribute
>
> The message originator has not been specified before, it may be good t= o
> clarify how it differs from the sender. It may also be good to specify= how this
> value is being used - against replay attacks.=C2=A0 section 2.7.1 prov= ides some
> indications of the expected usage of the signing time attribute but it= seems
> more associated to the capabilities.

Replaced message originator with signer.
ok

>
> 2.5.2.=C2=A0 SMIME Capabilities Attribute
>
> A client does not have to list every capability it
>=C2=A0 =C2=A0 supports, and need not list all its capabilities so that = the
>=C2=A0 =C2=A0 capabilities list doesn't get too long.
>
> It might be worth providing a recommendation on what too long means, > especially as a resulting list of capabilities is (expected) to be rel= atively short
> compared to the message itself - but I might be wrong.
> My reading of this attribute - and again I might be wrong - is that it= would be
> useless if implementations would follow the cryptographic
> recommendations.=C2=A0 It is mostly useful to have non updated senders= to
> received responses from up-to-date responders. In addition, this
> information is likely cached and as such may not be unnecessarily be > repeated. Wouldn't a MAY be more appropriated ?

I don't really want to try and quantify what long means because = for different clients it can mean different things.=C2=A0 In some considera= tions one could consider listing 3 encryption algorithms to be long while i= n other situations it might be 30 encryption algorithms that is too long.= =C2=A0 If I want to send you a message and need to be sure that there is a = common enabled language then 30 encryption algorrithms is better.=C2=A0 On = the other hand trying to figure out a common algorithm for a message going = to 100 recipients where each has a different set of algorithms and in a dif= ferent ranking order and come up with the best one means even 3 can feel re= ally long.

The problem is not byte count as even 30 items at 10 bytes apiece is only 3= 00 bytes which relative to the rest of a signed MIME message is pretty smal= l.=C2=A0 The problem is the question of how to make a decision and the para= meters are different based on how that algorithm is implemented.

While the information can be cached, I don't know that it can be assure= d to be cached.=C2=A0 Additionally this might put a greater burden on the s= ender as it would need to know if the current configuration has been sent t= o a recipient.=C2=A0 It is easier to just always send the list.=C2=A0 Howev= er I cannot see that there is any requirements on the document on having se= nding the attribute just on receiving it.

I got it, but my point was that by havin= g a mandatory to implement cryptography document, would enable to have inte= r operable cryptographic primitives that evolve over time. Such document wi= ll provide the necessary overlaps. This is how we proceed with IKEv2 / IPse= c... but S/MIME may have different deployment considerations. =C2=A0 I see = your last comment you do not think that is useful. I am fine as long as I a= m sure you got my purpose..

>
> Note also that while we have some cryptographic recommendations for RS= A,
> I would have expected a table summarizing the cryptographic
> recommendations with other algorithms than RSA.

I don't know that adding a table is going to be useful.=C2=A0 Mu= ch of this information is not really designed to be put into a table unless= you are going to footnote the heck out of it which kind of defeats the pro= cess.=C2=A0 This information is scattered through out the document, but it = tries to be in the right place for a specific field.


I agree with you point. H= owever, I believe that a mandatory to implement guidance section or documen= t would be helpful to specify which crypto is mandatory and the status of t= he other algorithms. Evolution of the crypto may address another scope than= the protocol description and might be another document. =C2=A0 Again this = is addressed by your last comment.
>
> 2.5.3.=C2=A0 Encryption Key Preference Attribute
>
>=C2=A0 This attribute is designed to
>=C2=A0 =C2=A0 enhance behavior for interoperating with those clients th= at use
>=C2=A0 =C2=A0 separate keys for encryption and signing.
>
> Maybe that would be good to position this attribute versus the keyusag= e
> when certificate are used to split the usage of each keys. I am wonder= ing if a
> recommendation could be state on whether one or both means should be > used and if one overwrite the other.=C2=A0 A preference may still be u= seful to
> indicate a preference when multiple keys for a given role are availabl= e. Is key
> management a relevant usage for preference ?
>
> I understand that Signing Time is being used to update the preferred > keys as one way to performed key roll over.

While there is some similarity between key usage and this attribute,= the attribute is more general and allows for things which are not necessar= ily mentioned here.=C2=A0 As an example, one could send different certifica= tes with different algorithms or key sizes and express a preference on whic= h certificate to use.=C2=A0 It may be that the names between the signing ce= rtificate and encryption key certificate are not the same, in that case whi= ch should be used.=C2=A0 =C2=A0 I think that this is covered in the introdu= ction and a reference to key usage is not really helpful.

The response clarifies my question thank= s.=C2=A0
>
>
> 3.1.=C2=A0 Preparing the MIME Entity for Signing, Enveloping, or Compr= essing
>
>=C2=A0 A MIME entity can be a sub-
>=C2=A0 =C2=A0 part, sub-parts of a message, or the whole message with a= ll its sub-
>=C2=A0 =C2=A0 parts.
>
> I am wondering if "a subpart, many subparts or ..." would no= t be clearer.

I don't see this as being clearer.

>
> I understand that "message" in the first paragraph is used a= s the MIME
> message and in other words, the message is not designating the mail. I= am
> reading message as MIME multi-part message and the MIME entities as a<= br> > subset of MIME headers and parts of MIME multi-part message. Similarly=
> MIME body would be the MIME multi-part message.=C2=A0 Is that correct = ? I
> believe the terminology paragraph could be clarified.

There is no requirement that message be multi-part, it could be a si= ngle-part message such as text/plain.=C2=A0 However that is generally corre= ct.=C2=A0 How do you believe that the text can be clarified.=C2=A0 Specific= text would be helpful.

I believe that = replacing message by MIME message would clarify the difference between the = message of the email. Then clarifying that MIME message is composed of MIME= entities.

Here is what I would propose:

S/MIME is used to secure MIME entities. A MIME message=
 is composed of a 
MIME header and a MIME body, which both can be consti=
tuted of a single 
part or of multiple parts. Any of these parts is desi=
gnated as a MIME message part.
A MIME entity can be a sub-
   part, sub-parts of a MIME message, or the whole Mime message with all it=
s sub-
   parts.  A MIME entity that is the whole MIME message includes only the
   MIME message headers and MIME body, and does not include the RFC-822
   header.  Note that S/MIME can also be used to secure MIME entities
   used in applications other than Internet mail.  If protection of the
   RFC-822 header is req=
uired, the use of the message/rfc822 media type
   is explained later in this section.


=C2=A0
=C2=A0

>
>
>=C2=A0 It is
>=C2=A0 =C2=A0 RECOMMENDED that a distinction be made between the locati= on of the
>=C2=A0 =C2=A0 header.
>
> I believe the purpose is to make a distinction between "protected= " and
> 'unprotected' to the end user. I would thus keep this distinct= ion even though
> this translates into 'inner' / 'outer'.

The problem of how to do this has been a topic of many discussions w= ithout ever getting to a conclusion.=C2=A0 One of the problems is that prot= ected can mean some different things depending on how you protect the heade= rs.=C2=A0 For example, one could have a multipart/mixed message with two se= ctions each of which consists of an encrypted message.=C2=A0 If each of tho= se has different protected headers in them then, while the difference betwe= en inner and outer makes sense as that is part of the tree structure, which= set of protected headers now needs to be dealt with.

Thanks for the explanation. I agree. =C2=A0
>
>
> 3.3.=C2=A0 Creating an Enveloped-Only Message
>
>
> A sample message would be:
>
>=C2=A0 =C2=A0 Content-Type: application/pkcs7-mime; name=3Dsmime.p7m; >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 smime-type=3Denveloped-data >
> Shouldn't we use an OID instead of data for the example ?

I don't know what you are trying to ask here.=C2=A0

I though of specifying an OID instead of using dat= a, but I agree that data is preferred.
=C2=A0

>
>
>
> 3.4.=C2=A0 Creating an Authenticated Enveloped-Only Message
>
> I believe the word "proof" is missing.
>
>=C2=A0 It is important to note that
>=C2=A0 =C2=A0 sending authenticated enveloped messages does not provide= for
>=C2=A0 =C2=A0 origination when using S/MIME.
>
> Maybe we should specify that this is especially true when multiple rec= ipients
> are involved.

done

>
> 3.5.3.=C2=A0 Signing Using the multipart/signed Format
>
>=C2=A0 The first part contains
>=C2=A0 =C2=A0 the MIME entity that is signed; the second part contains = the
>=C2=A0 =C2=A0 "detached signature" CMS SignedData object in w= hich the
>=C2=A0 =C2=A0 encapContentInfo eContent field is absent.
>
> I believe it would be good to specify parts are ordered as this is not= always
> the case of parts. What is unclear to me is why the second part is sep= arated
> by a boundary usually used to separate parts. It seems boundary can al= so be
> used as boundary inside a part which seems to make part parsing harder= .

The order is part of the definition of multipart/signed.

In the definition of multipart/*, the rules require that the boundary strin= g not exist within any of the different child body parts.=C2=A0 This means = that it can be used to uniquely distinguish the boundaries.

Agree. Thanks for the clarification.=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
>
>
>
> 3.5.3.2.=C2=A0 Creating a multipart/signed Message
>
>=C2=A0 =C2=A0 =C2=A0Algorithm Value Used
>=C2=A0 =C2=A0 =C2=A0MD5=C2=A0 =C2=A0 =C2=A0 =C2=A0md5
>=C2=A0 =C2=A0 =C2=A0SHA-1=C2=A0 =C2=A0 =C2=A0sha-1
>=C2=A0 =C2=A0 =C2=A0SHA-224=C2=A0 =C2=A0sha-224
>=C2=A0 =C2=A0 =C2=A0SHA-256=C2=A0 =C2=A0sha-256
>=C2=A0 =C2=A0 =C2=A0SHA-384=C2=A0 =C2=A0sha-384
>=C2=A0 =C2=A0 =C2=A0SHA-512=C2=A0 =C2=A0sha-512
>=C2=A0 =C2=A0 =C2=A0Any other (defined separately in algorithm profile = or "unknown" if
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not defined)
>
>
> Should we have any recommendations on the hash algorithm to be used by=
> sender / receivers ? Is that possible to deprecate MD5, SHA-1 and
> SHA-224 for senders ?

The recommendations on which algorithms to use is part of the signat= ure algorithm recommendations.=C2=A0 This is a different table and removing= items would be potentially harmful.

I am reading this as new implementations= should still implement MD5. If so, I believe an explanation might be usefu= l.=C2=A0
=C2=A0
>
>
> 3.7.=C2=A0 Multiple Operations
>
> Would it be recommended to have signed clear text than encrypted and > then signed encrypted=C2=A0 ? This seems to address all security conce= rns.

There are a large number of security concerns that have been uncover= ed with each of the different orders of operations.=C2=A0 Part of the quest= ion is going to be what concern are you trying to address and what are the = informal rules about this.=C2=A0 I don't think at this point we can rea= lly give an order, however RFC 2634 does have some guidance.

Correct. Maybe it would be useful the section referen= ces ESS for further recommendations. But I agree the reference has been men= tioned earlier.

>
> 3.9.=C2=A0 Registration Requests
>
> Should we mention DANE rfc8162 as a way to register you public key ?
I don't think so, we don=E2=80=99t ever talk about how to find k= eys in the document.

Agree ;-)

>
> 4.=C2=A0 Certificate Processing
>
> EdDSA Signatures recommendations for curve25519 and curve448 seems to<= br> > be missing in the key pair generating , signature section. Are there a= ny
> reasons not to consider these curves ?
>
> May be useful to have the following references:
> [1] https://datatracker= .ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/
> [2] https://datatracker.ietf.org/d= oc/draft-ietf-curdle-pkix/

Should have had [1] as a reference, the reference was there but not = the pointer to it.
The second would be referenced in rfc5750-bis not here.

>
> 6.=C2=A0 Security Considerations
>
> I am wondering if any considerations should be provided for data at re= st.
> Does the email needs to be archived encrypted or not and whether S/MIM= E
> can be used to store encrypted content. I believe that email should no= t be
> stored encrypted and as such S/MIME is only intended to
> protect mails in transit....=C2=A0 but I might be wrong.

I believe you to be wrong.=C2=A0 There are no problems w/ using S/MI= ME as a data at rest protection scheme.=C2=A0 The question of storing messa= ges as encrypted or not is something that different clients have dealt with= in different ways.=C2=A0 The client I use leaves things encrypted which I = consider to be the correct answer.

I see why... if there are no clear rules= , it might be better to leave it as it is. I agree.
=C2=A0
>
> As a general comment I would have like a table that summarizes or expl= icitly
> mention what crypto is recommended for encrypting / signing.
> RSA is being discussed, but ECDSA EdDSA, ECDH, hash... are not. I beli= eve
> such tables should be updated regularly to deprecate=C2=A0 and introdu= ce new
> algorithms while leaving S/MIME unchanged.

To do this would require that the algorithms be maintained in a sepa= rate document.=C2=A0 As above, I don't think a separate table adds to c= larity as it duplicates information and would be hard to write.

>
> There are a lot of double space in the text.
>


Ji= m


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

--000000000000f284ee056bf019b1-- From nobody Fri May 11 12:53:07 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C9C12D889 for ; Fri, 11 May 2018 12:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.21 X-Spam-Level: X-Spam-Status: No, score=-18.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 m03twgjd6rTr for ; Fri, 11 May 2018 12:53:01 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ACDC126E64 for ; Fri, 11 May 2018 12:52:58 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id t23-v6so8297999ioc.10 for ; Fri, 11 May 2018 12:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZB/a042RD4A6dUlvcKb0Vn99DQk2fZcVJeg8Xl8x0SA=; b=wP2oE7rqlYHAMKAHM1G4Okdf6uTyIjxkqnJjCY0fa7gXDIhfcs0F3NFKjGXXYFPCke oUHMA2g70C/yXVSzH0Fep+0rOFTLBj67ftc0BRYPMiTlmbZa2e9DNCwSgLeIb5WAFg6D xlDg/C71nYQllcgwx0DuHeZfxFrebfl1CKixyuiGc2nfFC8Rw7odymKSg350PLulxkj8 LJqgfUT+Iql72Vz74UCdXmk4u/+Z0mWz48bbct6HWBFvmbZzuvo4sKju5OFtDQ9v//8J QMftgrY5SJdOCQuoHXMy0fH4g6Q5gukLDgH1Hm17EL9gxiDFMtQ4e6rwqPfBgZzZQgtJ lI5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZB/a042RD4A6dUlvcKb0Vn99DQk2fZcVJeg8Xl8x0SA=; b=thR4gTtH/Q0iVlvfBN6+wK2ItVMOXcGMabEQCkjoViU+43MBWsNHJAwQKUVgXaOTnT UoEl7YoX0dly7yzYFMeG0lLv+w8TQPRqS7KIafD4wcVtGdKGuAWGKleBRULxQs25rDCe snioUVAQO16dQodrUVzLNjQC65ed1GxdgK+2xrP/99r5DRAV7qhI0oFK+CEF//zIw0Av +26NJdG/PmCseQZQBgSjhkxSTk1P4zvp7LvzBhKaEa7evvH5WwVU1J4eISwV9o+JbzHK EAz9ecUxat6Sw0KO37HJdo8ftcwyAB//rqwXROayYnYjn7/go+x6A0gz3pOrl2qbOcqA 8RHw== X-Gm-Message-State: ALKqPwc7Zu8k4Yju6k+4FNPy2Z01q9q/xbrMthi5+al9Zfr9/SY1U26z wft+lFdyj4ETb5iDXEWGZQg4wTykFZPa3Jr0qHe2txNdh7Y= X-Google-Smtp-Source: AB8JxZrWDprPhAPTiqA0HAL0l0H8pvbD+R4nxv8waMtwz3Si1W/PlGurpDob1/bNyGPfjAE3tzq0/a0JEGsu/p1E2zc= X-Received: by 2002:a6b:6b16:: with SMTP id g22-v6mr4725977ioc.20.1526068376982; Fri, 11 May 2018 12:52:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Wei Chuang Date: Fri, 11 May 2018 12:52:45 -0700 Message-ID: To: Russ Housley Cc: SPASM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000008d36a2056bf37b85" Archived-At: Subject: Re: [lamps] Logo carrying certificate profile for email` draft X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 19:53:06 -0000 --0000000000008d36a2056bf37b85 Content-Type: multipart/alternative; boundary="000000000000841f22056bf37bf7" --000000000000841f22056bf37bf7 Content-Type: text/plain; charset="UTF-8" Hi all, I chatted with the author of a related document to see if the independent stream is appropriate as the disposition of both documents should be similar. He actually talked with Alexey Melnikov about a separate working group so perhaps the BIMI certificate draft can go there, otherwise the independent stream is fine. In either case I withdraw consideration of draft-chuang-bimi-certificate for the LAMPS recharter. -Wei On Thu, May 10, 2018 at 10:00 AM Wei Chuang wrote: > I'm fine with that. I was checking with the author of the other likely > IETF document (BIMI assertion records) whether he intended his document to > be standards track to make sure that's aligned (likely it should be). > > -Wei > > On Thu, May 10, 2018 at 9:55 AM Russ Housley wrote: > >> Wei: >> >> I think that an Independent stream document is sufficient to get the code >> point assignments. >> >> Russ >> >> >> On May 8, 2018, at 3:02 AM, Wei Chuang wrote: >> >> Hi all, >> >> I've posted a draft >> https://datatracker.ietf.org/doc/draft-chuang-bimi-certificate/ >> regarding a logo carrying certificate for authenticated email using domain >> based methods (DKIM and SPF). In particular this draft calls for a new >> Extended Key Usage for these certificates to help distinguish this usage >> from other profiles such as S/MIME. Can this draft be considered for the >> LAMPS rechartering? This work is being done by a Brand Indicator for >> Message Identification (BIMI) working group. An early version of the >> overall protocol can be seen at >> https://authindicators.github.io/rfc-brand-indicators-for-message-identification/ >> though that version doesn't include changes that include X.509 >> certificates. >> >> thanks, >> -Wei >> >> >> --000000000000841f22056bf37bf7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I chatted with the autho= r of a related document to see if the independent stream is appropriate as = the disposition of both documents should be similar.=C2=A0 He actually talk= ed with Alexey Melnikov about a separate working group so perhaps the BIMI = certificate draft can go there, otherwise the independent stream is fine.= =C2=A0 In either case I withdraw consideration of=C2=A0draft-chuang-bim= i-certificate=C2=A0for the LAMPS recharter.

-Wei=C2=A0

On Thu, May 10,= 2018 at 10:00 AM Wei Chuang <weiha= w@google.com> wrote:
I'm fine with that.=C2=A0 I was checking with the author of t= he other likely IETF document (BIMI assertion records) whether he intended = his document to be standards track to make sure that's aligned (likely = it should be).

-Wei

On Thu, May 10, 2018 at 9:55 AM Russ Housley <= ;housley@vigilsec= .com> wrote:
Wei:

I think that an Independent st= ream document is sufficient to get the code point assignments.
Russ


On May 8, 2018, at 3:02 AM, Wei Chuang <weihaw@google.com> wrote:

Hi all,

I've posted a d= raft=C2=A0https://datatracker.ietf.org/doc/draft-chuang-= bimi-certificate/ regarding a logo carrying certificate for authenticat= ed email using domain based methods (DKIM and SPF).=C2=A0 In particular thi= s draft calls for a new Extended Key Usage for these certificates to help d= istinguish this usage from other profiles such as S/MIME.=C2=A0 Can this dr= aft be considered for the LAMPS rechartering?=C2=A0=C2=A0This work is being done by a Brand Indicator for Message Identification (B= IMI) working group.=C2=A0 An early version of the overall protocol can be s= een at https://authindicators.github.i= o/rfc-brand-indicators-for-message-identification/ though that version = doesn't include changes that include X.509 certificates.=C2=A0=C2=A0

thanks,
-Wei=C2=A0

<= /div>

--000000000000841f22056bf37bf7-- --0000000000008d36a2056bf37b85 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMYKpa6SINwoLGQXUgMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDExOTE4NDI1MVoXDTE4MDcx ODE4NDI1MVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC0xH6rq6JX6ckhX0CIaSEowE6QOIiGkrqCHW5huLmJvpTEafUz 0rlXHZCh4aJVU59ByZavVB5iKNphEUJKY91aG65S5e2TbJKRqxU3cXGZe1Ol0VjQZ6cgXa0spJXY oG6jZe7QQWtHLwV8Pm3xxAXqagWvYKW5RYa/9S0Ab5YpJtCiLCR0c+OhRAWV+UKsP3B71AD0kC8l 8ug3Irx+81/hQkx1u35BvOP1D79rOZh4zquem5luip6CSg1xlRVGG6FP5Cj2Et0pUAjBP3K2hu9S zmBghizN03vlAzFX/WWVmChKpqf81jUKnXG+Muv9E4Si838BQvnlERsWIHOnUOIZAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFCAGe6s17mfun3rE/l40dXgd9FU9MB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCyR6ITTdELc7OY1Z/3 OnkUrwCVfjWq4Uq+apV0oGja88w4X/P+a/avsMx1aK525Rxy9VuWSQCzTsGyE71USOjutTl3c+2u pDEr18aE2sRYQvu4h7zs0zHGVe60cJl+cRZ20ggTnltfbFrU9wvTVBmynL4eznCA4c2AjrREk0v9 ORQz0GuQJfO2O4YUuVVIERWKrcciSm+DaQ93OyfJ1FX+MDSaJgnDPvIUPqnpqcCyCtcQBvYVrvNn OVhzQInUukIiVuVRMcsYVbwAQOlX+WlpXZw78LcUxREr6eFyfmx8eHEOC0EP7jTbOsY2qr/e4J3t VdgC0xqFqcmv46MxC4pVMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMYKpa6SIN woLGQXUgMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCC5XVTwG/icggtWXaTrXFOz PF/GVMJJVX715q8Fn1pUHjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA1MTExOTUyNTdaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEApkT3x8LH4FllibYMwolX7WsB4vYpfKSwliM2JgvJ xuqi4pwivXgjzGt+Y0JsHuqDJEml4FX4WfivhsHxeB3w3V8zotxjP+mMlD9pycVoAI0Q0CsFaHfH PZnJoMmpTo9tAKVc9G82q8k4BxcgoZqEMOUVYp/W9pQuHXdxebdWPVUHdtCpzWiLzN7aPYm1mlFf s0Cx6hJk0+mLErJb5acBkD0+UvKJUlnV3pNqNY8th66xpS6aGMG9o/UpoCCx0kqFBRSq4BQDaDLD uVDdkQ0pPkQj8I2gtjwOs4v+VrK6dJ5PLmFp6+SZhB20zjwyyVkSBtvUqZYS/4hVsQoouPRZuw== --0000000000008d36a2056bf37b85-- From nobody Fri May 11 15:40:58 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49760128954 for ; Fri, 11 May 2018 15:40:57 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 Z2DifiPfdE1C for ; Fri, 11 May 2018 15:40:55 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63FCA1241F5 for ; Fri, 11 May 2018 15:40:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3FD10300A07 for ; Fri, 11 May 2018 18:40:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ql2fk3D3XwiC for ; Fri, 11 May 2018 18:40:51 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 72F51300261; Fri, 11 May 2018 18:40:51 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <7D9784FF-6198-41D3-A40A-941C6E8A2205@vigilsec.com> Date: Fri, 11 May 2018 18:40:57 -0400 Cc: LAMPS To: Eric Rescorla X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lamps] LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 22:40:57 -0000 Eric: Please start the IESG process to expand the LAMPS WG charter. Russ = = = = = = = = = The PKIX and S/MIME Working Groups have been closed for some time. Some updates have been proposed to the X.509 certificate documents produced by the PKIX Working Group and the electronic mail security documents produced by the S/MIME Working Group. The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working Group is chartered to make updates where there is a known constituency interested in real deployment and there is at least one sufficiently well specified approach to the update so that the working group can sensibly evaluate whether to adopt a proposal. The LAMPS WG is now tackling these topics: 1. Specify a discovery mechanism for CAA records to replace the one described in RFC 6844. Implementation experience has demonstrated an ambiguity in the handling of CNAME and DNAME records during discovery in RFC 6844, and subsequent discussion has suggested that a different discovery approach would resolve limitations inherent in that approach. 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. Unlike the previous hashing standards, the SHA-3 family of functions are the outcome of an open competition. They have a clear design rationale and have received a lot of public analysis, giving great confidence that the SHA-3 family of functions are secure. Also, since SHA-3 uses a very different construction from SHA-2, the SHA-3 family of functions offers an excellent alternative. In particular, SHAKE128/256 and SHAKE256/512 offer security and performance benefits. 3. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information, as a result revoking them pointless. 4. Specify the use of a pre-shared key (PSK) along with other key management techniques with supported by the Cryptographic Message Syntax (CMS) as a near-term mechanism to protect present day communication from the future invention of a large-scale quantum computer. The invention of a such a quantum computer would pose a serious challenge for the key management algorithms that are widely deployed, especially the key transport and key agreement algorithms used today with the CMS to protect S/MIME messages. 5. Specify the use of hash-based signatures with the Cryptographic Message Syntax (CMS). A hash-based signature uses small private and public keys, and it has low computational cost; however, the signature values are quite large. For this reason they might not be used for signing X.509 certificates or S/MIME messages, but they are secure even if a large-scale quantum computer is invented. These properties make hash-based signatures useful in some environments, such a the distribution of software updates. 6. Specifies a certificate extension that is carried in a self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate, to identify the next public key that will be used by the trust anchor. In addition, the LAMPS WG may investigate other updates to documents produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt any of these potential work items without rechartering. MILESTONES Mar 2018: Adopt a draft for rfc6844bis Apr 2018: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512 Apr 2018: Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512 Jun 2018: Adopt a draft for short-lived certificate conventions Jun 2018: Adopt a draft for the CMS with PSK Jun 2018: Adopt a draft for hash-based signatures with the CMS Jun 2018: Adopt a draft for root key rollover certificate extension Jul 2018: rfc6844bis sent to IESG for standards track publication Aug 2018: Root key rollover certificate extension sent to IESG for informational publication Sep 2018: SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for standards track publication Sep 2018: SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for standards track publication Oct 2018: Short-lived certificate conventions sent to IESG for BCP publication Oct 2018: The CMS with PSK sent to IESG for standards track publication Dec 2018: Hash-based signatures with the CMS sent to IESG for standards track publication From nobody Mon May 14 09:37:41 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25989126C22 for ; Mon, 14 May 2018 09:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-7S5zIkV-Ur for ; Mon, 14 May 2018 09:37:32 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD78512DA04 for ; Mon, 14 May 2018 09:37:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 802F0300AC8 for ; Mon, 14 May 2018 12:37:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id V4z5rIWSvSsG for ; Mon, 14 May 2018 12:37:28 -0400 (EDT) Received: from new-host.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id AE17C300AC7; Mon, 14 May 2018 12:37:27 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CE3BEB20-BA89-44BD-A4FD-7BA157BE713F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 14 May 2018 12:37:28 -0400 In-Reply-To: <51B631EC-78B3-4FF4-A82C-725A029F3DB3@nohats.ca> Cc: Phillip Hallam-Baker , IETF , LAMPS To: Paul Wouters References: <51B631EC-78B3-4FF4-A82C-725A029F3DB3@nohats.ca> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] More mail madness? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 16:37:35 -0000 --Apple-Mail=_CE3BEB20-BA89-44BD-A4FD-7BA157BE713F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 14, 2018, at 12:35 PM, Paul Wouters wrote: >=20 >> On May 14, 2018, at 12:29, Russ Housley wrote: >>=20 >> We are working on text for S/MIME that says that each portion of a = MIME multi-part needs to be handled in its own sandbox. The direct = exfiltration that is described happens because the mail user agent glues = the various portions together for display to the user, which in the = example on the web page causes an image to be fetched from the = attacker's website with the message plaintext as part of the URL. >=20 > So that=E2=80=99s the bandaid. What and where will work be done on a = solution? LAMPS just sent an update to the S/MIME message document to the IESG. = My guess is that there will be discussion on the spasm@ietf.org = mail list. Russ --Apple-Mail=_CE3BEB20-BA89-44BD-A4FD-7BA157BE713F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On May 14, 2018, at 12:35 PM, Paul Wouters <paul@nohats.ca> = wrote:

On May 14, 2018, at 12:29, Russ Housley <housley@vigilsec.com> wrote:

We are working on text for S/MIME that says that each portion = of a MIME multi-part needs to be handled in its own sandbox.  The = direct exfiltration that is described happens because the mail user = agent glues the various portions together for display to the user, which = in the example on the web page causes an image to be fetched from the = attacker's website with the message plaintext as part of the URL.

So that=E2=80=99s the bandaid. = What and where will work be done on a solution?

LAMPS just = sent an update to the S/MIME message document to the IESG.  My = guess is that there will be discussion on the spasm@ietf.org mail = list.

Russ

= --Apple-Mail=_CE3BEB20-BA89-44BD-A4FD-7BA157BE713F-- From nobody Mon May 14 09:39:43 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AAB12DDD0 for ; Mon, 14 May 2018 09:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 XG4C58dFUcO4 for ; Mon, 14 May 2018 09:39:39 -0700 (PDT) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183F512DA04 for ; Mon, 14 May 2018 09:39:39 -0700 (PDT) Received: by mail-ot0-x233.google.com with SMTP id g7-v6so15027030otj.11 for ; Mon, 14 May 2018 09:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wjiXdsMOWPRpKvL1Wj2bBS8TmnxiFBgbGBx4nZiKj0s=; b=XK7B8wYT0Rw4FNBH8YNTqYaZml64NMfMOdEUP2G1osJpg9EYLRAYY8kwWXP5sJj7P0 xXiEYvMHPoBciDIRXGlnBr+K4Pc42oCqGTRWFr/tbRv3dLuvkpZsgibq2xuz4NFZnk+S 0ShWlpo7DzEA9vMpSVu3o5h+nnGz7ybaN0NPHTzycfrQJ7/BzrxAPzgfaD+nyPrePsR5 vPmdfqc/Ae1dw5xdz7IC7yyAL5rvE+tr519S/MPLCi7Utt7/OyFmvs2E75bhU9GRWg50 KEeIqdSmbsYW7+zXbF4x+PmEgfDTsDNhL0eaP18dIjMZq98r9GLD2UjLKhzQyToxWLyk 5hbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wjiXdsMOWPRpKvL1Wj2bBS8TmnxiFBgbGBx4nZiKj0s=; b=f24Iet18McbAK5YtYxEcV1mg/VBLLHpbcgnOd2iVXJOs7/8yxsWKQrmBo1S0WWTAxr IlsK8F9mdhMCRI99QLvvTSaIxFQUibBNYel4kQLKbm6KrddCUHiSDUgOn/uy2tT/oezs 4eMjLdOrC3PN5EDbpf/A8APeDAfWEa6zzBOtQbkqqt9+pM7TWpaIRTIiFzraQIvHRyLU htm/sChtpLY0Bh5n0Ws4+chwn5NyU7QymHtFtoMir/ctwqI3qjScji8F2taHI+sSmuZU EFv8vGGtov55MG9IyNx5Ovd8AExjmSv9L5a9bCfBo/ryTfAxG0gkfCVEBibCloWffzer Q8UA== X-Gm-Message-State: ALKqPwfQtzFNowcJJv6pSy3rolKofzx62rLdFkVV2faD94BXa8Dq82VX znnQ/QdPEYG6L60C5/Gl2cmZ4BgSjQOsQPiF4gdQPw== X-Google-Smtp-Source: AB8JxZoWa+7n6RtJ83wm13gbBTOw+4ue7K9U5snv7vk0gpGi2FDRiw6vSBX//wuQOaSWnu7I0Vst5JQWiEEKxfvn+6Q= X-Received: by 2002:a9d:4b8f:: with SMTP id k15-v6mr7959366otf.248.1526315978422; Mon, 14 May 2018 09:39:38 -0700 (PDT) MIME-Version: 1.0 References: <51B631EC-78B3-4FF4-A82C-725A029F3DB3@nohats.ca> In-Reply-To: From: Richard Barnes Date: Mon, 14 May 2018 12:39:27 -0400 Message-ID: To: Russ Housley Cc: Paul Wouters , spasm@ietf.org, Phillip Hallam-Baker , IETF Content-Type: multipart/alternative; boundary="000000000000b58b43056c2d2121" Archived-At: Subject: Re: [lamps] More mail madness? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 16:39:41 -0000 --000000000000b58b43056c2d2121 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Russ: Is there some more work to be done here to address the CBC/CFB issues? Even if the encapsulation has AEAD support, maybe there's some negotiation thingy? On Mon, May 14, 2018, 12:37 Russ Housley wrote: > > On May 14, 2018, at 12:35 PM, Paul Wouters wrote: > > On May 14, 2018, at 12:29, Russ Housley wrote: > > We are working on text for S/MIME that says that each portion of a MIME > multi-part needs to be handled in its own sandbox. The direct exfiltrati= on > that is described happens because the mail user agent glues the various > portions together for display to the user, which in the example on the we= b > page causes an image to be fetched from the attacker's website with the > message plaintext as part of the URL. > > > So that=E2=80=99s the bandaid. What and where will work be done on a solu= tion? > > > LAMPS just sent an update to the S/MIME message document to the IESG. My > guess is that there will be discussion on the spasm@ietf.org mail list. > > Russ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --000000000000b58b43056c2d2121 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Russ: Is there some more work to be done here to address = the CBC/CFB issues?=C2=A0 Even if the encapsulation has AEAD support, maybe= there's some negotiation thingy?

<= div dir=3D"ltr">On Mon, May 14, 2018, 12:37 Russ Housley <housley@vigilsec.com> wrote:

On May 14, 2018, at 12:35 PM, Paul Wouters <= paul= @nohats.ca> wrote:

On M= ay 14, 2018, at 12:29, Russ Housley <housley@vigilsec.com> wrot= e:

We are working on text for S/MIME that says that each portion of = a MIME multi-part needs to be handled in its own sandbox.=C2=A0 The direct = exfiltration that is described happens because the mail user agent glues th= e various portions together for display to the user, which in the example o= n the web page causes an image to be fetched from the attacker's websit= e with the message plaintext as part of the URL.

So tha= t=E2=80=99s the bandaid. What and where will work be done on a solution?

LAMPS just sent an update to the S= /MIME message document to the IESG.=C2=A0 My guess is that there will be di= scussion on the spasm@ietf.org=C2=A0mail list.

Rus= s

_______________________________________________=
Spasm mailing list
Spas= m@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--000000000000b58b43056c2d2121-- From nobody Mon May 14 10:04:08 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB1712E892; Mon, 14 May 2018 10:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 s23du-3lI66B; Mon, 14 May 2018 10:03:57 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 525221201F8; Mon, 14 May 2018 10:03:57 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id 11-v6so11339253ois.8; Mon, 14 May 2018 10:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=MMqTky4iy6USAaWGfsR34yk/PlHfoXq/Vtj1OdaPX4c=; b=ec+YvR36KNKrf/oe4q+yd5CC6tBOHaSGhIcrP2NSC+R2TODJ5x15DUm2CNP9qErrsj 6p+a+r4eTnnZ2eyF2hwHLCmdOeyvjlrdMEkE6I2FW7MRRcHkMO9eHZC0fjb9paU6FBmD OLE/yl8OoCv+WX2BHphPzkHFZibQio7ubDTc0+bu+r85WEH3RW/GxbNDv7NLoEfal0Df weoMwkFOEJinvNWYIrqsXO/LKIT071/3CTFqQZBhJvPFlSVWfF2F56Iu5LsBCASGSJVo n+hFX6+jaCDgTBteVrshme3ZvzbTsNMfOn64cZh+gcz8Fvz3v0WGbcxCO5Jtf5QV3+Po GruQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=MMqTky4iy6USAaWGfsR34yk/PlHfoXq/Vtj1OdaPX4c=; b=HRLprS3b/10YjQZOmy1VN6LhlGKTaMdd/6ANdiWGU7+socUELrgv2+Ux1xI7JvvD1W EsNuF2ldgURB37wBt+0Ra8XQlaMDTsHs37LXqsufcL9wKq8ygRjA86s+dUda7+5jijNu SBdxmj/khyUGG5Q89F1irdW22G23iBKnDAeaVgStrEl+CXrP4cYqHII1Jq/GLaxh/jGl 60SfoZn6VorJOCBqlbnV9zgB2otyT7hxU44RZT72jTVV1RP4k5W+tSibx5OvKGJ3VAQh MWGWiesgMi4pm0LMSEQZja6lrNtm6BE4rJoaQsQexDsCFS8nyJIyPHpkJeH/tNaJ1fcO oxog== X-Gm-Message-State: ALKqPwfCyJ8Hqy5uAm+kHMDUunQdbmgjhJ6LmD5eQhYlJx8rA6Asbor3 AUP5DyAiKfUepPOKNGHTqBR5BiNNxVM7hx0XZyw= X-Google-Smtp-Source: AB8JxZouqUW5e/LM56EUvsyzMRoIkbe8CQA4eXnopDQQcJmeEA6L7gZZ4O1iJ177fjbwlyJx+168Cadt0+yz8LhQFJc= X-Received: by 2002:aca:6257:: with SMTP id w84-v6mr7580830oib.26.1526317436589; Mon, 14 May 2018 10:03:56 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:23:0:0:0:0:0 with HTTP; Mon, 14 May 2018 10:03:56 -0700 (PDT) In-Reply-To: References: <51B631EC-78B3-4FF4-A82C-725A029F3DB3@nohats.ca> From: Phillip Hallam-Baker Date: Mon, 14 May 2018 13:03:56 -0400 X-Google-Sender-Auth: p_rLkffhtR7ogknL9uSEiJWLbb0 Message-ID: To: Richard Barnes Cc: Russ Housley , Paul Wouters , SPASM , IETF Content-Type: multipart/alternative; boundary="0000000000009f5de8056c2d7882" Archived-At: Subject: Re: [lamps] More mail madness? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 17:04:00 -0000 --0000000000009f5de8056c2d7882 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Here is the approach I use for encryption which guards against the IV attack. It might seem a little over the top but the objective here is to minimize the number of code paths rather than the length of the code path. The reason I started on this approach was I was looking for a secure way to encrypt chat room logs etc. without having to do a key exchange per message. In the process, I realized that the same approach works remarkably well in S/MIME like applications where we may have multiple multiparts that we want to encrypt under one key exchange, we may want to encrypt subject lines and we may want to encrypt signatures over the plaintext. 1) Generate fresh session key of at least 256 bits which has the property of being infeasible to guess (note that unguessability is a stronger requirement than merely being random). 2) Perform a key exchange for each recipient. 2a) If it is a DH or EDH key exchange, use the key exchange result as the IKM for a KeyDerivation function with info tag "master". Then use the resulting key to perform an AES Key Wrap of the session key. 3) Create the Enhanced Data Sequences. For each EDC we create a salt value which needs to be unique within the context of this particular exchange. We then use HKDF to derive the encryption (+MAC if needed) and IV. This approach ensures that the IV is chosen in a rigid fashion and thus eliminates a possible area of manipulation as any change to the salt will prevent decryption and authentication of the message as well. On Mon, May 14, 2018 at 12:39 PM, Richard Barnes wrote: > Russ: Is there some more work to be done here to address the CBC/CFB > issues? Even if the encapsulation has AEAD support, maybe there's some > negotiation thingy? > > On Mon, May 14, 2018, 12:37 Russ Housley wrote: > >> >> On May 14, 2018, at 12:35 PM, Paul Wouters wrote: >> >> On May 14, 2018, at 12:29, Russ Housley wrote: >> >> We are working on text for S/MIME that says that each portion of a MIME >> multi-part needs to be handled in its own sandbox. The direct exfiltrat= ion >> that is described happens because the mail user agent glues the various >> portions together for display to the user, which in the example on the w= eb >> page causes an image to be fetched from the attacker's website with the >> message plaintext as part of the URL. >> >> >> So that=E2=80=99s the bandaid. What and where will work be done on a sol= ution? >> >> >> LAMPS just sent an update to the S/MIME message document to the IESG. M= y >> guess is that there will be discussion on the spasm@ietf.org mail list. >> >> Russ >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >> > --0000000000009f5de8056c2d7882 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Her= e is the approach I use for encryption which guards against the IV attack. = It might seem a little over the top but the objective here is to minimize t= he number of code paths rather than the length of the code path.

The reason I started on this approa= ch was I was looking for a secure way to encrypt chat room logs etc. withou= t having to do a key exchange per message. In the process, I realized that = the same approach works remarkably well in S/MIME like applications where w= e may have multiple multiparts that we want to encrypt under one key exchan= ge, we may want to encrypt subject lines and we may want to encrypt signatu= res over the plaintext.

<= br>
1) Generate= fresh session key of at least 256 bits which has the property of being inf= easible to guess (note that unguessability is a stronger requirement than m= erely being random).

2) P= erform a key exchange for each recipient.=C2=A0

2a) If it is a DH or EDH key exchange, use the key e= xchange result as the IKM for a KeyDerivation function with info tag "= master". Then use the resulting key to perform an AES Key Wrap of the = session key.
3) Create th= e Enhanced Data Sequences.

For each EDC we create a salt value which needs to be unique within the c= ontext of this particular exchange.=C2=A0

We then use HKDF to derive the encryption (+MAC if needed)= and IV.


This approach ensures that= the IV is chosen in a rigid fashion and thus eliminates a possible area of= manipulation as any change to the salt will prevent decryption and authent= ication of the message as well.









On Mon, May 14, 2018 at 12:39 PM, Richard Barnes <rlb@ipv.sx> wrote:
Russ: Is t= here some more work to be done here to address the CBC/CFB issues?=C2=A0 Ev= en if the encapsulation has AEAD support, maybe there's some negotiatio= n thingy?

On Mon, May 14, 2018, 12:37 Russ Housley <housley@vigilsec.com> wrote:<= br>
=

On May 14, 2018, at 12:35 PM, Paul Wouters <paul@nohats.ca> wrote:

On May 14, 2018, at 12:29, Russ= Housley <housley@vigilsec.com> wrote:

We are working on= text for S/MIME that says that each portion of a MIME multi-part needs to = be handled in its own sandbox.=C2=A0 The direct exfiltration that is descri= bed happens because the mail user agent glues the various portions together= for display to the user, which in the example on the web page causes an im= age to be fetched from the attacker's website with the message plaintex= t as part of the URL.

So that=E2=80=99s the bandaid. Wh= at and where will work be done on a solution?
<= div>
LAMPS just sent an update to the S/MIME message document to t= he IESG.=C2=A0 My guess is that there will be discussion on the spasm@ietf.org<= /a>=C2=A0mail list.


_______________________________________________
Spasm mailing list
Spas= m@ietf.org
https://www.ietf.org/mailman/listinfo/spa= sm

--0000000000009f5de8056c2d7882-- From nobody Mon May 14 10:59:33 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95540127010 for ; Mon, 14 May 2018 10:59:31 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHTCTvJ4-O3B for ; Mon, 14 May 2018 10:59:29 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7272D124205 for ; Mon, 14 May 2018 10:59:28 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 14 May 2018 10:56:46 -0700 From: Jim Schaad To: 'Richard Barnes' , 'Russ Housley' CC: References: <51B631EC-78B3-4FF4-A82C-725A029F3DB3@nohats.ca> In-Reply-To: Date: Mon, 14 May 2018 10:59:21 -0700 Message-ID: <02dc01d3ebad$4ad7c2c0$e0874840$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02DD_01D3EB72.9E798700" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHXifDGlbG83KKWFTkmGgShLneaiwESY5zRAsJnOHIBkucuKwGTT/BHo/BuCBA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] More mail madness? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 17:59:31 -0000 ------=_NextPart_000_02DD_01D3EB72.9E798700 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I am not sure what can be done to address the CBC issue in S/MIME (CFB = would be PGP). We can say don=E2=80=99t use it, use and AEAD algorithm = but not sure what else can be said. =20 The negotiation thingy is already present as you list the set of = algorithms you support (with modes) and thus if you advertise AES-GCM = then you are going to support AEAD algorithms and if everybody does so = then the message can be sent using that algorithm =20 From: Spasm On Behalf Of Richard Barnes Sent: Monday, May 14, 2018 9:39 AM To: Russ Housley Cc: spasm@ietf.org; Paul Wouters ; Phillip Hallam-Baker = ; IETF Subject: Re: [lamps] More mail madness? =20 Russ: Is there some more work to be done here to address the CBC/CFB = issues? Even if the encapsulation has AEAD support, maybe there's some = negotiation thingy? =20 On Mon, May 14, 2018, 12:37 Russ Housley > wrote: =20 On May 14, 2018, at 12:35 PM, Paul Wouters > wrote: On May 14, 2018, at 12:29, Russ Housley > wrote: We are working on text for S/MIME that says that each portion of a MIME = multi-part needs to be handled in its own sandbox. The direct = exfiltration that is described happens because the mail user agent glues = the various portions together for display to the user, which in the = example on the web page causes an image to be fetched from the = attacker's website with the message plaintext as part of the URL. So that=E2=80=99s the bandaid. What and where will work be done on a = solution? =20 LAMPS just sent an update to the S/MIME message document to the IESG. = My guess is that there will be discussion on the spasm@ietf.org = mail list. =20 Russ =20 _______________________________________________ Spasm mailing list Spasm@ietf.org =20 https://www.ietf.org/mailman/listinfo/spasm ------=_NextPart_000_02DD_01D3EB72.9E798700 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I am not = sure what can be done to address the CBC issue in S/MIME (CFB would be = PGP).=C2=A0 We can say don=E2=80=99t use it, use and AEAD algorithm but = not sure what else can be said.

 

The = negotiation thingy is already present as you list the set of algorithms = you support (with modes) and thus if you advertise AES-GCM then you are = going to support AEAD algorithms and if everybody does so then the = message can be sent using that algorithm

 

From: Spasm = <spasm-bounces@ietf.org> On Behalf Of Richard = Barnes
Sent: Monday, May 14, 2018 9:39 AM
To: Russ = Housley <housley@vigilsec.com>
Cc: spasm@ietf.org; Paul = Wouters <paul@nohats.ca>; Phillip Hallam-Baker = <phill@hallambaker.com>; IETF = <ietf@ietf.org>
Subject: Re: [lamps] More mail = madness?

 

Russ: = Is there some more work to be done here to address the CBC/CFB = issues?  Even if the encapsulation has AEAD support, maybe there's = some negotiation thingy?

 

On = Mon, May 14, 2018, 12:37 Russ Housley <housley@vigilsec.com> = wrote:

 

On May 14, 2018, at 12:35 PM, Paul Wouters <paul@nohats.ca> = wrote:



On = May 14, 2018, at 12:29, Russ Housley <housley@vigilsec.com> wrote:

We are = working on text for S/MIME that says that each portion of a MIME = multi-part needs to be handled in its own sandbox.  The direct = exfiltration that is described happens because the mail user agent glues = the various portions together for display to the user, which in the = example on the web page causes an image to be fetched from the = attacker's website with the message plaintext as part of the = URL.


So = that=E2=80=99s the bandaid. What and where will work be done on a = solution?

 

LAMPS = just sent an update to the S/MIME message document to the IESG.  My = guess is that there will be discussion on the spasm@ietf.org mail = list.

 

Russ

 

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

------=_NextPart_000_02DD_01D3EB72.9E798700-- From nobody Tue May 15 18:00:30 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA7E12EB2C for ; Tue, 15 May 2018 18:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoZ5J-tai1iu for ; Tue, 15 May 2018 18:00:26 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2926126DEE for ; Tue, 15 May 2018 18:00:25 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id m5-v6so2955279qti.1 for ; Tue, 15 May 2018 18:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=TTI68kUcMMGSdxxQWnIfLbqjKDzydxtrHBEyoDipFOA=; b=DiOM/GjUYpTT37HlMdVcuBzdPXbHjkogdXf9D8CN6JbAsoZJABzP4WHTghq7Pl7T5q tJwi/OHYRBvygDywd8P3SOdl8aRa7iQFkwrw2nFQBEFVrtf5G5YyCYObwv42Kq3XojN9 0vA0HMWKwwUHc8nLvV+fl+lERdwyU+wTDnqI4X260s26d/dsC6WP9xWLMMIc1qFF6Y/R qtYyoII4zEp3SJJwdXultUYAZlLlbm5FxfnBJVhSSctZhnGIA2HwfZigR+UYgq234gue QhlveAqqTOLnce8hK6IYulVxgMYhIhWAWCfGcADqbtoldX9nBAVEwGoyYv8zxYNobSI4 2O1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TTI68kUcMMGSdxxQWnIfLbqjKDzydxtrHBEyoDipFOA=; b=kz2hKASXmlttVoal9glc3xL3SNsTTrJcP+3Mm1CHX62yUhLhWEE8K8ITCnZB6xDgXe uiWkL+0ynqfxA9cAXngwWi6SUcD5N8ud3Wsmvr7Zx/DXfjsI2HV76xBq5HPcBHF4JHzQ LlVYnhh8vEw4xL7+aZKfXbSeXj7WAFLa3L5Yfns1VsEYK9EGKVuJaip43glsC4S2uLqK Wtv2R6uju78CoNancyIcaSUxn1kO51TdIpnlsQgol77Z97OZVF1MpepvStewfaZMXHfX N0hwQ48Www+jBZL4p1uak0HnzbR2s/uBEIuNybgIWncgI4sjNBLwpP7cyUNCcOgDrLW4 9S2Q== X-Gm-Message-State: ALKqPwdrQr7PD1gnv0Li3q67ZsX8ku3N3ywWBoVYrG1itHgiKqHnt9Lt W12wyYd7wyEGu2W7ytygsr5K42TxT7r0dZn+M6hhTQ== X-Google-Smtp-Source: AB8JxZr17tfK9P5tP8JX709z7WILE8VjOkzyR0pbEgidaRNOlPzQxOLs/udD/LMbTthWNP5JEn7ibPwLrSqWmH4OxxA= X-Received: by 2002:a0c:adfb:: with SMTP id x56-v6mr15840140qvc.198.1526432423927; Tue, 15 May 2018 18:00:23 -0700 (PDT) MIME-Version: 1.0 From: Wayne Thayer Date: Wed, 16 May 2018 01:00:11 +0000 Message-ID: To: spasm@ietf.org Content-Type: multipart/alternative; boundary="00000000000066e579056c483e60" Archived-At: Subject: [lamps] CAA Semantics for S/MIME X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 01:00:28 -0000 --00000000000066e579056c483e60 Content-Type: text/plain; charset="UTF-8" There is a vigorous discussion about CAA and S/MIME certificates happening over on the mozilla.dev.security.policy list [1]. It has been proposed that this issue could be addressed as part of rfc6844bis, but I'm reading the LAMPS recharter as being too narrow in scope to permit this. Does this work need to be deferred to a future LAMPS recharter? - Wayne [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/NIc2Nwa9Msg/RGx4A5HBBAAJ --00000000000066e579056c483e60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is a vigorous discussion about CAA and S/MIME c= ertificates happening over on the mozilla.dev.security.policy list [1]. It = has been proposed that this issue could be addressed as part of rfc6844bis,= but I'm reading the LAMPS recharter as being too narrow in scope to pe= rmit this. Does this work need to be deferred to a future LAMPS recharter?<= br>
- Wayne
--00000000000066e579056c483e60-- From nobody Tue May 15 18:23:56 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20465126DEE for ; Tue, 15 May 2018 18:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGHRHf4E5bd5 for ; Tue, 15 May 2018 18:23:53 -0700 (PDT) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::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 54246126CD6 for ; Tue, 15 May 2018 18:23:53 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id y10-v6so2492233otg.10 for ; Tue, 15 May 2018 18:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ymOhnk1r6I0nli5ljt5SdmE9MErcSl8gd/kBH1BrdHs=; b=hvGcid9OVFSo5ZNxUj69MaOTkEXBI4RBmXhUWjWeYaWQt1hGiDyrCKNHe86dlEYbKL N5Z0CqudWRIE/rogCUJ5iDD6FL4gQ0NKXnlxHWrUMkfxTH5gaPUUAKgb0PNFRb/XndQt MB9elejLzWenmK48UgA40snodoP8Dsp4DdRWyYYJ9U/hLtAdLx2wZn+sZmoMHYZJL5gj 6oiA36VXsFlf5ckYYXbdBkypV/DQJ4kiyll92hI/XPDzU3LTWaGwVqn6aV0kRFLWAOPo iypG8IwYQXKCxy7pbBMgbW2a8s09IkWMNfgGAEk0pgKg29jpciEXBLnPETun39Qmb95r o9xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ymOhnk1r6I0nli5ljt5SdmE9MErcSl8gd/kBH1BrdHs=; b=mTQz4sqIfK5AuqnYHOnV5UwYTjtnHGtwcXgpjdgro95AONMJe01bdLzW5cc9YvJ5BM nsz1IhSf9nfEY1n/vxfm1hmhmTwvkTD749KpgfUkPptfSKUodBtiqE3vUe3MQCZc0Kaa gzylR9Qrt7b/DVmqNcnZ71ji794+TOpjRYmTpw1hSCHt5yTS27I8tpbgOXtLaju7Yp/O RTNJ6a14DvKpKRiskDhnNyeCt0mwwgzAwcDsq317xzm77InbClHqSckyY6Z5Xoef9to4 Jw18yqfXI4+Memfbbn/yby2PTrez9JenWkjaznTvYE6CRvOS62/BA+snx/ZY+4IW9oMm PBpw== X-Gm-Message-State: ALKqPwe9AH8Mjfi7GiA3v2tfVi/TjQVF1UrKmX25JxUcQvGNsnxwTKqS wWUfHkui3YRDFXzp5nAnceGdPcftDtI/SXaNkuA= X-Google-Smtp-Source: AB8JxZrkLnk6LfFLCJ6NhpXnsbx4to2PrCxAxoXYThV1vXBV7fHs/FZKZpG0sfMpQDY/gHkqytsC5yB+Mg55hM8QgMQ= X-Received: by 2002:a9d:14b9:: with SMTP id d54-v6mr13079108ote.380.1526433832751; Tue, 15 May 2018 18:23:52 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:23:0:0:0:0:0 with HTTP; Tue, 15 May 2018 18:23:52 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Tue, 15 May 2018 21:23:52 -0400 X-Google-Sender-Auth: _wbC5QzPQ6TIQNhrETCVkjB0sG8 Message-ID: To: Wayne Thayer Cc: SPASM Content-Type: multipart/alternative; boundary="0000000000005fd7e9056c48923b" Archived-At: Subject: Re: [lamps] CAA Semantics for S/MIME X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 01:23:55 -0000 --0000000000005fd7e9056c48923b Content-Type: text/plain; charset="UTF-8" I think the work would need to be deferred because it will take us a little while to work out what to do.... But I have changed my mind on this. There is definitely a role for CAA in client cert issue. I would strongly recommend a different tag but there is certainly a role there. On Tue, May 15, 2018 at 9:00 PM, Wayne Thayer wrote: > There is a vigorous discussion about CAA and S/MIME certificates happening > over on the mozilla.dev.security.policy list [1]. It has been proposed that > this issue could be addressed as part of rfc6844bis, but I'm reading the > LAMPS recharter as being too narrow in scope to permit this. Does this work > need to be deferred to a future LAMPS recharter? > > - Wayne > > [1] https://groups.google.com/d/msg/mozilla.dev.security. > policy/NIc2Nwa9Msg/RGx4A5HBBAAJ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > --0000000000005fd7e9056c48923b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I t= hink the work would need to be deferred because it will take us a little wh= ile to work out what to do....

But I have changed my mind on this. There is definitely a role for CA= A in client cert issue. I would strongly recommend a different tag but ther= e is certainly a role there.



On Tue, May 15, 2018 at 9:00 PM, Wayne Thayer <wthayer@gmail.com>= ; wrote:
The= re is a vigorous discussion about CAA and S/MIME certificates happening ove= r on the mozilla.dev.security.policy list [1]. It has been proposed that th= is issue could be addressed as part of rfc6844bis, but I'm reading the = LAMPS recharter as being too narrow in scope to permit this. Does this work= need to be deferred to a future LAMPS recharter?

- Wayne
<= div>
[1] https://groups.google.c= om/d/msg/mozilla.dev.security.policy/NIc2Nwa9Msg/RGx4A5HBBAA= J

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


--0000000000005fd7e9056c48923b-- From nobody Wed May 16 07:29:18 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881AE12DA08 for ; Wed, 16 May 2018 07:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 sACGJjixHNVy for ; Wed, 16 May 2018 07:29:04 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B01B412EA42 for ; Wed, 16 May 2018 07:29:01 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id c203-v6so883559oib.7 for ; Wed, 16 May 2018 07:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=NQX7NoojQOP3zEhrvE6+BO/LfDzY/NxX7Qc9Up0cW+o=; b=Mudas6t8KjcAW6mkySs+AhfNUPN0nQiNiSRq+DpjmGFOfh+jDEm3Rjpm/tLbceiJZe ISkSkf6TSrj9F34dvY4r2uKMpW0RpnMFn0m8qCYcE7oFFk5Wlyl1qbdEWoIBZHbPZgoG /VOFMz2OVGJqnt9JYEbjG614I0zPbmS907dcBbXTHBLJhsTOeQleFtBvarZ/9CTh1EPZ tq1nDb6EDJg4vBUUo0oPxgsCBYJiMYpDiBFg/9Pq7sMIKjUZbW3JoHJRBph3g+4MhW+9 PP9uOOCkyPImcFzn02ZrfA/CI3tLJsHlphesENpq/vWsF1EhBCOw4qBU3/rFup+rr8dM 6riw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=NQX7NoojQOP3zEhrvE6+BO/LfDzY/NxX7Qc9Up0cW+o=; b=PwK9AP94BFxE9ENwAi9K+0KLtFE59C9Dw86OsgVoXXNAJIClT715mf2T5O9pq5+sZj VR0WI417/86fAfOkkO+wsnJ4+yU+Y3jcteiWt6RimiUYn8PovJ/TLLAeyoIF62vd0VHg QkuEI+9eMOJcVNtOHTYr363I+3c/wONIcynUehOrJEAmJFLkG+4ykOaJWshnlnihkzji es+5XZVUXoHnEwqjuRg/o9NHFZYbgNvnVxalUzDcEhJkuxpMMlAwhbYphJP0px9AoqT9 kirRH4VJWTJxGBQsF4SSCd+c+8409R28XVcdT/oi/VL7f0Wq/bv6yAVsbuSxZzNbLHzC 9Sxw== X-Gm-Message-State: ALKqPweu8ZcsBmsAFDIxwcZg7gS/3/5q9DtZiAb5JoaJ8Sys5sAS2hhp 3WGHyD7PovLih2BKOQxSrmBLOwC0cdLyHihW57g= X-Google-Smtp-Source: AB8JxZrns9a+lPb4hMSqN3D0KGDSDD4qxLyNE+kPJvHeKqIsra8UMY13XSNdt8YxlqkqKs5H2OzJwFeRuBuY105wkXc= X-Received: by 2002:aca:75cc:: with SMTP id q195-v6mr671367oic.319.1526480940696; Wed, 16 May 2018 07:29:00 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:23:0:0:0:0:0 with HTTP; Wed, 16 May 2018 07:28:59 -0700 (PDT) From: Phillip Hallam-Baker Date: Wed, 16 May 2018 10:28:59 -0400 X-Google-Sender-Auth: RH-e6t09vITQvAdGMN9UcJAGFU4 Message-ID: To: SPASM Content-Type: multipart/alternative; boundary="0000000000003a0a45056c538a7c" Archived-At: Subject: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 14:29:17 -0000 --0000000000003a0a45056c538a7c Content-Type: text/plain; charset="UTF-8" Looking at eFail, surely the simplest fix is to require that an HTML message body be presented in a single CMS envelope presented in a single MIME part? This would simplify the code substantially. While it is conceivable someone has worked out a way to make use of this mis-feature, I for one cannot imagine why Outlook, Thunderbird or the like would ever do anything of the sort. Separately, we have interest in CAA for S/MIME. Surely we should do ACME for S/MIME as well. If we are going to do that, surely we should have a discussion of what it would take to make end to end security the default for SMTP. I am not necessarily thinking of this as a LAMPS thing because we also need to get CAs, probably CABForum involved and maybe the OpenPGP folk. The model we have right now is that we have a lot of different camps offering technology. Some of that technology meets the needs of a particular community. What we do not have is a general solution or a mass deployment strategy. And this is really important because email security breaches have changed the course of history in the past few months. --0000000000003a0a45056c538a7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Loo= king at eFail, surely the simplest fix is to require that an HTML message b= ody be presented in a single CMS envelope presented in a single MIME part?<= /div>

This would simplify the c= ode substantially. While it is conceivable someone has worked out a way to = make use of this mis-feature, I for one cannot imagine why Outlook, Thunder= bird or the like would ever do anything of the sort.


Separately, we have interest in CAA for S/MIME. Surely we= should do ACME for S/MIME as well. If we are going to do that, surely we s= hould have a discussion of what it would take to make end to end security t= he default for SMTP.

I am= not necessarily thinking of this as a LAMPS thing because we also need to = get CAs, probably CABForum involved and maybe the OpenPGP folk.


The model we have right now is that we have a = lot of different camps offering technology. Some of that technology meets t= he needs of a particular community. What we do not have is a general soluti= on or a mass deployment strategy.

And this is really important because email security breaches hav= e changed the course of history in the past few months.
--0000000000003a0a45056c538a7c-- From nobody Wed May 16 07:49:15 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0246C12D7E8 for ; Wed, 16 May 2018 07:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 j3R0R99_TISe for ; Wed, 16 May 2018 07:49:12 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id CFCAC127078 for ; Wed, 16 May 2018 07:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1526482151; d=isode.com; s=june2016; i=@isode.com; bh=hvY8Alz7O9PvIElQ01+9slORD56vsK4s/iuTnEQJD+o=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=SShxBUD8K68WHj1REnUlas4lwZeGrubT4nTxKGK4FsLFe+qIwJN6nyEh2rToZhHJux6p2S SMQ9A0VRodtzWkCcucTcux8lXjC75BZ/+CZ7VlkZ22fOyG41Y+4XTvRbhrRS2VX0VQCNVQ rEiYGd8kdXQYBKcsGzRdS4zSdqJrkpQ=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 16 May 2018 15:49:11 +0100 To: Phillip Hallam-Baker , SPASM References: From: Alexey Melnikov Message-ID: <559ab3c7-ee5f-22b9-ef02-c091765011d2@isode.com> Date: Wed, 16 May 2018 15:48:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------FEB60CAF51A444A2821E9D55" Content-Language: en-GB Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 14:49:14 -0000 This is a multi-part message in MIME format. --------------FEB60CAF51A444A2821E9D55 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Philip, On 16/05/2018 15:28, Phillip Hallam-Baker wrote: > Looking at eFail, surely the simplest fix is to require that an HTML > message body be presented in a single CMS envelope presented in a > single MIME part? I am not sure what you mean here. A CMS envelope can contain multipart/mixed within it, which is a perfectly valid use case (i.e. if one wants to send some encrypted text together with some encrypted attachments). If you are talking about preventing the following construct: content-type: multipart/mixed; boundary=.f8231d7f-681b-442c-97cc-e6c5375d059d This is a multipart message in MIME format. --.f8231d7f-681b-442c-97cc-e6c5375d059d content-type: text/html ...some partial HTML... --.f8231d7f-681b-442c-97cc-e6c5375d059d content-disposition: inline; filename=smime.p7m Content-Transfer-Encoding: base64 content-type: application/pkcs7-mime; name=smime.p7m; smime-type=enveloped-data ...encrypted HTML... --.f8231d7f-681b-442c-97cc-e6c5375d059d content-type: text/html ...some partial HTML... --.f8231d7f-681b-442c-97cc-e6c5375d059d-- i.e. a multipart/mixed that contains a mixture of text/html and application/pkcs7-mime, then I might agree with you. But this is not really an S/MIME feature, it is a generic MIME feature. So maybe this WG should write a document on best S/MIME implementation practices. > This would simplify the code substantially. While it is conceivable > someone has worked out a way to make use of this mis-feature, I for > one cannot imagine why Outlook, Thunderbird or the like would ever do > anything of the sort. > > > Separately, we have interest in CAA for S/MIME. Surely we should do > ACME for S/MIME as well. Not surprisingly, I agree. See draft-ietf-acme-email-smime-02 > If we are going to do that, surely we should have a discussion of what > it would take to make end to end security the default for SMTP. > > I am not necessarily thinking of this as a LAMPS thing because we also > need to get CAs, probably CABForum involved and maybe the OpenPGP folk. Best Regards, Alexey --------------FEB60CAF51A444A2821E9D55 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi Philip,

On 16/05/2018 15:28, Phillip Hallam-Baker wrote:
Looking at eFail, surely the simplest fix is to require that an HTML message body be presented in a single CMS envelope presented in a single MIME part?

I am not sure what you mean here. A CMS envelope can contain multipart/mixed within it, which is a perfectly valid use case (i.e. if one wants to send some encrypted text together with some encrypted attachments).
If you are talking about preventing the following construct:


content-type: multipart/mixed; boundary=.f8231d7f-681b-442c-97cc-e6c5375d059d

This is a multipart message in MIME format. 
--.f8231d7f-681b-442c-97cc-e6c5375d059d
content-type: text/html

...some partial HTML...
--.f8231d7f-681b-442c-97cc-e6c5375d059d
content-disposition: inline; filename=smime.p7m
Content-Transfer-Encoding: base64
content-type: application/pkcs7-mime; name=smime.p7m; smime-type=enveloped-data

...encrypted HTML...
--.f8231d7f-681b-442c-97cc-e6c5375d059d
content-type: text/html

...some partial HTML...
--.f8231d7f-681b-442c-97cc-e6c5375d059d--

i.e. a multipart/mixed that contains a mixture of text/html and application/pkcs7-mime, then I might agree with you. But this is not really an S/MIME feature, it is a generic MIME feature. So maybe this WG should write a document on best S/MIME implementation practices.

This would simplify the code substantially. While it is conceivable someone has worked out a way to make use of this mis-feature, I for one cannot imagine why Outlook, Thunderbird or the like would ever do anything of the sort.


Separately, we have interest in CAA for S/MIME. Surely we should do ACME for S/MIME as well.

Not surprisingly, I agree. See draft-ietf-acme-email-smime-02
If we are going to do that, surely we should have a discussion of what it would take to make end to end security the default for SMTP.

I am not necessarily thinking of this as a LAMPS thing because we also need to get CAs, probably CABForum involved and maybe the OpenPGP folk.

Best Regards,
Alexey

--------------FEB60CAF51A444A2821E9D55-- From nobody Wed May 16 07:54:15 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30F412DA13 for ; Wed, 16 May 2018 07:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 7GAbqiPWrzIx for ; Wed, 16 May 2018 07:53:56 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 76A8712E8CC for ; Wed, 16 May 2018 07:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1526482435; d=isode.com; s=june2016; i=@isode.com; bh=rJRJJj6Ugc/ruWjzKwvOc6qqK1J9khFTFYAHOdY5fVc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=pR2ZCoMurYuVRCYZHxQUe7dM6rZKIubzTmGO69mq4QNOJbMxZM50j0bojJMFlXD6lqlhgN QX7BdR8hYPohZ4WvG6n1Dv8QqQPmjpksLT4sg+21W21fqW/koC16uInMahXa6ue4x+8MYO GHx/ga7UufquyBijMjhRWjBalHkgLI0=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 16 May 2018 15:53:55 +0100 From: Alexey Melnikov To: Phillip Hallam-Baker , SPASM References: <559ab3c7-ee5f-22b9-ef02-c091765011d2@isode.com> Message-ID: <1cf69c7f-9497-f816-3117-68a7be18767d@isode.com> Date: Wed, 16 May 2018 15:53:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 In-Reply-To: <559ab3c7-ee5f-22b9-ef02-c091765011d2@isode.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A84341CFB3A537F8303B9F03" Content-Language: en-GB Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 14:54:09 -0000 This is a multi-part message in MIME format. --------------A84341CFB3A537F8303B9F03 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 16/05/2018 15:48, Alexey Melnikov wrote: > Hi Philip, > > On 16/05/2018 15:28, Phillip Hallam-Baker wrote: >> Looking at eFail, surely the simplest fix is to require that an HTML >> message body be presented in a single CMS envelope presented in a >> single MIME part? > > I am not sure what you mean here. A CMS envelope can contain > multipart/mixed within it, which is a perfectly valid use case (i.e. > if one wants to send some encrypted text together with some encrypted > attachments). > If you are talking about preventing the following construct: > > > content-type: multipart/mixed; > boundary=.f8231d7f-681b-442c-97cc-e6c5375d059d > > This is a multipart message in MIME format. > --.f8231d7f-681b-442c-97cc-e6c5375d059d > content-type: text/html > > ...some partial HTML... > --.f8231d7f-681b-442c-97cc-e6c5375d059d > content-disposition: inline; filename=smime.p7m > Content-Transfer-Encoding: base64 > content-type: application/pkcs7-mime; name=smime.p7m; smime-type=enveloped-data > > ...encrypted HTML... > --.f8231d7f-681b-442c-97cc-e6c5375d059d > content-type: text/html > > ...some partial HTML... > --.f8231d7f-681b-442c-97cc-e6c5375d059d-- > > i.e. a multipart/mixed that contains a mixture of text/html and > application/pkcs7-mime, then I might agree with you. Implementations that can validate HTML should check that each body part contains valid HTML. So if it detects partial HTML, it should reject displaying it or concatenating it into a single HTML object that might end up syntactically valid. > But this is not really an S/MIME feature, it is a generic MIME > feature. So maybe this WG should write a document on best S/MIME > implementation practices. --------------A84341CFB3A537F8303B9F03 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

On 16/05/2018 15:48, Alexey Melnikov wrote:

Hi Philip,

On 16/05/2018 15:28, Phillip Hallam-Baker wrote:
Looking at eFail, surely the simplest fix is to require that an HTML message body be presented in a single CMS envelope presented in a single MIME part?

I am not sure what you mean here. A CMS envelope can contain multipart/mixed within it, which is a perfectly valid use case (i.e. if one wants to send some encrypted text together with some encrypted attachments).
If you are talking about preventing the following construct:


content-type: multipart/mixed; boundary=.f8231d7f-681b-442c-97cc-e6c5375d059d

This is a multipart message in MIME format. 
--.f8231d7f-681b-442c-97cc-e6c5375d059d
content-type: text/html

...some partial HTML...
--.f8231d7f-681b-442c-97cc-e6c5375d059d
content-disposition: inline; filename=smime.p7m
Content-Transfer-Encoding: base64
content-type: application/pkcs7-mime; name=smime.p7m; smime-type=enveloped-data

...encrypted HTML...
--.f8231d7f-681b-442c-97cc-e6c5375d059d
content-type: text/html

...some partial HTML...
--.f8231d7f-681b-442c-97cc-e6c5375d059d--

i.e. a multipart/mixed that contains a mixture of text/html and application/pkcs7-mime, then I might agree with you.
Implementations that can validate HTML should check that each body part contains valid HTML. So if it detects partial HTML, it should reject displaying it or concatenating it into a single HTML object that might end up syntactically valid.

But this is not really an S/MIME feature, it is a generic MIME feature. So maybe this WG should write a document on best S/MIME implementation practices.

--------------A84341CFB3A537F8303B9F03-- From nobody Wed May 16 10:36:34 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8687712D96D for ; Wed, 16 May 2018 10:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 rGOMtklmQi8H for ; Wed, 16 May 2018 10:36:29 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17B7F12D95B for ; Wed, 16 May 2018 10:36:29 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 16 May 2018 10:33:23 -0700 From: Jim Schaad To: 'Alexey Melnikov' , 'Phillip Hallam-Baker' , 'SPASM' References: <559ab3c7-ee5f-22b9-ef02-c091765011d2@isode.com> In-Reply-To: <559ab3c7-ee5f-22b9-ef02-c091765011d2@isode.com> Date: Wed, 16 May 2018 10:35:59 -0700 Message-ID: <04ca01d3ed3c$5c158050$144080f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04CB_01D3ED01.AFB7B9C0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG9wg/QzC0+NttcLYwxpzBnDU/XXAKqIHHopEmjJHA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 17:36:33 -0000 ------=_NextPart_000_04CB_01D3ED01.AFB7B9C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I will note that unless multipart/mixed has some special text associated = with it. Text/html is defined by RFC 1866 to only hold a single HTML = document. Thus building an HTML document from multiple parts is not = according to Hoyle. =20 Jim =20 =20 From: Spasm On Behalf Of Alexey Melnikov Sent: Wednesday, May 16, 2018 7:49 AM To: Phillip Hallam-Baker ; SPASM Subject: Re: [lamps] S/MIME fix =20 Hi Philip, On 16/05/2018 15:28, Phillip Hallam-Baker wrote: Looking at eFail, surely the simplest fix is to require that an HTML = message body be presented in a single CMS envelope presented in a single = MIME part? I am not sure what you mean here. A CMS envelope can contain = multipart/mixed within it, which is a perfectly valid use case (i.e. if = one wants to send some encrypted text together with some encrypted = attachments). If you are talking about preventing the following construct: content-type: multipart/mixed; = boundary=3D.f8231d7f-681b-442c-97cc-e6c5375d059d This is a multipart message in MIME format.=20 --.f8231d7f-681b-442c-97cc-e6c5375d059d content-type: text/html =20 ....some partial HTML... --.f8231d7f-681b-442c-97cc-e6c5375d059d content-disposition: inline; filename=3Dsmime.p7m Content-Transfer-Encoding: base64 content-type: application/pkcs7-mime; name=3Dsmime.p7m; = smime-type=3Denveloped-data =20 ....encrypted HTML... --.f8231d7f-681b-442c-97cc-e6c5375d059d content-type: text/html =20 ....some partial HTML... --.f8231d7f-681b-442c-97cc-e6c5375d059d-- i.e. a multipart/mixed that contains a mixture of text/html and = application/pkcs7-mime, then I might agree with you. But this is not = really an S/MIME feature, it is a generic MIME feature. So maybe this WG = should write a document on best S/MIME implementation practices. This would simplify the code substantially. While it is conceivable = someone has worked out a way to make use of this mis-feature, I for one = cannot imagine why Outlook, Thunderbird or the like would ever do = anything of the sort. =20 =20 Separately, we have interest in CAA for S/MIME. Surely we should do ACME = for S/MIME as well. Not surprisingly, I agree. See draft-ietf-acme-email-smime-02=20 If we are going to do that, surely we should have a discussion of what = it would take to make end to end security the default for SMTP. =20 I am not necessarily thinking of this as a LAMPS thing because we also = need to get CAs, probably CABForum involved and maybe the OpenPGP folk. Best Regards, Alexey ------=_NextPart_000_04CB_01D3ED01.AFB7B9C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I will note that unless multipart/mixed has = some special text associated with it.=C2=A0 Text/html is defined by = RFC 1866 to only hold a single HTML document.=C2=A0 Thus building = an HTML document from multiple parts is not according to = Hoyle.

 

Jim

 

 

From: Spasm <spasm-bounces@ietf.org> On = Behalf Of Alexey Melnikov
Sent: Wednesday, May 16, 2018 = 7:49 AM
To: Phillip Hallam-Baker = <phill@hallambaker.com>; SPASM = <SPASM@ietf.org>
Subject: Re: [lamps] S/MIME = fix

 

Hi = Philip,

On 16/05/2018 15:28, = Phillip Hallam-Baker wrote:

Looking at eFail, = surely the simplest fix is to require that an HTML message body be = presented in a single CMS envelope presented in a single MIME = part?


I am not sure what you mean here. A CMS envelope = can contain multipart/mixed within it, which is a perfectly valid use = case (i.e. if one wants to send some encrypted text together with some = encrypted attachments).
If you are talking about preventing the = following construct:


content-type: multipart/mixed; = boundary=3D.f8231d7f-681b-442c-97cc-e6c5375d059d

This is a = multipart message in MIME format. = 

--.f8231d7f-681b-442c-97cc-e6c5375d059d
content-type: =
text/html
 
....some =
partial =
HTML...
--.f8231d7f-681b-442c-97cc-e6c5375d059d=

content-disposition: inline; =
filename=3Dsmime.p7m
Content-Transfer-Encoding: =
base64
content-type: application/pkcs7-mime; =
name=3Dsmime.p7m; =
smime-type=3Denveloped-data
 
<=
pre>....encrypted =
HTML...
--.f8231d7f-681b-442c-97cc-e6c5375d059d=

content-type: =
text/html
 
....some =
partial =
HTML...
--.f8231d7f-681b-442c-97cc-e6c5375d059d--


i.e. a multipart/mixed that = contains a mixture of text/html and application/pkcs7-mime, then I might = agree with you. But this is not really an S/MIME feature, it is a = generic MIME feature. So maybe this WG should write a document on best = S/MIME implementation practices.


This would simplify = the code substantially. While it is conceivable someone has worked out a = way to make use of this mis-feature, I for one cannot imagine why = Outlook, Thunderbird or the like would ever do anything of the = sort.

 

 

Separately, we have = interest in CAA for S/MIME. Surely we should do ACME for S/MIME as = well.


Not surprisingly, I agree. See = draft-ietf-acme-email-smime-02

If we are going to do = that, surely we should have a discussion of what it would take to make = end to end security the default for = SMTP.

 

I am not necessarily = thinking of this as a LAMPS thing because we also need to get CAs, = probably CABForum involved and maybe the OpenPGP = folk.


Best = Regards,
Alexey

------=_NextPart_000_04CB_01D3ED01.AFB7B9C0-- From nobody Wed May 16 10:45:11 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5CD412D95C for ; Wed, 16 May 2018 10:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtALpxPG5yOS for ; Wed, 16 May 2018 10:45:03 -0700 (PDT) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 1C8F81273B1 for ; Wed, 16 May 2018 10:45:03 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id t1-v6so1874943ott.13 for ; Wed, 16 May 2018 10:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=a/waVUh9kaUju6ZlXFKtniKtyXekiOauLaMwmQoFP8U=; b=SuXr/IQQ82S/DliCjir8mC69NXtC9IuajpXdAXTCRZat01cRlZo2OzHnijvxYb1DCU oda6mqOf8Of6T8D/vXBgZb0t74mA9PjmWDXI9dZ/QBL6lpmqHsU+taKCj0jaYd+Ows5g fKAVE5RjKCgdaPCAvC8pL/u4d97hAKfpNYlC5fzO8rmct1y/gtGhjyUpzkO6kql1TwdX lbeuGks58NQr/9tULfxGUgCTEDPj2mgRgYXmeLTo1RO9DTGrjFDnm0Bqw0/W03Xiwax/ YjJfKIplNDPbfGpoZkolGMYduUwnKj5LCV84UbrXLoqudB6Wy9NUD8KqBmmcIyKmYpPS vGUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=a/waVUh9kaUju6ZlXFKtniKtyXekiOauLaMwmQoFP8U=; b=fy00b/9Vx1vM2AOsYucoAkTmBGcE/RM5YRm4s6gV/Ey6hg1wWYSQ1y3y0FODWXsaMq AjgSN6fonbmNzTjoCfTBDtC9aEWlOizLgNRdqTSB3N8ftEjrCu7ZqMRQ04QxsNdrmLDC Bnx1Y7r5SSVAWaGF5q3OACZRSBjaxFn4nZy+C6YsrdtZpkdUukZfiDh24KZCS6zoVu2e qApskSXYM57IJLt3+RspUyzUVMu1D6/ExIsyF/pYRLu0HUUKDahINSDXlev97pzAO/7L qqYR+qLrNOurl+MiWwCL6fMQrGr8ADCgCbIZqWSRB4HauwtfwdhVaOYcLo8W9tw2kUGB cL8Q== X-Gm-Message-State: ALKqPwcS4o7a5K2omD/xjGwXMGFqr5O2XEAf97LBRRwgRqtWuMUwXRQR VkDLP5KLnhYeRIDz9kMOVXmk3ffJhs27VDqs5c4= X-Google-Smtp-Source: AB8JxZpWajSlxuMZynw1T8AvSx8XcyGRdaSJjmdNNbm72Oc0OxhKR6qNoDDhWqcBn1F14y8QCQgr/UIbMEIctf6hoWg= X-Received: by 2002:a9d:14b9:: with SMTP id d54-v6mr1445127ote.380.1526492702456; Wed, 16 May 2018 10:45:02 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:23:0:0:0:0:0 with HTTP; Wed, 16 May 2018 10:45:01 -0700 (PDT) In-Reply-To: <559ab3c7-ee5f-22b9-ef02-c091765011d2@isode.com> References: <559ab3c7-ee5f-22b9-ef02-c091765011d2@isode.com> From: Phillip Hallam-Baker Date: Wed, 16 May 2018 13:45:01 -0400 X-Google-Sender-Auth: jjBI49o1ZZE2ZR8xvdAfVCGv58Q Message-ID: To: Alexey Melnikov Cc: SPASM Content-Type: multipart/alternative; boundary="0000000000004841aa056c5647d5" Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 17:45:05 -0000 --0000000000004841aa056c5647d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 16, 2018 at 10:48 AM, Alexey Melnikov wrote: > Hi Philip, > On 16/05/2018 15:28, Phillip Hallam-Baker wrote: > > Looking at eFail, surely the simplest fix is to require that an HTML > message body be presented in a single CMS envelope presented in a single > MIME part? > > > I am not sure what you mean here. A CMS envelope can contain > multipart/mixed within it, which is a perfectly valid use case (i.e. if o= ne > wants to send some encrypted text together with some encrypted attachment= s). > =E2=80=8BAgreed. =E2=80=8B > If you are talking about preventing the following construct: > > > content-type: multipart/mixed; boundary=3D.f8231d7f-681b-442c- > 97cc-e6c5375d059d > > This is a multipart message in MIME format. > > --.f8231d7f-681b-442c-97cc-e6c5375d059d > content-type: text/html > > ...some partial HTML... > --.f8231d7f-681b-442c-97cc-e6c5375d059d > content-disposition: inline; filename=3Dsmime.p7m > Content-Transfer-Encoding: base64 > content-type: application/pkcs7-mime; name=3Dsmime.p7m; smime-type=3Denve= loped-data > > ...encrypted HTML... > --.f8231d7f-681b-442c-97cc-e6c5375d059d > content-type: text/html > > ...some partial HTML... > --.f8231d7f-681b-442c-97cc-e6c5375d059d-- > > > i.e. a multipart/mixed that contains a mixture of text/html and > application/pkcs7-mime, then I might agree with you. But this is not real= ly > an S/MIME feature, it is a generic MIME feature. So maybe this WG should > write a document on best S/MIME implementation practices. > =E2=80=8BAgreed. It is a feature of MIME which seems to have been carried o= ver to S/MIME without people asking WTF?=E2=80=8B --0000000000004841aa056c5647d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Ma= y 16, 2018 at 10:48 AM, Alexey Melnikov <alexey.melnikov@isode.com= > wrote:
=20 =20 =20

Hi Philip,

On 16/05/2018 15:2= 8, Phillip Hallam-Baker wrote:
Looking at eFail, surely the simplest fix is to require that an HTML message body be presented in a single CMS envelope presented in a single MIME part?

 I am not sure what you mean here. A CMS envelope can contain multipart/mixed within it, which is a perfectly valid use case (i.e. if one wants to send some encrypted text together with some encrypted attachments).

=E2=80=8BAgreed.

=E2=80=8B
=C2=A0<= /div>
If you are talking about preventing the following construct:


content-type: multipart/mixed; boundary=3D.f8231d7f-681b-442c-97cc-e6c5375d059d

This is a multipart message in MIME format. 
--.f8231d7f-681b-442c-97cc-e6c5375d059d
content-type: text/html

...some partial HTML...
--.f8231d7f-681b-442c-97cc-e6c5375d059d
content-disposition: inline; filename=3Dsmime.p7m
Content-Transfer-Encoding: base64
content-type: application/pkcs7-mime; name=3Dsmime.p7m; smime-type=3Denvelo=
ped-data

...encrypted HTML...
--.f8231d7f-681b-442c-97cc-e6c5375d059d
content-type: text/html

...some partial HTML...
--.f8231d7f-681b-442c-97cc-e6c5375d059d--

i.e. a multipart/mixed that contains a mixture of text/html and application/pkcs7-mime, then I might agree with you. But this is not really an S/MIME feature, it is a generic MIME feature. So maybe this WG should write a document on best S/MIME implementation practices.

=E2=80=8BAgreed. It is a feature of MIME w= hich seems to have been carried over to S/MIME without people asking WTF?= =E2=80=8B


--0000000000004841aa056c5647d5-- From nobody Wed May 16 10:51:55 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC1B12D9FF for ; Wed, 16 May 2018 10:51:53 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 ldmK_Rh0_qFk for ; Wed, 16 May 2018 10:51:51 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 45453126CF6 for ; Wed, 16 May 2018 10:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1526493110; d=isode.com; s=june2016; i=@isode.com; bh=xsI7VEsIq+FYBO+ZPCKYLsLA9Axz8lP41cs0Vs4kHm0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=O8BH6GkRtXuf6SZdvZHyx/9AoxY+Ngqi/piXYoyv96sWT8e8wysFo4glbW3HJzkyIq5Ja2 SEOQK2FwALhA4b2J7zdyyeMdcW6+9lvM/v+NMDPtomLunbxpCZFXT4FsfCY3nLcLZVnWKu wCUxsVeVt3WcwVIHLQPCrEWhBOjw5k0=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 16 May 2018 18:51:50 +0100 To: Jim Schaad , 'Phillip Hallam-Baker' , 'SPASM' References: <559ab3c7-ee5f-22b9-ef02-c091765011d2@isode.com> <04ca01d3ed3c$5c158050$144080f0$@augustcellars.com> From: Alexey Melnikov Message-ID: <951633c7-0cad-58e7-236c-bb82e44c9e9f@isode.com> Date: Wed, 16 May 2018 18:51:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 In-Reply-To: <04ca01d3ed3c$5c158050$144080f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------54CA522A61D206B9D85D6203" Content-Language: en-GB Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 17:51:53 -0000 --------------54CA522A61D206B9D85D6203 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable On 16/05/2018 18:35, Jim Schaad wrote: > I will note that unless multipart/mixed has some special text=20 > associated with it.=C2=A0 Text/html is defined by RFC 1866 to only hold a= =20 > single HTML document.=C2=A0 Thus building an HTML document from multiple= =20 > parts is not according to Hoyle. > Yes, but people do this anyway, as separate HTML body parts are=20 frequently valid HTML documents. So building from pieces works most(*)=20 of the time. (*) spam and phishing nonwithstanding. > > > Jim > > *From:*Spasm *On Behalf Of *Alexey Melnikov > *Sent:* Wednesday, May 16, 2018 7:49 AM > *To:* Phillip Hallam-Baker ; SPASM > *Subject:* Re: [lamps] S/MIME fix > > Hi Philip, > > On 16/05/2018 15:28, Phillip Hallam-Baker wrote: > > Looking at eFail, surely the simplest fix is to require that an > HTML message body be presented in a single CMS envelope presented > in a single MIME part? > > > I am not sure what you mean here. A CMS envelope can contain=20 > multipart/mixed within it, which is a perfectly valid use case (i.e.=20 > if one wants to send some encrypted text together with some encrypted=20 > attachments). > If you are talking about preventing the following construct: > > > content-type: multipart/mixed;=20 > boundary=3D.f8231d7f-681b-442c-97cc-e6c5375d059d > > This is a multipart message in MIME format. > > --.f8231d7f-681b-442c-97cc-e6c5375d059d > content-type: text/html > ....some partial HTML... > --.f8231d7f-681b-442c-97cc-e6c5375d059d > content-disposition: inline; filename=3Dsmime.p7m > Content-Transfer-Encoding: base64 > content-type: application/pkcs7-mime; name=3Dsmime.p7m; smime-type=3Denvel= oped-data > ....encrypted HTML... > --.f8231d7f-681b-442c-97cc-e6c5375d059d > content-type: text/html > ....some partial HTML... > --.f8231d7f-681b-442c-97cc-e6c5375d059d-- > > > i.e. a multipart/mixed that contains a mixture of text/html and=20 > application/pkcs7-mime, then I might agree with you. But this is not=20 > really an S/MIME feature, it is a generic MIME feature. So maybe this=20 > WG should write a document on best S/MIME implementation practices. > > > This would simplify the code substantially. While it is > conceivable someone has worked out a way to make use of this > mis-feature, I for one cannot imagine why Outlook, Thunderbird or > the like would ever do anything of the sort. > > Separately, we have interest in CAA for S/MIME. Surely we should > do ACME for S/MIME as well. > > > Not surprisingly, I agree. See draft-ietf-acme-email-smime-02 > > If we are going to do that, surely we should have a discussion of > what it would take to make end to end security the default for SMTP. > > I am not necessarily thinking of this as a LAMPS thing because we > also need to get CAs, probably CABForum involved and maybe the > OpenPGP folk. > > > Best Regards, > Alexey > --------------54CA522A61D206B9D85D6203 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On 16/05/2018 18:35, Jim Schaad wrote:

I will note that unless multipart/mixed has some special text associated with it.=C2=A0 Text/html is defined by RFC 1866 to only hold a single HTML document.=C2=A0 Thus building an HTML document from multiple parts is not according to Hoyle.

Yes, but people do this anyway, as separate HTML body parts are frequently valid HTML documents. So building from pieces works most(*) of the time.

(*) spam and phishing nonwithstanding.

<= o:p>

Jim

=C2=A0<= /o:p>

=C2=A0<= /o:p>

Fro= m: Spasm <spasm-bounces@ietf.org> On Behalf Of Alexe= y Melnikov
Sent: Wednesday, May 16, 2018 7:49 AM
To: Phillip Hallam-Baker <phill@hallambaker.com>; SPASM <SPASM@ietf.org>
Subject: Re: [lamps] S/MIME fix

=C2=A0

Hi Philip,

On 16/05/2018 15:28, Phillip Hallam-Baker wrote:

Look= ing at eFail, surely the simplest fix is to require that an HTML message body be presented in a single CMS envelope presented in a single MIME part?


I am not sure what you mean here. A CMS envelope can contain multipart/mixed within it, which is a perfectly valid use case (i.e. if one wants to send some encrypted text together with some encrypted attachments).
If you are talking about preventing the following construct:


content-type: multipart/mixed; boundary=3D.f8231d7f-681b-442c-97cc-e6c5375d059d

This is a multipart message in MIME format. 

--.f8231d7f-681b-442c-97cc-e6c5375d059d
content-type: text/html
=C2=A0
....some partial HTML...
--.f8231d7f-681b-442c-97cc-e6c5375d059d
content-disposition: inline; filename=3Dsmime.p7m<=
/pre>
          
Content-Transfer-Encoding: base64

          
content-type: application/pkcs7-mime; name=3Dsmime.p7m; smime=
-type=3Denveloped-data

          
=C2=A0

          
....encrypted HTML...

          
--.f8231d7f-681b-442c-97cc-e6c5375d059d

          
content-type: text/html

          
=C2=A0

          
....some partial HTML...

          
--.f8231d7f-681b-442c-97cc-e6c5375d059d--

          


            i.e. a multipart/mixed that contains a mixture of text/html
            and application/pkcs7-mime, then I might agree with you. But
            this is not really an S/MIME feature, it is a generic MIME
            feature. So maybe this WG should write a document on best
            S/MIME implementation practices.

            

            

            

          

            

              

                
This
                    would simplify the code substantially. While it is
                    conceivable someone has worked out a way to make use
                    of this mis-feature, I for one cannot imagine why
                    Outlook, Thunderbird or the like would ever do
                    anything of the sort.

              

              

                
=C2=A0

              

              

                
=C2=A0

              

              

                
Sepa=
rately,
                    we have interest in CAA for S/MIME. Surely we should
                    do ACME for S/MIME as well.

              

            

          

          


            Not surprisingly, I agree. See
            draft-ietf-acme-email-smime-02 

          

            

              

                
If
                    we are going to do that, surely we should have a
                    discussion of what it would take to make end to end
                    security the default for SMTP.

              

              

                
=C2=A0

              

              

                
I am
                    not necessarily thinking of this as a LAMPS thing
                    because we also need to get CAs, probably CABForum
                    involved and maybe the OpenPGP folk.
              

            

          

          


            Best Regards,

            Alexey

--------------54CA522A61D206B9D85D6203-- From nobody Wed May 16 12:59:48 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F2512D957 for ; Wed, 16 May 2018 12:59:47 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.599, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 9aPCHzgmyq9N for ; Wed, 16 May 2018 12:59:44 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.201]) (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 19FC912D88B for ; Wed, 16 May 2018 12:59:43 -0700 (PDT) Received: from [216.82.242.36] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-9.bemta-8.messagelabs.com id 24/7C-15733-FAD8CFA5; Wed, 16 May 2018 19:59:43 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTaUwTQRTHO7vbdkFqhoXKs4JAg4liIHhjjEY TjajxAuNRCbrVhTb2wG5VNCZi4lmqglKlFSmi8QOKMQaDF0ZLvPC+MFE8UL6IGjBeWJDa7dTr y+Q3//97b96bzLA016PQsEKRXbBZeJNWEcncSz/CpZ3c1avL6HMPyizrOogyq1pWTKay7h//S mUdPfqDmkfp5EaL3lq0XG5oPn4JFX5cVHT1/gG6GNXkOFAky2AnDT86vZS04XApBc7m80qyeY Wgy9HJOFAEq8AZ0NJ4nZI4FmdBha9bIXEMToTGmlIl0ZPgTNMpuQOxQR4JX+8Ok2QGD4E7Dj+ SWIVzoe48KcnheeBt2BfSI/B8eLl/W6gMwgPge/OJ0FE0joNn7d4QA46Ftge3FITV8O5tn5zE 58Khz76wngRNOx6E4xPgobcESbMArqfA37glbKRBl8tFE+MygteB/QqpacCp0F0WjlkFNz5tV RKeCYHbe2jCg6F2VxtDuJ6GytoswvFQdvIAQ2q2yqGl6iwiU66E8lqpO8l4i6Dhi5shN6eBF4 93olKU6vlnUk8wjsZeBG1vKuWe0JVFw013O0OCdND7/YOCcCq46jrC+nA4dvg97QkOQeNhcO2 R9n9Z4glQ4b8STk2G8pI2JeEx8P7qJ1SN+tWioaJgWyvY0kaPTNfbjAUGu5k3mtJGZGSmmwVR 5AsEE68X01dYzadR8PFtksnQWfTu2FIfGshSWrVqd1+Pjuuvt65cb+BFwzLbGpMg+lA8y2pBV eLs1XHRNqFAKMo3moIv+LcNbJQ2VjVWslViIW8WjQXEakbj2db6vU6a9XWWB9e70soxFqtF0M SpCqUELCUY1lj+lPv9Jx6iBE2MCslkMi6qULCZjfb//Q4UxyJtjKpGqhJltNj/nNoRbIgKNoQ u90gN2fm/lqYYVTdUrRrF5SZaJ52eooyunP2EdS7snRhDJf5MbBqo7t7if5VXrM7XD81M6ajP 9ozLg6d7Li44N6du82p3xMYWV+u3zavLctzPz93IOzMtP5A07oL7Az13bYrTG60LJM9afGvmx qWBJet6Ih3qqOwZ07uo+Qnxd2ZMm+p/sb103ybXqA1aRjTwI1Jpm8j/AkzWYaEOBAAA X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-10.tower-94.messagelabs.com!1526500781!177578471!1 X-Originating-IP: [207.46.163.18] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 44744 invoked from network); 16 May 2018 19:59:42 -0000 Received: from mail-dm3nam03lp0018.outbound.protection.outlook.com (HELO NAM03-DM3-obe.outbound.protection.outlook.com) (207.46.163.18) by server-10.tower-94.messagelabs.com with AES256-SHA256 encrypted SMTP; 16 May 2018 19:59:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BdcJrCLQOnk8JQpgqJNwU1pPmY2yWNxa8p70VYnoAJ0=; b=CwDUM9Ue8l3ec8+baJqfqrz8AFz5JtzKDaM/PE4z3Tz7r1NzClMtWAxzDeWslUwTG2EO/5f8jYbMP38DDg60Y9d9cwYN/pmAhdpJjx8G7N8+fiJfMw2aKAriZ4GquKW8ERLjeOrV0d1VAKhpKrtQB9RkqCWFXnXSwinBxW943DI= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1604.namprd14.prod.outlook.com (10.171.175.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.776.11; Wed, 16 May 2018 19:59:40 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::40d8:6bed:a1a5:de4e]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::40d8:6bed:a1a5:de4e%3]) with mapi id 15.20.0776.010; Wed, 16 May 2018 19:59:40 +0000 From: Tim Hollebeek To: Phillip Hallam-Baker , SPASM Thread-Topic: [lamps] S/MIME fix Thread-Index: AQHT7SJdOmZQG8Umo0udkM2b+/ucJqQyxYkA Date: Wed, 16 May 2018 19:59:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [98.111.202.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1604; 7:cnQeC/gjx9aAAzRwqQZ9rm7zYyAKzWfLHi8iIRamz3xWPMz2IExWQJ41JF+LwrwkxYBweVrHLKexrKTPpJll5LLwx8jsQjsiRCBjxiBVtvW7HDQvG2ISTFcKwdAQ0hLIsKkzpsrvwN4YIF51KSJBYef+rgEmTvYpBlMIfnCKQxBpIbmpsx7syz/tDzHExn4yV0PAOew0sQRoCRWagihrUaW/aL9wgjw15NQfVTUVwCmaqM06Eok4/+eHubKIXu8w x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1604; x-ms-traffictypediagnostic: BN6PR14MB1604: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(3002001)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:BN6PR14MB1604; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1604; x-forefront-prvs: 0674DC6DD3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(39860400002)(366004)(39380400002)(189003)(199004)(3280700002)(476003)(3846002)(44832011)(790700001)(66066001)(99286004)(486006)(33656002)(3660700001)(11346002)(446003)(8676002)(186003)(8936002)(81166006)(6506007)(81156014)(2900100001)(76176011)(7696005)(7736002)(26005)(102836004)(2906002)(478600001)(6116002)(54896002)(14454004)(6306002)(9686003)(5660300001)(5250100002)(110136005)(55016002)(6436002)(74316002)(99936001)(97736004)(68736007)(53936002)(106356001)(229853002)(25786009)(105586002)(6246003)(316002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1604; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: XjQ0oe1saSgkhwguxos6t1qBTNkONODfKZUfTPiudwnUwaXKzwvtrq/3Zpldju74uc/b1kvCx3VUbxlcxiUggzgB6rmrJH5qsIr5+Lf32bRJriplkJUZ50MNrVr+3VhW7xmN9PMbElmXxbKqGWUkEmeSAtIAn6YLhtYqcYYcqgvETEGv6349oqoqxjCYdGl6 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_081A_01D3ED2E.DFA0C410" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 89689194-a358-43be-0014-08d5bb678f85 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 89689194-a358-43be-0014-08d5bb678f85 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2018 19:59:40.5586 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1604 Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 19:59:47 -0000 ------=_NextPart_000_081A_01D3ED2E.DFA0C410 Content-Type: multipart/alternative; boundary="----=_NextPart_001_081B_01D3ED2E.DFA0C410" ------=_NextPart_001_081B_01D3ED2E.DFA0C410 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable It=E2=80=99s not necessarily an either / or thing. After July 3, = we=E2=80=99ll have a S/MIME group at CABF and from talking privately to = some people it sounds like we will have good participation. But that = will mostly be a policy discussion. =20 It would be nice to have IETF RFCs to point to for all the persnickety = technical details about how things like ACME and CAA work with email. = I=E2=80=99m sure there=E2=80=99s plenty of nuances we haven=E2=80=99t = thought of yet. There certainly were for the web. =20 Draining the email swamp is actually very high on my priority list for = this year. =20 -Tim =20 I am not necessarily thinking of this as a LAMPS thing because we also = need to get CAs, probably CABForum involved and maybe the OpenPGP folk. ------=_NextPart_001_081B_01D3ED2E.DFA0C410 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

It=E2=80=99s not necessarily an either / or = thing.=C2=A0 After July 3, we=E2=80=99ll have a S/MIME group at CABF and = from talking privately to some people it sounds like we will have good = participation.=C2=A0 But that will mostly be a policy = discussion.

 

It would be nice to have IETF RFCs to point to for all = the persnickety technical details about how things like ACME and CAA = work with email.=C2=A0 I=E2=80=99m sure there=E2=80=99s plenty of = nuances we haven=E2=80=99t thought of yet.=C2=A0 There certainly were = for the web.

 

Draining the email swamp is actually very high on my = priority list for this year.

 

-Tim

 

I = am not necessarily thinking of this as a LAMPS thing because we also = need to get CAs, probably CABForum involved and maybe the OpenPGP = folk.

------=_NextPart_001_081B_01D3ED2E.DFA0C410-- ------=_NextPart_000_081A_01D3ED2E.DFA0C410 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwNTE2MTk1OTMwWjAvBgkqhkiG9w0BCQQxIgQgMx14MVEMhN663B8hPtSuThiDBED3 nXz3BCHHwWoGH6swgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAL97TAghd4GECIfHh6vTFUXVVY2eKy3tdJOUxFq0alLCb7yNFe6aAvn0HzK4B6nfrEHs4uVB 2E380CN0s4iumj61GQaGjSTuqlGNa1b1AB3zVdji/EBvkKuQVctAmdPRokOpak/orpMizok2ui/h Ts1rNeABdMzIJ5P5N0P4PD3uTW/4WlL4aSrpZUWtLcro4dGScf72Vghzyms18xE7uEg40GItmnAI vs7uCjw0h/AFTlT0JsGTTJFD7VofHfNW0y0O+iKQcwn3lgZ5wbR9DiVMMA9dHvBfF8zPb0xdQcax EDYb6dhji4HDY20Rkcyci+NZKZCqIJaW6yHHM3d/WukAAAAAAAA= ------=_NextPart_000_081A_01D3ED2E.DFA0C410-- From nobody Wed May 16 13:55:44 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB9312DA21 for ; Wed, 16 May 2018 13:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 Nj-RLg8QL2he for ; Wed, 16 May 2018 13:55:35 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA92912E034 for ; Wed, 16 May 2018 13:55:22 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id e80-v6so2003195oig.11 for ; Wed, 16 May 2018 13:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=oQjKnxl/FS5ceuuPaPr6B2Z/gX2D+LsoWePWx93KcIQ=; b=gkp8YulOGkNkqJ8zo6da+7IHw9BnP+DC8ptUXoVziUwskuVJcYqUoKsNw9Eu0ZODnG pOn7yMhjxqNVV208PjsYDYhBMiR0snKK60b8aCH5xVL2eBdfcsBjjOvv4bQbI0vsC+bn kKCR06IuHhUv6ufrxdnjiLir8cqnmc/zhEBHAUXy50fKCwFArO/s1dLf3QEbc9hw7vLh MQZHN8Nz2W9iGODwWoITrqAA8zY8whdq6zaUdMdYzEXMtGfK8yrbPEIwEwymh81bHPjY 79EnozFPI1qTIvfl+F35cpwuGFe5yb7OjLUbaLEB/oQ2knDX3zT3ZhAQ3O9TFgEkKhID bxzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=oQjKnxl/FS5ceuuPaPr6B2Z/gX2D+LsoWePWx93KcIQ=; b=ciQ2YUacqbuA5c/Z3h3C0DQycQP4clQ76ikwqQz7G+LHeX2VgcPS1p45LWmRTCezIJ raqcAK+ah2iS3TkObB29D3Lroc7wwi5ClgrSohRyzqDpaMQBflFZb5h6WDy0TVUWhkY3 SpFb+1Tbelri0ihF93J0mnUM9wuQKAP6mCOFNX+kgLQ4yhEdfOrU7NjJc9R7I2Erh5Jh 4+5B3lm9J99IZ46wx2L7BXIOtV1WdJnJ+Zpbz7cHRXHIf6HWRFzEB7LS5I332/WYA+4q MH7/sQFywvtVQNe75qrhNs5ho0wVaSojpgaxs1STBskYW1tBVDuE4TcDQWu6bUXqprc3 ujWA== X-Gm-Message-State: ALKqPwd8sBZjTI0QcyZsLkRXFTu8k1wUZKGkkAgtXKdeAHjbiUSf0AvH YnydWqQFVdSDzyTuDlWEmObyGWWBU6HkHBVJhVU= X-Google-Smtp-Source: AB8JxZqU6IYIE7O/Uld4R4tbG3A54Py5OhHUlBNF6O1SNX0Pk1mx1NyFvvWhVi+WU0Wd3oQOXedIa2CYCJz5OrM8K1Q= X-Received: by 2002:aca:ce42:: with SMTP id e63-v6mr1782126oig.34.1526504122283; Wed, 16 May 2018 13:55:22 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:23:0:0:0:0:0 with HTTP; Wed, 16 May 2018 13:55:21 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Wed, 16 May 2018 16:55:21 -0400 X-Google-Sender-Auth: 9uhBNfw60-GgVZBRURwzRf29NuI Message-ID: To: Tim Hollebeek Cc: SPASM Content-Type: multipart/alternative; boundary="000000000000f4fcef056c58efc5" Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 20:55:42 -0000 --000000000000f4fcef056c58efc5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Absolutely, it is not either/or. What I would like to see us do however is come together at some point and identify ALL the issues that are barriers to ubiquitous deployment of S/MIME and come up with a comprehensive scheme. What I think we are going to need is a standard that allows folk to know if their infrastructure supports S/MIME-NG. On Wed, May 16, 2018 at 3:59 PM, Tim Hollebeek wrote: > It=E2=80=99s not necessarily an either / or thing. After July 3, we=E2= =80=99ll have a > S/MIME group at CABF and from talking privately to some people it sounds > like we will have good participation. But that will mostly be a policy > discussion. > > > > It would be nice to have IETF RFCs to point to for all the persnickety > technical details about how things like ACME and CAA work with email. I= =E2=80=99m > sure there=E2=80=99s plenty of nuances we haven=E2=80=99t thought of yet.= There certainly > were for the web. > > > > Draining the email swamp is actually very high on my priority list for > this year. > > > > -Tim > > > > I am not necessarily thinking of this as a LAMPS thing because we also > need to get CAs, probably CABForum involved and maybe the OpenPGP folk. > --000000000000f4fcef056c58efc5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Abs= olutely, it is not either/or.

What I would like to see us do however is come together at some point = and identify ALL the issues that are barriers to ubiquitous deployment of S= /MIME and come up with a comprehensive scheme.

What I think we are going to need is a standard that = allows folk to know if their infrastructure supports S/MIME-NG.


On Wed, May 16, 2018 at 3:59 PM, = Tim Hollebeek <tim.hollebeek@digicert.com> wrote:

It=E2=80=99s not necessarily an either / or thing.=C2=A0 After J= uly 3, we=E2=80=99ll have a S/MIME group at CABF and from talking privately= to some people it sounds like we will have good participation.=C2=A0 But t= hat will mostly be a policy discussion.

=C2=A0

It would be nice to hav= e IETF RFCs to point to for all the persnickety technical details about how= things like ACME and CAA work with email.=C2=A0 I=E2=80=99m sure there=E2= =80=99s plenty of nuances we haven=E2=80=99t thought of yet.=C2=A0 There ce= rtainly were for the web.

= =C2=A0

Draining the email swamp is actuall= y very high on my priority list for this year.

=C2=A0

-Tim

=C2=A0

I am not necessarily thinking of th= is as a LAMPS thing because we also need to get CAs, probably CABForum invo= lved and maybe the OpenPGP folk.

=

--000000000000f4fcef056c58efc5-- From nobody Wed May 16 14:16:52 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EEB12D948 for ; Wed, 16 May 2018 14:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] 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 skEwX76kvOhc for ; Wed, 16 May 2018 14:16:47 -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 80FA1126CBF for ; Wed, 16 May 2018 14:16:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 297F4BE55; Wed, 16 May 2018 22:16:45 +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 bkHmW3eiH5X8; Wed, 16 May 2018 22:16:43 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 93E98BE2F; Wed, 16 May 2018 22:16:43 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1526505403; bh=t8xuSwDzu98xZgEkz0IFsu4/8rwN07KUdddVoPtcnvE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=GkuL8t2iCtmvN8lzo/1D/uGPZE9YA65Bw0KFwduvF0go1tfOlMkOrPEvwbS44wooa XIk4dS5rDhyJ6NH4LUZS3w8y6j712koc1tm6peoYGu8gQMwVJtc+lgJ4Mjb8q3Fsie VkCjh5d2ohyk6baybtHbtOSW2tByAWCSHDdO6gzg= To: Phillip Hallam-Baker , Tim Hollebeek Cc: SPASM References: From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <1e8468d7-da6c-62f1-e24b-1ee03df22606@cs.tcd.ie> Date: Wed, 16 May 2018 22:16:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uhPDb8wEDZ0vXWhGJYxVBAKebNtnx6Zdw" Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 21:16:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uhPDb8wEDZ0vXWhGJYxVBAKebNtnx6Zdw Content-Type: multipart/mixed; boundary="iZUVblroy3kK8C44Nt0KSj9BTdJWARVhp"; protected-headers="v1" From: Stephen Farrell To: Phillip Hallam-Baker , Tim Hollebeek Cc: SPASM Message-ID: <1e8468d7-da6c-62f1-e24b-1ee03df22606@cs.tcd.ie> Subject: Re: [lamps] S/MIME fix References: In-Reply-To: --iZUVblroy3kK8C44Nt0KSj9BTdJWARVhp Content-Type: multipart/mixed; boundary="------------9EF818C80537A552967D942E" Content-Language: en-GB This is a multi-part message in MIME format. --------------9EF818C80537A552967D942E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 16/05/18 21:55, Phillip Hallam-Baker wrote: > What I would like to see us do however is come together at some point a= nd > identify ALL the issues that are barriers to ubiquitous deployment of > S/MIME and come up with a comprehensive scheme. I agree with the above, so long as we don't exclude PGP. (There are pros and cons to both.) I'd be willing to do work to try even get consensus on the barriers to large scale usage for e2e email security. (A list of those that I use in class is below - I don't claim that's the best possible list.) That said, I'm not so optimistic as I think some of those barriers are currently insurmountable. Still willing for another tilt at the windmill though. I don't think that ought be a formal anything at the next IETF meeting - I can't see us making progress with 40+ people in a room, so something with a much smaller number would be needed to start. If someone does organise such, I'd be happy to join in if the set of folks includes at least one of the main players in email - if there're none of those involved, it's probably not even worth tilting at, is my gloomy conclusion. Cheers, S. - Designs pre-date web user agent which changes trust model (where's the private key kept? Needs new infrastructure) - Needs all major email service providers (yahoo, hotmail, gmail) to deploy the same thing which also needs to be implemented by all major user agent developers (microsoft, mozilla, apple, google) - Public key retrieval needs to be fixed (doable if the above done, but a killer if not done), likely with some new PKI (doable but who's gonna pay?) - Mail headers need to be protected as users don't get that S/MIME and PGP only protect body and not e.g. Subject, From (new enveloping protocol needed, can be done but kludgy) - We need to unify S/MIME and PGP or pick one or we'll lose interop (it's ok if the other soldiers on for some niches) - Users don't care much, so it has to be entirely transparent for them (needs signifcant UI work, co-ordinated across MUAs and signifcant web-UAs) --------------9EF818C80537A552967D942E Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6 UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM 1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/ lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9 lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/ VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3DTOQn -----END PGP PUBLIC KEY BLOCK----- --------------9EF818C80537A552967D942E-- --iZUVblroy3kK8C44Nt0KSj9BTdJWARVhp-- --uhPDb8wEDZ0vXWhGJYxVBAKebNtnx6Zdw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlr8n7UACgkQWrL68XsX K+ruxQ//Vf2EVPC0LH7Jp9PlvJRltg50WZ7ZtCfCUP6Kz5WTHlI/gnuu6tiU3WYr 5RFGa+oUIB1jZFDscpqM0lV82f7eotdgof3/Akxjkn1WyRMxzrYAWZ5rCK3mnoSV Zt/wO2xUJT1SV1N+ftX/c6uhhXXi34y2w48aPhtLXjVWSJQNNUEGFaY1ZvKYtid5 ytkjJcQ6x/7aRz4HQJBraBQD8MeDC+knF24afGAlspiPTNi1JFMf5YG0e0IR6GMG zpSDzgKDqE6dk9LS/sB7JBxgGX0vGIm0QYlfQJd7O8o7ReYgjWMlu2zU97npi72Z Lsdcx2BKSRUGWhqqmL1WvLHCU5THVY6/Pf8xifWMr/4gmjrkW9QtEOacb1Z9NIMg jRcq2h3D7mDnVHopFyjNSM4UQKID9YwB4kvrkVIHS3HOUaNcpK0EXAaxwnnTIOnP 9Ph+0h3Alhx08wrJNyqIEKbkyrZsUBZzNffnF4epPUCPIG2yIUSy44p1wveuOgXd 1m3g6pAtjH8nv2l9VpZoE5C0/+DX9xYYNvUT2bkrVvfk2CHEpumdSbKpGAtyEkpL K4KmyKmljFFvlqp36ERM+T2W0X6YyZGZZSFWNC/N7JXjHkYnIUtfDO7z/M9KiJaC q6f0CalXNDbZ5ccNojb7nE3oSKA3RWNAeTvuaC001X/e4f5ijWc= =BbFC -----END PGP SIGNATURE----- --uhPDb8wEDZ0vXWhGJYxVBAKebNtnx6Zdw-- From nobody Wed May 16 15:33:00 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D7D12D960 for ; Wed, 16 May 2018 15:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 cvxE-xK05rQ5 for ; Wed, 16 May 2018 15:32:57 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 F187B126D05 for ; Wed, 16 May 2018 15:32:56 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4GMWkx5069640 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 May 2018 17:32:46 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Stephen Farrell , Phillip Hallam-Baker , Tim Hollebeek Cc: SPASM References: <1e8468d7-da6c-62f1-e24b-1ee03df22606@cs.tcd.ie> From: Adam Roach Message-ID: Date: Wed, 16 May 2018 17:32:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1e8468d7-da6c-62f1-e24b-1ee03df22606@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 22:32:58 -0000 On 5/16/18 4:16 PM, Stephen Farrell wrote: > - Designs pre-date web user agent which changes trust model > (where's the private key kept? Needs new infrastructure) To understand the challenges surrounding what you suggest, you probably want to study the issues surrounding isolated media streams in WebRTC. Start by looking at section 4.3.2.4 of draft-ietf-rtcweb-security, and then read through . To create an analogous situation for secure email, you'd need to use webcrypto in a way that stored your private key in the browser (inaccessible to the page), and develop web standards that add some affordance for web pages to hand encrypted data to the browser in a way that causes the corresponding unencrypted data to be displayed to the user, but isolated from the web page completely (e.g., rendered into an iframe that the parent cannot inspect). Whether that kind of isolated context for email (which should be usable for real-time messaging as well, if done correctly) is reasonable or too clunky to work is yet to be seen. (I've had a few conversations that concluded "too clunky," but reasonable people may disagree.) In any case, the bulk of the work for that kind of system would need to take place in the W3C. There are, of course, possible trade-offs to be made in which the user trusts the web-hosted mail service with access to message plain text, or even to their private key; but once you take that leap, you're doing scantly better than the hop-by-hop security provided by DANE and/or MTA-STS. /a From nobody Wed May 16 16:36:50 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310D4126D73 for ; Wed, 16 May 2018 16:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.599, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 ismoGIbxRbYd for ; Wed, 16 May 2018 16:36:46 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.200]) (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 6BBD1126C2F for ; Wed, 16 May 2018 16:36:46 -0700 (PDT) Received: from [216.82.242.46] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-8.bemta-8.messagelabs.com id D6/B9-05993-D80CCFA5; Wed, 16 May 2018 23:36:45 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSWUwTURSGe2em7aDUXIYKxwZcStzQNqghafR B5MX6gHtiRKIMONLGLmSmGtyJGqNQFEFU6gIikAhqRTFqArGCShRlDRjRYIhgFBVRYxDRaqdT UN++c/7/nuXm0CTzRqGhuQwHx9tYi1YxjmrWXwzROT0/E2M+l6kNNb9KlIbjg2eQ4XxnquFUb acyjjJeye5QGFsqvxHG0tJhwui600utpBLlZluKPSNZbnpR069ML0vIuOQdlmeig8uy0Diawk 4SDr06RogBg3MJ6MvPQVLwCsHINy+ZhYJoBY6BztoGn4um1XgPtDfsFtMk1kD+/d9I5FA8BWp LcpUiq/FUuFl/TS7xcjja6PYzhaeDu8qtEFmFk+BGYS0hMoObCPjkWiJyEF4MnutF/joIh8HQ 48uE1CscunqL/AxYDT2tjQqJJ8K711655E+Cc1/rAvmpUH+4NeCPhLaibP9egKsJaDw0EDDpY LCggJSEFgTPsveTkhANHZ35gddbYaiuWClxEgxUDQfyk6Eip4eSuJqE7r4NEkfA8aunAvnzCm h/OlfacjOcqBCnE5u9RlDS7SZz0RzXP9u5fBqJixB4jjSRLv83hcCjwl5KMkVDwZX+AE+BWx/ PkhIvgtM/7ikkngYnsnuUEsfC+wefUTGiK9AsgeO3c7xufqw+hTenmRxW1mzRzYsx6K2cILBp nIVNEfSpdut15Lu2fTIZuo36BhPq0CSa0E5UHfWOJDITUuybd5hYwbSJ32bhhDoUQdNaUOXc/ ZnIhPBcGpexxWzxneyoDHSwVq2aI8oqIZ21CuY0SXqMFtAvq/OcJP2w/aSTZCib3cZpwlWpoh WLVtM221ih0fNvQ5GaUBWSyWRMcDrHW82O//V+FE4jbaiqWKwSbLY5xvr1+0YhfKMgz4g4ioP 9K2kyUYl1rnZtckxm4RnPzC/vcixMPfu86gNdP8nesG5vvKVr79CFxdHrrU8KIpfOKFuxavxA Rznp1G2swlzF90p9WVT6mvgWvKgveehDzbLVwVzW+F3lzB7vcMKnvIUHwzhjyOWwH+7IpsnNo YILVe880Bwb/7Y1jo9y8TtmzKZnf8zTUoKJnRdN8gL7BwtoKIb5AwAA X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-14.tower-96.messagelabs.com!1526513803!102348485!1 X-Originating-IP: [207.46.163.17] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10154 invoked from network); 16 May 2018 23:36:44 -0000 Received: from mail-dm3nam03lp0017.outbound.protection.outlook.com (HELO NAM03-DM3-obe.outbound.protection.outlook.com) (207.46.163.17) by server-14.tower-96.messagelabs.com with AES256-SHA256 encrypted SMTP; 16 May 2018 23:36:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r0/IS+fQN+uUkfNBGJJJTKUoGixmh+1L2QYo3G3O6Dg=; b=o0Wx9X2iXYPp6UorX9LPhd4iSfbI7SynrnN2PtFPkeBGn5ble/ylcniQjEuYXrroOMT9LagUp3eEEyA4bsMgYxP/Kqq3KJtttj9vJaq7qNJ0TM5mzPNrOwSgr9AD4AIRjVIPANnWFnyJOU9Yz3/eNi6/amubztDaVhmBUSQSAXU= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1169.namprd14.prod.outlook.com (10.173.161.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.776.11; Wed, 16 May 2018 23:36:42 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::40d8:6bed:a1a5:de4e]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::40d8:6bed:a1a5:de4e%3]) with mapi id 15.20.0776.010; Wed, 16 May 2018 23:36:42 +0000 From: Tim Hollebeek To: Adam Roach , Stephen Farrell , Phillip Hallam-Baker CC: SPASM Thread-Topic: [lamps] S/MIME fix Thread-Index: AQHT7SJdOmZQG8Umo0udkM2b+/ucJqQyxYkAgAAQmoCAAAXxgIAAFUGAgAAPyLA= Date: Wed, 16 May 2018 23:36:41 +0000 Message-ID: References: <1e8468d7-da6c-62f1-e24b-1ee03df22606@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [98.111.202.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1169; 7:auTY2TCTy9cEm2Px8vObozcVf7BX9gPy9c7q6JDoeuMXdvboeEgyacVQuDabp9WzoIPWsFoN07OjNo66r9xfgWToeRnvgkYf7WNjuTcD3Fp2PxUFOu1jmUn9JWzZXJDK13WE+9IXmF9T2c/L0rTLQYaQwbDMVVqJ0L9omnufRCCA49b50dAsMd1vJ9rV9QTUDpLwWDvTqJjOinm3yHJs2PQ2KeXsbAl8W1X/wYw9Ix6bfjiijpMKPiPhiVOcS3J+ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:(32856632585715); BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1169; x-ms-traffictypediagnostic: BN6PR14MB1169: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(192374486261705)(258766100185102); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BN6PR14MB1169; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1169; x-forefront-prvs: 0674DC6DD3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(346002)(376002)(39380400002)(396003)(13464003)(199004)(189003)(305945005)(4326008)(68736007)(7696005)(7736002)(59450400001)(93886005)(6436002)(74316002)(53546011)(229853002)(76176011)(6116002)(316002)(3846002)(66066001)(102836004)(6506007)(99936001)(14454004)(575784001)(97736004)(3660700001)(44832011)(99286004)(86362001)(26005)(55016002)(5250100002)(8676002)(81166006)(9686003)(476003)(81156014)(106356001)(486006)(6246003)(33656002)(186003)(6306002)(2906002)(3280700002)(5660300001)(25786009)(110136005)(105586002)(11346002)(446003)(2900100001)(8936002)(53936002)(478600001)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1169; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ze1AVL53dOueJ+CZA4CktJzRt8kPd8uoxarsFrHAM0MXS2EIrFZsUJVqG/3YhQ6n5anD76qMqjEOuCqg3VYTDdoN8TG2OcmFaa7ilTkw+hJXOTRhC6WTsL/ShMI+RR94dLi83YMvFGv5kdgVuz4wImzMan4DnfTWPP/DM8HV7a4I5XtstosofSttd+Nc+QbW spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_08CD_01D3ED4D.30BD1880" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 9aa8061d-f67b-443b-87c1-08d5bb85e0fd X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9aa8061d-f67b-443b-87c1-08d5bb85e0fd X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2018 23:36:42.0777 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1169 Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 23:36:49 -0000 ------=_NextPart_000_08CD_01D3ED4D.30BD1880 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit This is interesting, I hadn't thought of the parallels with WebRTC, despite the fact that I've given a talk on the fact that all of these things are basically the same problem. I have a soft spot for the WebRTC security stuff. It really is far more elegant and well designed than it initially appears. It's not perfect, but it's worth looking at closely and thinking carefully about. -Tim > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Wednesday, May 16, 2018 6:33 PM > To: Stephen Farrell ; Phillip Hallam-Baker > ; Tim Hollebeek > Cc: SPASM > Subject: Re: [lamps] S/MIME fix > > On 5/16/18 4:16 PM, Stephen Farrell wrote: > > - Designs pre-date web user agent which changes trust model (where's > > the private key kept? Needs new infrastructure) > > > To understand the challenges surrounding what you suggest, you probably > want to study the issues surrounding isolated media streams in WebRTC. > Start by looking at section 4.3.2.4 of draft-ietf-rtcweb-security, and then > read > through uWvB_9Olp-hukiQj_tS5vyo4=?d=J11B9dbh9pdZkagcAZSOz6N- > lMrt249fI1GArrhjTyT2Mv0bxRlEJ34cZbS87eUKrlHkdxKTyM16fzk6Oa2cbNkCsS6 > T7wEgMqMBZ7jiNVeZi__gmD30Y7U3ikHJyMppa7BM6IWhNCSXAbGI1SCtQpF9 > pZ2hlFhqpJrzzXd65YdPDL9iwlDdNbt72F5wUNK26Zb- > sF9hbGrLwyarefR9gaWnh15R3EjJ- > OqlLE4CDFWsBJGSxmMLBvwj263QrMrRM72PJxKZU3XFmsj9e3cEupBLjH6N0QX > oLmMD42i2wt0MnYSoCtKaiTWzTg33hRlj8XVNAc32mj0D- > o18pnLVxHi2q9Nbdn3kYxepwnSq&u=https%3A%2F%2Fwww.w3.org%2FTR%2F > webrtc%2F%23isolated-media-streams>. > > To create an analogous situation for secure email, you'd need to use > webcrypto > in a way that stored your private key in the browser (inaccessible to the > page), > and develop web standards that add some affordance for web pages to hand > encrypted data to the browser in a way that causes the corresponding > unencrypted data to be displayed to the user, but isolated from the web page > completely (e.g., rendered into an iframe that the parent cannot inspect). > > Whether that kind of isolated context for email (which should be usable for > real-time messaging as well, if done correctly) is reasonable or too clunky > to > work is yet to be seen. (I've had a few conversations that concluded "too > clunky," but reasonable people may disagree.) In any case, the bulk of the > work > for that kind of system would need to take place in the W3C. > > There are, of course, possible trade-offs to be made in which the user > trusts > the web-hosted mail service with access to message plain text, or even to > their > private key; but once you take that leap, you're doing scantly better than > the > hop-by-hop security provided by DANE and/or MTA-STS. > > /a ------=_NextPart_000_08CD_01D3ED4D.30BD1880 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwNTE2MjMzNjMwWjAvBgkqhkiG9w0BCQQxIgQgJzERX8mbj2Hp8v//8O19ILzIRg4H o9EJRFpd61H/OGgwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAFj+XFbmSWlKVNARaQHXhsvzSdqe3PKWnL0Kh0UvEvDPLgWESSeSrrwNShzfE8GbcY3gTpRj qRnz99pVD8UD3iizfNT3zN9GsXtTbj0LCUbRpGUtGI5YoKjOf8+SkvYmBlHNiZ/cgIX0t9AFPTKF uxmtZhNYFV+ePzAFPSpEVqsKj0UgPO1o7zKTgYVjp+teYY254TZQ/iUr+n2UXbpPSWoK8UujqAZd bzvpZSP/v2p0gczKHCYzoT5a2JYXgRRQ1CVRgvOvbilI8MLIIM9Z4fAv2ZlpVcuDt2naXrNQgm/y ly/rCja1SzpscAjFw325Wxo9+Zfxd6Jcf8ymuV2fp9sAAAAAAAA= ------=_NextPart_000_08CD_01D3ED4D.30BD1880-- From nobody Wed May 16 16:42:20 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684E0126D73 for ; Wed, 16 May 2018 16:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] 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 1MEDIyKDtHiv for ; Wed, 16 May 2018 16:42:16 -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 A7FC3126C2F for ; Wed, 16 May 2018 16:42:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3DDDABE55; Thu, 17 May 2018 00:42:14 +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 cPj4oR7GhfMR; Thu, 17 May 2018 00:42:03 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AF2BEBE2D; Thu, 17 May 2018 00:42:03 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1526514123; bh=3XzrqiGB/v/j23LiZ+URZicTdcH02E0zU+vnjLoAqOM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=dtD8gltRdaX04f2rZwDN5keWik25A0IXHlQV3JmSFsRjRhWd9K+gFxQPtFGG2haqD q8YWOUN69KX0WFN7sHg3qpv5yhzx3s/YR3dmzJo33WcNxjxXSGXT2CL1ezlGzwDRLe MWwO1NVIvOG8gA4b1av5R7k+V/0JVmer00FscUZQ= To: Adam Roach , Phillip Hallam-Baker , Tim Hollebeek Cc: SPASM References: <1e8468d7-da6c-62f1-e24b-1ee03df22606@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <93c0b3b3-f624-d84a-7c2b-41dc14cf9ae0@cs.tcd.ie> Date: Thu, 17 May 2018 00:42:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sVDn6w2wjjmgMXA7niBiO2N7TWDxDYrsA" Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 23:42:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sVDn6w2wjjmgMXA7niBiO2N7TWDxDYrsA Content-Type: multipart/mixed; boundary="l5T28nOfGVqwDQHulIkWFd9cqu8kb35SB"; protected-headers="v1" From: Stephen Farrell To: Adam Roach , Phillip Hallam-Baker , Tim Hollebeek Cc: SPASM Message-ID: <93c0b3b3-f624-d84a-7c2b-41dc14cf9ae0@cs.tcd.ie> Subject: Re: [lamps] S/MIME fix References: <1e8468d7-da6c-62f1-e24b-1ee03df22606@cs.tcd.ie> In-Reply-To: --l5T28nOfGVqwDQHulIkWFd9cqu8kb35SB Content-Type: multipart/mixed; boundary="------------52F381A09BE8933448CBAC83" Content-Language: en-GB This is a multi-part message in MIME format. --------------52F381A09BE8933448CBAC83 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 16/05/18 23:32, Adam Roach wrote: > On 5/16/18 4:16 PM, Stephen Farrell wrote: >> - Designs pre-date web user agent which changes trust model >> (where's the private key kept? Needs new infrastructure) >=20 >=20 > To understand the challenges surrounding what you suggest, Just to be clear - that was only a list of hard (or possibly killer) problems with no solutions suggested. I do agree with what you say below, though there could be at least one more option which'd be to keep your private key(s) for mail-message decryption on a key server (supposedly) controlled by the user and to have all your MUAs talk to it over some client-authenticated channel. Not saying that's any better or more practical than the ones you describe below though. Cheers, S > you probably > want to study the issues surrounding isolated media streams in WebRTC. > Start by looking at section 4.3.2.4 of draft-ietf-rtcweb-security, and > then read through . >=20 > To create an analogous situation for secure email, you'd need to use > webcrypto in a way that stored your private key in the browser > (inaccessible to the page), and develop web standards that add some > affordance for web pages to hand encrypted data to the browser in a way= > that causes the corresponding unencrypted data to be displayed to the > user, but isolated from the web page completely (e.g., rendered into an= > iframe that the parent cannot inspect). >=20 > Whether that kind of isolated context for email (which should be usable= > for real-time messaging as well, if done correctly) is reasonable or to= o > clunky to work is yet to be seen. (I've had a few conversations that > concluded "too clunky," but reasonable people may disagree.) In any > case, the bulk of the work for that kind of system would need to take > place in the W3C. >=20 > There are, of course, possible trade-offs to be made in which the user > trusts the web-hosted mail service with access to message plain text, o= r > even to their private key; but once you take that leap, you're doing > scantly better than the hop-by-hop security provided by DANE and/or > MTA-STS. >=20 > /a >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 --------------52F381A09BE8933448CBAC83 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6 UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM 1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/ lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9 lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/ VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3DTOQn -----END PGP PUBLIC KEY BLOCK----- --------------52F381A09BE8933448CBAC83-- --l5T28nOfGVqwDQHulIkWFd9cqu8kb35SB-- --sVDn6w2wjjmgMXA7niBiO2N7TWDxDYrsA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlr8wcsACgkQWrL68XsX K+oL4BAAjU8pluR2y5QZm8KeBFAvY+Dd7gNQxWE17N3xj7aGzDDCGw2NfKeTxu0y a1Uvdimdn8dfIfQ+dea1q94ca6+ue8A6Ta7aTD8bCGnZFNWQuoxoeIRC8MdL65dm BX07kvVynO0OMd72dwWKpsBE3/3Dp4kT7Hdx2TZkbUUcdzOlYC3E9px1xyNrS2Jf n9hhNH8kvFe/VZdk8uPBbfkUhPJuNVIWCPreyGlHliWv7LXYP9KTmjB4qt2wrdzM xrRTbqYI7ZRZjpG8RyUSu5EpP/dGPSAkDAwimF+jjvhaWroelA1NTW6kqGjNz4pV c9KmM9kzRcQurxek8+fNBvMHbnAXdfwYM2gCqfBhKrRRp8+6hOh5MskOniUobTQd tYoxI+TM9fadkAGojh+f2YAv8ZnxQQzq8ELTE5d15nLbEtv/m6ySgGf8DFWG6ppf DTx1uynhzLWFOiYkWIXZAy4zC0c+0Xuczh8TqwVWG8FA3mC7XHZfRPLQ8KL0h1Ny WXPUzhtB94WF/CAELtUoIQGHcEtdV3tb9Fnzix1t90ZlAjhVR5KwA6VsJticNrby SJbQBN66qFrEVp0kf9S7yCCvBUEdA80bMJBDSa45rnKhZ/wPHYrqomIZ3L/ZZLj4 UWXSIMy+XFdkwcHNmcxgwg0zjyQ7eZmK9QIkmK8/L1/p9SiPX20= =Rlfo -----END PGP SIGNATURE----- --sVDn6w2wjjmgMXA7niBiO2N7TWDxDYrsA-- From nobody Thu May 17 06:43:10 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8DE12EB15 for ; Thu, 17 May 2018 06:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 pOP0u975RbSS for ; Thu, 17 May 2018 06:42:47 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D21112EB37 for ; Thu, 17 May 2018 06:42:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0A012300A2D for ; Thu, 17 May 2018 09:42:45 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tzV8pSxypRDa for ; Thu, 17 May 2018 09:42:40 -0400 (EDT) Received: from new-host.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 02E783005C5 for ; Thu, 17 May 2018 09:42:39 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_46B555DA-F817-4324-A520-73BBE703970E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 17 May 2018 09:42:43 -0400 References: <559ab3c7-ee5f-22b9-ef02-c091765011d2@isode.com> <04ca01d3ed3c$5c158050$144080f0$@augustcellars.com> <951633c7-0cad-58e7-236c-bb82e44c9e9f@isode.com> To: SPASM In-Reply-To: <951633c7-0cad-58e7-236c-bb82e44c9e9f@isode.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 13:42:57 -0000 --Apple-Mail=_46B555DA-F817-4324-A520-73BBE703970E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 16, 2018, at 1:51 PM, Alexey Melnikov = wrote: > On 16/05/2018 18:35, Jim Schaad wrote: >=20 >> I will note that unless multipart/mixed has some special text = associated with it. Text/html is defined by RFC 1866 to only hold a = single HTML document. Thus building an HTML document from multiple = parts is not according to Hoyle. > Yes, but people do this anyway, as separate HTML body parts are = frequently valid HTML documents. So building from pieces works most(*) = of the time. >=20 > (*) spam and phishing nonwithstanding. I do not see a way to totally thwart eFail unless each portion of a = multi-part is processed in its own sandbox. Russ --Apple-Mail=_46B555DA-F817-4324-A520-73BBE703970E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On May 16, 2018, at 1:51 PM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:

On 16/05/2018 18:35, = Jim Schaad wrote:

I will note = that unless multipart/mixed has some special text associated with = it.  Text/html is defined by RFC 1866 to only = hold a single HTML document.  Thus building an HTML document from = multiple parts is not according to Hoyle.
Yes, but people do this anyway, as separate HTML = body parts are frequently valid HTML documents. So building from pieces = works most(*) of the time.

(*) spam and phishing nonwithstanding.

I do not see a = way to totally thwart eFail unless each portion of a multi-part is = processed in its own sandbox.

Russ

= --Apple-Mail=_46B555DA-F817-4324-A520-73BBE703970E-- From nobody Thu May 17 07:02:02 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394E2126D0C for ; Thu, 17 May 2018 07:02:00 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 1zzssmaZOt0d for ; Thu, 17 May 2018 07:01:58 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC88A12783A for ; Thu, 17 May 2018 07:01:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9CB3E3009FF for ; Thu, 17 May 2018 10:01:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uQh_TYCKv93r for ; Thu, 17 May 2018 10:01:51 -0400 (EDT) Received: from new-host.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id BCFE130044B; Thu, 17 May 2018 10:01:51 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Thu, 17 May 2018 10:01:52 -0400 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: References: <1e8468d7-da6c-62f1-e24b-1ee03df22606@cs.tcd.ie> To: Adam Roach X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 14:02:00 -0000 Adam: >=20 > On 5/16/18 4:16 PM, Stephen Farrell wrote: >> - Designs pre-date web user agent which changes trust model >> (where's the private key kept? Needs new infrastructure) >=20 >=20 > To understand the challenges surrounding what you suggest, you = probably want to study the issues surrounding isolated media streams in = WebRTC. Start by looking at section 4.3.2.4 of = draft-ietf-rtcweb-security, and then read through = . I see the parallel, and in fact, the biggest problem is the use of HTML = that includes a reference to something that is outside the message = itself. > To create an analogous situation for secure email, you'd need to use = webcrypto in a way that stored your private key in the browser = (inaccessible to the page), and develop web standards that add some = affordance for web pages to hand encrypted data to the browser in a way = that causes the corresponding unencrypted data to be displayed to the = user, but isolated from the web page completely (e.g., rendered into an = iframe that the parent cannot inspect). I am not following you. I do not see the requirement to do anything = with webcrypto. However, I completely agree with the need to isolate = each portion of the multi-part. Russ From nobody Thu May 17 08:37:35 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B03E12D965 for ; Thu, 17 May 2018 08:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 sSSrOZG_hE5w for ; Thu, 17 May 2018 08:37:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 670C81270AE for ; Thu, 17 May 2018 08:37:32 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4HFbU0i039103 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 17 May 2018 10:37:31 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Russ Housley Cc: SPASM References: <1e8468d7-da6c-62f1-e24b-1ee03df22606@cs.tcd.ie> From: Adam Roach Message-ID: Date: Thu, 17 May 2018 10:37:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 15:37:34 -0000 On 5/17/18 9:01 AM, Russ Housley wrote: >> To create an analogous situation for secure email, you'd need to use webcrypto in a way that stored your private key in the browser (inaccessible to the page), and develop web standards that add some affordance for web pages to hand encrypted data to the browser in a way that causes the corresponding unencrypted data to be displayed to the user, but isolated from the web page completely (e.g., rendered into an iframe that the parent cannot inspect). > I am not following you. I do not see the requirement to do anything with webcrypto. However, I completely agree with the need to isolate each portion of the multi-part. Presumably, we would need a means to generate a keypair, and to make the public key available to the webpage so that it can be conveyed to remote parties. That could be a new API, but it feels like something that could be added to webcrypto without much fuss. (I'll note that WebRTC did take the other approach, by defining an RTCPeerConnection.generateCertificate() method that is very roughly equivalent to window.crypto.subtle.generateKey(), but with the properties I describe above). Admittedly, this can all be done by the browser itself using local UI, but the general idea of the web platform is that you delegate only as little as is necessary to the browser. I mean, if you push enough of this to the local binary, and it becomes a full-fledged email client. ;) /a From nobody Thu May 17 08:46:34 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2732F12EB9E for ; Thu, 17 May 2018 08:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cP1lE6bkR6xJ for ; Thu, 17 May 2018 08:46:25 -0700 (PDT) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::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 2C5E512EB95 for ; Thu, 17 May 2018 08:46:23 -0700 (PDT) Received: by mail-ot0-x231.google.com with SMTP id n3-v6so5571866ota.5 for ; Thu, 17 May 2018 08:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=C+9/B+hM5Rje4Edo0R23Rf8zfodz4/0V2fPg4DeNlzA=; b=jHPrJT5mVo9sjOTNuHY1iVUXIzreidt8taXylm1W3Cdn/A5xvEppcO3eBwW1+vJQaD oxezitSJieTuFnEukx8SG4AOfh1MW6rTP26MOpO7YKViB6pdWOLZZeRLKGfAvUW/bjA9 Q+v2Dim8gtwxA/lgcOlF8Qgr2ME7W45dExECSjo2mdikmkpRsbMSXvRo2iOiCADSwZ8p uVwwegSLZ2uwj9d30Zf2ExFFTojn54mW33we3ZZvuIs/IPHN2t4oj4ZwTPwrgfqTmHLe MtmDwANMmBJvifXf0o8otXxnnmmfygdSgBzoZzOlmM+EU7YQ8iK8s6RTBLtvGk6p7Z6D RbgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=C+9/B+hM5Rje4Edo0R23Rf8zfodz4/0V2fPg4DeNlzA=; b=AiVQaLT/+e3p9cpgovK5QjlIOn6x204S10CUpaKsSKaDeAsgEq2AR/5vstEgn9wy+D WSB7qTuTLkDvFt+ycJHgNsv5720UO1wN4F1KPxz75UFCSPZVlWcmOGaTIiNkwZkutI4w MpxkEyXvReX4S54zaEqeO0R0CQhQrhECD7PgYUr/2AxJXUgA44L+G6xhNXIC84t1K8CI 29nUTzNOeTXKxYckr7yILFrDwWQ5xun1BK6lHh6Xth94JGFjgzWFdnLY+VUixraB2XK4 xFuKUsj+f506ndBFhd7BGSvi5Qug4nFyW8qvwrsf1MCn6zhmQlP7TJeMU90llpn2PnvJ ovug== X-Gm-Message-State: ALKqPwermsga6mcKbEVke4MWNZGNlWxkyqjzsw4WzIJD5pzzNNhjqQKN 38MDfBNK9vRqSNzkwhh3f/iJCzMi92z6eeWztlw= X-Google-Smtp-Source: AB8JxZpV3uQ0q2L4XHhyCIHEtt/uTLc4ne+OnwDBdnsSdRp4a3y43wC46yB1fnS02jMtxSxhzzXYLlcdBF4epn9P1lw= X-Received: by 2002:a9d:14b9:: with SMTP id d54-v6mr4156162ote.380.1526571982385; Thu, 17 May 2018 08:46:22 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:23:0:0:0:0:0 with HTTP; Thu, 17 May 2018 08:46:21 -0700 (PDT) In-Reply-To: References: <1e8468d7-da6c-62f1-e24b-1ee03df22606@cs.tcd.ie> From: Phillip Hallam-Baker Date: Thu, 17 May 2018 11:46:21 -0400 X-Google-Sender-Auth: ZNPbI22ANiQFw8i_b-HXYrq5mqY Message-ID: To: Adam Roach Cc: Russ Housley , SPASM Content-Type: multipart/alternative; boundary="000000000000bbf898056c68bcdc" Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 15:46:33 -0000 --000000000000bbf898056c68bcdc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 17, 2018 at 11:37 AM, Adam Roach wrote: > On 5/17/18 9:01 AM, Russ Housley wrote: > >> To create an analogous situation for secure email, you'd need to use >>> webcrypto in a way that stored your private key in the browser >>> (inaccessible to the page), and develop web standards that add some >>> affordance for web pages to hand encrypted data to the browser in a way >>> that causes the corresponding unencrypted data to be displayed to the u= ser, >>> but isolated from the web page completely (e.g., rendered into an ifram= e >>> that the parent cannot inspect). >>> >> I am not following you. I do not see the requirement to do anything wit= h >> webcrypto. However, I completely agree with the need to isolate each >> portion of the multi-part. >> > > Presumably, we would need a means to generate a keypair, and to make the > public key available to the webpage so that it can be conveyed to remote > parties. That could be a new API, but it feels like something that could = be > added to webcrypto without much fuss. (I'll note that WebRTC did take the > other approach, by defining an RTCPeerConnection.generateCertificate() > method that is very roughly equivalent to window.crypto.subtle.generateKe= y(), > but with the properties I describe above). > > Admittedly, this can all be done by the browser itself using local UI, bu= t > the general idea of the web platform is that you delegate only as little = as > is necessary to the browser. I mean, if you push enough of this to the > local binary, and it becomes a full-fledged email client. ;) =E2=80=8BThat was the CERN approach. Netscape disagreed, threw JavaScript together in a fortnight and launched it on the world with no consultation. We have been in damage control ever since. A modern Web browser is a Turing complete language for constructing thick clients for the Web Services of your choice. I don't like the fact but it is what it is. I am composing this in Gmail right now. And there is my outlook client in the window underneath. =E2=80=8BThe Web browser is not just a full fledged = email client, it is the client of choice. --000000000000bbf898056c68bcdc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Ma= y 17, 2018 at 11:37 AM, Adam Roach <adam@nostrum.com> wrote:<= br>
On 5/17/18 9:01 AM, Russ= Housley wrote:
To create an analogous situation for secure email, you'd need to use we= bcrypto in a way that stored your private key in the browser (inaccessible = to the page), and develop web standards that add some affordance for web pa= ges to hand encrypted data to the browser in a way that causes the correspo= nding unencrypted data to be displayed to the user, but isolated from the w= eb page completely (e.g., rendered into an iframe that the parent cannot in= spect).
I am not following you.=C2=A0 I do not see the requirement to do anything w= ith webcrypto.=C2=A0 However, I completely agree with the need to isolate e= ach portion of the multi-part.

 Presumably, we would need a means to generate a keypair, and to make the pu= blic key available to the webpage so that it can be conveyed to remote part= ies. That could be a new API, but it feels like something that could be add= ed to webcrypto without much fuss. (I'll note that WebRTC did take the = other approach, by defining an RTCPeerConnection.generateCertificate()= method that is very roughly equivalent to window.crypto.subtle.generateKey(), but with the properties I describe above).

Admittedly, this can all be done by the browser itself using local UI, but = the general idea of the web platform is that you delegate only as little as= is necessary to the browser. I mean, if you push enough of this to the loc= al binary, and it becomes a full-fledged email client. ;)
=
=E2=80=8BT= hat was the CERN approach.

Netscape disagreed, threw JavaScript together in a fortnight and launched= it on the world with no consultation. We have been in damage control ever = since.

A modern Web brows= er is a Turing complete language for constructing thick clients for the Web= Services of your choice. I don't like the fact but it is what it is.

I am composing this in Gma= il right now. And there is my outlook client in the window underneath. =E2= =80=8BThe Web browser is not just a full fledged email client, it is the cl= ient of choice.



--000000000000bbf898056c68bcdc-- From nobody Thu May 17 08:51:56 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0225D12D93E for ; Thu, 17 May 2018 08:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 ZzUspLMD7VYg for ; Thu, 17 May 2018 08:51:53 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A92881270A7 for ; Thu, 17 May 2018 08:51:53 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4HFpnjY041480 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 17 May 2018 10:51:50 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Phillip Hallam-Baker Cc: SPASM , Russ Housley References: <1e8468d7-da6c-62f1-e24b-1ee03df22606@cs.tcd.ie> From: Adam Roach Message-ID: Date: Thu, 17 May 2018 10:51:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EC45D7A48CDE7583D54C5B65" Content-Language: en-US Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 15:51:55 -0000 This is a multi-part message in MIME format. --------------EC45D7A48CDE7583D54C5B65 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/17/18 10:46 AM, Phillip Hallam-Baker wrote: > I am composing this in Gmail right now. And there is my outlook client > in the window underneath. ​The Web browser is not just a full fledged > email client, it is the client of choice. I don't want to get too far down the rabbit hole of semantics here, but claiming that a browser is an email client because it can run Gmail is fully congruent with claiming your operating system is an email client because it can run Outlook. More to the point: you know what I meant. /a --------------EC45D7A48CDE7583D54C5B65 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/17/18 10:46 AM, Phillip Hallam-Baker wrote:
I am composing this in Gmail right now. And there is my outlook client in the window underneath. ​The Web browser is not just a full fledged email client, it is the client of choice.


I don't want to get too far down the rabbit hole of semantics here, but claiming that a browser is an email client because it can run Gmail is fully congruent with claiming your operating system is an email client because it can run Outlook.

More to the point: you know what I meant.

/a

--------------EC45D7A48CDE7583D54C5B65-- From nobody Thu May 17 11:54:11 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46B1127058 for ; Thu, 17 May 2018 11:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 F7CaJsRL6Zbl for ; Thu, 17 May 2018 11:53:57 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E66D126C25 for ; Thu, 17 May 2018 11:53:57 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id C6C54680079E2 for ; Thu, 17 May 2018 11:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=rk2rUoQINpSIw0XADp6CtkxZ9ZY=; b= p1g2t1///vOJgUxdC9KIRKlBgGMlp6WHNqegp0WBI9Eh+iTF0pBmRX+3t+/sRzsh Zz3iybfTsm3KnmD4vOXBrAuBv+y6PF2pLASwNOpvA1SsIeQwlrKTbzRqxFjgQJdB PVNccuRt1KSeI3Ar9PdJim37LMDVmU3qM/BdsVFcEe8= Received: from mail-it0-f52.google.com (mail-it0-f52.google.com [209.85.214.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id B2860680079D8 for ; Thu, 17 May 2018 11:53:55 -0700 (PDT) Received: by mail-it0-f52.google.com with SMTP id y189-v6so10145316itb.2 for ; Thu, 17 May 2018 11:53:55 -0700 (PDT) X-Gm-Message-State: ALKqPwe4ySxJGN3JUUiI7H85z8SfYseq1sFuzMJfO3pOj6nkpM+VCzDQ lk9/Wg/hhlzsQe/IlmXCLkRqqcH2+5FCkk8W49E= X-Google-Smtp-Source: AB8JxZqUAixyP1LYVj9f5w9KVePeaCydcc8ZR4Dxey1uVkcUbezB51Z8fyeiDRb6ojN18A6TyelpCrB6nB+iD/jCM3c= X-Received: by 2002:a24:9d44:: with SMTP id f65-v6mr3831822itd.119.1526583235083; Thu, 17 May 2018 11:53:55 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:985a:0:0:0:0:0 with HTTP; Thu, 17 May 2018 11:53:54 -0700 (PDT) In-Reply-To: References: <1e8468d7-da6c-62f1-e24b-1ee03df22606@cs.tcd.ie> From: Ryan Sleevi Date: Thu, 17 May 2018 14:53:54 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Adam Roach Cc: Phillip Hallam-Baker , SPASM , Russ Housley Content-Type: multipart/alternative; boundary="0000000000007293c8056c6b5b15" Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 18:54:10 -0000 --0000000000007293c8056c6b5b15 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm having trouble understanding how the current discussion relates to the LAMPS work. It sounds from Phil's initial message, is that this isn't related to LAMPS. There's been suggestions that this might be the CA/Browser Forum (despite the CA/Browser Forum not even having a proposed charter to clean this up), that this might be a W3C/WHATWG issue (despite the browsers explicitly rejecting some of these proposals), or perhaps somewhere else. For my own understanding, is there a concrete proposal for either a document or work LAMPS should take on? Otherwise, would it be better to have this discussion elsewhere? On Thu, May 17, 2018 at 11:51 AM, Adam Roach wrote: > On 5/17/18 10:46 AM, Phillip Hallam-Baker wrote: > > I am composing this in Gmail right now. And there is my outlook client in > the window underneath. =E2=80=8BThe Web browser is not just a full fledge= d email > client, it is the client of choice. > > > I don't want to get too far down the rabbit hole of semantics here, but > claiming that a browser is an email client because it can run Gmail is > fully congruent with claiming your operating system is an email client > because it can run Outlook. > > More to the point: you know what I meant. > > /a > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > --0000000000007293c8056c6b5b15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm having trouble understanding how the current discu= ssion relates to the LAMPS work. It sounds from Phil's initial message,= is that this isn't related to LAMPS. There's been suggestions that= this might be the CA/Browser Forum (despite the CA/Browser Forum not even = having a proposed charter to clean this up), that this might be a W3C/WHATW= G issue (despite the browsers explicitly rejecting some of these proposals)= , or perhaps somewhere else.

For my own understanding, i= s there a concrete proposal for either a document or work LAMPS should take= on? Otherwise, would it be better to have this discussion elsewhere?
=

On Thu, May= 17, 2018 at 11:51 AM, Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
On 5/17/18 10:46 AM= , Phillip Hallam-Baker wrote:
I am composing this in Gmail right now. And there is my outlook client in the window underneath. =E2=80=8BThe Web browser is not just a full fled= ged email client, it is the client of choice.


I don't want to get too far down the rabbit hole of seman= tics here, but claiming that a browser is an email client because it can run Gmail is fully congruent with claiming your operating system is an email client because it can run Outlook.

More to the point: you know what I meant.

/a


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


--0000000000007293c8056c6b5b15-- From nobody Thu May 17 11:58:09 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA500127058 for ; Thu, 17 May 2018 11:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 uz70v5U80Iyw for ; Thu, 17 May 2018 11:58:04 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC06126C25 for ; Thu, 17 May 2018 11:58:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 65A1B300A2D for ; Thu, 17 May 2018 14:58:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2vj2ZItHmeWI for ; Thu, 17 May 2018 14:58:01 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id E6C85300435; Thu, 17 May 2018 14:58:00 -0400 (EDT) From: Russ Housley Message-Id: <858D7264-5B1D-4834-B122-CE49C1B89A32@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_46A27AF6-0D02-4B1E-AEA7-7B3C80A52A26" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 17 May 2018 14:58:01 -0400 In-Reply-To: Cc: SPASM To: Ryan Sleevi References: <1e8468d7-da6c-62f1-e24b-1ee03df22606@cs.tcd.ie> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 18:58:07 -0000 --Apple-Mail=_46A27AF6-0D02-4B1E-AEA7-7B3C80A52A26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ryan: It seems to me that the LAMPS WG should say something about how to avoid = the eFail attack in the Security Considerations of = draft-ietf-lamps-rfc5751. Russ > On May 17, 2018, at 2:53 PM, Ryan Sleevi wrote: >=20 > I'm having trouble understanding how the current discussion relates to = the LAMPS work. It sounds from Phil's initial message, is that this = isn't related to LAMPS. There's been suggestions that this might be the = CA/Browser Forum (despite the CA/Browser Forum not even having a = proposed charter to clean this up), that this might be a W3C/WHATWG = issue (despite the browsers explicitly rejecting some of these = proposals), or perhaps somewhere else. >=20 > For my own understanding, is there a concrete proposal for either a = document or work LAMPS should take on? Otherwise, would it be better to = have this discussion elsewhere? >=20 > On Thu, May 17, 2018 at 11:51 AM, Adam Roach > wrote: > On 5/17/18 10:46 AM, Phillip Hallam-Baker wrote: >> I am composing this in Gmail right now. And there is my outlook = client in the window underneath. =E2=80=8BThe Web browser is not just a = full fledged email client, it is the client of choice. >=20 > I don't want to get too far down the rabbit hole of semantics here, = but claiming that a browser is an email client because it can run Gmail = is fully congruent with claiming your operating system is an email = client because it can run Outlook. >=20 > More to the point: you know what I meant. >=20 > /a >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm = >=20 >=20 --Apple-Mail=_46A27AF6-0D02-4B1E-AEA7-7B3C80A52A26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ryan:

It = seems to me that the LAMPS WG should say something about how to avoid = the eFail attack in the Security Considerations = of draft-ietf-lamps-rfc5751.

Russ


On May 17, 2018, at 2:53 PM, = Ryan Sleevi <ryan-ietf@sleevi.com> wrote:

I'm having trouble understanding how the current discussion = relates to the LAMPS work. It sounds from Phil's initial message, is = that this isn't related to LAMPS. There's been suggestions that this = might be the CA/Browser Forum (despite the CA/Browser Forum not even = having a proposed charter to clean this up), that this might be a = W3C/WHATWG issue (despite the browsers explicitly rejecting some of = these proposals), or perhaps somewhere else.

For my own understanding, is there a = concrete proposal for either a document or work LAMPS should take on? = Otherwise, would it be better to have this discussion = elsewhere?

On Thu, May 17, 2018 at 11:51 AM, Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
On 5/17/18 10:46 = AM, Phillip Hallam-Baker wrote:
I am = composing this in Gmail right now. And there is my outlook client in the window underneath. =E2=80=8BThe Web browser is not just a full = fledged email client, it is the client of choice.


I don't want to get too far down the rabbit = hole of semantics here, but claiming that a browser is an email client because it can run Gmail is fully congruent with claiming your operating system is an email client because it can run Outlook.

More to the point: you know what I meant.

/a


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



= --Apple-Mail=_46A27AF6-0D02-4B1E-AEA7-7B3C80A52A26-- From nobody Thu May 17 12:36:11 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083FE126D85 for ; Thu, 17 May 2018 12:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 KsipHpQtNeMO for ; Thu, 17 May 2018 12:36:07 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FFCC12D942 for ; Thu, 17 May 2018 12:36:07 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTP id B8E0830002835 for ; Thu, 17 May 2018 12:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=8+WYd8E/jpqzRFCwMpNPU/5Kk94=; b= pk1oz9cVPLvrpiKloZLpiAt4D3jguE6YlrAAy9QhGGUCGiRfapvmntgdfxIfj6oL KXsi+hLU19SKiRlIepFTMjp9DexwYbIDPdIbGO3P5yY3yoQ9HCtCF/Rk16uW6Huk aOiNXWRsg4/Mo29BvoV/xiOkc61GwP1kTxG4EPzZ9WY= Received: from mail-it0-f42.google.com (mail-it0-f42.google.com [209.85.214.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTPSA id AB1723000282C for ; Thu, 17 May 2018 12:36:07 -0700 (PDT) Received: by mail-it0-f42.google.com with SMTP id q4-v6so10326614ite.3 for ; Thu, 17 May 2018 12:36:06 -0700 (PDT) X-Gm-Message-State: ALKqPwfrQdvtVSFnx/ewDXGlEH9b5bTOgIaxuJKXK3mkIcj6F9qWsclJ 3DieCFTff42gPs8xNSC4ra5MHADfwWcjmH6HPec= X-Google-Smtp-Source: AB8JxZq0PtMTmM/p0pZ/LJ3hFtEYkitbyXLSNeju0I7qpuzNpkjVktk17vVzxChQQsYPzah+oNJUpR+tf35Xh/ZirtI= X-Received: by 2002:a24:5e4d:: with SMTP id h74-v6mr3883936itb.91.1526585765706; Thu, 17 May 2018 12:36:05 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:985a:0:0:0:0:0 with HTTP; Thu, 17 May 2018 12:36:05 -0700 (PDT) In-Reply-To: <858D7264-5B1D-4834-B122-CE49C1B89A32@vigilsec.com> References: <1e8468d7-da6c-62f1-e24b-1ee03df22606@cs.tcd.ie> <858D7264-5B1D-4834-B122-CE49C1B89A32@vigilsec.com> From: Ryan Sleevi Date: Thu, 17 May 2018 15:36:05 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Russ Housley Cc: Ryan Sleevi , SPASM Content-Type: multipart/alternative; boundary="00000000000048e59c056c6bf284" Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 19:36:09 -0000 --00000000000048e59c056c6bf284 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sure, that part sounded uncontroversial. I was simply having a hard time about the WebCrypto API or the philosophical differences of CERN and Netscape's design philosophies was helping us move towards that. The conversation from Jim and Alexey seemed a great path forward to exploring that. On Thu, May 17, 2018 at 2:58 PM, Russ Housley wrote: > Ryan: > > It seems to me that the LAMPS WG should say something about how to avoid > the eFail attack in the Security Considerations of draft-ietf-lamps-rfc57= 51. > > Russ > > > On May 17, 2018, at 2:53 PM, Ryan Sleevi wrote: > > I'm having trouble understanding how the current discussion relates to th= e > LAMPS work. It sounds from Phil's initial message, is that this isn't > related to LAMPS. There's been suggestions that this might be the > CA/Browser Forum (despite the CA/Browser Forum not even having a proposed > charter to clean this up), that this might be a W3C/WHATWG issue (despite > the browsers explicitly rejecting some of these proposals), or perhaps > somewhere else. > > For my own understanding, is there a concrete proposal for either a > document or work LAMPS should take on? Otherwise, would it be better to > have this discussion elsewhere? > > On Thu, May 17, 2018 at 11:51 AM, Adam Roach wrote: > >> On 5/17/18 10:46 AM, Phillip Hallam-Baker wrote: >> >> I am composing this in Gmail right now. And there is my outlook client i= n >> the window underneath. =E2=80=8BThe Web browser is not just a full fledg= ed email >> client, it is the client of choice. >> >> >> I don't want to get too far down the rabbit hole of semantics here, but >> claiming that a browser is an email client because it can run Gmail is >> fully congruent with claiming your operating system is an email client >> because it can run Outlook. >> >> More to the point: you know what I meant. >> >> /a >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >> >> > > --00000000000048e59c056c6bf284 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sure, that part sounded uncontroversial. I was simply havi= ng a hard time about the WebCrypto API or the philosophical differences of = CERN and Netscape's design philosophies was helping us move towards tha= t. The conversation from Jim and Alexey seemed a great path forward to expl= oring that.

= On Thu, May 17, 2018 at 2:58 PM, Russ Housley <housley@vigilsec.com= > wrote:
Ryan:

It seems to me that the LAMPS WG sho= uld say something about how to avoid the eFail attack in the Security Consi= derations of=C2=A0draft-ietf-lamps-rfc5751.

Russ


On= May 17, 2018, at 2:53 PM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:

= I'm having trouble understanding how the current discussion relates to = the LAMPS work. It sounds from Phil's initial message, is that this isn= 't related to LAMPS. There's been suggestions that this might be th= e CA/Browser Forum (despite the CA/Browser Forum not even having a proposed= charter to clean this up), that this might be a W3C/WHATWG issue (despite = the browsers explicitly rejecting some of these proposals), or perhaps some= where else.

For my own understanding, is there a concret= e proposal for either a document or work LAMPS should take on? Otherwise, w= ould it be better to have this discussion elsewhere?

On Thu, May 17, 2018 at 11:= 51 AM, Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
On 5/17/18 10:46 AM, Phillip Hallam-Baker wrote:
I am composing this in Gmail right now. And there is my outlook client in the window underneath. =E2=80=8BThe Web browser is not just a full fled= ged email client, it is the client of choice.


I don't want to get too far down the rabbit hole of seman= tics here, but claiming that a browser is an email client because it can run Gmail is fully congruent with claiming your operating system is an email client because it can run Outlook.

More to t= he point: you know what I meant.

/a


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



--00000000000048e59c056c6bf284-- From nobody Thu May 17 13:00:54 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3CA1270B4 for ; Thu, 17 May 2018 13:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkkIUOvfvICV for ; Thu, 17 May 2018 13:00:50 -0700 (PDT) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (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 5E0C0126B6E for ; Thu, 17 May 2018 13:00:50 -0700 (PDT) Received: by mail-oi0-x243.google.com with SMTP id n65-v6so5123609oig.6 for ; Thu, 17 May 2018 13:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Qpcguy3XQ/8U86AuKtDS2JY6DrRsqS/K9RyPUwntzz8=; b=U7rhUw19OjP/Qdfcq6yiO3BbzlZS/4XF2kijDDf2IvECzcCmYnzd4T77v0snfUxCP8 RYkEIIv9g0aKKrePRZP3a+zMDGbTBoPESz/HWZjgitqxFlTmh2rOwr62UIia0wFe/TgX BM7A2840SwKzljkoZxJ5s0Ycj8+dn9VG2VCDUdT09fGGR5OEmLezl9LeN6qr6YJvuRC6 TJKP9dVRkW4nnJBl8H2QhavKX3MT3+QkHKBbE5hMD0KvaACqzVtoCj4mSSz3A/qx52/7 8utrYVX7YrBrSbuvyxFtkY6+l7ArPXqI+rE6UMnh14uuWOkf/jCXdwqxO5Jj4GRVP5yU /k7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Qpcguy3XQ/8U86AuKtDS2JY6DrRsqS/K9RyPUwntzz8=; b=VIwV2d+hHGOkBIhPjJ8Zp9uvTyYHHLTGPcCDrOGhuT5mZFVhTOKb/wOxHydHExahtK j+9SUB0fCupBvYB9ZiHg8BUQQtNiJJQTDsOmLhfiUBdbGDDJUbPhnzxpoCW9CIilBhut uHqcejLN43QlrSGPnXU07Y02Iq/aox4+zgc0ZHZFTvRDGSJBr5IMyyadlOGwiRhFPnRM UpQjqq8GFfsFINOMc5yV9D305MQq9EhGwv+ZZKrgOoqbZe9XYquNt1J8oMAg42muIDut GBMIppZIsxHhntBOSdYJsJyei8Fv8oFTmKYAY6kEJzgXuJkS4Af6UU6CGrBVabQIA3WA sI+g== X-Gm-Message-State: ALKqPwdVQu3Lr0K2EpFeOHWFLiS3R1g0/ivAtMLxYK2AuUXdeWaG2rTB zHudHfigrxe6Vr5XCEOLaznhYRn5FEZ+/0tOFAk= X-Google-Smtp-Source: AB8JxZpo6J3ccp/MMuYgqo3iddiBAH1rD92x7OCGkxvdpA0SfyCBidv4dsxkuTtDi961qvWqnTPE9F2snhbJN5VfxlA= X-Received: by 2002:aca:720a:: with SMTP id p10-v6mr4284297oic.180.1526587249333; Thu, 17 May 2018 13:00:49 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:23:0:0:0:0:0 with HTTP; Thu, 17 May 2018 13:00:48 -0700 (PDT) In-Reply-To: References: <1e8468d7-da6c-62f1-e24b-1ee03df22606@cs.tcd.ie> From: Phillip Hallam-Baker Date: Thu, 17 May 2018 16:00:48 -0400 X-Google-Sender-Auth: trTdgjbEoJjRn3eeSp7lrJJUFZQ Message-ID: To: Ryan Sleevi Cc: Adam Roach , SPASM , Russ Housley Content-Type: multipart/alternative; boundary="000000000000b71aa5056c6c4a7c" Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 20:00:53 -0000 --000000000000b71aa5056c6c4a7c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am not sure why this discussion would cause confusion as it is normal for people to discuss the broad outlines of a proposal before writing text. It is also common for people to discuss an emerging security issue in a closely related working group before deciding on what the appropriate venue to hold discussions in would be. Even more so in this case since the problem and solution spaces are strongly constrained and I suspect that there is a very wide range of agreement about what needs to be done and how to approach a solution. But if you will insist on Internet Drafts relevant to the subject matter, you will find my proposals on the topic here: http://mathmesh.com/Resources/ Since my design brief was to provide a proof of concept, I started from a clean state and ignored existing work. Now that we have established that transparent end-to-end security is possible we can look at what changes we would need to make to the existing mail infrastructure to apply that approach to legacy systems. On Thu, May 17, 2018 at 2:53 PM, Ryan Sleevi wrote: > I'm having trouble understanding how the current discussion relates to th= e > LAMPS work. It sounds from Phil's initial message, is that this isn't > related to LAMPS. There's been suggestions that this might be the > CA/Browser Forum (despite the CA/Browser Forum not even having a proposed > charter to clean this up), that this might be a W3C/WHATWG issue (despite > the browsers explicitly rejecting some of these proposals), or perhaps > somewhere else. > > For my own understanding, is there a concrete proposal for either a > document or work LAMPS should take on? Otherwise, would it be better to > have this discussion elsewhere? > > On Thu, May 17, 2018 at 11:51 AM, Adam Roach wrote: > >> On 5/17/18 10:46 AM, Phillip Hallam-Baker wrote: >> >> I am composing this in Gmail right now. And there is my outlook client i= n >> the window underneath. =E2=80=8BThe Web browser is not just a full fledg= ed email >> client, it is the client of choice. >> >> >> I don't want to get too far down the rabbit hole of semantics here, but >> claiming that a browser is an email client because it can run Gmail is >> fully congruent with claiming your operating system is an email client >> because it can run Outlook. >> >> More to the point: you know what I meant. >> >> /a >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >> >> > --000000000000b71aa5056c6c4a7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I a= m not sure why this discussion would cause confusion as it is normal for pe= ople to discuss the broad outlines of a proposal before writing text. It is= also common for people to discuss an emerging security issue in a closely = related working group before deciding on what the appropriate venue to hold= discussions in would be.

Even more so in this case since the problem and solution spaces are strong= ly constrained and I suspect that there is a very wide range of agreement a= bout what needs to be done and how to approach a solution.

But if you will insist on Internet Draft= s relevant to the subject matter, you will find my proposals on the topic h= ere:

=
htt= p://mathmesh.com/Resources/

Since my design brief was to provide a proof of concept, I start= ed from a clean state and ignored existing work. Now that we have establish= ed that transparent end-to-end security is possible we can look at what cha= nges we would need to make to the existing mail infrastructure to apply tha= t approach to legacy systems.


On Thu, May 17, 2018 at 2:53 PM, Ryan Sleevi <= ryan-ietf@sleevi.= com> wrote:
I'm having trouble understanding how the current d= iscussion relates to the LAMPS work. It sounds from Phil's initial mess= age, is that this isn't related to LAMPS. There's been suggestions = that this might be the CA/Browser Forum (despite the CA/Browser Forum not e= ven having a proposed charter to clean this up), that this might be a W3C/W= HATWG issue (despite the browsers explicitly rejecting some of these propos= als), or perhaps somewhere else.

For my own understandin= g, is there a concrete proposal for either a document or work LAMPS should = take on? Otherwise, would it be better to have this discussion elsewhere?

On Thu, May 17, 2018 at 11:51 AM, Adam Roach <adam@no= strum.com> wrote:
=20 =20 =20
On 5/17/18 10:46 AM, Phillip Hallam-Baker wrote:
I am composing this in Gmail right now. And there is my outlook client in the window underneath. =E2=80=8BThe Web browser is not just a full fled= ged email client, it is the client of choice.


I don't want to get too far down the rabbit hole of seman= tics here, but claiming that a browser is an email client because it can run Gmail is fully congruent with claiming your operating system is an email client because it can run Outlook.

More to the point: you know what I meant.

/a


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



--000000000000b71aa5056c6c4a7c-- From nobody Thu May 17 19:04:31 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F91126D0C for ; Thu, 17 May 2018 19:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exuVd6RVsR2Y for ; Thu, 17 May 2018 19:04:28 -0700 (PDT) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 0C62A126BF3 for ; Thu, 17 May 2018 19:04:28 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id 15-v6so7326520otn.12 for ; Thu, 17 May 2018 19:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2iXCjvTtbg0blSWBEu3iy11HkV4czIvWEuX7Ud0Zzto=; b=asbRN9P/mJsAVPdPLY+TPLOJuIzRDko8D1Q8Jz6MIUXHpZWiXuy11V7LxhAD8RCL7u LIyqHF0onQ6XAyF+qSi4FL54Ko5bABzS4jXVHxnCq7NxpQXdqAWXut++wAprHRTq2oLC fa0WYhUBB6y5aqNFGGE82HpgnhIBeLvqWVTW7fv7hOnhNaZB+7oGlnh5Rr2yQ0bcjFA+ srezIq+hJXA8WSW2wI5AJAELKDvIw+TxH5rYrWOxMgZOjuXWp09731358Selycp8peb/ GX+5hDHwOpUWc6a80MENn67b2blHqcFHYFspli4hL1gnuh3HX/8KobmLHQw/ZWCZ9ISU E0WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=2iXCjvTtbg0blSWBEu3iy11HkV4czIvWEuX7Ud0Zzto=; b=cBZ5f99TJaxjm+sNYwKSigcPe4VXrCMzs3C1ZCQJnTpbJrYs2l3VG/XFGiT3tEj13Y +W++oNHHC9MSUmLG2uG9XuHrsXn9hlHzf+89lpCESrS2Q8QCQGqu18lH29/YWAb5dl13 3orrSqJc9JGhWz38R9N28jW8/71GYd58XCIA59WkuLkpcaTx6cxF8+2tVekmNO7PvZZL RM5KDBBYX3FUZvoGoLgaknVN/ZLWVvk/W48rxFlBK2qSur+lr7JRRL8w/toMSkFsf95j v+V19mTrxwysPsk2MHAOWlNajH/SdkCvAXNVRIb0+s56CUuAO+YT+m59VygxPLqQRmke q3Ww== X-Gm-Message-State: ALKqPwcDEXN2msmmObT5rE5R0Ua7UPFg6pq7FVwbssT1HTm80vGf5nR9 50XnaBlmJEFX1ASNm4ElkTzYa/UEh89fzm/nr6o= X-Google-Smtp-Source: AB8JxZqk8TA0JBl7Z6WBYeVmRGY9j3gSxBWKU50f+eWNQhZognIo9Kc1I5zo9YQIHxVaDZhSAOCMRMB0NtEWCNBWYts= X-Received: by 2002:a9d:2511:: with SMTP id k17-v6mr4849658otb.129.1526609067359; Thu, 17 May 2018 19:04:27 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:23:0:0:0:0:0 with HTTP; Thu, 17 May 2018 19:04:26 -0700 (PDT) In-Reply-To: References: <559ab3c7-ee5f-22b9-ef02-c091765011d2@isode.com> <04ca01d3ed3c$5c158050$144080f0$@augustcellars.com> <951633c7-0cad-58e7-236c-bb82e44c9e9f@isode.com> From: Phillip Hallam-Baker Date: Thu, 17 May 2018 22:04:26 -0400 X-Google-Sender-Auth: -bBUgm9cRI_vjZXIGG-R9AAYHmU Message-ID: To: Russ Housley Cc: SPASM Content-Type: multipart/alternative; boundary="0000000000002bc41d056c715f46" Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 02:04:30 -0000 --0000000000002bc41d056c715f46 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 17, 2018 at 9:42 AM, Russ Housley wrote: > On May 16, 2018, at 1:51 PM, Alexey Melnikov > wrote: > > On 16/05/2018 18:35, Jim Schaad wrote: > > I will note that unless multipart/mixed has some special text associated > with it. Text/html is defined by RFC 1866 to only hold a single HTML > document. Thus building an HTML document from multiple parts is not > according to Hoyle. > > Yes, but people do this anyway, as separate HTML body parts are frequentl= y > valid HTML documents. So building from pieces works most(*) of the time. > > (*) spam and phishing nonwithstanding. > > > I do not see a way to totally thwart eFail unless each portion of a > multi-part is processed in its own sandbox. > =E2=80=8BI concur with Russ on this. Though defining what a sandbox is may = be a challenge.=E2=80=8B =E2=80=8BWhile I don't doubt that spammers are abusing multipart/related, i= s there a circumstance in which an end user is likely to generate an email with text/html split across several multipart/related blocks? I think that is really rather unlikely. The gadget attack is less of a concern to me since encryption never assures authentication, thats why you need authenticated encryption or a MAC. --0000000000002bc41d056c715f46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On = Thu, May 17, 2018 at 9:42 AM, Russ Housley <housley@vigilsec.com>= ; wrote:
On May 16, 2018, at 1:51 PM, Alexey Melnikov <alexey.melnikov@isode.com= > wrote:
<= div>

On 16/05/2018 18:35, Jim Schaad wrote:<= br>

I will note that unless multipart/mixed has some special text associat= ed with it.=C2=A0 Text/html is defined by=C2=A0RFC 1866 to only hold a singl= e HTML document.=C2=A0 Thus building an HTML document from multiple parts i= s not according to Hoyle.
Yes, but people do this anywa= y, as separate HTML body parts are frequently valid HTML documents. So buil= ding from pieces works most(*) of the time.

(*) spam and phishing nonwithstanding.=

<= /span>I do not see a way to totally thwart eFail unless each portion of a m= ulti-part is processed in its own sandbox.
=E2=80= =8BI concur with Russ on this. Though defining what a sandbox is may be a c= hallenge.=E2=80=8B

=E2=80=8BWhile I don't doubt that spammers are abu= sing multipart/related, is there a circumstance in which an end user is lik= ely to generate an email with text/html split across several multipart/rela= ted blocks? I think that is really rather unlikely.=C2=A0


The gadget attack is less of a concern to me since= encryption never assures authentication, thats why you need authenticated = encryption or a MAC.
--0000000000002bc41d056c715f46-- From nobody Fri May 18 04:18:23 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E14312D868 for ; Fri, 18 May 2018 04:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 OliDiuqNrOx0 for ; Fri, 18 May 2018 04:18:17 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6271412D7F8 for ; Fri, 18 May 2018 04:18:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 518943005AE for ; Fri, 18 May 2018 07:18:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Zk-_WEhwntsP for ; Fri, 18 May 2018 07:18:14 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id E85B230044B for ; Fri, 18 May 2018 07:18:13 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_46EB5316-6FCC-495F-B6C4-4AC9F0FEDEAD" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 18 May 2018 07:18:14 -0400 References: <1e8468d7-da6c-62f1-e24b-1ee03df22606@cs.tcd.ie> To: SPASM In-Reply-To: Message-Id: <2D6DD22A-AB08-409B-AB74-B6F27511F878@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] S/MIME fix X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 11:18:20 -0000 --Apple-Mail=_46EB5316-6FCC-495F-B6C4-4AC9F0FEDEAD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 { RETRANSMISSION due to the short mail list outage yesterday. } Ryan: It seems to me that the LAMPS WG should say something about how to avoid = the eFail attack in the Security Considerations of = draft-ietf-lamps-rfc5751. Russ > On May 17, 2018, at 2:53 PM, Ryan Sleevi > wrote: >=20 > I'm having trouble understanding how the current discussion relates to = the LAMPS work. It sounds from Phil's initial message, is that this = isn't related to LAMPS. There's been suggestions that this might be the = CA/Browser Forum (despite the CA/Browser Forum not even having a = proposed charter to clean this up), that this might be a W3C/WHATWG = issue (despite the browsers explicitly rejecting some of these = proposals), or perhaps somewhere else. >=20 > For my own understanding, is there a concrete proposal for either a = document or work LAMPS should take on? Otherwise, would it be better to = have this discussion elsewhere? >=20 > On Thu, May 17, 2018 at 11:51 AM, Adam Roach > wrote: > On 5/17/18 10:46 AM, Phillip Hallam-Baker wrote: >> I am composing this in Gmail right now. And there is my outlook = client in the window underneath. =E2=80=8BThe Web browser is not just a = full fledged email client, it is the client of choice. >=20 > I don't want to get too far down the rabbit hole of semantics here, = but claiming that a browser is an email client because it can run Gmail = is fully congruent with claiming your operating system is an email = client because it can run Outlook. >=20 > More to the point: you know what I meant. >=20 > /a >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm = >=20 >=20 --Apple-Mail=_46EB5316-6FCC-495F-B6C4-4AC9F0FEDEAD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

{ RETRANSMISSION due to the short mail list outage yesterday. = }

Ryan:

It seems to me that the = LAMPS WG should say something about how to avoid the eFail attack in the = Security Considerations of draft-ietf-lamps-rfc5751.

Russ


On May = 17, 2018, at 2:53 PM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:

I'm having trouble understanding how the current discussion = relates to the LAMPS work. It sounds from Phil's initial message, is = that this isn't related to LAMPS. There's been suggestions that this = might be the CA/Browser Forum (despite the CA/Browser Forum not even = having a proposed charter to clean this up), that this might be a = W3C/WHATWG issue (despite the browsers explicitly rejecting some of = these proposals), or perhaps somewhere else.

For my own understanding, is there a = concrete proposal for either a document or work LAMPS should take on? = Otherwise, would it be better to have this discussion = elsewhere?

On Thu, May 17, 2018 at 11:51 AM, Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
On 5/17/18 10:46 = AM, Phillip Hallam-Baker wrote:
I am = composing this in Gmail right now. And there is my outlook client in the window underneath. =E2=80=8BThe Web browser is not just a full = fledged email client, it is the client of choice.


I don't want to get too far down the rabbit = hole of semantics here, but claiming that a browser is an email client because it can run Gmail is fully congruent with claiming your operating system is an email client because it can run Outlook.

More to the point: you know what I meant.

/a


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



= --Apple-Mail=_46EB5316-6FCC-495F-B6C4-4AC9F0FEDEAD-- From nobody Fri May 18 10:45:51 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E5212D95D for ; Fri, 18 May 2018 10:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VU8milJn5cDG for ; Fri, 18 May 2018 10:45:48 -0700 (PDT) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 7F1E412D942 for ; Fri, 18 May 2018 10:45:48 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id n1-v6so10037051otf.7 for ; Fri, 18 May 2018 10:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BI23+dH3oG4/yN3QbCxWaaokxe57eko5QBWK/tPVsgA=; b=Tij/JOg+fKCUH8wO4q4qZNwBxoAEg/33i7oXu4WZHEd6CPTOzgiGKGNRxgUiT45Uew WxMf+dyEzkNW1wjDmSNoSop6PkWyjFp6G/Fach16S2aWoSMe6GDS5oHsatkBv1ravWPj IZMzehI70gvN1nHOj+0NLW8aWrEjieKhCwpWbpKApAlzNqbHpDI2rnJZK13CUmErrb6d rcat0VNWm36OisJMJasdTpp6d/gPylCykrLzpP+IgiJ8fOcEPcUtIk17t7WqEMvbRcMb siO0YwFKtEZj9ka/5oXoRaYoibMYYuVZ7p2WjEqGTgUuJev8Ruh0zisVEjSd0TU8cGKu IK7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BI23+dH3oG4/yN3QbCxWaaokxe57eko5QBWK/tPVsgA=; b=Fg5TbEZkZ7AILZ2iG7IqD/i2ZCnrS45tiouPeF000TOnAtkDHrHqNX6G1Q3vQydTna f71VaINQbqrC9aMEviC2AcnlHpMcyLChIAt7vDywl5MAU3a3yLgHtz4xTibnMQk2eLDC LgOVyC5xEeN6ZCvAHrKD0q/iSQkz/kxJK0nywBQv480/8Kmwd9Gh5pLtAWvuCFNHeIxU 4OJIAhfpN4cPoTsU5RiaPtYNBXoTmo5Tw8cO+ZsCrg07GW5tl+oSZE8sU+2DSNCQcuxP Hq2kv6++V+jILBGQ2suM711ZSwuTys1AOa3lgxI0+eVB8R/G5veit2J1OAQn5UzlIruL 7x1g== X-Gm-Message-State: ALKqPwdeXvgDqPoZ+NNYBFLiO+eWTh3IO8E9Ury4v3LUsGBo9FVhfUag uvgN0hKRMwA2bRoX5nbBsUXfksQrYsJo4wi8DfPOTw== X-Google-Smtp-Source: AB8JxZq1yYb5QL2PmOdnt9hcbcAVRwfd0PQ4ya47JRhQ+PPw9iGA4vTna+P0phh0CtQYWXLHrH2/71VV4Z7hAqAdYTk= X-Received: by 2002:a9d:1055:: with SMTP id o21-v6mr7447386oto.371.1526665547926; Fri, 18 May 2018 10:45:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Fri, 18 May 2018 10:45:07 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 18 May 2018 10:45:07 -0700 Message-ID: To: Wayne Thayer Cc: SPASM Content-Type: multipart/alternative; boundary="000000000000ace73f056c7e8587" Archived-At: Subject: Re: [lamps] CAA Semantics for S/MIME X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 17:45:50 -0000 --000000000000ace73f056c7e8587 Content-Type: text/plain; charset="UTF-8" I agree that this is out of the proposed charter. If the WG wants to add it as a charter item now, that seems fine. -Ekr On Tue, May 15, 2018 at 6:00 PM, Wayne Thayer wrote: > There is a vigorous discussion about CAA and S/MIME certificates happening > over on the mozilla.dev.security.policy list [1]. It has been proposed that > this issue could be addressed as part of rfc6844bis, but I'm reading the > LAMPS recharter as being too narrow in scope to permit this. Does this work > need to be deferred to a future LAMPS recharter? > > - Wayne > > [1] https://groups.google.com/d/msg/mozilla.dev.security. > policy/NIc2Nwa9Msg/RGx4A5HBBAAJ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > --000000000000ace73f056c7e8587 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that this is out of the proposed charter. If = the WG wants to add it as a charter item now, that seems fine.
-Ekr


=
On Tue, May 15, 2018 at 6:00 PM, Wayne Thayer <= wthayer@gmail.com> wrote:
<= div dir=3D"ltr">
There is a vigorous discussion about CAA and S/MIME ce= rtificates happening over on the mozilla.dev.security.policy list [1]. It h= as been proposed that this issue could be addressed as part of rfc6844bis, = but I'm reading the LAMPS recharter as being too narrow in scope to per= mit this. Does this work need to be deferred to a future LAMPS recharter?
- Wayne

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


--000000000000ace73f056c7e8587-- From nobody Fri May 18 20:24:11 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0FA12E8C6 for ; Fri, 18 May 2018 20:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 HcGxcpSKQhi3 for ; Fri, 18 May 2018 20:24:06 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 C1D7312E8C5 for ; Fri, 18 May 2018 20:24:06 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id l1-v6so8822479oii.1 for ; Fri, 18 May 2018 20:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9+292oQEnqmrBT6l3/63V2eny+8LLV49AOxKNQtyjPg=; b=Q3s3x9uf2mMDP8BLQ+CUEH+SHoxL9KinYz7BXTYuRYrmNk2qH2tQlpkEpFL2+x5y5E O/5ZZhXp5iLTs8UXE6yt/oP2Ea6L0Df15f/8zfGMHJFDAhl+QkyXMzKPd93LnJATWMGv YTZC05xUh0R7Td7F0zfbTqEsPaKjdWqcB6iPIOEE/J6nLtQ/cTb7ItwWWyZzW8R0PiwZ 1I7/0gf6+F6055dasieaWNyfvNTVLuGTfWqrH0pFaouIgOUtR4cI6CoU4EArwaI4x4gE qNLmXZ5TP61PYevzvoGmBbAkidZMn3CSQ2Af7IkNbHkjMz6zd+xuh1PSC9LNVY8dGSvv hTQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9+292oQEnqmrBT6l3/63V2eny+8LLV49AOxKNQtyjPg=; b=hMiNIcYkaKog4DVmU8f096fijvWBgvf9IUbQDooZIZdG282aECGiJP7pxcDB7QSLBO 8Zzr+Ih9Ui2VgH/K7BrgfM05FGcJeqye+X6xGsGJ2xhIkc9XZ2GBNTSg/zVurC01SwCh H6RxqH7nWM0X8/NZk6qAeIRx6MdbJEXB6gSf7hU1a/X7Ki5SccvwASESOk5ako/NH2eX 1YjrVwllO+YdQ6OJhA/bR1MKkusL+uAKWAbrPaZA69qwdKeH3Bb+77D3J/d22AGWV9wh w89gQus5NOjSf3uRESmVwixjgQFRVRkeFoSmK0A1KCGTGO/eI7IrIOcN9IqfdXwHAmsz Wfxw== X-Gm-Message-State: ALKqPwcpc94To/vtpLkdX6X+ihVbxtJRdVe3aTmKeXMll50yjEjqdRry tJV6bC0ACpsWy9xpeiE7vjFTuWKwh+28lVIDn4k= X-Google-Smtp-Source: AB8JxZoLliIyznZMi6CckQb/3xmVFLVTxn/YOEFBfuHKmE76uKoU0tDZzbDTJSqWrE4B4iFH7z51u9slCWI9HDhS4ww= X-Received: by 2002:aca:6257:: with SMTP id w84-v6mr7430837oib.26.1526700246049; Fri, 18 May 2018 20:24:06 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:23:0:0:0:0:0 with HTTP; Fri, 18 May 2018 20:24:05 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Fri, 18 May 2018 23:24:05 -0400 X-Google-Sender-Auth: 9i1WMgh_WBRFyByrCNudTsdA4ss Message-ID: To: Eric Rescorla Cc: Wayne Thayer , SPASM Content-Type: multipart/alternative; boundary="000000000000d82b13056c8699dc" Archived-At: Subject: Re: [lamps] CAA Semantics for S/MIME X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2018 03:24:09 -0000 --000000000000d82b13056c8699dc Content-Type: text/plain; charset="UTF-8" Perhaps we could have a side discussion about this at the London CABForum meeting if folk are there. On Fri, May 18, 2018 at 1:45 PM, Eric Rescorla wrote: > I agree that this is out of the proposed charter. If the WG wants to add > it as a charter item now, that seems fine. > > -Ekr > > > On Tue, May 15, 2018 at 6:00 PM, Wayne Thayer wrote: > >> There is a vigorous discussion about CAA and S/MIME certificates >> happening over on the mozilla.dev.security.policy list [1]. It has been >> proposed that this issue could be addressed as part of rfc6844bis, but I'm >> reading the LAMPS recharter as being too narrow in scope to permit this. >> Does this work need to be deferred to a future LAMPS recharter? >> >> - Wayne >> >> [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/ >> NIc2Nwa9Msg/RGx4A5HBBAAJ >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >> >> > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > --000000000000d82b13056c8699dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Per= haps we could have a side discussion about this at the London CABForum meet= ing if folk are there.


On = Fri, May 18, 2018 at 1:45 PM, Eric Rescorla <ekr@rtfm.com> wrot= e:
I agree that thi= s is out of the proposed charter. If the WG wants to add it as a charter it= em now, that seems fine.

-Ekr

=

On Tue, May 15, 2018 at 6:00 PM, Wayne Thayer <wthayer@gmail.c= om> wrote:
There is a vigorous discussion abo= ut CAA and S/MIME certificates happening over on the mozilla.dev.security.p= olicy list [1]. It has been proposed that this issue could be addressed as = part of rfc6844bis, but I'm reading the LAMPS recharter as being too na= rrow in scope to permit this. Does this work need to be deferred to a futur= e LAMPS recharter?

- Wayne

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



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


--000000000000d82b13056c8699dc-- From nobody Fri May 18 21:03:46 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B2912E8C8 for ; Fri, 18 May 2018 21:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.599, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 gLauE2Yd96At for ; Fri, 18 May 2018 21:03:42 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3387812E8CB for ; Fri, 18 May 2018 21:03:42 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id C8F4A6001306 for ; Fri, 18 May 2018 21:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=MFFBYESomMvEAXxo1FzR/CdjnoM=; b= s8WPXwDasOGbSJGegTk0aS0489CII9pojgcORKYqIxvwbOZ5JsTA1+lL4K9HjCZI AB52InrYnC5Ftu+KTOGymyCTUNU1viIW2hqQyIOn7CIP5emlHpb2OVdai6wyK5FL 210Qj5fP+g4PDLZXlc0Tsxw9izFvacSsPmUBoDlf1aE= Received: from mail-io0-f181.google.com (mail-io0-f181.google.com [209.85.223.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 93C786000129 for ; Fri, 18 May 2018 21:03:39 -0700 (PDT) Received: by mail-io0-f181.google.com with SMTP id g1-v6so8538482iob.2 for ; Fri, 18 May 2018 21:03:39 -0700 (PDT) X-Gm-Message-State: ALKqPwfb5Rhk/RFL8qPru4v6GF/O1tC66vXwz/bdSPMWtZrnkXBIT4ZK qnqvjbp0YCzi7e9xJwiIBD+vmSohCIy37CDtigc= X-Google-Smtp-Source: AB8JxZqN954gIcV02T+Q3MKeFFMVk2tGQgoHdAsGfwZYlM/lXUrOZpo0whIbiwd7yUE2PF5ZxnNXsAPA75mCXlpnqmI= X-Received: by 2002:a6b:d312:: with SMTP id s18-v6mr12783137iob.284.1526702618869; Fri, 18 May 2018 21:03:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ryan Sleevi Date: Sat, 19 May 2018 00:03:28 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Phillip Hallam-Baker Cc: Eric Rescorla , SPASM , Wayne Thayer Content-Type: multipart/alternative; boundary="000000000000469d4e056c872758" Archived-At: Subject: Re: [lamps] CAA Semantics for S/MIME X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2018 04:03:44 -0000 --000000000000469d4e056c872758 Content-Type: text/plain; charset="UTF-8" Seems like it would be better discussed in a place with open access and participation? To avoid capture by CAs by having a diverse set of views represented? On Fri, May 18, 2018 at 11:24 PM Phillip Hallam-Baker wrote: > Perhaps we could have a side discussion about this at the London CABForum > meeting if folk are there. > > > > On Fri, May 18, 2018 at 1:45 PM, Eric Rescorla wrote: > >> I agree that this is out of the proposed charter. If the WG wants to add >> it as a charter item now, that seems fine. >> >> -Ekr >> >> >> On Tue, May 15, 2018 at 6:00 PM, Wayne Thayer wrote: >> >>> There is a vigorous discussion about CAA and S/MIME certificates >>> happening over on the mozilla.dev.security.policy list [1]. It has been >>> proposed that this issue could be addressed as part of rfc6844bis, but I'm >>> reading the LAMPS recharter as being too narrow in scope to permit this. >>> Does this work need to be deferred to a future LAMPS recharter? >>> >>> - Wayne >>> >>> [1] >>> https://groups.google.com/d/msg/mozilla.dev.security.policy/NIc2Nwa9Msg/RGx4A5HBBAAJ >>> >>> _______________________________________________ >>> Spasm mailing list >>> Spasm@ietf.org >>> https://www.ietf.org/mailman/listinfo/spasm >>> >>> >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >> >> > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --000000000000469d4e056c872758 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Seems like it would be better discussed in a place w= ith open access and participation? To avoid capture by CAs by having a dive= rse set of views represented?

On F= ri, May 18, 2018 at 11:24 PM Phillip Hallam-Baker <phill@hallambaker.com> wrote:
Perhaps we could have a side discussion about this at the London CAB= Forum meeting if folk are there.



On Fri, May 18, 2018 at 1:45 PM, Eric Rescorla <ekr@rtfm.com> wrote:
I agree that this is out of the = proposed charter. If the WG wants to add it as a charter item now, that see= ms fine.

-Ekr


On Tue, May 15, 2018 at 6:00 PM, Wayne Thayer <<= a href=3D"mailto:wthayer@gmail.com" target=3D"_blank">wthayer@gmail.com= > wrote:
There is a vigorous discussi= on about CAA and S/MIME certificates happening over on the mozilla.dev.secu= rity.policy list [1]. It has been proposed that this issue could be address= ed as part of rfc6844bis, but I'm reading the LAMPS recharter as being = too narrow in scope to permit this. Does this work need to be deferred to a= future LAMPS recharter?

- Wayne

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



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


_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--000000000000469d4e056c872758-- From nobody Tue May 22 19:39:29 2018 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 708E012D96B for ; Tue, 22 May 2018 19:39:27 -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.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152704316745.26872.7061976644869307168.idtracker@ietfa.amsl.com> Date: Tue, 22 May 2018 19:39:27 -0700 From: IETF Secretariat Archived-At: Subject: [lamps] Milestones changed for lamps WG X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 02:39:27 -0000 Changed milestone "Adopt a draft for rfc6844bis", resolved as "Done". Changed milestone "Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512", resolved as "Done". Changed milestone "Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512", resolved as "Done". Added milestone "Adopt a draft for short-lived certificate conventions", due June 2018. Added milestone "Adopt a draft for the CMS with PSK", due June 2018. Added milestone "Adopt a draft for hash-based signatures with the CMS", due June 2018. Added milestone "Adopt a draft for root key rollover certificate extension", due June 2018. Changed milestone "rfc6844bis sent to IESG for standards track publication", set due date to July 2018 from April 2018. Added milestone "Root key rollover certificate extension sent to IESG for informational publication", due August 2018. Added milestone "Short-lived certificate conventions sent to IESG for BCP publication", due October 2018. Added milestone "The CMS with PSK sent to IESG for standards track publication", due October 2018. Added milestone "Hash-based signatures with the CMS sent to IESG for standards track publication", due December 2018. URL: https://datatracker.ietf.org/wg/lamps/about/ From nobody Tue May 22 19:43:43 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C977812D96A for ; Tue, 22 May 2018 19:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAlYqFuOKjPr for ; Tue, 22 May 2018 19:43:40 -0700 (PDT) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 0B27D1200C1 for ; Tue, 22 May 2018 19:43:40 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id m11-v6so23456627otf.3 for ; Tue, 22 May 2018 19:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tjh1lNRmwnIQms9iGtHdgALV3nwYSlRdeotDY37gMnQ=; b=MNswwgHtxeB8L1K61INeyw75+CWcP2wqE4JD7zMai+jtruuHNHzbh4wouwNjWU6lOG ZjCGmLzxYesLfeMNUceRBcHWLVDUsA9L5Q22RGN60/RNytzDNq1Cr0PIsQ9p3Kmzq0I+ j5nphpf5VSNC0zXVMTuHjwQvNOkHja/b+MB8CoE16jZuTvgoyG4fGSL1pXPrJG+OLEFf LcZQGOi02zo/IyaC4Jqo+6tXk66C2moG4TZppocMMveUWIyy4lGg9JtxpVgS1oEzesRS t8uoMi5jhSJQaDxXdz0GYTFdA3bC/grggZYDlHoXd1b5CsgRfoX/6rmjWusarDwjSmXY 1/eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tjh1lNRmwnIQms9iGtHdgALV3nwYSlRdeotDY37gMnQ=; b=tCq/5CMd0+QgvDObAvQXBDC3pEIJvwNpO3ijPJbSo7Ds6FNWxjZ0hOBRBQTA7M6kd0 q86usYIbc3bWG4QlibCGvShNVjm+VwlljaD5QCCoXbvBrVpGXFYUZ0ldlkjL+Pfbohqb KwIo2LcKH2Z6ZXnFU4Xx4bDTvJd12PQtxe9IyW0llpQIbx/yzuwokWnkiwGUnjEWM3ix El0yu2uQSUM5WUuYgjqVv/oNrCS9QfUnyBcvUfQVmbpmPZv3W5BZWuyQtmVtZTsOai1x eUr44lGTyi3dhjaUQrhwa3VaCnQ3gPQUsNQgAfjYvWiQH8jw0JaxqAChoITyRi6OVyje NBUQ== X-Gm-Message-State: ALKqPwfFLZjHAhu64bp8jIX5HU33wrScd4WkIXR8+9hyrOm+inkhby2s mD4CJBN54hOKUnb/kuOQ2TZEBmfmd9GgtotuP1pCFw== X-Google-Smtp-Source: AB8JxZquTHk3tTrTchgL0CB14bkozSD5yhPw8uMvO3qzJ2Ducg5BS5M3YPDfq3jaEANICFL0UIZd55kxY7ZqAKqGgHQ= X-Received: by 2002:a9d:224d:: with SMTP id o71-v6mr667692ota.101.1527043419350; Tue, 22 May 2018 19:43:39 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:66:0:0:0:0:0 with HTTP; Tue, 22 May 2018 19:42:58 -0700 (PDT) In-Reply-To: <152704316745.26872.7061976644869307168.idtracker@ietfa.amsl.com> References: <152704316745.26872.7061976644869307168.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Tue, 22 May 2018 19:42:58 -0700 Message-ID: To: IETF Secretariat Cc: SPASM Content-Type: multipart/alternative; boundary="000000000000913b0f056cd680f2" Archived-At: Subject: Re: [lamps] Milestones changed for lamps WG X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 02:43:42 -0000 --000000000000913b0f056cd680f2 Content-Type: text/plain; charset="UTF-8" Hmm.... I seem to have edited the in-place milestones rather than the prospective ones. I'll sort this out.... On Tue, May 22, 2018 at 7:39 PM, IETF Secretariat < ietf-secretariat-reply@ietf.org> wrote: > Changed milestone "Adopt a draft for rfc6844bis", resolved as "Done". > > Changed milestone "Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512", > resolved as "Done". > > Changed milestone "Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512", > resolved as "Done". > > Added milestone "Adopt a draft for short-lived certificate conventions", > due > June 2018. > > Added milestone "Adopt a draft for the CMS with PSK", due June 2018. > > Added milestone "Adopt a draft for hash-based signatures with the CMS", due > June 2018. > > Added milestone "Adopt a draft for root key rollover certificate > extension", > due June 2018. > > Changed milestone "rfc6844bis sent to IESG for standards track > publication", > set due date to July 2018 from April 2018. > > Added milestone "Root key rollover certificate extension sent to IESG for > informational publication", due August 2018. > > Added milestone "Short-lived certificate conventions sent to IESG for BCP > publication", due October 2018. > > Added milestone "The CMS with PSK sent to IESG for standards track > publication", due October 2018. > > Added milestone "Hash-based signatures with the CMS sent to IESG for > standards track publication", due December 2018. > > URL: https://datatracker.ietf.org/wg/lamps/about/ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --000000000000913b0f056cd680f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hmm.... I seem to have edited the in-place milestones rath= er than the prospective ones. I'll sort this out....

On Tue, May 22, 2018 at 7:= 39 PM, IETF Secretariat <ietf-secretariat-reply@ietf.org= > wrote:
=
Changed milestone "Adopt a draft for rfc6844bis"= ;, resolved as "Done".

Changed milestone "Adopt a PKIX draft for SHAKE128/256 and SHAKE256/51= 2",
resolved as "Done".

Changed milestone "Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/= 512",
resolved as "Done".

Added milestone "Adopt a draft for short-lived certificate conventions= ", due
June 2018.

Added milestone "Adopt a draft for the CMS with PSK", due June 20= 18.

Added milestone "Adopt a draft for hash-based signatures with the CMS&= quot;, due
June 2018.

Added milestone "Adopt a draft for root key rollover certificate exten= sion",
due June 2018.

Changed milestone "rfc6844bis sent to IESG for standards track publica= tion",
set due date to July 2018 from April 2018.

Added milestone "Root key rollover certificate extension sent to IESG = for
informational publication", due August 2018.

Added milestone "Short-lived certificate conventions sent to IESG for = BCP
publication", due October 2018.

Added milestone "The CMS with PSK sent to IESG for standards track
publication", due October 2018.

Added milestone "Hash-based signatures with the CMS sent to IESG for standards track publication", due December 2018.

URL: https://datatracker.ietf.org/wg/lamps/about/

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

--000000000000913b0f056cd680f2-- From nobody Tue May 22 20:02:36 2018 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE891200C1; Tue, 22 May 2018 20:02:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152704455343.26954.10233535327739436158@ietfa.amsl.com> Date: Tue, 22 May 2018 20:02:33 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc5751-bis-09.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 03:02:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification Authors : Jim Schaad Blake Ramsdell Sean Turner Filename : draft-ietf-lamps-rfc5751-bis-09.txt Pages : 58 Date : 2018-05-22 Abstract: This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-09 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5751-bis-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5751-bis-09 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 22 20:13:21 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356C712D96B for ; Tue, 22 May 2018 20:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60B6gleeUvWn for ; Tue, 22 May 2018 20:13:16 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB60312895E for ; Tue, 22 May 2018 20:13:15 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 22 May 2018 20:10:28 -0700 From: Jim Schaad To: 'SPASM' References: <152704455383.26954.22999208293898579.idtracker@ietfa.amsl.com> In-Reply-To: <152704455383.26954.22999208293898579.idtracker@ietfa.amsl.com> Date: Tue, 22 May 2018 20:13:08 -0700 Message-ID: <00ba01d3f243$fad54d90$f07fe8b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQF3WYoXrXg0WgooDhDE3H0g0W5Tm6T11JqQ Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [lamps] FW: New Version Notification for draft-ietf-lamps-rfc5751-bis-09.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 03:13:19 -0000 This version updates by adding two paragraphs to the security = considerations to deal with the Efail challenges. =20 EKR - I think that you should be able to take this to a telechat now. Jim -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Tuesday, May 22, 2018 8:03 PM To: Jim Schaad ; Blake Ramsdell = ; Sean Turner Subject: New Version Notification for = draft-ietf-lamps-rfc5751-bis-09.txt A new version of I-D, draft-ietf-lamps-rfc5751-bis-09.txt has been successfully submitted by Jim Schaad and posted to the IETF = repository. Name: draft-ietf-lamps-rfc5751-bis Revision: 09 Title: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version = 4.0 Message Specification Document date: 2018-05-22 Group: lamps Pages: 58 URL: = https://www.ietf.org/internet-drafts/draft-ietf-lamps-rfc5751-bis-09.txt Status: = https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ Htmlized: = https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-09 Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5751-bis Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-rfc5751-bis-09 Abstract: This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. = =20 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. The IETF Secretariat From nobody Wed May 23 06:10:22 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1C712DA6A for ; Wed, 23 May 2018 06:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 IWqDqT7n52-T for ; Wed, 23 May 2018 06:10:17 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64281124D6C for ; Wed, 23 May 2018 06:10:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 59945300A23 for ; Wed, 23 May 2018 09:10:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id exG4eEjjGqem for ; Wed, 23 May 2018 09:10:09 -0400 (EDT) Received: from [10.5.245.234] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id E818830048E; Wed, 23 May 2018 09:10:05 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_563619B2-5A38-4B39-984A-68BF4308E974" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 23 May 2018 09:10:04 -0400 In-Reply-To: Cc: SPASM To: Eric Rescorla References: <152704316745.26872.7061976644869307168.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Milestones changed for lamps WG X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 13:10:20 -0000 --Apple-Mail=_563619B2-5A38-4B39-984A-68BF4308E974 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Those "Done" items are on the current charter, so no problem. Russ > On May 22, 2018, at 10:42 PM, Eric Rescorla wrote: >=20 > Hmm.... I seem to have edited the in-place milestones rather than the = prospective ones. I'll sort this out.... >=20 > On Tue, May 22, 2018 at 7:39 PM, IETF Secretariat = > wrote: > Changed milestone "Adopt a draft for rfc6844bis", resolved as "Done". >=20 > Changed milestone "Adopt a PKIX draft for SHAKE128/256 and = SHAKE256/512", > resolved as "Done". >=20 > Changed milestone "Adopt a S/MIME draft for SHAKE128/256 and = SHAKE256/512", > resolved as "Done". >=20 > Added milestone "Adopt a draft for short-lived certificate = conventions", due > June 2018. >=20 > Added milestone "Adopt a draft for the CMS with PSK", due June 2018. >=20 > Added milestone "Adopt a draft for hash-based signatures with the = CMS", due > June 2018. >=20 > Added milestone "Adopt a draft for root key rollover certificate = extension", > due June 2018. >=20 > Changed milestone "rfc6844bis sent to IESG for standards track = publication", > set due date to July 2018 from April 2018. >=20 > Added milestone "Root key rollover certificate extension sent to IESG = for > informational publication", due August 2018. >=20 > Added milestone "Short-lived certificate conventions sent to IESG for = BCP > publication", due October 2018. >=20 > Added milestone "The CMS with PSK sent to IESG for standards track > publication", due October 2018. >=20 > Added milestone "Hash-based signatures with the CMS sent to IESG for > standards track publication", due December 2018. >=20 > URL: https://datatracker.ietf.org/wg/lamps/about/ = >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm = >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --Apple-Mail=_563619B2-5A38-4B39-984A-68BF4308E974 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Those "Done" items are on the current charter, so no = problem.

Russ


On May 22, 2018, at 10:42 PM, Eric Rescorla <ekr@rtfm.com> = wrote:

Hmm.... I seem to have edited the in-place = milestones rather than the prospective ones. I'll sort this out....

On Tue, May 22, 2018 at 7:39 PM, IETF Secretariat = <ietf-secretariat-reply@ietf.org> wrote:
Changed milestone "Adopt a draft for = rfc6844bis", resolved as "Done".

Changed milestone "Adopt a PKIX draft for SHAKE128/256 and = SHAKE256/512",
resolved as "Done".

Changed milestone "Adopt a S/MIME draft for SHAKE128/256 and = SHAKE256/512",
resolved as "Done".

Added milestone "Adopt a draft for short-lived certificate conventions", = due
June 2018.

Added milestone "Adopt a draft for the CMS with PSK", due June 2018.

Added milestone "Adopt a draft for hash-based signatures with the CMS", = due
June 2018.

Added milestone "Adopt a draft for root key rollover certificate = extension",
due June 2018.

Changed milestone "rfc6844bis sent to IESG for standards track = publication",
set due date to July 2018 from April 2018.

Added milestone "Root key rollover certificate extension sent to IESG = for
informational publication", due August 2018.

Added milestone "Short-lived certificate conventions sent to IESG for = BCP
publication", due October 2018.

Added milestone "The CMS with PSK sent to IESG for standards track
publication", due October 2018.

Added milestone "Hash-based signatures with the CMS sent to IESG for
standards track publication", due December 2018.

URL: https://datatracker.ietf.org/wg/lamps/about/

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

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

= --Apple-Mail=_563619B2-5A38-4B39-984A-68BF4308E974-- From nobody Wed May 23 09:50:53 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDC212E865 for ; Wed, 23 May 2018 09:50:51 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.599, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 eqvkB79VpW0H for ; Wed, 23 May 2018 09:50:49 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.15]) (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 515E712E05D for ; Wed, 23 May 2018 09:50:49 -0700 (PDT) Received: from [216.82.251.38] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-15.bemta-12.messagelabs.com id FF/2A-23913-8EB950B5; Wed, 23 May 2018 16:50:48 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTe0hTcRTH97uP7VpOrtPyZBp1ISlrI3vQIqi IsAUSBRnkgrqrmxttU3ZXGEUJRQ+1MlOrZa6nmc4KW2XYy5WVc1jLWA97mfZSoyLC7EX3+luv f358ON9zzvf8Xgyp2auKZ4Qcp+Cw81ZOOYB6MNyr177eTxvHnXs7Xl/Z3aLS7/qwH+mLnh1A+ vLQMv2Pj6YZtOGC64nKcKf6M2E4erSPMOzu2EwaNtbXU/PoDNpiN2XlLKXNtS/XZhdvQTnnWp +qclHp+jwUwVBsAQk/T2fkoQGMhi0k4GzwBpIFDfsMwZGeuTIr2XEQunSTkDmWTYdTlYF+Jlk jnPSUqfIQw8SwWgjUcDhFB+ere2jMqVDde4vEXiNhZ3OPSmY1uxgeHSqise9hAj4d8fUnRbDz 4Uefn5IZsYOh1+8Je8XBo053PwMbC+3BZiXmQfC24yeN8xfDgU++cJyDQFsuhTkR7rrzEWYvA W2bJmDWwoeSElIeAtirCOpKd4UNkuF52WUa80r48jmowrwOmnZsDMeHQdX2dgoXXyLhYPl9Eg sJcN7bF+56VgnbGispfKTLobhKHk8WOhDca6ikC9EY1z/bc0kayboR1L57TLv6DyoamvZ1Ujg pA9yhZiXmZCip6QrHx0DFoW7SJd0DyY6GG63c/2GZp8Lerw3h0hFQnN+uwjwJuhs/ooNoYBUa JQqO1YJDO2GSzuSwZJqdNt5i1aakjNfZBFHkMwUrbxJ1y7JstUh6mRsUClSHXl0x+tAQhuAGq ZcW0kZNlClr+RozL5qXOFZZBdGHEhiGA3XAJWnRDiFTyFlhsUrP+7cMTCQXq36zT5LVYjZvEy 2ZWPKjKcx3b1EByfjeF0tri7xqKHuWXYiPUw+R+7FygXmV/U+73x/mLkqMj1EjhUKhicwWHDa L83+9C8UxiItR2+QukRa7849rlzQQIQ0UPE7KAzn5v1J8LkrYfCfqYiggPrw+0Z9+8UJSc2e0 qcyW2vvEox2bfixp9809jaGIJdnzBT9xu7xpqLtdM6pses2CuoIKfeui9DbjzCvbDGmLtjg9r pmHXzSsr1995sRg0hssvZbWMTtNjJq2tSq1VfmtQdeUOGvydEP0Qn1+S3lF28sRc0Z67Em5IR 9HiWY+JZl0iPwvg6n9JSsEAAA= X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-13.tower-163.messagelabs.com!1527094247!158051991!1 X-Originating-IP: [216.32.180.56] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 37161 invoked from network); 23 May 2018 16:50:47 -0000 Received: from mail-by2nam03lp0056.outbound.protection.outlook.com (HELO NAM03-BY2-obe.outbound.protection.outlook.com) (216.32.180.56) by server-13.tower-163.messagelabs.com with AES256-SHA256 encrypted SMTP; 23 May 2018 16:50:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=j8ZNm3W48Ub0KeiI8WFgEKbGA59DHzJPpWb5/LJVjN0=; b=KrP4VrsWDy4Al7eH731syPsv6fWZFU8ls4mVIBnpgCvVBitCzeJJTC3EZkywWTuOwacDLYuukgm/37fVtGa3p8mOJLXGAFs5ZMSB9Cv6efiwmnleAM2JcN8S2f8hZg/uptOjvYh/W4AWIKJSoZ9XTqt2O2MJE31eussweVKXbt8= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1268.namprd14.prod.outlook.com (10.173.162.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.797.11; Wed, 23 May 2018 16:50:46 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::40d8:6bed:a1a5:de4e]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::40d8:6bed:a1a5:de4e%3]) with mapi id 15.20.0797.011; Wed, 23 May 2018 16:50:46 +0000 From: Tim Hollebeek To: Ryan Sleevi , Phillip Hallam-Baker CC: SPASM , Eric Rescorla , Wayne Thayer Thread-Topic: [lamps] CAA Semantics for S/MIME Thread-Index: AQHT7LFMDXXTmEgBBkmQhc7Ojkm90qQ1xoiAgAChw4CAAAsBAIAHH63Q Date: Wed, 23 May 2018 16:50:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.71.184.143] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1268; 7:JP80JfsK5TiSg/XpIEOmw0SbvpqkhcaB8MSTDELlLaQVF3cohHQ+lwKSDuiWERXkHJRF2DOQMZY7DYQPoHbV3aVAmUmIvbD9SdAlgYhluSgjG5fDa1O0A8wJy7FvbGTletZ2MsO9Ee8UDvtKH1f/r7tKyxrletbiwFQ6B8/ZY1OFMmvuOXxXj4wMBTjbo751m167xL3FLjQUbYEdNo6rKwzm+tulAtvPIbPrhrzrzZl7v44hoSvcY9O3DA2R46L+ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1268; x-ms-traffictypediagnostic: BN6PR14MB1268: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(228788266533470)(85827821059158)(211936372134217)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231254)(944501410)(52105095)(93006095)(93001095)(149027)(150027)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:BN6PR14MB1268; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1268; x-forefront-prvs: 06818431B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(376002)(39380400002)(39860400002)(346002)(199004)(189003)(97736004)(236005)(3280700002)(9686003)(6306002)(54896002)(2906002)(55016002)(6246003)(3660700001)(446003)(86362001)(8936002)(81156014)(478600001)(81166006)(5250100002)(966005)(25786009)(229853002)(74316002)(6436002)(186003)(68736007)(99936001)(26005)(486006)(106356001)(5660300001)(53546011)(606006)(59450400001)(44832011)(33656002)(6506007)(8676002)(14454004)(790700001)(6116002)(3846002)(11346002)(99286004)(476003)(316002)(7736002)(4326008)(110136005)(66066001)(54906003)(2900100001)(53936002)(93886005)(76176011)(102836004)(105586002)(7696005)(39060400002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1268; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: AjbeWvu1JOTgwRwcU/D45o2oIb8acZ5Fjg6WbggqnR0RnbnBNo7ypnEEwndg3bKN1y0aTb8sSQrI1Ohr+2EQqBtixSlEFipOm53gGqsPUuPF22xCb0wF7whlskLR3whQNEvEc06kU+mAiDyho/+F6uG333yW4CEx9DTTVikhzvWjGpPqiph/FSFRXESF1w69 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0195_01D3F295.3220B6D0" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 1b1b0d58-8bfe-42ef-0d5d-08d5c0cd5480 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1b1b0d58-8bfe-42ef-0d5d-08d5c0cd5480 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2018 16:50:45.9908 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1268 Archived-At: Subject: Re: [lamps] CAA Semantics for S/MIME X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 16:50:52 -0000 ------=_NextPart_000_0195_01D3F295.3220B6D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0196_01D3F295.3220B6D0" ------=_NextPart_001_0196_01D3F295.3220B6D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable (chair hat off) =20 The charter issue seems to me like a simple enough issue that we should = be able to resolve it here on the list. I was actually the one who = suggested it should be handled in 6844bis over on m.d.s-p, and was = surprised when Wayne correctly pointed out it is out of scope. I think = we should take this opportunity to fix the charter to include it. This = seems like the most appropriate forum for that work. It doesn=E2=80=99t = smell like a CABF thing. Though coordination would be useful so we = produce something they can easily consume. =20 -Tim =20 From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Ryan Sleevi Sent: Saturday, May 19, 2018 12:03 AM To: Phillip Hallam-Baker Cc: SPASM ; Eric Rescorla ; Wayne Thayer = Subject: Re: [lamps] CAA Semantics for S/MIME =20 Seems like it would be better discussed in a place with open access and = participation? To avoid capture by CAs by having a diverse set of views = represented? =20 On Fri, May 18, 2018 at 11:24 PM Phillip Hallam-Baker = > wrote: Perhaps we could have a side discussion about this at the London = CABForum meeting if folk are there. =20 =20 =20 On Fri, May 18, 2018 at 1:45 PM, Eric Rescorla > wrote: I agree that this is out of the proposed charter. If the WG wants to add = it as a charter item now, that seems fine. =20 -Ekr =20 =20 On Tue, May 15, 2018 at 6:00 PM, Wayne Thayer > wrote: There is a vigorous discussion about CAA and S/MIME certificates = happening over on the mozilla.dev.security.policy list [1]. It has been = proposed that this issue could be addressed as part of rfc6844bis, but = I'm reading the LAMPS recharter as being too narrow in scope to permit = this. Does this work need to be deferred to a future LAMPS recharter? - Wayne [1] = https://groups.google.com/d/msg/mozilla.dev.security.policy/NIc2Nwa9Msg/R= Gx4A5HBBAAJ =20 _______________________________________________ Spasm mailing list Spasm@ietf.org =20 https://www.ietf.org/mailman/listinfo/spasm =20 _______________________________________________ Spasm mailing list Spasm@ietf.org =20 https://www.ietf.org/mailman/listinfo/spasm =20 _______________________________________________ Spasm mailing list Spasm@ietf.org =20 https://www.ietf.org/mailman/listinfo/spasm ------=_NextPart_001_0196_01D3F295.3220B6D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

(chair hat = off)

 

The charter issue seems to me like a simple enough = issue that we should be able to resolve it here on the list.=C2=A0 I was = actually the one who suggested it should be handled in 6844bis over on = m.d.s-p, and was surprised when Wayne correctly pointed out it is out of = scope.=C2=A0 I think we should take this opportunity to fix the charter = to include it.=C2=A0 This seems like the most appropriate forum for that = work.=C2=A0 It doesn=E2=80=99t smell like a CABF thing.=C2=A0 Though = coordination would be useful so we produce something they can easily = consume.

 

-Tim

 

From: Spasm = [mailto:spasm-bounces@ietf.org] On Behalf Of Ryan = Sleevi
Sent: Saturday, May 19, 2018 12:03 AM
To: = Phillip Hallam-Baker <phill@hallambaker.com>
Cc: SPASM = <spasm@ietf.org>; Eric Rescorla <ekr@rtfm.com>; Wayne Thayer = <wthayer@gmail.com>
Subject: Re: [lamps] CAA Semantics = for S/MIME

 

Seems like it would be better discussed in a place = with open access and participation? To avoid capture by CAs by having a = diverse set of views represented?

 

On = Fri, May 18, 2018 at 11:24 PM Phillip Hallam-Baker <phill@hallambaker.com> = wrote:

Perhaps we could have = a side discussion about this at the London CABForum meeting if folk are = there.

 

 

<= p class=3DMsoNormal> 

On = Fri, May 18, 2018 at 1:45 PM, Eric Rescorla <ekr@rtfm.com> = wrote:

I agree that this is out of the proposed charter. If = the WG wants to add it as a charter item now, that seems = fine.

 

-Ekr

 

 

On Tue, May 15, 2018 at 6:00 PM, Wayne Thayer <wthayer@gmail.com> = wrote:

There is a vigorous = discussion about CAA and S/MIME certificates happening over on the = mozilla.dev.security.policy list [1]. It has been proposed that this = issue could be addressed as part of rfc6844bis, but I'm reading the = LAMPS recharter as being too narrow in scope to permit this. Does this = work need to be deferred to a future LAMPS = recharter?

- = Wayne

 

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

 


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

 

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

------=_NextPart_001_0196_01D3F295.3220B6D0-- ------=_NextPart_000_0195_01D3F295.3220B6D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwNTIzMTY1NDMyWjAvBgkqhkiG9w0BCQQxIgQgCHE+QaLYybEvaiO4T608i+0xCr5u QuRh6lvxYMtBSnMwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAC9dOKymzY7CHoN2NJ1BpMURjdM3khQrWbAMHij9Os4397v3Gh/h+lS2tdjK1F+xuWGHWnYo v4fEKkqqnZ4Mcr42DmdmvfzxWdUipyVn2VwUI87TKgflQyCIpTe75rxFackyAGnSdThLZmZqsN47 aZrEv6X12LA5APJXEajZCSV18Gnaciw6K/LZ7Eb679ab/+twyH9QwOqhsp4HdxzMVsdYQ9DVrNN5 quvjLDLQSxSRn6YM072nPaPHhNMlHHYkI72uCcJ4Bt1bssvrc009nILa2m1t6ccrJF0hZO3Q/o9c R7bWmss25hC2VASnQ+13wnzn3Xa0EPlsrHCSBpqUK5AAAAAAAAA= ------=_NextPart_000_0195_01D3F295.3220B6D0-- From nobody Wed May 23 10:10:45 2018 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5780412741D; Wed, 23 May 2018 10:10:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: lamps-chairs@ietf.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152709543734.26876.14669273511731581188.idtracker@ietfa.amsl.com> Date: Wed, 23 May 2018 10:10:37 -0700 Archived-At: Subject: [lamps] Warren Kumari's Block on charter-ietf-lamps-02-00: (with BLOCK and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 17:10:38 -0000 Warren Kumari has entered the following ballot position for charter-ietf-lamps-02-00: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-lamps/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- "3. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information, as a result revoking them pointless." This makes me twitch -- how short is "short"? And how long is the time to "detect, report, and distribute revocation information"? With e.g: CT, misissued certificates may be visible before they are used in an attack, decreasing the detection time. Also, I would figure that it is still useful to know that a certificate was revoked and didn't just expire -- if I see a certificate which expired 10 minutes ago I may be willing (after some consideration, checking my clock, etc) to decide to trust it anyway (even if that's a bad idea!), but a revoked certificate is a clear indication that something bad happened, and changes my risk assessment. It's entirely possible that there is a really good reason why I'm wrong / that this argument doesn't make sense in some use cases (or just that I'm nuts!) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Also, "revoking them pointless" does not parse - perhaps "revoking them is pointless"? From nobody Wed May 23 10:40:05 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750FA12E886; Wed, 23 May 2018 10:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_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 ju5dkpF0W5b0; Wed, 23 May 2018 10:39:55 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3579912E87F; Wed, 23 May 2018 10:39:55 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id o78-v6so11504641wmg.0; Wed, 23 May 2018 10:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KA8rdg1+lHEBKTWL3R2X+E7gPoah4w/9cZcc1p4YrYw=; b=VstxsBxIlz+SqIhHwq6qad+evADKI8+cQFfeg8MlUQEcJOHf8Y5Ll9Ul/VuDk5hq79 eMX9ybdnA/oXGYNo0+nqWdIrkKAMI1hooDB9tiXP+eFHSYlAbhhsIrbwaQlM22MlswdT 6k0KftcE1cb16iSkFgXSowIr/7hv7cKvFhGcppcmv1AJyo3KwUVy90tkM3GhT5WxvSy/ fKEQ2h9uHSw/Cr2rEAQo5tPwCFoO4/rwoG6sSqPbBAWAcX1z1e4f5PCrnTjLp2QF0ezl 8CWpDTirP9qSJrNTpVugN/oKLizQUWxX3Fixrp2pHJUTJgLVSH7yTb5uryyMDNtFwW8E 6VQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KA8rdg1+lHEBKTWL3R2X+E7gPoah4w/9cZcc1p4YrYw=; b=uEbOP7g20Wap2wcym02BXqDJKLDwPJr9JLeH9jDctr0MTodF0Hop1Fl4gVYYvhqgbx 2d+PcRcfdtCaYxhglW9/t3nI67pTJOQheSWh0qNtr1nZuzc5rNTegJuvky8X//wmgk8H cicLHHzVaids9ESJ8+cNtb5/Vw0LWqgkI5EczRX1+tF+u9qcSg500LQ4ubOfKcFJ5n8L 34gQ7Yc5xYEGM5PFNJP433E5wMhlxGrI2k6CMHYvcQOH+supSovF+6nF6Xryt0I2UYK/ 3UzTJqTpJEfGJ3sI2sNh/aFn0jwse6hWxF9ewiFXW6AVU68E0JgOXzCbc5MyliNVPBx9 5TKw== X-Gm-Message-State: ALKqPweAEkyjv4VuToLOe8mkMrpKLh1uDyGk5YZjrB+P4SwWtpSuvtJx AV7yxanjlDnfeBP/USjxHqdnOQXs X-Google-Smtp-Source: AB8JxZprDMaKRQ/c1ww8PG4Stc0JvZiTcQCt+XyreZd0sGVQV7giTS09g9MzsyxDzeUoKAz5VasUCA== X-Received: by 2002:a1c:30ce:: with SMTP id w197-v6mr4463761wmw.22.1527097193675; Wed, 23 May 2018 10:39:53 -0700 (PDT) Received: from [192.168.1.17] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 42-v6sm40691245wrx.24.2018.05.23.10.39.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 May 2018 10:39:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Yoav Nir In-Reply-To: <152709543734.26876.14669273511731581188.idtracker@ietfa.amsl.com> Date: Wed, 23 May 2018 20:39:50 +0300 Cc: The IESG , spasm@ietf.org, lamps-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <64EA6F18-9275-40FC-8FDE-3E12C4458EFB@gmail.com> References: <152709543734.26876.14669273511731581188.idtracker@ietfa.amsl.com> To: Warren Kumari X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [lamps] Warren Kumari's Block on charter-ietf-lamps-02-00: (with BLOCK and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 17:39:58 -0000 Hi Warren. Since it was my draft and presentation at SecDispatch that led to this = item, I feel I can answer this. Inline. > On 23 May 2018, at 20:10, Warren Kumari wrote: >=20 > Warren Kumari has entered the following ballot position for > charter-ietf-lamps-02-00: Block >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-lamps/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- >=20 > "3. Specify the use of short-lived X.509 certificates for which no > revocation information is made available by the Certification = Authority. > Short-lived certificates have a lifespan that is shorter than the time > needed to detect, report, and distribute revocation information, as a > result revoking them pointless." >=20 > This makes me twitch -- how short is "short=E2=80=9D? [YN] I expect this to be contentious within the working group, and I = expect the exact cut-off point to be different from one use-case to = another. For highly reliable systems with good clock synchronization = =E2=80=9Cshort=E2=80=9D could be as low as an hour. For typical systems = I think the likely lifetime will be between 1 day and 1 week. IMHO = it=E2=80=99s valid for the working group to leave the cut-off between = =E2=80=9Cshort=E2=80=9D and =E2=80=9Cnot short=E2=80=9D to per-domain = profiles, but I don=E2=80=99t think anything beyond 2 weeks would ever = count as short. > And how long is the time to > "detect, report, and distribute revocation information"? With e.g: CT, > misissued certificates may be visible before they are used in an = attack, > decreasing the detection time. [YN] Someone needs to see the certificate to add it to the log, and = someone needs to find the certificate on the log and understand that it = is mis-issued. And then someone needs to add it to the CRL / database = that feeds the OCSP responder. And when this is updated, relying parties = may have cached copies of older revocation information. Add it up and it = can take days on the web. In closed environments there may not be CT at = all. =20 >=20 > Also, I would figure that it is still useful to know that a = certificate was > revoked and didn't just expire -- if I see a certificate which expired = 10 > minutes ago I may be willing (after some consideration, checking my = clock, etc) > to decide to trust it anyway (even if that's a bad idea!), but a = revoked > certificate is a clear indication that something bad happened, and = changes my > risk assessment. [YN] Yes, and the candidate draft has a SHOULD-level requirement to not = allow any grace periods for such certificates. One of the feedbacks I = got was that this should be upgraded to MUST (or rather MUST NOT) >=20 > It's entirely possible that there is a really good reason why I'm = wrong / that > this argument doesn't make sense in some use cases (or just that I'm = nuts!) [YN] There was some push-back about the name. The important point is not = so much that the lifetime is short, but that there is no revocation = information. We want these certificates because we don=E2=80=99t want to = deal with revocation information. Non-revocation is the end. Making = them short-term is the means, or rather the sacrifice we need to make to = make (other) security people happy. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > Also, "revoking them pointless" does not parse - perhaps "revoking = them is pointless"? >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Wed May 23 11:13:51 2018 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A224127869; Wed, 23 May 2018 11:13:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: lamps-chairs@ietf.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152709922899.26838.11074435093932176947.idtracker@ietfa.amsl.com> Date: Wed, 23 May 2018 11:13:48 -0700 Archived-At: Subject: [lamps] Spencer Dawkins' No Objection on charter-ietf-lamps-02-00: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 18:13:49 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-lamps-02-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-lamps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am, of course, curious about Warren's BLOCKing comment, but assuming that conversation goes well ... I had some editorial comments, of course. The last sentence in this list item is borked, as Warren noted ... 3. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information, as a result revoking them pointless. Perhaps something like 3. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information. As a result, revoking such short-lived certificates is unnecessary and would be pointless. I'm not sure that "near-term" is necessary in the first sentence of this list item. 4. Specify the use of a pre-shared key (PSK) along with other key management techniques with supported by the Cryptographic Message Syntax (CMS) as a near-term mechanism to protect present day communication from the future invention of a large-scale quantum computer. I found it confusing because "near-term" isn't "near-term from now", it's "near-term after the invention of quantum computing destroys civilization. If you want an adjective, perhaps something like "proactive" would be closer. In this text, 5. Specify the use of hash-based signatures with the Cryptographic Message Syntax (CMS). A hash-based signature uses small private and public keys, and it has low computational cost; however, the signature values are quite large. For this reason they might not be used for signing X.509 certificates or S/MIME messages, but they are secure even if a large-scale quantum computer is invented. These properties make hash-based signatures useful in some environments, such a the distribution of software updates. I wasn't sure from this description whether quantum computing resistance was the only "environment" where these are applicable. As a nit, s/such a/such as/. From nobody Wed May 23 12:32:11 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CB9127010 for ; Wed, 23 May 2018 12:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 eLOQUZ79WTvF for ; Wed, 23 May 2018 12:32:06 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE2A3127735 for ; Wed, 23 May 2018 12:32:04 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id w3-v6so20802652wrl.12 for ; Wed, 23 May 2018 12:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sz53f81vTdzQSB1svuM9fzXiJMBvRFiXu/5gZT0Q+2w=; b=yy41XIU/mSErJESElBy8aSR0YYMfDfmOM25rkJwAQUdq5sTdnaNfh2B8ucHBMr0eLI feOYarx6gnRKEyYp5/Dfzv0PGjJo7+EGEW+YBzCbpNi5fBCntrA5p4aof90FTa4b/3Rm QfmsVJbdkZ6P5keWZyvZV1P6vBJUTyQQ8AnhZZ6PmzIp/O2UVrp46SGWD3BDJct7jatB gQjcUh1wVk/zAPUwUHIqBXU+Kdf+XMwcD5LOSCBQtbPCpHH+RtpFhWNpc7kFaj9SeVuy 7R5FG5Oc/aQK2991SljrKe40nN4yGuUER4EZxDaiwAtUf1Ktq5MjIFpiCFdNpiMetU8E K82Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sz53f81vTdzQSB1svuM9fzXiJMBvRFiXu/5gZT0Q+2w=; b=g2iSVWrEyAT/SRGD+iyQx8Z0iMzG7ueK/Xc13MjIm0qVhEh1EDcRTXNGIXnF/tvK7B brxgnrjD3sfhNywmjectv6oaOjNYFAcbnqhszZB7DTrIAu/eyZctL4i+JL2FkcOrgEkO /aywGVqXBraA8Hi7323hQ6lte5QPWMWdpCNuC7pXJG8Fpegyy9qcnTaag5bK3PMurvjJ nGzw+/z5xpnO0xaCu7jSO/1qdRR9G9SvRli/kzLX5TyCFPBM0V+h2Y7RSm0AQdMM7kFY ELVGtmA/C82ehP17QWAefdc5rBEy9qp3+AM6gIVPePGRzleml6UljOCLmjf4o4C+O2xC EQPA== X-Gm-Message-State: ALKqPwe/psdrrk1fNN4hdvJoy+/wiF5LqtfBmgs23yxHq5qR56x9PyJk bpx8hXBl8vyNLMMpCndsR7/qd6qe1vqJyZps6vCMTFQGnD4= X-Google-Smtp-Source: AB8JxZrjZc5Lxyi8ESpAxVCpemejDN5Q98Pvod+msFV6Cbs9CKMhyNbcemUg0n8ZpcD2uxU6g0yz7aiIlJ8CxtY0DRo= X-Received: by 2002:adf:afce:: with SMTP id y14-v6mr3883323wrd.249.1527103923086; Wed, 23 May 2018 12:32:03 -0700 (PDT) MIME-Version: 1.0 References: <152709543734.26876.14669273511731581188.idtracker@ietfa.amsl.com> <64EA6F18-9275-40FC-8FDE-3E12C4458EFB@gmail.com> In-Reply-To: <64EA6F18-9275-40FC-8FDE-3E12C4458EFB@gmail.com> From: Warren Kumari Date: Wed, 23 May 2018 15:31:26 -0400 Message-ID: To: Yoav Nir Cc: The IESG , spasm@ietf.org, lamps-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000def750056ce4961c" Archived-At: Subject: Re: [lamps] Warren Kumari's Block on charter-ietf-lamps-02-00: (with BLOCK and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 19:32:09 -0000 --000000000000def750056ce4961c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 23, 2018 at 1:39 PM Yoav Nir wrote: > Hi Warren. > > Since it was my draft and presentation at SecDispatch that led to this > item, I feel I can answer this. Inline. > > > On 23 May 2018, at 20:10, Warren Kumari wrote: > > > > Warren Kumari has entered the following ballot position for > > charter-ietf-lamps-02-00: Block > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/charter-ietf-lamps/ > > > > > > > > ---------------------------------------------------------------------- > > BLOCK: > > ---------------------------------------------------------------------- > > > > "3. Specify the use of short-lived X.509 certificates for which no > > revocation information is made available by the Certification Authority= . > > Short-lived certificates have a lifespan that is shorter than the time > > needed to detect, report, and distribute revocation information, as a > > result revoking them pointless." > > > > This makes me twitch -- how short is "short=E2=80=9D? > > [YN] I expect this to be contentious within the working group, and I > expect the exact cut-off point to be different from one use-case to > another. For highly reliable systems with good clock synchronization > =E2=80=9Cshort=E2=80=9D could be as low as an hour. For typical systems I= think the likely > lifetime will be between 1 day and 1 week. IMHO it=E2=80=99s valid for t= he working > group to leave the cut-off between =E2=80=9Cshort=E2=80=9D and =E2=80=9Cn= ot short=E2=80=9D to per-domain > profiles, but I don=E2=80=99t think anything beyond 2 weeks would ever co= unt as > short. > > > And how long is the time to > > "detect, report, and distribute revocation information"? With e.g: CT, > > misissued certificates may be visible before they are used in an attack= , > > decreasing the detection time. > > [YN] Someone needs to see the certificate to add it to the log, and > someone needs to find the certificate on the log and understand that it i= s > mis-issued. And then someone needs to add it to the CRL / database that > feeds the OCSP responder. And when this is updated, relying parties may > have cached copies of older revocation information. Add it up and it can > take days on the web. In closed environments there may not be CT at all. > > =E2=80=8BSo, here you say: "Add it up and it can take days on the web." and= above that you say: "For typical systems I think the likely lifetime will be between 1 day and 1 week. [...] , but I don=E2=80=99t think anything beyon= d 2 weeks would ever count as short." "1 week" minus "days" is still greater than zero, and so it still *seems* to me that removing revocation is a bad idea -- but, my role is (or should be!) to make sure that this charter doesn't conflict with other work (esp. ops work), that the charter "describes the specific problem or deliverables (a guideline, standards specification, etc.) it has been formed to address. WG charters state the scope of work for group, and lay out goals and milestones that show how this work will be completed." It is (IMO) the sponsoring ADs, the WGs and IETFs decision as to if the ideas themselves are acceptable. I'm not (yet!) so arrogant that I'm sure I know the right answer to everything, so I'd like to discuss this with EKR on the call tomorrow, and will clear my block once I've been assured process is being followed / this has been considered. > > > Also, I would figure that it is still useful to know that a certificate > was > > revoked and didn't just expire -- if I see a certificate which expired = 10 > > minutes ago I may be willing (after some consideration, checking my > clock, etc) > > to decide to trust it anyway (even if that's a bad idea!), but a revoke= d > > certificate is a clear indication that something bad happened, and > changes my > > risk assessment. > > [YN] Yes, and the candidate draft has a SHOULD-level requirement to not > allow any grace periods for such certificates. One of the feedbacks I got > was that this should be upgraded to MUST (or rather MUST NOT) > > Ok. That helps. Thanks! W > > > It's entirely possible that there is a really good reason why I'm wrong > / that > > this argument doesn't make sense in some use cases (or just that I'm > nuts!) > > [YN] There was some push-back about the name. The important point is not > so much that the lifetime is short, but that there is no revocation > information. We want these certificates because we don=E2=80=99t want to = deal with > revocation information. Non-revocation is the end. Making them short-ter= m > is the means, or rather the sacrifice we need to make to make (other) > security people happy. > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > > > Also, "revoking them pointless" does not parse - perhaps "revoking them > is pointless"? > > > > > > _______________________________________________ > > Spasm mailing list > > Spasm@ietf.org > > https://www.ietf.org/mailman/listinfo/spasm > > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --000000000000def750056ce4961c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On We= d, May 23, 2018 at 1:39 PM Yoav Nir <ynir.ietf@gmail.com> wrote:
Hi Warren.

Since it was my draft and presentation at SecDispatch that led to this item= , I feel I can answer this.=C2=A0 Inline.

> On 23 May 2018, at 20:10, Warren Kumari <warren@kumari.net> wrote:
>
> Warren Kumari has entered the following ballot position for
> charter-ietf-lamps-02-00: Block
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-= ietf-lamps/
>
>
>
> ----------------------------------------------------------------------=
> BLOCK:
> ----------------------------------------------------------------------=
>
> "3. Specify the use of short-lived X.509 certificates for which n= o
> revocation information is made available by the Certification Authorit= y.
> Short-lived certificates have a lifespan that is shorter than the time=
> needed to detect, report, and distribute revocation information, as a<= br> > result revoking them pointless."
>
> This makes me twitch -- how short is "short=E2=80=9D?

[YN] I expect this to be contentious within the working group, and I expect= the exact cut-off point to be different from one use-case to another. For = highly reliable systems with good clock synchronization =E2=80=9Cshort=E2= =80=9D could be as low as an hour. For typical systems I think the likely l= ifetime will be between 1 day and 1 week.=C2=A0 IMHO it=E2=80=99s valid for= the working group to leave the cut-off between =E2=80=9Cshort=E2=80=9D and= =E2=80=9Cnot short=E2=80=9D to per-domain profiles, but I don=E2=80=99t th= ink anything beyond 2 weeks would ever count as short.

> And how long is the time to
> "detect, report, and distribute revocation information"? Wit= h e.g: CT,
> misissued certificates may be visible before they are used in an attac= k,
> decreasing the detection time.

[YN] Someone needs to see the certificate to add it to the log, and someone= needs to find the certificate on the log and understand that it is mis-iss= ued. And then someone needs to add it to the CRL / database that feeds the = OCSP responder. And when this is updated, relying parties may have cached c= opies of older revocation information. Add it up and it can take days on th= e web.=C2=A0 In closed environments there may not be CT at all.=C2=A0


=E2=80=8BSo, here you say: &quo= t;Add it up and it can take days on the web." and above that you say: = "For typical systems I think the likely lifetime will be between 1 day= and 1 week. =C2=A0[...] , but I don=E2=80=99t think anything beyond 2 week= s would ever count as short."

"1 week" minus "da= ys" is still greater than zero, and so it still *seems* to me that rem= oving revocation is a bad idea -- but, my role is (or should be!) to make s= ure that this charter doesn't conflict with other work (esp. ops work),= that the charter "describes the specific problem or deliverables (a g= uideline, standards specification, etc.) it has been formed to address. WG = charters state the scope of work for group, and lay out goals and milestone= s that show how this work will be completed." It is (IMO) the sponsori= ng ADs, the WGs and IETFs decision as to if the ideas themselves are accept= able.
I'm not (yet!) so arrogant that I'm sure I know the righ= t answer to everything, so I'd like to discuss this with EKR on the cal= l tomorrow, and will clear my block once I've been assured process is b= eing followed
/ this has been considered.

>
> Also, I would figure that it is still useful to know that a certificat= e was
> revoked and didn't just expire -- if I see a certificate which exp= ired 10
> minutes ago I may be willing (after some consideration, checking my cl= ock, etc)
> to decide to trust it anyway (even if that's a bad idea!), but a r= evoked
> certificate is a clear indication that something bad happened, and cha= nges my
> risk assessment.

[YN] Yes, and the candidate draft has a SHOULD-level requirement to not all= ow any grace periods for such certificates. One of the feedbacks I got was = that this should be upgraded to MUST (or rather MUST NOT)


Ok. That helps.

Thanks!
W

>
> It's entirely possible that there is a really good reason why I= 9;m wrong / that
> this argument doesn't make sense in some use cases (or just that I= 'm nuts!)

[YN] There was some push-back about the name. The important point is not so= much that the lifetime is short, but that there is no revocation informati= on. We want these certificates because we don=E2=80=99t want to deal with r= evocation information. Non-revocation is the end.=C2=A0 Making them short-t= erm is the means, or rather the sacrifice we need to make to make (other) s= ecurity people happy.

> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
>
> Also, "revoking them pointless" does not parse - perhaps &qu= ot;revoking them is pointless"?
>
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org=
> https://www.ietf.org/mailman/listinfo/spasm



--
I don't think the execution is relevant when= it was obviously a bad idea in the first place.
This is like putting ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div>
--000000000000def750056ce4961c-- From nobody Wed May 23 12:36:24 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08A512D574; Wed, 23 May 2018 12:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 1MJzmjjnfjTg; Wed, 23 May 2018 12:36:01 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 3EFB012D77A; Wed, 23 May 2018 12:36:01 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4NJZx6H044970 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 23 May 2018 14:35:59 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Spencer Dawkins , The IESG Cc: spasm@ietf.org, lamps-chairs@ietf.org References: <152709922899.26838.11074435093932176947.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <41e7a726-0175-7e3d-d35c-d413bf01ea12@nostrum.com> Date: Wed, 23 May 2018 14:35:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <152709922899.26838.11074435093932176947.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [lamps] Spencer Dawkins' No Objection on charter-ietf-lamps-02-00: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 19:36:17 -0000 On 5/23/18 1:13 PM, Spencer Dawkins wrote: > 4. Specify the use of a pre-shared key (PSK) along with other key > management techniques with supported by the Cryptographic Message > Syntax (CMS) as a near-term mechanism to protect present day > communication from the future invention of a large-scale quantum > computer. > > I found it confusing because "near-term" isn't "near-term from now", it's > "near-term after the invention of quantum computing destroys civilization. My understanding is that the intention is "near-term from now." The idea is that LAMPS should develop something that you could use, say, next year to encrypt email you send so that, 15 years from now when someone finally builds a 4,000 qubit machine, they can't dig out your (then) 14-year-old email and decrypt it. /a From nobody Wed May 23 12:40:53 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C32C1277BB; Wed, 23 May 2018 12:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 bxu6DjWsDztm; Wed, 23 May 2018 12:40:38 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 104A7127010; Wed, 23 May 2018 12:40:37 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4NJdEKJ011749; Wed, 23 May 2018 20:40:35 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=c1lhUFDuxHRX8GkggShXAt7H9m4FCD8IuGOnRIzM6j0=; b=H/+ivu17RnRDJPOUadFRg53uxH7EUBW+K9DQM+NaPd6AiKqWV9DPrjmq/L5JG8G3hEHk I2DDCPYEjweR5AJe/JNCqHk38cfIe3FOw3jlw/A81ykoQv/ehavBMf+DRUCvR+Opt1hO +pr0U3cT6taPiLU7VYkhBBlMjVNlk59odT1sjQm4pK8QlAgrh/ALleS9Mw3bgh29TaAh S0z6DLXrg+9gG/d6SMd8lR+wGjwEuNzdKlKTWezaPON+PmYLcBVB4qAw/wyi4FZbgAwK RHhOGPQmpjJN7331Nu7ELArmGu7KJNSQLguAY5m/2K/EycpvYE5XITdiFUitmqdFfL58 Kg== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2j5e91g2c0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 May 2018 20:40:35 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w4NJVtqe016113; Wed, 23 May 2018 15:40:35 -0400 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint3.akamai.com with ESMTP id 2j2f8wb1yy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 23 May 2018 15:40:35 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 23 May 2018 14:40:34 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Wed, 23 May 2018 14:40:34 -0500 From: "Salz, Rich" To: Adam Roach , Spencer Dawkins , The IESG CC: "spasm@ietf.org" , "lamps-chairs@ietf.org" Thread-Topic: [lamps] Spencer Dawkins' No Objection on charter-ietf-lamps-02-00: (with COMMENT) Thread-Index: AQHT8sHQeu/yCKfdfEmAmiT4c7N2fKQ+CNUA//++PwA= Date: Wed, 23 May 2018 19:40:34 +0000 Message-ID: <32DD6ED8-F2C9-4193-98FA-BC7876634318@akamai.com> References: <152709922899.26838.11074435093932176947.idtracker@ietfa.amsl.com> <41e7a726-0175-7e3d-d35c-d413bf01ea12@nostrum.com> In-Reply-To: <41e7a726-0175-7e3d-d35c-d413bf01ea12@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.d.0.180513 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.137] Content-Type: text/plain; charset="utf-8" Content-ID: <20E984FD2C2954409FB28D09AAB0444E@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-23_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=544 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805230191 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-23_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=465 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805230192 Archived-At: Subject: Re: [lamps] Spencer Dawkins' No Objection on charter-ietf-lamps-02-00: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 19:40:40 -0000 PiAgICBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIGludGVudGlvbiBpcyAibmVhci10ZXJt IGZyb20gbm93LiIgVGhlIGlkZWEgDQogICAgaXMgdGhhdCBMQU1QUyBzaG91bGQgZGV2ZWxvcCBz b21ldGhpbmcgdGhhdCB5b3UgY291bGQgdXNlLCBzYXksIG5leHQgDQogICAgeWVhciB0byBlbmNy eXB0IGVtYWlsIHlvdSBzZW5kIHNvIHRoYXQsIDE1IHllYXJzIGZyb20gbm93IHdoZW4gc29tZW9u ZSANCiAgICBmaW5hbGx5IGJ1aWxkcyBhIDQsMDAwIHF1Yml0IG1hY2hpbmUsIHRoZXkgY2FuJ3Qg ZGlnIG91dCB5b3VyICh0aGVuKSANCiAgICAxNC15ZWFyLW9sZCBlbWFpbCBhbmQgZGVjcnlwdCBp dC4NCiAgDQpLZW5ueSBQYXRlcnNvbiBnYXZlIGEgdGFsayBhdCBhIHJlY2VudCBJRVRGIHdoZXJl IGhlIHNhaWQsIGJhc2ljYWxseSwgdGhhdCB0aGUgSUVURiBzaG91bGQgd2FpdCB1bnRpbCBOSVNU IGlzIGRvbmUgd2l0aCB0aGVpciBwb3N0LXF1YW50dW0gZXZhbHVhdGlvbi9jb21wZXRpdGlvbi4g IEFyZSB3ZSBzdXJlIHdlIHdhbnQgdG8gZGlzYWdyZWUgd2l0aCBoaW0/ICBPciBpcyBpdCBqdXN0 IGJlY2F1c2UgZGlnZXN0LWJhc2VkIHNpZ25hdHVyZXMgYXJlIHdlbGwtdW5kZXJzdG9vZCB0aGF0 IHdlJ3JlIHdpbGxpbmcgdG8gZG8gc28uDQoNCg0K From nobody Wed May 23 12:53:34 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E33512D875; Wed, 23 May 2018 12:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 zPYcQ8bIq84f; Wed, 23 May 2018 12:53:14 -0700 (PDT) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::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 2C7E312E8D9; Wed, 23 May 2018 12:53:12 -0700 (PDT) Received: by mail-ot0-x229.google.com with SMTP id t1-v6so26641697oth.8; Wed, 23 May 2018 12:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=9QkYiil/QEAk3bCtHW5lOWQzOivBjp1IMTiRu3vEyCY=; b=ntpW+dPAkN+BOzfnftJUqxMuHqHsEYu/3tzw4F7qS8IQox0A9kw0V/JIysRdFaHDjn GL5xCr+AVVykTSbJjuvxIy2LbBJNltbfJk1A3A9w7/1UzBVXIDe/HxHmBWNP2ghxovmQ 6x9D6UPSpLvQbqdKud1s3th9G9lGpUD0/nvlMxYDzYKI8ZEjHK0U1Ipkt+0xOJlnTQYd bjaKEbDDjIohd6WtT/QxBenjWUvo30R3pa4iOXucDCLgJToMgbrVmZKLaZvoUK952mGW eNVYup1GfRgMyZZTpO6qKMh4axpv5inpcIQkxaclt46vQ5drgUuIeu7wpovuft1yYOt5 QPVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=9QkYiil/QEAk3bCtHW5lOWQzOivBjp1IMTiRu3vEyCY=; b=n8nvSh1DxlA4VLn4vfkqbl4OmQ55/KVoNbNh24KeOheLNJzdGOpfeucvFt8Ql0YTyS AouH33iQGuiySXf/0Qpbeo8NJZe5ASjiIC7nd8zxxe7DQPLbnA5r3BvU2OjtWeLPgxQd XCiYTCBlQlXoct+905eB2OtJMO3cLc+SMg2t3RN8Q74lwNzE58/DcqILhnjDIFNsg2J9 LccRK8y5LC3MfJDzQTRt2/6SzeUSgbsvUaeJiN1IBpDGhLlhPBA5ATY+DAYgpl1dpEOm RyxIFeebOcULau7fs02FaMxCz9TMfWzsUwuoqdrXTLbFpSN41mGbJu1FJaQnff5afGYG X9JQ== X-Gm-Message-State: ALKqPweEDmb1eJty3CUZKI7ONablEvbQFFRZe1uDP9MbUzyWtmuS5QYT zumS+nWDPpb/MYS2/6hKjSud/LDS2AknnG2LpmY= X-Google-Smtp-Source: AB8JxZr5tjtFp0KsskwL6FX9QsdvSAqoaZTAsAY6WdtbHCPw8STxEdLX3Ix9FtLNcMq9lmdQagTWkCtznXx+qck371M= X-Received: by 2002:a9d:86c:: with SMTP id 99-v6mr2537323oty.268.1527105191503; Wed, 23 May 2018 12:53:11 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 23 May 2018 12:53:10 -0700 From: Alvaro Retana In-Reply-To: References: <152709543734.26876.14669273511731581188.idtracker@ietfa.amsl.com> <64EA6F18-9275-40FC-8FDE-3E12C4458EFB@gmail.com> X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Wed, 23 May 2018 12:53:10 -0700 Message-ID: To: Yoav Nir , Warren Kumari Cc: spasm@ietf.org, lamps-chairs@ietf.org, The IESG Content-Type: multipart/alternative; boundary="000000000000796cbe056ce4e228" Archived-At: Subject: Re: [lamps] Warren Kumari's Block on charter-ietf-lamps-02-00: (with BLOCK and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 19:53:26 -0000 --000000000000796cbe056ce4e228 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On May 23, 2018 at 3:32:21 PM, Warren Kumari (warren@kumari.net) wrote: Hi! =E2=80=8BSo, here you say: "Add it up and it can take days on the web." and= above that you say: "For typical systems I think the likely lifetime will be between 1 day and 1 week. [...] , but I don=E2=80=99t think anything beyon= d 2 weeks would ever count as short." "1 week" minus "days" is still greater than zero, and so it still *seems* to me that removing revocation is a bad idea -- but, my role is (or should be!) to make sure that this charter doesn't conflict with other work (esp. ops work), that the charter "describes the specific problem or deliverables (a guideline, standards specification, etc.) it has been formed to address. WG charters state the scope of work for group, and lay out goals and milestones that show how this work will be completed." It is (IMO) the sponsoring ADs, the WGs and IETFs decision as to if the ideas themselves are acceptable. I'm not (yet!) so arrogant that I'm sure I know the right answer to everything, so I'd like to discuss this with EKR on the call tomorrow , and will clear my block once I've been assured process is being followed / this has been considered. I agree with Warren=E2=80=99s assessment. However, I also think that a charter may give undue validation to items that would benefit from at least a little more description or consideration. IOW, adding (to the charter) a longer description, and listing which things should be satisfied, or at least considered, seems like a good idea to me. Alvaro. --000000000000796cbe056ce4e228 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On May 23, 201= 8 at 3:32:21 PM, Warren Kumari (warren= @kumari.net) wrote:

Hi!

=E2=80=8BSo, here you say: &quo= t;Add it up and it can take days on the web." and above that you say: = "For typical systems I think the likely lifetime will be between 1 day= and 1 week. =C2=A0[...] , but I don=E2=80=99t think anything beyond 2 week= s would ever count as short."

"1 week" minus "da= ys" is still greater than zero, and so it still *seems* to me that rem= oving revocation is a bad idea -- but, my role is (or should be!) to make s= ure that this charter doesn't conflict with other work (esp. ops work),= that the charter "describes the specific problem or deliverables (a g= uideline, standards specification, etc.) it has been formed to address. WG = charters state the scope of work for group, and lay out goals and milestone= s that show how this work will be completed." It is (IMO) the sponsori= ng ADs, the WGs and IETFs decision as to if the ideas themselves are accept= able.
I'm not (yet!) so arrogant that I'm sure I know the righ= t answer to everything, so I'd like to discuss this with EKR on the cal= l=C2=A0tomorrow, and will clear my block = once I've been assured process is being followed
/ this has been con= sidered.

I agree with Warren=E2=80=99s assessment.

However, I also think that a charter may give undue validation t= o items that would benefit from at least a little more description or consi= deration.=C2=A0 IOW, adding (to the charter) a longer description, and list= ing which things should be satisfied, or at least considered, seems like a = good idea to me.

Alvaro.


=
--000000000000796cbe056ce4e228-- From nobody Wed May 23 13:00:14 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DC71277BB for ; Wed, 23 May 2018 13:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJmRb-dlVynU for ; Wed, 23 May 2018 13:00:09 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D608127010 for ; Wed, 23 May 2018 13:00:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A0E52300A23 for ; Wed, 23 May 2018 15:53:41 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0ehtEuWQ7Mzb for ; Wed, 23 May 2018 15:53:38 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 83A803005AE; Wed, 23 May 2018 15:53:37 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D7057CA5-4FAF-434B-B5E2-0C585C262643" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 23 May 2018 15:53:38 -0400 In-Reply-To: Cc: Yoav Nir , spasm@ietf.org, lamps-chairs@ietf.org, IESG To: Warren Kumari References: <152709543734.26876.14669273511731581188.idtracker@ietfa.amsl.com> <64EA6F18-9275-40FC-8FDE-3E12C4458EFB@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Warren Kumari's Block on charter-ietf-lamps-02-00: (with BLOCK and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 20:00:12 -0000 --Apple-Mail=_D7057CA5-4FAF-434B-B5E2-0C585C262643 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Please see my response at the bottom of the message ... > On May 23, 2018, at 3:31 PM, Warren Kumari wrote: >=20 > On Wed, May 23, 2018 at 1:39 PM Yoav Nir > wrote: > Hi Warren. >=20 > Since it was my draft and presentation at SecDispatch that led to this = item, I feel I can answer this. Inline. >=20 > > On 23 May 2018, at 20:10, Warren Kumari > wrote: > >=20 > > Warren Kumari has entered the following ballot position for > > charter-ietf-lamps-02-00: Block > >=20 > > When responding, please keep the subject line intact and reply to = all > > email addresses included in the To and CC lines. (Feel free to cut = this > > introductory paragraph, however.) > >=20 > >=20 > >=20 > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/charter-ietf-lamps/ = > >=20 > >=20 > >=20 > > = ---------------------------------------------------------------------- > > BLOCK: > > = ---------------------------------------------------------------------- > >=20 > > "3. Specify the use of short-lived X.509 certificates for which no > > revocation information is made available by the Certification = Authority. > > Short-lived certificates have a lifespan that is shorter than the = time > > needed to detect, report, and distribute revocation information, as = a > > result revoking them pointless." > >=20 > > This makes me twitch -- how short is "short=E2=80=9D? >=20 > [YN] I expect this to be contentious within the working group, and I = expect the exact cut-off point to be different from one use-case to = another. For highly reliable systems with good clock synchronization = =E2=80=9Cshort=E2=80=9D could be as low as an hour. For typical systems = I think the likely lifetime will be between 1 day and 1 week. IMHO = it=E2=80=99s valid for the working group to leave the cut-off between = =E2=80=9Cshort=E2=80=9D and =E2=80=9Cnot short=E2=80=9D to per-domain = profiles, but I don=E2=80=99t think anything beyond 2 weeks would ever = count as short. >=20 > > And how long is the time to > > "detect, report, and distribute revocation information"? With e.g: = CT, > > misissued certificates may be visible before they are used in an = attack, > > decreasing the detection time. >=20 > [YN] Someone needs to see the certificate to add it to the log, and = someone needs to find the certificate on the log and understand that it = is mis-issued. And then someone needs to add it to the CRL / database = that feeds the OCSP responder. And when this is updated, relying parties = may have cached copies of older revocation information. Add it up and it = can take days on the web. In closed environments there may not be CT at = all. =20 >=20 >=20 > =E2=80=8BSo, here you say: "Add it up and it can take days on the = web." and above that you say: "For typical systems I think the likely = lifetime will be between 1 day and 1 week. [...] , but I don=E2=80=99t = think anything beyond 2 weeks would ever count as short." >=20 > "1 week" minus "days" is still greater than zero, and so it still = *seems* to me that removing revocation is a bad idea -- but, my role is = (or should be!) to make sure that this charter doesn't conflict with = other work (esp. ops work), that the charter "describes the specific = problem or deliverables (a guideline, standards specification, etc.) it = has been formed to address. WG charters state the scope of work for = group, and lay out goals and milestones that show how this work will be = completed." It is (IMO) the sponsoring ADs, the WGs and IETFs decision = as to if the ideas themselves are acceptable. > I'm not (yet!) so arrogant that I'm sure I know the right answer to = everything, so I'd like to discuss this with EKR on the call tomorrow, = and will clear my block once I've been assured process is being followed > / this has been considered. Warren: I think the point you are missing is that it take time to process = revocation and get the CRL published or OCSP responder updated. This is = always over a week because people do not revoke without doing due = diligence. So, letting the short-lived certificate expire without = issuing a replacement will actually cause revocation to happen more = quickly. Russ --Apple-Mail=_D7057CA5-4FAF-434B-B5E2-0C585C262643 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Please see my response at the bottom of the message ...

On May 23, 2018, at 3:31 PM, Warren Kumari <warren@kumari.net> = wrote:

On = Wed, May 23, 2018 at 1:39 PM Yoav Nir <ynir.ietf@gmail.com>= wrote:
Hi Warren.

Since it was my draft and presentation at SecDispatch that led to this = item, I feel I can answer this.  Inline.

> On 23 May 2018, at 20:10, Warren Kumari <warren@kumari.net> wrote:
>
> Warren Kumari has entered the following ballot position for
> charter-ietf-lamps-02-00: Block
>
> When responding, please keep the subject line intact and reply to = all
> email addresses included in the To and CC lines. (Feel free to cut = this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found = here:
> https://datatracker.ietf.org/doc/charter-ietf-lamps/
>
>
>
> = ----------------------------------------------------------------------
> BLOCK:
> = ----------------------------------------------------------------------
>
> "3. Specify the use of short-lived X.509 certificates for which = no
> revocation information is made available by the Certification = Authority.
> Short-lived certificates have a lifespan that is shorter than the = time
> needed to detect, report, and distribute revocation information, as = a
> result revoking them pointless."
>
> This makes me twitch -- how short is "short=E2=80=9D?

[YN] I expect this to be contentious within the working group, and I = expect the exact cut-off point to be different from one use-case to = another. For highly reliable systems with good clock synchronization = =E2=80=9Cshort=E2=80=9D could be as low as an hour. For typical systems = I think the likely lifetime will be between 1 day and 1 week.  IMHO = it=E2=80=99s valid for the working group to leave the cut-off between = =E2=80=9Cshort=E2=80=9D and =E2=80=9Cnot short=E2=80=9D to per-domain = profiles, but I don=E2=80=99t think anything beyond 2 weeks would ever = count as short.

> And how long is the time to
> "detect, report, and distribute revocation information"? With e.g: = CT,
> misissued certificates may be visible before they are used in an = attack,
> decreasing the detection time.

[YN] Someone needs to see the certificate to add it to the log, and = someone needs to find the certificate on the log and understand that it = is mis-issued. And then someone needs to add it to the CRL / database = that feeds the OCSP responder. And when this is updated, relying parties = may have cached copies of older revocation information. Add it up and it = can take days on the web.  In closed environments there may not be = CT at all. 


=E2=80=8BSo, here you say: "Add it up and = it can take days on the web." and above that you say: "For typical = systems I think the likely lifetime will be between 1 day and 1 week. =  [...] , but I don=E2=80=99t think anything beyond 2 weeks would = ever count as short."

"1 week" minus "days" = is still greater than zero, and so it still *seems* to me that removing = revocation is a bad idea -- but, my role is (or should be!) to make sure = that this charter doesn't conflict with other work (esp. ops work), that = the charter "describes the specific problem or deliverables (a = guideline, standards specification, etc.) it has been formed to address. = WG charters state the scope of work for group, and lay out goals and = milestones that show how this work will be completed." It is (IMO) the = sponsoring ADs, the WGs and IETFs decision as to if the ideas themselves = are acceptable.
I'm not (yet!) so arrogant that I'm sure I know the = right answer to everything, so I'd like to discuss this with EKR on the = call tomorrow, and will clear my block once I've been assured process is = being followed
/ this has been = considered.

Warren:

I think the = point you are missing is that it take time to process revocation and get = the CRL published or OCSP responder updated.  This is always over a = week because people do not revoke without doing due diligence.  So, = letting the short-lived certificate expire without issuing a replacement = will actually cause revocation to happen more quickly.

Russ

= --Apple-Mail=_D7057CA5-4FAF-434B-B5E2-0C585C262643-- From nobody Wed May 23 13:07:04 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0CB12D778; Wed, 23 May 2018 13:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 zHrNO5ZrLCFP; Wed, 23 May 2018 13:07:02 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 59CA7127010; Wed, 23 May 2018 13:07:02 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4NK6qWU008360; Wed, 23 May 2018 21:07:02 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=3sNBbqd5OBF+0/T0n13gh6RPmwXvtJ3eiDJ/Q6aR6WA=; b=IQQCIc7zbIUrRHYzFKlQS1cAP2es1ymuJ9yK1OkDjLk7x1gI+AYoXVHkBQ4qUqAb9osn 5qW5XcnqDEOwCj7aM9SATBKMktWmN2HdZvxzLGMENIUf7LbXE06V0DNZoJbO3+1byljZ TGSdO0ResC3grLU2SObvcM7Ene3sqagDj3sjY36Ff+d/yVff38aoImp3YnWM7V+IdVFb u95C/C8hmSRrnZgSxZ0O3Ji29f3bnfjZbOkxWaSo0yr24C6nIs29UK/aSeVq8TmDnF20 0DQwkpcni/y5FeIjeeKc0clQGPFR3r94AW58KrIlIZp6Pq1l33RO2wkd1BtC72AwXMzG kA== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2j5e91g4mh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 May 2018 21:07:01 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w4NK68To008096; Wed, 23 May 2018 16:07:00 -0400 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint4.akamai.com with ESMTP id 2j2f8vu154-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 23 May 2018 16:07:00 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 23 May 2018 15:07:00 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Wed, 23 May 2018 15:07:00 -0500 From: "Salz, Rich" To: Russ Housley CC: IESG , "spasm@ietf.org" Thread-Topic: [lamps] Spencer Dawkins' No Objection on charter-ietf-lamps-02-00: (with COMMENT) Thread-Index: AQHT8sHQeu/yCKfdfEmAmiT4c7N2fKQ+CNUA//++PwCAAEjUgP//vmqA Date: Wed, 23 May 2018 20:06:59 +0000 Message-ID: References: <152709922899.26838.11074435093932176947.idtracker@ietfa.amsl.com> <41e7a726-0175-7e3d-d35c-d413bf01ea12@nostrum.com> <32DD6ED8-F2C9-4193-98FA-BC7876634318@akamai.com> <65287CF3-4150-4A07-99D8-D3855901CB94@vigilsec.com> In-Reply-To: <65287CF3-4150-4A07-99D8-D3855901CB94@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.d.0.180513 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.7] Content-Type: text/plain; charset="utf-8" Content-ID: <9985363466DDD344B8FF4E6AA2B76858@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-23_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=477 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805230196 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-23_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=398 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805230196 Archived-At: Subject: Re: [lamps] Spencer Dawkins' No Objection on charter-ietf-lamps-02-00: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 20:07:04 -0000 PiAgICBUaGF0IGlzIG5vdCBxdWl0ZSB3aGF0IGhlIHNhaWQuICBLZW5ueSBzYWlkIHRoYXQgd2Ug c2hvdWxkIG5vdCBhZG9wdCBhIHBvc3QtcXVhbnR1bSBzZWN1cmUgYWxnb3JpdGhtLiAgS2Vubnkg ZGlkIG5vdCBzYXkgd2Ugc2hvdWxkIG5vdCBmaW5kIHdheXMgdG8gdXNlIHByZS1zaGFyZWQgc2Vj cmV0cyB0byBib2xzdGVyIHRoZSBzZWN1cml0eSBvZiB0aGUgdGVjaG5pcXVlcyB3ZSBhcmUgYWxy ZWFkeSB1c2luZy4NCiAgDQpZb3UgYXJlIHJpZ2h0LCB0aGFua3MgZm9yIHRoZSBjb3JyZWN0aW9u Lg0KDQo= From nobody Wed May 23 13:10:51 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD3812D77B for ; Wed, 23 May 2018 13:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uBMolC_cUsu for ; Wed, 23 May 2018 13:10:46 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9551512E87B for ; Wed, 23 May 2018 13:10:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7E47E300A30 for ; Wed, 23 May 2018 16:01:14 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RhDfIhqnWXAw for ; Wed, 23 May 2018 16:01:12 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id BCAAF30044B; Wed, 23 May 2018 16:01:12 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <32DD6ED8-F2C9-4193-98FA-BC7876634318@akamai.com> Date: Wed, 23 May 2018 16:01:13 -0400 Cc: IESG , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <65287CF3-4150-4A07-99D8-D3855901CB94@vigilsec.com> References: <152709922899.26838.11074435093932176947.idtracker@ietfa.amsl.com> <41e7a726-0175-7e3d-d35c-d413bf01ea12@nostrum.com> <32DD6ED8-F2C9-4193-98FA-BC7876634318@akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Spencer Dawkins' No Objection on charter-ietf-lamps-02-00: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 20:10:50 -0000 > On May 23, 2018, at 3:40 PM, Salz, Rich = wrote: >=20 >> My understanding is that the intention is "near-term from now." The = idea=20 > is that LAMPS should develop something that you could use, say, = next=20 > year to encrypt email you send so that, 15 years from now when = someone=20 > finally builds a 4,000 qubit machine, they can't dig out your = (then)=20 > 14-year-old email and decrypt it. >=20 > Kenny Paterson gave a talk at a recent IETF where he said, basically, = that the IETF should wait until NIST is done with their post-quantum = evaluation/competition. Are we sure we want to disagree with him? Or = is it just because digest-based signatures are well-understood that = we're willing to do so. Rich: That is not quite what he said. Kenny said that we should not adopt a = post-quantum secure algorithm. Kenny did not say we should not find = ways to use pre-shared secrets to bolster the security of the techniques = we are already using. Another example where we are mixing the pre-shared secret is = draft-ietf-ipsecme-qr-ikev2. Russ From nobody Wed May 23 13:16:42 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E707127978; Wed, 23 May 2018 13:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 n5xAefl_sdb9; Wed, 23 May 2018 13:16:38 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A829127010; Wed, 23 May 2018 13:16:38 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id v2-v6so20691728oif.3; Wed, 23 May 2018 13:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=v80QUkHTnAQOazlx+jcoQGpsG5QvgWyzBdB1L0txUFo=; b=agUX37yWnvB4RhFGYx3SSI4O+MgfKVpVUI9mc1a2XifEQqTTrGGgbbTfkni8q0HANy 001Ehtc/viY5yQWOjRI9rq3Nzo5cyF4ncsb95powqOiDh43BNzPgKZ/9HXq6jhExf8sE kDYBg3wFCJQ6VK8Jx+xh6YBESij72U2Mi1GbpnOAhWQVCjQg9BUESzwJ/rajj4sm74St l9f37eK8bub+mopEK46Yqpx2L/X7B4j9CDMPtBAhUEp0Xaq98+P0tcLzbwAPA1h+E0uC k/3b25RgZEggh9b6vmmDOiuWoFxAx4uw9NMNgMZSmwr+YuQ4Y2+cJ1/1Ips/CE4g5NyW ePmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=v80QUkHTnAQOazlx+jcoQGpsG5QvgWyzBdB1L0txUFo=; b=jQZSXvJDucXCfXwdT2kzZscwG0oK3iJAXsnPG8ll/wgbYwEF/cFrD/qUj37nC5YwPH W8A9sJf52mfAi9ZUoVy+mpvmfm9lp1ebvNlmO9ytGC0H7ecjUKNXIZKGgu9BsKr23ZfB TayEy+BKb5UdROinPYgJyMANGeAwakHDgBYbmGGm/3IDRNivLQoI1sWgT+7y96V17Z3u 1Op09kR6aP7pCmvsRIYkCvcYLDDAH86Up/vNx+cbKLfFhPjfLgqHOSFQwZ7wV5uBiEeF oomuWMKLDeGlIu/+wCddIXqMA+H/2544lCzi/6Lxtkqt5bSy+xPqSNOyxgjkJJG5sCgj BsfA== X-Gm-Message-State: ALKqPwfNd0SHIylHm3AfTiZaXB20ieq311DCjyroyJQzIHXuVhl4RkNY bmmW+81sXpQGli20SmPe7/4YCUwZpNORYeAimiE= X-Google-Smtp-Source: AB8JxZreQ6TiOkSLO/oK/cPhxz3DYuMUpls8wi645zCFhva9RNregAl5zrfYHWXt/GIARUzbYZNV7Z40TsAWHUvBex0= X-Received: by 2002:aca:3b0b:: with SMTP id i11-v6mr2277645oia.271.1527106597667; Wed, 23 May 2018 13:16:37 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:23:0:0:0:0:0 with HTTP; Wed, 23 May 2018 13:16:37 -0700 (PDT) In-Reply-To: <41e7a726-0175-7e3d-d35c-d413bf01ea12@nostrum.com> References: <152709922899.26838.11074435093932176947.idtracker@ietfa.amsl.com> <41e7a726-0175-7e3d-d35c-d413bf01ea12@nostrum.com> From: Phillip Hallam-Baker Date: Wed, 23 May 2018 16:16:37 -0400 X-Google-Sender-Auth: Hh3wKfuvN31XqoPfmKE-0tuIrDs Message-ID: To: Adam Roach Cc: Spencer Dawkins , The IESG , SPASM , lamps-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000049c91f056ce5360e" Archived-At: Subject: Re: [lamps] Spencer Dawkins' No Objection on charter-ietf-lamps-02-00: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 20:16:40 -0000 --00000000000049c91f056ce5360e Content-Type: text/plain; charset="UTF-8" I am not sure that that is possible. Signature is easy, just pickle the data and signature in a hash-chain and you are done. Problem with confidentiality is it is break once and it fails. All that you can do by adding technology to a public key encryption system is to provide additional ways to decrypt. The only way to protect against quantum cryptanalysis is to only use quantum resistant crypto. We can do that (e.g. Kerberos) but it ain't easy. Forward secrecy doesn't provide quantum resistance and it only works at the message layer, I don't know how to apply forward secrecy to data at rest (would love to hear suggestions), What I do to provide protection is a multi-layer encryption stack with crypto going on at the Transport, Transaction and Data layers. I can't use forward secrecy above the transaction layer. On Wed, May 23, 2018 at 3:35 PM, Adam Roach wrote: > On 5/23/18 1:13 PM, Spencer Dawkins wrote: > >> 4. Specify the use of a pre-shared key (PSK) along with other key >> management techniques with supported by the Cryptographic Message >> Syntax (CMS) as a near-term mechanism to protect present day >> communication from the future invention of a large-scale quantum >> computer. >> >> I found it confusing because "near-term" isn't "near-term from now", it's >> "near-term after the invention of quantum computing destroys civilization. >> > > My understanding is that the intention is "near-term from now." The idea > is that LAMPS should develop something that you could use, say, next year > to encrypt email you send so that, 15 years from now when someone finally > builds a 4,000 qubit machine, they can't dig out your (then) 14-year-old > email and decrypt it. > > /a > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --00000000000049c91f056ce5360e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I a= m not sure that that is possible.

Signature is easy, just pickle the data and signature in a hash-= chain and you are done.

P= roblem with confidentiality is it is break once and it fails. All that you = can do by adding technology to a public key encryption system is to provide= additional ways to decrypt. The only way to protect against quantum crypta= nalysis is to only use quantum resistant crypto. We can do that (e.g. Kerbe= ros) but it ain't easy.


Forward= secrecy doesn't provide quantum resistance and it only works at the me= ssage layer, I don't know how to apply forward secrecy to data at rest = (would love to hear suggestions),

What I do to provide protection is a multi-layer encryption stac= k with crypto going on at the Transport, Transaction and Data layers. I can= 't use forward secrecy above the transaction layer.



On Wed, May 23, 2018 at 3:35 PM, Adam Roach <adam@n= ostrum.com> wrote:
On 5/23/18 1:13 PM, Spencer Dawkins wrote:
4. Specify the use of a pre-shared key (PSK) along with other key
management techniques with supported by the Cryptographic Message
Syntax (CMS) as a near-term mechanism to protect present day
communication from the future invention of a large-scale quantum
computer.

I found it confusing because "near-term" isn't "near-ter= m from now", it's
"near-term after the invention of quantum computing destroys civilizat= ion.

 My understanding is that the intention is "near-term from now." T= he idea is that LAMPS should develop something that you could use, say, nex= t year to encrypt email you send so that, 15 years from now when someone fi= nally builds a 4,000 qubit machine, they can't dig out your (then) 14-y= ear-old email and decrypt it.

/a


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

--00000000000049c91f056ce5360e-- From nobody Wed May 23 13:23:57 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF6412E8EE; Wed, 23 May 2018 13:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 uZX9GCC0Q9nY; Wed, 23 May 2018 13:23:38 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6529C12EA56; Wed, 23 May 2018 13:23:38 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 118883C001C00; Wed, 23 May 2018 13:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=OCnzBxKFuGT6OTaH1itQm7x3o5c=; b= tPA2Wuveqq3DneHuyp/X01CM4yo5XYaEHCsQHFuv0VJuVRpOC8/ighJrMg0Tp7YL gyAjE9/+vBfvpP+QRBwPIlHyimThfg8NLJMKAZavWpaY7cBK+5O9LsqLpv6hpRRf 2xAetCe8O3hKmvJUfsaItedI3tescBfeapbOma+TuyA= Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPSA id D7B7C3C00074A; Wed, 23 May 2018 13:23:36 -0700 (PDT) Received: by mail-it0-f54.google.com with SMTP id d10-v6so5521025itj.1; Wed, 23 May 2018 13:23:36 -0700 (PDT) X-Gm-Message-State: ALKqPwepC1aE0wQJ5J0zuGuhYiW9Sinqt+lR2Yuo5fwcq+cCWyvbheQt vYLkTWqJxCH8PlhneWvMrnw2e8d3lXsjT78D2UI= X-Google-Smtp-Source: AB8JxZq+40gMtLtY2oBCvYOxWjUCTSS5A9bh2NE7NyEkt6DZflqMTRFdl5G4sx0qmld0DSz9fa+cXYYXgj95VOImEmk= X-Received: by 2002:a24:9d44:: with SMTP id f65-v6mr6523856itd.119.1527107016241; Wed, 23 May 2018 13:23:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:985a:0:0:0:0:0 with HTTP; Wed, 23 May 2018 13:23:35 -0700 (PDT) In-Reply-To: References: <152709543734.26876.14669273511731581188.idtracker@ietfa.amsl.com> <64EA6F18-9275-40FC-8FDE-3E12C4458EFB@gmail.com> From: Ryan Sleevi Date: Wed, 23 May 2018 16:23:35 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Alvaro Retana Cc: Yoav Nir , Warren Kumari , SPASM , lamps-chairs@ietf.org, The IESG Content-Type: multipart/alternative; boundary="0000000000003cb949056ce54f90" Archived-At: Subject: Re: [lamps] Warren Kumari's Block on charter-ietf-lamps-02-00: (with BLOCK and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 20:23:49 -0000 --0000000000003cb949056ce54f90 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 23, 2018 at 3:53 PM, Alvaro Retana wrote: > On May 23, 2018 at 3:32:21 PM, Warren Kumari (warren@kumari.net) wrote: > > Hi! > > =E2=80=8BSo, here you say: "Add it up and it can take days on the web." a= nd above > that you say: "For typical systems I think the likely lifetime will be > between 1 day and 1 week. [...] , but I don=E2=80=99t think anything bey= ond 2 > weeks would ever count as short." > > "1 week" minus "days" is still greater than zero, and so it still *seems* > to me that removing revocation is a bad idea -- but, my role is (or shoul= d > be!) to make sure that this charter doesn't conflict with other work (esp= . > ops work), that the charter "describes the specific problem or deliverabl= es > (a guideline, standards specification, etc.) it has been formed to addres= s. > WG charters state the scope of work for group, and lay out goals and > milestones that show how this work will be completed." It is (IMO) the > sponsoring ADs, the WGs and IETFs decision as to if the ideas themselves > are acceptable. > I'm not (yet!) so arrogant that I'm sure I know the right answer to > everything, so I'd like to discuss this with EKR on the call tomorrow > , and will clear my > block once I've been assured process is being followed > / this has been considered. > > I agree with Warren=E2=80=99s assessment. > > However, I also think that a charter may give undue validation to items > that would benefit from at least a little more description or > consideration. IOW, adding (to the charter) a longer description, and > listing which things should be satisfied, or at least considered, seems > like a good idea to me. > This was my request in https://mailarchive.ietf.org/arch/msg/spasm/paYqxqRL1LEEPgwOuGmUVB8V6lE/?qi= d=3D356aa0482508fa29bf866d05ea1981e6 and Stephen Farrell's agreement in https://mailarchive.ietf.org/arch/msg/spasm/Evk_hbJsHBuBGEnNaMCqaQEVceI --0000000000003cb949056ce54f90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 23, 2018 at 3:53 PM, Alvaro Retana <aretana.ietf@gmai= l.com> wrote:
On May 23, 2018 at 3:32:21 PM, Warren Kumari (warren@kumari.net) wrote:<= /div>

Hi!

=E2=80=8BSo, here you say= : "Add it up and it can take days on the web." and above that you= say: "For typical systems I think the likely lifetime will be between= 1 day and 1 week. =C2=A0[...] , but I don=E2=80=99t think anything beyond = 2 weeks would ever count as short."

"1 week" minus &q= uot;days" is still greater than zero, and so it still *seems* to me th= at removing revocation is a bad idea -- but, my role is (or should be!) to = make sure that this charter doesn't conflict with other work (esp. ops = work), that the charter "describes the specific problem or deliverable= s (a guideline, standards specification, etc.) it has been formed to addres= s. WG charters state the scope of work for group, and lay out goals and mil= estones that show how this work will be completed." It is (IMO) the sp= onsoring ADs, the WGs and IETFs decision as to if the ideas themselves are = acceptable.
I'm not (yet!) so arrogant that I'm sure I know th= e right answer to everything, so I'd like to discuss this with EKR on t= he call= =C2=A0tomorrow, and will clear my block once I've bee= n assured process is being followed
/ this has been considered.

I ag= ree with Warren=E2=80=99s assessment.

However, I also think that a charter may give undue validation to items th= at would benefit from at least a little more description or consideration.= =C2=A0 IOW, adding (to the charter) a longer description, and listing which= things should be satisfied, or at least considered, seems like a good idea= to me.

=

--0000000000003cb949056ce54f90-- From nobody Wed May 23 13:30:10 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09E312E873 for ; Wed, 23 May 2018 13:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 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_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9r5FjF_JBPMX for ; Wed, 23 May 2018 13:30:03 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C7E12D7F0 for ; Wed, 23 May 2018 13:29:59 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id t27-v6so20716212oij.9 for ; Wed, 23 May 2018 13:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=44fa8+bey6HlJBqubo3TArsxNZfayDLWVGEEkePqAWw=; b=BSzarVtECt5rW4awliQdZwQjcX8hT3vCwrwHyqCZoKOuysvOQWDR8OuzYdk10b+2vI 99jYFIbM46iYKEZH2m33Gmfw5v54jxmV+eJD+E2lyVLxtsuNrkLjQ+qIOV76ctGBfQGA dL4W9Cu4Sf1VE2+8UtCnwbDNzalZsP4n80x1gOjWOGepksyRlzJKqoRpw96nIcDtJsuN lmhzSM7VDLSImgXQaUfi+UCTpgynW68aQSDcgDEA/nerkcwWgk7Z938bKoiKKM4auVIr +2D2ZEBLEAA30m+XDH3nax54kYHHSGDPK/KsWvw5BKMfWsdqpQOFTwrssT4btyUkOAH2 gU7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=44fa8+bey6HlJBqubo3TArsxNZfayDLWVGEEkePqAWw=; b=MTfuTiVHADvdDWzfrj3CFT2JPZYwfz2iEovO6tfZlGC/ux9UKYnCRIyUacxAwLSv/y nevOmGfXCp2EMQslxjtiYSrJsf4bqSCVS97ehrhzL+OIvhFBsag3n0Zb/8YiAWCnoggG 8TxYTAPknO1lcc5p6oNFzNpIe613WZXFKO+UzF2xs5mQIiArA1zYeTFeS5s2cz3O8wyT m1FTWvcPyhSWLiHgUtZl3FFj+yNhJCFNqpWxJQu4nHErvjzTYhkgcy2Cgu0m4Np0p6N1 gNSAVYLy1sQFPgW9uG/o7qSIiD1U6kKOkBhtPePAjDGT5O2tXjTd+2SnBkznrMOo4C8S +ACg== X-Gm-Message-State: ALKqPwd+F+DhJ8lSQtdHAiAAyKN2a9a/4/SW1A/yzAmVApQVrxa96MnA ZXjK7B9TvPbyHo7mpW0CZKT0SeSdiHG9wlbv8d1YsQ== X-Google-Smtp-Source: AB8JxZoluyW4sruoeJK4QcjGQxBgBf1ezeHLrFrqXicEOU8MuMXpsRWputtur8ZhcL62/FYS2pirrtbxH/BZQlZ3F/c= X-Received: by 2002:aca:d10:: with SMTP id 16-v6mr2454602oin.108.1527107399162; Wed, 23 May 2018 13:29:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:66:0:0:0:0:0 with HTTP; Wed, 23 May 2018 13:29:18 -0700 (PDT) In-Reply-To: References: <152709543734.26876.14669273511731581188.idtracker@ietfa.amsl.com> <64EA6F18-9275-40FC-8FDE-3E12C4458EFB@gmail.com> From: Eric Rescorla Date: Wed, 23 May 2018 13:29:18 -0700 Message-ID: To: Warren Kumari Cc: Yoav Nir , SPASM , lamps-chairs@ietf.org, The IESG Content-Type: multipart/alternative; boundary="0000000000000fb4ad056ce56626" Archived-At: Subject: Re: [lamps] Warren Kumari's Block on charter-ietf-lamps-02-00: (with BLOCK and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 20:30:06 -0000 --0000000000000fb4ad056ce56626 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 23, 2018 at 12:31 PM, Warren Kumari wrote: > > > On Wed, May 23, 2018 at 1:39 PM Yoav Nir wrote: > >> Hi Warren. >> >> Since it was my draft and presentation at SecDispatch that led to this >> item, I feel I can answer this. Inline. >> >> > On 23 May 2018, at 20:10, Warren Kumari wrote: >> > >> > Warren Kumari has entered the following ballot position for >> > charter-ietf-lamps-02-00: Block >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut thi= s >> > introductory paragraph, however.) >> > >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/charter-ietf-lamps/ >> > >> > >> > >> > ---------------------------------------------------------------------- >> > BLOCK: >> > ---------------------------------------------------------------------- >> > >> > "3. Specify the use of short-lived X.509 certificates for which no >> > revocation information is made available by the Certification Authorit= y. >> > Short-lived certificates have a lifespan that is shorter than the time >> > needed to detect, report, and distribute revocation information, as a >> > result revoking them pointless." >> > >> > This makes me twitch -- how short is "short=E2=80=9D? >> >> [YN] I expect this to be contentious within the working group, and I >> expect the exact cut-off point to be different from one use-case to >> another. For highly reliable systems with good clock synchronization >> =E2=80=9Cshort=E2=80=9D could be as low as an hour. For typical systems = I think the likely >> lifetime will be between 1 day and 1 week. IMHO it=E2=80=99s valid for = the working >> group to leave the cut-off between =E2=80=9Cshort=E2=80=9D and =E2=80=9C= not short=E2=80=9D to per-domain >> profiles, but I don=E2=80=99t think anything beyond 2 weeks would ever c= ount as >> short. >> >> > And how long is the time to >> > "detect, report, and distribute revocation information"? With e.g: CT, >> > misissued certificates may be visible before they are used in an attac= k, >> > decreasing the detection time. >> >> [YN] Someone needs to see the certificate to add it to the log, and >> someone needs to find the certificate on the log and understand that it = is >> mis-issued. And then someone needs to add it to the CRL / database that >> feeds the OCSP responder. And when this is updated, relying parties may >> have cached copies of older revocation information. Add it up and it can >> take days on the web. In closed environments there may not be CT at all= . >> >> > =E2=80=8BSo, here you say: "Add it up and it can take days on the web." a= nd above > that you say: "For typical systems I think the likely lifetime will be > between 1 day and 1 week. [...] , but I don=E2=80=99t think anything bey= ond 2 > weeks would ever count as short." > > "1 week" minus "days" is still greater than zero, and so it still *seems* > to me that removing revocation is a bad idea -- but, my role is (or shoul= d > be!) to make sure that this charter doesn't conflict with other work (esp= . > ops work), that the charter "describes the specific problem or deliverabl= es > (a guideline, standards specification, etc.) it has been formed to addres= s. > WG charters state the scope of work for group, and lay out goals and > milestones that show how this work will be completed." It is (IMO) the > sponsoring ADs, the WGs and IETFs decision as to if the ideas themselves > are acceptable. > I'm not (yet!) so arrogant that I'm sure I know the right answer to > everything, so I'd like to discuss this with EKR on the call tomorrow, an= d > will clear my block once I've been assured process is being followed > / this has been considered. > Thanks. I think the thing that's important to understand is that revocation on the Web is badly broken. The two primary standardized ways to deal with revocation are: - OCSP -- but it's so brittle that people won't hard fail, so it's not very good - OCSP stapling - which has a lifetime of around a week or so, and so basically has the same security properties as short-lived certs. -Ekr > > >> > Also, I would figure that it is still useful to know that a certificat= e >> was >> > revoked and didn't just expire -- if I see a certificate which expired >> 10 >> > minutes ago I may be willing (after some consideration, checking my >> clock, etc) >> > to decide to trust it anyway (even if that's a bad idea!), but a revok= ed >> > certificate is a clear indication that something bad happened, and >> changes my >> > risk assessment. >> >> [YN] Yes, and the candidate draft has a SHOULD-level requirement to not >> allow any grace periods for such certificates. One of the feedbacks I go= t >> was that this should be upgraded to MUST (or rather MUST NOT) >> >> > Ok. That helps. > > Thanks! > W > > > >> > It's entirely possible that there is a really good reason why I'm wron= g >> / that >> > this argument doesn't make sense in some use cases (or just that I'm >> nuts!) >> >> [YN] There was some push-back about the name. The important point is not >> so much that the lifetime is short, but that there is no revocation >> information. We want these certificates because we don=E2=80=99t want to= deal with >> revocation information. Non-revocation is the end. Making them short-te= rm >> is the means, or rather the sacrifice we need to make to make (other) >> security people happy. >> >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > >> > Also, "revoking them pointless" does not parse - perhaps "revoking the= m >> is pointless"? >> > >> > >> > _______________________________________________ >> > Spasm mailing list >> > Spasm@ietf.org >> > https://www.ietf.org/mailman/listinfo/spasm >> >> > > -- > I don't think the execution is relevant when it was obviously a bad idea > in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair of > pants. > ---maf > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > --0000000000000fb4ad056ce56626 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 23, 2018 at 12:31 PM, Warren Kumari <<= a href=3D"mailto:warren@kumari.net" target=3D"_blank">warren@kumari.net= > wrote:


On Wed, May 23, 2018 at 1:39= PM Yoav Nir <y= nir.ietf@gmail.com> wrote:
Hi Warren.

Since it was my draft and presentation at SecDispatch that led to this item= , I feel I can answer this.=C2=A0 Inline.

> On 23 May 2018, at 20:10, Warren Kumari <warren@kumari.net> wrote:
>
> Warren Kumari has entered the following ballot position for
> charter-ietf-lamps-02-00: Block
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/cha= rter-ietf-lamps/
>
>
>
> ------------------------------------------------------------= ----------
> BLOCK:
> ------------------------------------------------------------= ----------
>
> "3. Specify the use of short-lived X.509 certificates for which n= o
> revocation information is made available by the Certification Authorit= y.
> Short-lived certificates have a lifespan that is shorter than the time=
> needed to detect, report, and distribute revocation information, as a<= br> > result revoking them pointless."
>
> This makes me twitch -- how short is "short=E2=80=9D?

[YN] I expect this to be contentious within the working group, and I expect= the exact cut-off point to be different from one use-case to another. For = highly reliable systems with good clock synchronization =E2=80=9Cshort=E2= =80=9D could be as low as an hour. For typical systems I think the likely l= ifetime will be between 1 day and 1 week.=C2=A0 IMHO it=E2=80=99s valid for= the working group to leave the cut-off between =E2=80=9Cshort=E2=80=9D and= =E2=80=9Cnot short=E2=80=9D to per-domain profiles, but I don=E2=80=99t th= ink anything beyond 2 weeks would ever count as short.

> And how long is the time to
> "detect, report, and distribute revocation information"? Wit= h e.g: CT,
> misissued certificates may be visible before they are used in an attac= k,
> decreasing the detection time.

[YN] Someone needs to see the certificate to add it to the log, and someone= needs to find the certificate on the log and understand that it is mis-iss= ued. And then someone needs to add it to the CRL / database that feeds the = OCSP responder. And when this is updated, relying parties may have cached c= opies of older revocation information. Add it up and it can take days on th= e web.=C2=A0 In closed environments there may not be CT at all.=C2=A0


=E2=80=8BSo, here you say: "Add it up and it can = take days on the web." and above that you say: "For typical syste= ms I think the likely lifetime will be between 1 day and 1 week. =C2=A0[...= ] , but I don=E2=80=99t think anything beyond 2 weeks would ever count as s= hort."

"1 week" minus "days" is still great= er than zero, and so it still *seems* to me that removing revocation is a b= ad idea -- but, my role is (or should be!) to make sure that this charter d= oesn't conflict with other work (esp. ops work), that the charter "= ;describes the specific problem or deliverables (a guideline, standards spe= cification, etc.) it has been formed to address. WG charters state the scop= e of work for group, and lay out goals and milestones that show how this wo= rk will be completed." It is (IMO) the sponsoring ADs, the WGs and IET= Fs decision as to if the ideas themselves are acceptable.
I'm not = (yet!) so arrogant that I'm sure I know the right answer to everything,= so I'd like to discuss this with EKR on the call tomorrow, and will cl= ear my block once I've been assured process is being followed
/ this= has been considered.

Tha= nks. I think the thing that's important to understand is that revocatio= n on the Web is badly broken. The two primary standardized ways to deal wit= h revocation are:

- OCSP -- but it's so brittl= e that people won't hard fail, so it's not very good
- OC= SP stapling - which has a lifetime of around a week or so, and so basically= has the same security properties as short-lived certs.

<= /div>
-Ekr


>
> Also, I would figure that it is still useful to know that a certificat= e was
> revoked and didn't just expire -- if I see a certificate which exp= ired 10
> minutes ago I may be willing (after some consideration, checking my cl= ock, etc)
> to decide to trust it anyway (even if that's a bad idea!), but a r= evoked
> certificate is a clear indication that something bad happened, and cha= nges my
> risk assessment.

[YN] Yes, and the candidate draft has a SHOULD-level requirement to not all= ow any grace periods for such certificates. One of the feedbacks I got was = that this should be upgraded to MUST (or rather MUST NOT)


Ok. That helps.

Thanks!
W

>
> It's entirely possible that there is a really good reason why I= 9;m wrong / that
> this argument doesn't make sense in some use cases (or just that I= 'm nuts!)

[YN] There was some push-back about the name. The important point is not so= much that the lifetime is short, but that there is no revocation informati= on. We want these certificates because we don=E2=80=99t want to deal with r= evocation information. Non-revocation is the end.=C2=A0 Making them short-t= erm is the means, or rather the sacrifice we need to make to make (other) s= ecurity people happy.

> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
>
> Also, "revoking them pointless" does not parse - perhaps &qu= ot;revoking them is pointless"?
>
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org=
> https://www.ietf.org/mailman/listinfo/spasm=


--
I don't think the execution is relevant whe= n it was obviously a bad idea in the first place.
This is like putting r= abid weasels in your pants, and later expressing regret at having chosen th= ose particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf=

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


--0000000000000fb4ad056ce56626-- From nobody Wed May 23 13:52:34 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7E0127010; Wed, 23 May 2018 13:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 NSyBZGnObIvR; Wed, 23 May 2018 13:52:29 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 BA30A12D7E6; Wed, 23 May 2018 13:52:29 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id l1-v6so20796885oii.1; Wed, 23 May 2018 13:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=KkGvfEs/gtM9Jwdyi4JYAXm9LOeo6caX4eeq3ATte/4=; b=ft3ueiha1yDwWrv5YeZqs0McqBaWFSeeZKp47QxLfIvlW6dIVCsXQx9IpIXHNOOYpg A/N6kP3XP8o01kHVd3OsJ5D8dYZDQ/YWyfZCLi44BJcgIQ0LFQhBbr7qoYsXPjLd/oz5 sANc4UFORYRrNwRun6OosQReHouXLr6xxIQ0Yf9zK/bn//Ehok7hiWMKEbAGyDEvlGCw mgFCabKlrelue40Z18jUQEYvAulMBQ80u59IO23jlF+YE25ijebqr+rEZu33ycnooDIP u2MKYPRY9UA/cQbpREegYR16OQsA4cVv1LRpswr+z8dGsTr8sFZFzfUUl49IU6HB0yqg 1eDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=KkGvfEs/gtM9Jwdyi4JYAXm9LOeo6caX4eeq3ATte/4=; b=Faxq/6rPz2M4awNKjYz4dHJE6JZPOPI/f6YiKx+SNqCw9lmV52aPKQeQmnukUSxX3s o53AXmBnRjP36pdXzXbHrFOT/5n4pphyNgTHi2UOByF6/N6ZVydaMzhdmzpr8FaNcDEW 6tBzaA/Zxl4QEhqtfhlWwiJm9BJJ7G2PMZivvDzYOnCLqKzKyMDlwjiiUOAwnoTaOget FrPg7DcD92/PKv0+gsy4bgrtx8px7FonLkIKMkKAJ+3ydeTvDV1OLM0O3FJ/42rYNLVH YAT//sxEJk6f1stMLgHonB/5D/CK4y7Kq9Yw06XrbpbfQLA+uPxsXMP9FDI93vUEfj3b e68Q== X-Gm-Message-State: ALKqPweREVeQ6qLN6N3xfYMPKszwWSDTBtdc6xVg2D/fNKkEskBB54P8 uKkpDu050GjoAp4SIebyLoo2HL742bmBUAK9vbixNQ== X-Google-Smtp-Source: AB8JxZq+p7MDQHPISdULFteeknkFmRgcYSj9X4uib9Rd7Ukf6RhR5Eux5xhK7DS0oeVB20901btNvfmYvS5BL8FaDJs= X-Received: by 2002:aca:6257:: with SMTP id w84-v6mr2614661oib.26.1527108748906; Wed, 23 May 2018 13:52:28 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:23:0:0:0:0:0 with HTTP; Wed, 23 May 2018 13:52:28 -0700 (PDT) In-Reply-To: <152709543734.26876.14669273511731581188.idtracker@ietfa.amsl.com> References: <152709543734.26876.14669273511731581188.idtracker@ietfa.amsl.com> From: Phillip Hallam-Baker Date: Wed, 23 May 2018 16:52:28 -0400 X-Google-Sender-Auth: 1ZVDqG1ADPGKuMkKi3hGo_8dnUM Message-ID: To: Warren Kumari Cc: The IESG , SPASM , lamps-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000083164d056ce5b627" Archived-At: Subject: Re: [lamps] Warren Kumari's Block on charter-ietf-lamps-02-00: (with BLOCK and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 20:52:33 -0000 --00000000000083164d056ce5b627 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 23, 2018 at 1:10 PM, Warren Kumari wrote: > Warren Kumari has entered the following ballot position for > charter-ietf-lamps-02-00: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-lamps/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > "3. > =E2=80=8B=E2=80=8B > Specify the use of short-lived X.509 certificates for which no > revocation information is made available by the Certification Authority. > Short-lived certificates have a lifespan > =E2=80=8B=E2=80=8B > that is shorter than the time > needed to detect, report, and distribute revocation information, as a > result revoking them pointless." > > This makes me twitch -- how short is "short"? And how long is the time to > "detect, report, and distribute revocation information"? With e.g: CT, > misissued certificates may be visible before they are used in an attack, > decreasing the detection time. > =E2=80=8BHow about =E2=80=8B =E2=80=8B" =E2=80=8B Specify the use of "short-lived" X.509 certificates that are issued with validity intervals that fall within the validity window for reporting revocation information permitted by the application, thus obviating the need for online certificate status reporting" Note: * Yeah, 'obviating', sorry but it does not necessarily eliminate the OCSP requirement for legacy reasons but it makes using the service pointless. =E2=80=8B* Such certificates may still be listed in CRLs but the treatment = of these is likely to be different. * At least one browser provider still believes in certificate revocation and is looking to support short lived certificates as part of a strategy that provides for much more aggressive revocation than is currently possible. That is within minutes rather than days.=E2=80=8B So this is not = really about killing revocation, it is about superseding OCSP. > Also, I would figure that it is still useful to know that a certificate w= as > revoked and didn't just expire -- if I see a certificate which expired 10 > minutes ago I may be willing (after some consideration, checking my clock= , > etc) > to decide to trust it anyway (even if that's a bad idea!), but a revoked > certificate is a clear indication that something bad happened, and change= s > my > risk assessment. > > It's entirely possible that there is a really good reason why I'm wrong / > that > this argument doesn't make sense in some use cases (or just that I'm nuts= !) > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Also, "revoking them pointless" does not parse - perhaps "revoking them i= s > pointless"? > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --00000000000083164d056ce5b627 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Ma= y 23, 2018 at 1:10 PM, Warren Kumari <warren@kumari.net> wro= te:
Warren Kumari has entered the followi= ng ballot position for
charter-ietf-lamps-02-00: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ie= tf-lamps/



-----------------------------------------------------------------= -----
BLOCK:
-----------------------------------------------------------------= -----

"3.
=E2=80=8B=E2=80=8B
Specify the use of short-lived X.509 certificat= es for which no
revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan
=E2=80=8B=E2=80=8B
that is shorter= than the time
needed to detect, report, and distribute revocation information, as a
result revoking them pointless."

This makes me twitch -- how short is "short"? And how long is the= time to
"detect, report, and distribute revocation information"? With e.g= : CT,
misissued certificates may be visible before they are used in an attack, decreasing the detection time.

=E2=80=8BHow about =E2=80=8B=
=E2=80=8B"= ;
=E2=80=8B
Specify the use of "short-lived" X.509 certificates that are= issued with=C2=A0
validity intervals that fall within th= e validity window for reporting revocation
information pe= rmitted by the application, thus obviating the need for
o= nline certificate status reporting"

Note:

* Yeah, 'obviating', sorry but it does = not necessarily eliminate the OCSP requirement for legacy reasons but it ma= kes using the service pointless.

=E2=80=8B* Such certificates may s= till be listed in CRLs but the treatment of these is likely to be different= .

* At least one browser = provider still believes in certificate revocation and is looking to support= short lived certificates as part of a strategy that provides for much more= aggressive revocation than is currently possible. That is within minutes r= ather than days.=E2=80=8B So this is not really about killing revocation, i= t is about superseding OCSP.



<= div>=C2=A0
Also, I would figure that it is still useful to know that a certificate was=
revoked and didn't just expire -- if I see a certificate which expired = 10
minutes ago I may be willing (after some consideration, checking my clock, = etc)
to decide to trust it anyway (even if that's a bad idea!), but a revoke= d
certificate is a clear indication that something bad happened, and changes = my
risk assessment.

It's entirely possible that there is a really good reason why I'm w= rong / that
this argument doesn't make sense in some use cases (or just that I'= m nuts!)


-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----


Also, "revoking them pointless" does not parse - perhaps "re= voking them is pointless"?


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

--00000000000083164d056ce5b627-- From nobody Wed May 23 14:09:43 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F24312D7F5 for ; Wed, 23 May 2018 14:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 oT3v2UBYH92g for ; Wed, 23 May 2018 14:09:38 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 2A631127010 for ; Wed, 23 May 2018 14:09:38 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id f8-v6so12866045wmc.4 for ; Wed, 23 May 2018 14:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mtmQteiR0jjhYA+DeOboXH7kABchTzpr8Rip8tZh+Lc=; b=EKkOUhtLSHbGy1W8LxJRjuGLZCahOJbKVD/IVB5u/QGZP5nP4R3MN5/+ZglF8cCfS9 hRTDDrBDG9+hsaAZbeMFk2YtIJtR1dcjRZeW2AveXTFjg6gkQYM02WZS98uGyKR6slm/ P4BtN46NnJZREAZNxgobwh7KGIr+fR6h+es1xOJdFJoxFDqbgeqn372H6UBJUpGyGzAG jDU2HG5b9M/ngJNhjedEpRZKL7vZwbcdKyGMIn1uqHdltlkyYtebxv9JNuxSl46pOnLo hovPxYtjqCWG3kJcsWgwz/KeV7wNxXCrxPC3iuVOFFrtx1LjdB8SCkYOIQoTZqCTmNYG e7Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mtmQteiR0jjhYA+DeOboXH7kABchTzpr8Rip8tZh+Lc=; b=reocl/d1PuKRQLarIyyrPNBzzZ4s26oMBr+6IWv8ftoahQ4yo9bC2ntzEMc+RKpBj7 GtN7sq5i7FuH9pSyfs61WRRBBEX8/X2oFbHvg9eRPu+DekIY7//szga9zjtMla50f8VJ QKcjOGoIbitDsiYERAyhogkwqqqisxsCz5Z9/XHxiXz2Bo2km4Xquf93CswUdx1QphN+ ZyoYe/WbW7iB6jYS+EIv8SiJ8CX3wOdbJZWtW42qaDgXOQGHUAKZQImMwSAA4C17HnTR +pD3sE1dIn54rxyWkK7KSHA3lfPmbYjcV6+PLg7iNwn5ERZjCqkw2NkUuNxK0aM6/pwi EUQA== X-Gm-Message-State: ALKqPweawXaK3S7/3KtMC4stcys/AvYwPOL9zg2lEBt0zOg10TUieA8e LvDlqmgvqBZROGB6ffTCMIVmhZUMA9CJkSkQ7zZw2ojjoJg= X-Google-Smtp-Source: AB8JxZpMjaZObfjQ+U8I8JRBeuuvu8vo350BkWAWwGn1myelXSCUt52jI0SE7AQFS3J4qyxCLZYEvD0SiagSEzrftu4= X-Received: by 2002:a1c:d755:: with SMTP id o82-v6mr4762757wmg.71.1527109776280; Wed, 23 May 2018 14:09:36 -0700 (PDT) MIME-Version: 1.0 References: <152709543734.26876.14669273511731581188.idtracker@ietfa.amsl.com> <64EA6F18-9275-40FC-8FDE-3E12C4458EFB@gmail.com> In-Reply-To: From: Warren Kumari Date: Wed, 23 May 2018 17:08:59 -0400 Message-ID: To: Russ Housley Cc: Yoav Nir , spasm@ietf.org, lamps-chairs@ietf.org, The IESG Content-Type: multipart/alternative; boundary="000000000000bfa01d056ce5f34b" Archived-At: Subject: Re: [lamps] Warren Kumari's Block on charter-ietf-lamps-02-00: (with BLOCK and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 21:09:42 -0000 --000000000000bfa01d056ce5f34b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 23, 2018 at 3:53 PM Russ Housley wrote: > Please see my response at the bottom of the message ... > > =E2=80=8B... and mine even further down :-)=E2=80=8B > On May 23, 2018, at 3:31 PM, Warren Kumari wrote: > > On Wed, May 23, 2018 at 1:39 PM Yoav Nir wrote: > >> Hi Warren. >> >> Since it was my draft and presentation at SecDispatch that led to this >> item, I feel I can answer this. Inline. >> >> > On 23 May 2018, at 20:10, Warren Kumari wrote: >> > >> > Warren Kumari has entered the following ballot position for >> > charter-ietf-lamps-02-00: Block >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut thi= s >> > introductory paragraph, however.) >> > >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/charter-ietf-lamps/ >> > >> > >> > >> > ---------------------------------------------------------------------- >> > BLOCK: >> > ---------------------------------------------------------------------- >> > >> > "3. Specify the use of short-lived X.509 certificates for which no >> > revocation information is made available by the Certification Authorit= y. >> > Short-lived certificates have a lifespan that is shorter than the time >> > needed to detect, report, and distribute revocation information, as a >> > result revoking them pointless." >> > >> > This makes me twitch -- how short is "short=E2=80=9D? >> >> [YN] I expect this to be contentious within the working group, and I >> expect the exact cut-off point to be different from one use-case to >> another. For highly reliable systems with good clock synchronization >> =E2=80=9Cshort=E2=80=9D could be as low as an hour. For typical systems = I think the likely >> lifetime will be between 1 day and 1 week. IMHO it=E2=80=99s valid for = the working >> group to leave the cut-off between =E2=80=9Cshort=E2=80=9D and =E2=80=9C= not short=E2=80=9D to per-domain >> profiles, but I don=E2=80=99t think anything beyond 2 weeks would ever c= ount as >> short. >> >> > And how long is the time to >> > "detect, report, and distribute revocation information"? With e.g: CT, >> > misissued certificates may be visible before they are used in an attac= k, >> > decreasing the detection time. >> >> [YN] Someone needs to see the certificate to add it to the log, and >> someone needs to find the certificate on the log and understand that it = is >> mis-issued. And then someone needs to add it to the CRL / database that >> feeds the OCSP responder. And when this is updated, relying parties may >> have cached copies of older revocation information. Add it up and it can >> take days on the web. In closed environments there may not be CT at all= . >> >> > =E2=80=8BSo, here you say: "Add it up and it can take days on the web." a= nd above > that you say: "For typical systems I think the likely lifetime will be > between 1 day and 1 week. [...] , but I don=E2=80=99t think anything bey= ond 2 > weeks would ever count as short." > > "1 week" minus "days" is still greater than zero, and so it still *seems* > to me that removing revocation is a bad idea -- but, my role is (or shoul= d > be!) to make sure that this charter doesn't conflict with other work (esp= . > ops work), that the charter "describes the specific problem or deliverabl= es > (a guideline, standards specification, etc.) it has been formed to addres= s. > WG charters state the scope of work for group, and lay out goals and > milestones that show how this work will be completed." It is (IMO) the > sponsoring ADs, the WGs and IETFs decision as to if the ideas themselves > are acceptable. > I'm not (yet!) so arrogant that I'm sure I know the right answer to > everything, so I'd like to discuss this with EKR on the call tomorrow, an= d > will clear my block once I've been assured process is being followed > / this has been considered. > > > Warren: > > I think the point you are missing is that it take time to process > revocation and get the CRL published or OCSP responder updated. This is > always over a week because people do not revoke without doing due > diligence. So, letting the short-lived certificate expire without issuin= g > a replacement will actually cause revocation to happen more quickly. > > =E2=80=8BI remain unconvinced -- some years ago I purchased a =E2=80=8BDV c= ert and, though a series of stupidly I managed to delete the private key[0]. The CA / reseller I was using had a friendly "Revoke" button which let me upload a new CSR and get a new cert within a few minutes. I'll happily admit that I didn't check if they actually added the old one to a CRL, a: I assumed that they did and b: they did let me reissue without more $$$ - which was the only bit I actually cared about :-). Now that I've finished writing this it feels somewhat like: "I just the other day got=E2=80=A6 an Internet was sent by my staff at 10 o'clock in th= e morning on Friday. I got it yesterday [Tuesday]. Why? Because it got tangled up with all these things going on the Internet commercially." - Ted Stevens. W [0]: ejabberd wants the key, cert and intermediate certs all in a single .pem file -- while trying to make this I managed to overwrite the key (I did 'cp * > kumari.net-combined.pem' instead of 'cat * > kumari.net-combined.pem') > Russ > > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --000000000000bfa01d056ce5f34b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On We= d, May 23, 2018 at 3:53 PM Russ Housley <housley@vigilsec.com> wrote:
Please see= my response at the bottom of the message ...


=E2=80=8B... and mine even further down :-)=E2=80=8B
On May 23, 2018, at 3:31 P= M, Warren Kumari <warren@kumari.net> wrote:

On Wed, May 23, 2018 at 1:39 PM Yoav Nir = <ynir.ietf@gmai= l.com> wrote:
Hi Warren.

Since it was my draft and presentation at SecDispatch that led to this item= , I feel I can answer this.=C2=A0 Inline.

> On 23 May 2018, at 20:10, Warren Kumari <warren@kumari.net> wrote:
>
> Warren Kumari has entered the following ballot position for
> charter-ietf-lamps-02-00: Block
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-= ietf-lamps/
>
>
>
> ----------------------------------------------------------------------=
> BLOCK:
> ----------------------------------------------------------------------=
>
> "3. Specify the use of short-lived X.509 certificates for which n= o
> revocation information is made available by the Certification Authorit= y.
> Short-lived certificates have a lifespan that is shorter than the time=
> needed to detect, report, and distribute revocation information, as a<= br> > result revoking them pointless."
>
> This makes me twitch -- how short is "short=E2=80=9D?

[YN] I expect this to be contentious within the working group, and I expect= the exact cut-off point to be different from one use-case to another. For = highly reliable systems with good clock synchronization =E2=80=9Cshort=E2= =80=9D could be as low as an hour. For typical systems I think the likely l= ifetime will be between 1 day and 1 week.=C2=A0 IMHO it=E2=80=99s valid for= the working group to leave the cut-off between =E2=80=9Cshort=E2=80=9D and= =E2=80=9Cnot short=E2=80=9D to per-domain profiles, but I don=E2=80=99t th= ink anything beyond 2 weeks would ever count as short.

> And how long is the time to
> "detect, report, and distribute revocation information"? Wit= h e.g: CT,
> misissued certificates may be visible before they are used in an attac= k,
> decreasing the detection time.

[YN] Someone needs to see the certificate to add it to the log, and someone= needs to find the certificate on the log and understand that it is mis-iss= ued. And then someone needs to add it to the CRL / database that feeds the = OCSP responder. And when this is updated, relying parties may have cached c= opies of older revocation information. Add it up and it can take days on th= e web.=C2=A0 In closed environments there may not be CT at all.=C2=A0


=E2=80=8BI= remain unconvinced -- some years ago I purchased a =E2=80=8BDV cert and, t= hough a series of stupidly I managed to delete the private key[0]. The CA /= reseller I was using had a friendly "Revoke" button which let me= upload a new CSR and get a new cert within a few minutes. I'll happily= admit that I didn't check if they actually added the old one to a CRL,= a: I assumed that they did and b: they did let me reissue without more $$$= - which was the only bit I actually cared about :-).

Now that I= 've finished writing this it feels somewhat like: "I just the othe= r day got=E2=80=A6 an Internet was sent by my staff at 10 o'clock in th= e morning on Friday. I got it yesterday [Tuesday]. Why? Because it got tang= led up with all these things going on the Internet commercially." - Te= d Stevens.

W
[0]: ejabberd wants the key, cert and intermediate certs = all in a single .pem file -- while trying to make this I managed to overwri= te the key=C2=A0 (I did 'cp * > kumari.net-combined.pem' instead= of 'cat * > kumari.net-combined.pem')
=C2=A0
Russ



--
I don't think the e= xecution is relevant when it was obviously a bad idea in the first place.This is like putting rabid weasels in your pants, and later expressing re= gret at having chosen those particular rabid weasels and that pair of pants= .
=C2=A0 =C2=A0---maf
--000000000000bfa01d056ce5f34b-- From nobody Wed May 23 14:15:02 2018 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FA9127010; Wed, 23 May 2018 14:14:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: lamps-chairs@ietf.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152711009395.26876.300138090771817722.idtracker@ietfa.amsl.com> Date: Wed, 23 May 2018 14:14:53 -0700 Archived-At: Subject: [lamps] Warren Kumari's No Objection on charter-ietf-lamps-02-00: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 21:14:54 -0000 Warren Kumari has entered the following ballot position for charter-ietf-lamps-02-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-lamps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for educating me - it sounds like my concerns have been considered, clearing my Block position. ---- Also, "revoking them pointless" does not parse - perhaps "revoking them is pointless"? Original Block position (for archeology): "3. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information, as a result revoking them pointless." This makes me twitch -- how short is "short"? And how long is the time to "detect, report, and distribute revocation information"? With e.g: CT, misissued certificates may be visible before they are used in an attack, decreasing the detection time. Also, I would figure that it is still useful to know that a certificate was revoked and didn't just expire -- if I see a certificate which expired 10 minutes ago I may be willing (after some consideration, checking my clock, etc) to decide to trust it anyway (even if that's a bad idea!), but a revoked certificate is a clear indication that something bad happened, and changes my risk assessment. It's entirely possible that there is a really good reason why I'm wrong / that this argument doesn't make sense in some use cases (or just that I'm nuts!) From nobody Wed May 23 14:16:28 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B0412D7F5 for ; Wed, 23 May 2018 14:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 d-GZaF7TmJZA for ; Wed, 23 May 2018 14:16:13 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 47BF312E8EE for ; Wed, 23 May 2018 14:16:13 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id j5-v6so12874351wme.5 for ; Wed, 23 May 2018 14:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ks5UEqL/aGSo5LqC9sqFCehTO5OVj86m2Fm9zQLebks=; b=r85eVSNOffKQkZDuhlHZYWOPWKd+mbyug93bw9NMoKEf0BgA2tqZZ3clThwzjNKfZ/ VXa8lMc3NCWITxGadyl5r3UWasmxiZHqGrbeeWuCWimLcrhCBq7PWX+cJ8UmaFRcVWM9 JpBQTDWgXH1vsWqHvw7sOLuBBVO3NOef9Qi1X0FOXtfOuVHcIuU6lGOc1ssqc4K1Uv2x s6oD6qjIS/QnpX6q4hDkvCNJG3qB/z/WrpLqYPXeyfCUvy5in1bSohn7DYvoruopdjJv kYcKXjYLVN0hWs1s71sk7LTk9rG6AO1yKBuUe6DSWdqoQhFVyLzoKUnb5dQ+h70gxKrc M8dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ks5UEqL/aGSo5LqC9sqFCehTO5OVj86m2Fm9zQLebks=; b=b17UMtgNePrRptUFGFDW3QKmsYP+Ztl8BCifzaAb46+0MyHwY1rfu41kKlnZdfRU4L Jg5SJEWrSinl8/7xli2p6aowlZm/9x5xO5ST2oIVP+gLoWeUrmUOhvK/Uf734Bx3J58e 9tKtvaA8XFhJsN2Pe8EezcSwOhQLnZD2ffo+seRlLJSVKV5n8q3Zny/Wh88SqjH6trNU 87lEcXHaJ/26Xlk8NKDxGDccxXTxOi2aAsFH3WzYIOiWKC4WxXQSzbidVOgx4pQByfqd tu8+pUjyhvDMNP6uK3rCcGx5M7zZLS79YTAukFoYR7MF6nAgjqPP/cs9Mfd5FJwi+w5c otOw== X-Gm-Message-State: ALKqPwciQkd2k0yLjsOktgjUMz9E45FX9Fz3mfZ9zx8ISq/FAbJ8NVo5 CBplKI/buElItr0lqbLJZtVouXblV5jIKqAptKqOlQ== X-Google-Smtp-Source: AB8JxZqjtC4R29xutFTaGFTc9Ak017vZLThntqZS7MmvAM7cqIQsZTXt4hLY3Qskc95eXBmkSyEFssR6a1wq9Oam8yU= X-Received: by 2002:a1c:4ad9:: with SMTP id n86-v6mr6400726wmi.0.1527110171359; Wed, 23 May 2018 14:16:11 -0700 (PDT) MIME-Version: 1.0 References: <152709543734.26876.14669273511731581188.idtracker@ietfa.amsl.com> <64EA6F18-9275-40FC-8FDE-3E12C4458EFB@gmail.com> In-Reply-To: From: Warren Kumari Date: Wed, 23 May 2018 17:15:35 -0400 Message-ID: To: Eric Rescorla Cc: Yoav Nir , spasm@ietf.org, lamps-chairs@ietf.org, The IESG Content-Type: multipart/alternative; boundary="0000000000004c1597056ce60b21" Archived-At: Subject: Re: [lamps] Warren Kumari's Block on charter-ietf-lamps-02-00: (with BLOCK and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 21:16:22 -0000 --0000000000004c1597056ce60b21 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 23, 2018 at 4:29 PM Eric Rescorla wrote: > > > On Wed, May 23, 2018 at 12:31 PM, Warren Kumari wrote= : > >> >> >> On Wed, May 23, 2018 at 1:39 PM Yoav Nir wrote: >> >>> Hi Warren. >>> >>> Since it was my draft and presentation at SecDispatch that led to this >>> item, I feel I can answer this. Inline. >>> >>> > On 23 May 2018, at 20:10, Warren Kumari wrote: >>> > >>> > Warren Kumari has entered the following ballot position for >>> > charter-ietf-lamps-02-00: Block >>> > >>> > When responding, please keep the subject line intact and reply to all >>> > email addresses included in the To and CC lines. (Feel free to cut th= is >>> > introductory paragraph, however.) >>> > >>> > >>> > >>> > The document, along with other ballot positions, can be found here: >>> > https://datatracker.ietf.org/doc/charter-ietf-lamps/ >>> > >>> > >>> > >>> > ---------------------------------------------------------------------= - >>> > BLOCK: >>> > ---------------------------------------------------------------------= - >>> > >>> > "3. Specify the use of short-lived X.509 certificates for which no >>> > revocation information is made available by the Certification >>> Authority. >>> > Short-lived certificates have a lifespan that is shorter than the tim= e >>> > needed to detect, report, and distribute revocation information, as a >>> > result revoking them pointless." >>> > >>> > This makes me twitch -- how short is "short=E2=80=9D? >>> >>> [YN] I expect this to be contentious within the working group, and I >>> expect the exact cut-off point to be different from one use-case to >>> another. For highly reliable systems with good clock synchronization >>> =E2=80=9Cshort=E2=80=9D could be as low as an hour. For typical systems= I think the likely >>> lifetime will be between 1 day and 1 week. IMHO it=E2=80=99s valid for= the working >>> group to leave the cut-off between =E2=80=9Cshort=E2=80=9D and =E2=80= =9Cnot short=E2=80=9D to per-domain >>> profiles, but I don=E2=80=99t think anything beyond 2 weeks would ever = count as >>> short. >>> >>> > And how long is the time to >>> > "detect, report, and distribute revocation information"? With e.g: CT= , >>> > misissued certificates may be visible before they are used in an >>> attack, >>> > decreasing the detection time. >>> >>> [YN] Someone needs to see the certificate to add it to the log, and >>> someone needs to find the certificate on the log and understand that it= is >>> mis-issued. And then someone needs to add it to the CRL / database that >>> feeds the OCSP responder. And when this is updated, relying parties may >>> have cached copies of older revocation information. Add it up and it ca= n >>> take days on the web. In closed environments there may not be CT at al= l. >>> >>> >> =E2=80=8BSo, here you say: "Add it up and it can take days on the web." = and >> above that you say: "For typical systems I think the likely lifetime wil= l >> be between 1 day and 1 week. [...] , but I don=E2=80=99t think anything= beyond 2 >> weeks would ever count as short." >> >> "1 week" minus "days" is still greater than zero, and so it still *seems= * >> to me that removing revocation is a bad idea -- but, my role is (or shou= ld >> be!) to make sure that this charter doesn't conflict with other work (es= p. >> ops work), that the charter "describes the specific problem or deliverab= les >> (a guideline, standards specification, etc.) it has been formed to addre= ss. >> WG charters state the scope of work for group, and lay out goals and >> milestones that show how this work will be completed." It is (IMO) the >> sponsoring ADs, the WGs and IETFs decision as to if the ideas themselves >> are acceptable. >> I'm not (yet!) so arrogant that I'm sure I know the right answer to >> everything, so I'd like to discuss this with EKR on the call tomorrow, a= nd >> will clear my block once I've been assured process is being followed >> / this has been considered. >> > > Thanks. I think the thing that's important to understand is that > revocation on the Web is badly broken. > =E2=80=8BOk. *That* I'll buy... :-) It sounds like the WG / people more knowledge about the subject than me (i.e. everyone :-)) has considered this, and I'm in the rough / it isn't as scary as I'd though. I just cleared my Block, thank you everyone for the education, W > The two primary standardized ways to deal with revocation are: > > - OCSP -- but it's so brittle that people won't hard fail, so it's not > very good > - OCSP stapling - which has a lifetime of around a week or so, and so > basically has the same security properties as short-lived certs. > > -Ekr > > >> > >>> > Also, I would figure that it is still useful to know that a >>> certificate was >>> > revoked and didn't just expire -- if I see a certificate which expire= d >>> 10 >>> > minutes ago I may be willing (after some consideration, checking my >>> clock, etc) >>> > to decide to trust it anyway (even if that's a bad idea!), but a >>> revoked >>> > certificate is a clear indication that something bad happened, and >>> changes my >>> > risk assessment. >>> >>> [YN] Yes, and the candidate draft has a SHOULD-level requirement to not >>> allow any grace periods for such certificates. One of the feedbacks I g= ot >>> was that this should be upgraded to MUST (or rather MUST NOT) >>> >>> >> Ok. That helps. >> >> Thanks! >> W >> >> > >>> > It's entirely possible that there is a really good reason why I'm >>> wrong / that >>> > this argument doesn't make sense in some use cases (or just that I'm >>> nuts!) >>> >>> [YN] There was some push-back about the name. The important point is no= t >>> so much that the lifetime is short, but that there is no revocation >>> information. We want these certificates because we don=E2=80=99t want t= o deal with >>> revocation information. Non-revocation is the end. Making them short-t= erm >>> is the means, or rather the sacrifice we need to make to make (other) >>> security people happy. >>> >>> > ---------------------------------------------------------------------= - >>> > COMMENT: >>> > ---------------------------------------------------------------------= - >>> > >>> > >>> > Also, "revoking them pointless" does not parse - perhaps "revoking >>> them is pointless"? >>> > >>> > >>> > _______________________________________________ >>> > Spasm mailing list >>> > Spasm@ietf.org >>> > https://www.ietf.org/mailman/listinfo/spasm >>> >>> >> >> -- >> I don't think the execution is relevant when it was obviously a bad idea >> in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair of >> pants. >> ---maf >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >> >> > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --0000000000004c1597056ce60b21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On We= d, May 23, 2018 at 4:29 PM Eric Rescorla <ekr@rtfm.com> wrote:


O= n Wed, May 23, 2018 at 12:31 PM, Warren Kumari <warren@kumari.net><= /span> wrote:


On Wed, May = 23, 2018 at 1:39 PM Yoav Nir <ynir.ietf@gmail.com> wrote:
Hi Warren.

Since it was my draft and presentation at SecDispatch that led to this item= , I feel I can answer this.=C2=A0 Inline.

> On 23 May 2018, at 20:10, Warren Kumari <warren@kumari.net> wrote:
>
> Warren Kumari has entered the following ballot position for
> charter-ietf-lamps-02-00: Block
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-= ietf-lamps/
>
>
>
> ----------------------------------------------------------------------=
> BLOCK:
> ----------------------------------------------------------------------=
>
> "3. Specify the use of short-lived X.509 certificates for which n= o
> revocation information is made available by the Certification Authorit= y.
> Short-lived certificates have a lifespan that is shorter than the time=
> needed to detect, report, and distribute revocation information, as a<= br> > result revoking them pointless."
>
> This makes me twitch -- how short is "short=E2=80=9D?

[YN] I expect this to be contentious within the working group, and I expect= the exact cut-off point to be different from one use-case to another. For = highly reliable systems with good clock synchronization =E2=80=9Cshort=E2= =80=9D could be as low as an hour. For typical systems I think the likely l= ifetime will be between 1 day and 1 week.=C2=A0 IMHO it=E2=80=99s valid for= the working group to leave the cut-off between =E2=80=9Cshort=E2=80=9D and= =E2=80=9Cnot short=E2=80=9D to per-domain profiles, but I don=E2=80=99t th= ink anything beyond 2 weeks would ever count as short.

> And how long is the time to
> "detect, report, and distribute revocation information"? Wit= h e.g: CT,
> misissued certificates may be visible before they are used in an attac= k,
> decreasing the detection time.

[YN] Someone needs to see the certificate to add it to the log, and someone= needs to find the certificate on the log and understand that it is mis-iss= ued. And then someone needs to add it to the CRL / database that feeds the = OCSP responder. And when this is updated, relying parties may have cached c= opies of older revocation information. Add it up and it can take days on th= e web.=C2=A0 In closed environments there may not be CT at all.=C2=A0


=E2=80=8BSo, here you say: "Add it up and it can = take days on the web." and above that you say: "For typical syste= ms I think the likely lifetime will be between 1 day and 1 week. =C2=A0[...= ] , but I don=E2=80=99t think anything beyond 2 weeks would ever count as s= hort."

"1 week" minus "days" is still great= er than zero, and so it still *seems* to me that removing revocation is a b= ad idea -- but, my role is (or should be!) to make sure that this charter d= oesn't conflict with other work (esp. ops work), that the charter "= ;describes the specific problem or deliverables (a guideline, standards spe= cification, etc.) it has been formed to address. WG charters state the scop= e of work for group, and lay out goals and milestones that show how this wo= rk will be completed." It is (IMO) the sponsoring ADs, the WGs and IET= Fs decision as to if the ideas themselves are acceptable.
I'm not = (yet!) so arrogant that I'm sure I know the right answer to everything,= so I'd like to discuss this with EKR on the call tomorrow, and will cl= ear my block once I've been assured process is being followed
/ this= has been considered.

Tha= nks. I think the thing that's important to understand is that revocatio= n on the Web is badly broken.
=E2=80=8BOk. *That* I'll buy... :-)

It sounds like = the WG / people more knowledge about the subject than me (i.e. everyone :-)= ) has considered this, and I'm in the rough / it isn't as scary as = I'd though.

I just cleared my Block, thank you everyone for the ed= ucation,
W


=C2=A0
<= div dir=3D"ltr">
= The two primary standardized ways to deal with revocation are:
- OCSP -- but it's so brittle that people won't hard f= ail, so it's not very good
- OCSP stapling - which has a life= time of around a week or so, and so basically has the same security propert= ies as short-lived certs.

-Ekr

<= /div>

>
> Also, I would figure that it is still useful to know that a certificat= e was
> revoked and didn't just expire -- if I see a certificate which exp= ired 10
> minutes ago I may be willing (after some consideration, checking my cl= ock, etc)
> to decide to trust it anyway (even if that's a bad idea!), but a r= evoked
> certificate is a clear indication that something bad happened, and cha= nges my
> risk assessment.

[YN] Yes, and the candidate draft has a SHOULD-level requirement to not all= ow any grace periods for such certificates. One of the feedbacks I got was = that this should be upgraded to MUST (or rather MUST NOT)


Ok. That helps.

Thanks!
W
<= br>
>
> It's entirely possible that there is a really good reason why I= 9;m wrong / that
> this argument doesn't make sense in some use cases (or just that I= 'm nuts!)

[YN] There was some push-back about the name. The important point is not so= much that the lifetime is short, but that there is no revocation informati= on. We want these certificates because we don=E2=80=99t want to deal with r= evocation information. Non-revocation is the end.=C2=A0 Making them short-t= erm is the means, or rather the sacrifice we need to make to make (other) s= ecurity people happy.

> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
>
> Also, "revoking them pointless" does not parse - perhaps &qu= ot;revoking them is pointless"?
>
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org=
> https://www.ietf.org/mailman/listinfo/spasm



--
I don= 't think the execution is relevant when it was obviously a bad idea in = the first place.
This is like putting rabid weasels in your pants, and l= ater expressing regret at having chosen those particular rabid weasels and = that pair of pants.
=C2=A0 =C2=A0---maf

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




--
I don't t= hink the execution is relevant when it was obviously a bad idea in the firs= t place.
This is like putting rabid weasels in your pants, and later exp= ressing regret at having chosen those particular rabid weasels and that pai= r of pants.
=C2=A0 =C2=A0---maf
--0000000000004c1597056ce60b21-- From nobody Wed May 23 14:18:40 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C494512D7E6 for ; Wed, 23 May 2018 14:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 Bfff3qSYvdQc for ; Wed, 23 May 2018 14:18:35 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49EE31201F8 for ; Wed, 23 May 2018 14:18:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2F9CE300558 for ; Wed, 23 May 2018 17:18:33 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QmHIvwEEfKKk for ; Wed, 23 May 2018 17:18:30 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 7CD8E3002C6; Wed, 23 May 2018 17:18:30 -0400 (EDT) From: Russ Housley Message-Id: <27DB472B-5905-4D3D-87C6-0A407B4BF0F4@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CC835D67-0BA0-4247-B773-C4F2250CF8E4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 23 May 2018 17:18:31 -0400 In-Reply-To: Cc: SPASM , IESG To: Warren Kumari References: <152709543734.26876.14669273511731581188.idtracker@ietfa.amsl.com> <64EA6F18-9275-40FC-8FDE-3E12C4458EFB@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Warren Kumari's Block on charter-ietf-lamps-02-00: (with BLOCK and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 21:18:38 -0000 --Apple-Mail=_CC835D67-0BA0-4247-B773-C4F2250CF8E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Please see my response at the bottom of the message ... >> On May 23, 2018, at 3:31 PM, Warren Kumari > wrote: >>=20 >> On Wed, May 23, 2018 at 1:39 PM Yoav Nir > wrote: >> Hi Warren. >>=20 >> Since it was my draft and presentation at SecDispatch that led to = this item, I feel I can answer this. Inline. >>=20 >> > On 23 May 2018, at 20:10, Warren Kumari > wrote: >> >=20 >> > Warren Kumari has entered the following ballot position for >> > charter-ietf-lamps-02-00: Block >> >=20 >> > When responding, please keep the subject line intact and reply to = all >> > email addresses included in the To and CC lines. (Feel free to cut = this >> > introductory paragraph, however.) >> >=20 >> >=20 >> >=20 >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/charter-ietf-lamps/ = >> >=20 >> >=20 >> >=20 >> > = ---------------------------------------------------------------------- >> > BLOCK: >> > = ---------------------------------------------------------------------- >> >=20 >> > "3. Specify the use of short-lived X.509 certificates for which no >> > revocation information is made available by the Certification = Authority. >> > Short-lived certificates have a lifespan that is shorter than the = time >> > needed to detect, report, and distribute revocation information, as = a >> > result revoking them pointless." >> >=20 >> > This makes me twitch -- how short is "short=E2=80=9D? >>=20 >> [YN] I expect this to be contentious within the working group, and I = expect the exact cut-off point to be different from one use-case to = another. For highly reliable systems with good clock synchronization = =E2=80=9Cshort=E2=80=9D could be as low as an hour. For typical systems = I think the likely lifetime will be between 1 day and 1 week. IMHO = it=E2=80=99s valid for the working group to leave the cut-off between = =E2=80=9Cshort=E2=80=9D and =E2=80=9Cnot short=E2=80=9D to per-domain = profiles, but I don=E2=80=99t think anything beyond 2 weeks would ever = count as short. >>=20 >> > And how long is the time to >> > "detect, report, and distribute revocation information"? With e.g: = CT, >> > misissued certificates may be visible before they are used in an = attack, >> > decreasing the detection time. >>=20 >> [YN] Someone needs to see the certificate to add it to the log, and = someone needs to find the certificate on the log and understand that it = is mis-issued. And then someone needs to add it to the CRL / database = that feeds the OCSP responder. And when this is updated, relying parties = may have cached copies of older revocation information. Add it up and it = can take days on the web. In closed environments there may not be CT at = all. =20 >>=20 >>=20 >> =E2=80=8BSo, here you say: "Add it up and it can take days on the = web." and above that you say: "For typical systems I think the likely = lifetime will be between 1 day and 1 week. [...] , but I don=E2=80=99t = think anything beyond 2 weeks would ever count as short." >>=20 >> "1 week" minus "days" is still greater than zero, and so it still = *seems* to me that removing revocation is a bad idea -- but, my role is = (or should be!) to make sure that this charter doesn't conflict with = other work (esp. ops work), that the charter "describes the specific = problem or deliverables (a guideline, standards specification, etc.) it = has been formed to address. WG charters state the scope of work for = group, and lay out goals and milestones that show how this work will be = completed." It is (IMO) the sponsoring ADs, the WGs and IETFs decision = as to if the ideas themselves are acceptable. >> I'm not (yet!) so arrogant that I'm sure I know the right answer to = everything, so I'd like to discuss this with EKR on the call tomorrow, = and will clear my block once I've been assured process is being followed >> / this has been considered. >=20 > Warren: >=20 > I think the point you are missing is that it take time to process = revocation and get the CRL published or OCSP responder updated. This is = always over a week because people do not revoke without doing due = diligence. So, letting the short-lived certificate expire without = issuing a replacement will actually cause revocation to happen more = quickly. >=20 >=20 > =E2=80=8BI remain unconvinced -- some years ago I purchased a =E2=80=8BD= V cert and, though a series of stupidly I managed to delete the private = key[0]. The CA / reseller I was using had a friendly "Revoke" button = which let me upload a new CSR and get a new cert within a few minutes. = I'll happily admit that I didn't check if they actually added the old = one to a CRL, a: I assumed that they did and b: they did let me reissue = without more $$$ - which was the only bit I actually cared about :-). >=20 > Now that I've finished writing this it feels somewhat like: "I just = the other day got=E2=80=A6 an Internet was sent by my staff at 10 = o'clock in the morning on Friday. I got it yesterday [Tuesday]. Why? = Because it got tangled up with all these things going on the Internet = commercially." - Ted Stevens. >=20 > W > [0]: ejabberd wants the key, cert and intermediate certs all in a = single .pem file -- while trying to make this I managed to overwrite the = key (I did 'cp * > kumari.net-combined.pem' instead of 'cat * > = kumari.net-combined.pem') You needed a replacement certificate associated with a new key pair = because the private key was lost. You were not worried about someone = else using the private key in a malicious manner. I do not think this = work item will make that easier or harder. Russ --Apple-Mail=_CC835D67-0BA0-4247-B773-C4F2250CF8E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Please see my response at the bottom of the message ...

On May 23, 2018, at 3:31 PM, Warren Kumari = <warren@kumari.net> wrote:

On Wed, May 23, 2018 at 1:39 PM Yoav Nir <ynir.ietf@gmail.com> wrote:
Hi Warren.

Since it was my draft and presentation at SecDispatch that led to this = item, I feel I can answer this.  Inline.

> On 23 May 2018, at 20:10, Warren Kumari <warren@kumari.net> wrote:
>
> Warren Kumari has entered the following ballot position for
> charter-ietf-lamps-02-00: Block
>
> When responding, please keep the subject line intact and reply to = all
> email addresses included in the To and CC lines. (Feel free to cut = this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found = here:
> https://datatracker.ietf.org/doc/charter-ietf-lamps/
>
>
>
> = ----------------------------------------------------------------------
> BLOCK:
> = ----------------------------------------------------------------------
>
> "3. Specify the use of short-lived X.509 certificates for which = no
> revocation information is made available by the Certification = Authority.
> Short-lived certificates have a lifespan that is shorter than the = time
> needed to detect, report, and distribute revocation information, as = a
> result revoking them pointless."
>
> This makes me twitch -- how short is "short=E2=80=9D?

[YN] I expect this to be contentious within the working group, and I = expect the exact cut-off point to be different from one use-case to = another. For highly reliable systems with good clock synchronization = =E2=80=9Cshort=E2=80=9D could be as low as an hour. For typical systems = I think the likely lifetime will be between 1 day and 1 week.  IMHO = it=E2=80=99s valid for the working group to leave the cut-off between = =E2=80=9Cshort=E2=80=9D and =E2=80=9Cnot short=E2=80=9D to per-domain = profiles, but I don=E2=80=99t think anything beyond 2 weeks would ever = count as short.

> And how long is the time to
> "detect, report, and distribute revocation information"? With e.g: = CT,
> misissued certificates may be visible before they are used in an = attack,
> decreasing the detection time.

[YN] Someone needs to see the certificate to add it to the log, and = someone needs to find the certificate on the log and understand that it = is mis-issued. And then someone needs to add it to the CRL / database = that feeds the OCSP responder. And when this is updated, relying parties = may have cached copies of older revocation information. Add it up and it = can take days on the web.  In closed environments there may not be = CT at all. 


=E2=80=8BSo, here you say: "Add it up and it can take = days on the web." and above that you say: "For typical systems I think = the likely lifetime will be between 1 day and 1 week.  [...] , but = I don=E2=80=99t think anything beyond 2 weeks would ever count as = short."

"1 week" minus "days" is still = greater than zero, and so it still *seems* to me that removing = revocation is a bad idea -- but, my role is (or should be!) to make sure = that this charter doesn't conflict with other work (esp. ops work), that = the charter "describes the specific problem or deliverables (a = guideline, standards specification, etc.) it has been formed to address. = WG charters state the scope of work for group, and lay out goals and = milestones that show how this work will be completed." It is (IMO) the = sponsoring ADs, the WGs and IETFs decision as to if the ideas themselves = are acceptable.
I'm not (yet!) so arrogant that I'm sure I know the = right answer to everything, so I'd like to discuss this with EKR on the = call tomorrow, and will clear my block once I've been assured process is = being followed
/ this has been = considered.

Warren:

I think the point you are missing is that it take time to = process revocation and get the CRL published or OCSP responder = updated.  This is always over a week because people do not revoke = without doing due diligence.  So, letting the short-lived = certificate expire without issuing a replacement will actually cause = revocation to happen more quickly.


=E2=80=8BI remain unconvinced = -- some years ago I purchased a =E2=80=8BDV cert and, though a series of = stupidly I managed to delete the private key[0]. The CA / reseller I was = using had a friendly "Revoke" button which let me upload a new CSR and = get a new cert within a few minutes. I'll happily admit that I didn't = check if they actually added the old one to a CRL, a: I assumed that = they did and b: they did let me reissue without more $$$ - which was the = only bit I actually cared about :-).

Now that I've finished writing = this it feels somewhat like: "I just the other day got=E2=80=A6 an = Internet was sent by my staff at 10 o'clock in the morning on Friday. I = got it yesterday [Tuesday]. Why? Because it got tangled up with all = these things going on the Internet commercially." - Ted = Stevens.

W
[0]: = ejabberd wants the key, cert and intermediate certs all in a single .pem = file -- while trying to make this I managed to overwrite the key  = (I did 'cp * > kumari.net-combined.pem' instead of 'cat * > kumari.net-combined.pem')

You needed a replacement certificate = associated with a new key pair because the private key was lost. =  You were not worried about someone else using the private key in a = malicious manner.  I do not think this work item will make that = easier or harder.

Russ

= --Apple-Mail=_CC835D67-0BA0-4247-B773-C4F2250CF8E4-- From nobody Wed May 23 16:05:10 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462C512D810; Wed, 23 May 2018 16:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 WbjeWTMeHWRB; Wed, 23 May 2018 16:05:01 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BEA512D7F0; Wed, 23 May 2018 16:05:01 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 16C2DB817D3; Wed, 23 May 2018 16:04:49 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, spasm@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180523230449.16C2DB817D3@rfc-editor.org> Date: Wed, 23 May 2018 16:04:49 -0700 (PDT) Archived-At: Subject: [lamps] =?utf-8?q?RFC_8398_on_Internationalized_Email_Addresses_i?= =?utf-8?q?n_X=2E509_Certificates?= X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 23:05:03 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8398 Title: Internationalized Email Addresses in X.509 Certificates Author: A. Melnikov, Ed., W. Chuang, Ed. Status: Standards Track Stream: IETF Date: May 2018 Mailbox: alexey.melnikov@isode.com, weihaw@google.com Pages: 12 Characters: 26562 Updates: RFC 5280 I-D Tag: draft-ietf-lamps-eai-addresses-18.txt URL: https://www.rfc-editor.org/info/rfc8398 DOI: 10.17487/RFC8398 This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an internationalized email address. This document updates RFC 5280. This document is a product of the Limited Additional Mechanisms for PKIX and SMIME Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed May 23 16:05:33 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FFD12E89D; Wed, 23 May 2018 16:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 3oGPd1ThfGzZ; Wed, 23 May 2018 16:05:05 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B893812D7F0; Wed, 23 May 2018 16:05:05 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 47547B817DA; Wed, 23 May 2018 16:04:53 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, spasm@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180523230453.47547B817DA@rfc-editor.org> Date: Wed, 23 May 2018 16:04:53 -0700 (PDT) Archived-At: Subject: [lamps] =?utf-8?q?RFC_8399_on_Internationalization_Updates_to_RFC?= =?utf-8?q?_5280?= X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 23:05:19 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8399 Title: Internationalization Updates to RFC 5280 Author: R. Housley Status: Standards Track Stream: IETF Date: May 2018 Mailbox: housley@vigilsec.com Pages: 9 Characters: 19372 Updates: RFC 5280 I-D Tag: draft-ietf-lamps-rfc5280-i18n-update-04.txt URL: https://www.rfc-editor.org/info/rfc8399 DOI: 10.17487/RFC8399 The updates to RFC 5280 described in this document provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and add support for internationalized email addresses in X.509 certificates. This document is a product of the Limited Additional Mechanisms for PKIX and SMIME Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed May 23 18:22:29 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0198B124217; Wed, 23 May 2018 18:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrgE5COq54Nz; Wed, 23 May 2018 18:22:18 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B6C1289B0; Wed, 23 May 2018 18:22:18 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id h8-v6so27516208otb.2; Wed, 23 May 2018 18:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kcOHHDm6TAnbHMzgvo5FmF/j9LwqnTogzSKbI3c70rI=; b=BIGogw8pyvQTuwF0wtjmHXYtYlar86nm0QZjnXZzXoI34oF+i6G7dl6dw5cXws6lBd YklcZfCJjnFbGZb62ugj6uQ/3Cc1K4we4/lCRetO36HaxT/84SEO1iXD+MK+Csk+udGu ZyLnZL3Yl2f71PJGvGwbh1cNz3eT4xIUJXlYdyg/uhg+RQ6JtNw/ci3JQepJjU2twwL7 6a8TGFwP8BX8yBpKC3+Bw16o2HRbAblLUai9tFxCZQav3iQErkE2E2ayyOiCq8YQzlkf 0m2VEp/JqEzapNvxH/GCvUwUcW3+HmSHiVM/2Xfe4VEjc2km26SAgVpBAQHCtVaPVJvT zE+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kcOHHDm6TAnbHMzgvo5FmF/j9LwqnTogzSKbI3c70rI=; b=jmHy3gy0wBVGgelnBytXwnT8Mp9UAxifoWo72NldsR6yvGr4qCOhI5uKcLlEpGURVP kp7///et6h8WgOzOABW3WHyBtvgRZ+vjoSceHAZO4YFnOZbcX0sZI6KhU5a1Tfk+uje1 4vYbAx1YSVP6BXJg0mtLPC51DzS7hPX5TUUwDD5Ojk1N23dzuxyWRtqjjjiEYeMvKlwM GppPCUjtIYJoo1iWTzWucQ8WYPoanWm/iidJdRWfXIxWPESSJ+Ycm/MB2we8A9ezStaF n9PnRpFtR+K13tqCrHxi62+Q8EaWuvHZMdtvkaDvzZT/RamWTgrbpBSjOFMVgJKgTD1S j6wA== X-Gm-Message-State: ALKqPwcC49Bs0z4YF25J2HvbFLHffVt/v9z4+9oLzZL9/mE32lrIJsQr s+9h2Yy6hNJ5DdO0r+J83/Bb1rjUG84cqAWFmE0= X-Google-Smtp-Source: AB8JxZom0e/SZv2vzjpHF6GqbIcBUhxutnOo35C10Gw3RwLr2UlEaIuYD1gS9CWbilpZtsQwZWtMxRvcMt5GpWfjKaU= X-Received: by 2002:a9d:2511:: with SMTP id k17-v6mr3043074otb.129.1527124937737; Wed, 23 May 2018 18:22:17 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:23:0:0:0:0:0 with HTTP; Wed, 23 May 2018 18:22:17 -0700 (PDT) In-Reply-To: References: <152709543734.26876.14669273511731581188.idtracker@ietfa.amsl.com> <64EA6F18-9275-40FC-8FDE-3E12C4458EFB@gmail.com> From: Phillip Hallam-Baker Date: Wed, 23 May 2018 21:22:17 -0400 X-Google-Sender-Auth: cD2GCA6Rn9i7DwIZECvXXGNS01w Message-ID: To: Warren Kumari Cc: Russ Housley , SPASM , lamps-chairs@ietf.org, The IESG , Yoav Nir Content-Type: multipart/alternative; boundary="000000000000710b41056ce97b19" Archived-At: Subject: Re: [lamps] Warren Kumari's Block on charter-ietf-lamps-02-00: (with BLOCK and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 01:22:21 -0000 --000000000000710b41056ce97b19 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 23, 2018 at 5:08 PM, Warren Kumari wrote: > > > On Wed, May 23, 2018 at 3:53 PM Russ Housley wrote= : > >> Please see my response at the bottom of the message ... >> >> > =E2=80=8B... and mine even further down :-)=E2=80=8B > >> On May 23, 2018, at 3:31 PM, Warren Kumari wrote: >> >> On Wed, May 23, 2018 at 1:39 PM Yoav Nir wrote: >> >>> Hi Warren. >>> >>> Since it was my draft and presentation at SecDispatch that led to this >>> item, I feel I can answer this. Inline. >>> >>> > On 23 May 2018, at 20:10, Warren Kumari wrote: >>> > >>> > Warren Kumari has entered the following ballot position for >>> > charter-ietf-lamps-02-00: Block >>> > >>> > When responding, please keep the subject line intact and reply to all >>> > email addresses included in the To and CC lines. (Feel free to cut th= is >>> > introductory paragraph, however.) >>> > >>> > >>> > >>> > The document, along with other ballot positions, can be found here: >>> > https://datatracker.ietf.org/doc/charter-ietf-lamps/ >>> > >>> > >>> > >>> > ---------------------------------------------------------------------= - >>> > BLOCK: >>> > ---------------------------------------------------------------------= - >>> > >>> > "3. Specify the use of short-lived X.509 certificates for which no >>> > revocation information is made available by the Certification >>> Authority. >>> > Short-lived certificates have a lifespan that is shorter than the tim= e >>> > needed to detect, report, and distribute revocation information, as a >>> > result revoking them pointless." >>> > >>> > This makes me twitch -- how short is "short=E2=80=9D? >>> >>> [YN] I expect this to be contentious within the working group, and I >>> expect the exact cut-off point to be different from one use-case to >>> another. For highly reliable systems with good clock synchronization >>> =E2=80=9Cshort=E2=80=9D could be as low as an hour. For typical systems= I think the likely >>> lifetime will be between 1 day and 1 week. IMHO it=E2=80=99s valid for= the working >>> group to leave the cut-off between =E2=80=9Cshort=E2=80=9D and =E2=80= =9Cnot short=E2=80=9D to per-domain >>> profiles, but I don=E2=80=99t think anything beyond 2 weeks would ever = count as >>> short. >>> >>> > And how long is the time to >>> > "detect, report, and distribute revocation information"? With e.g: CT= , >>> > misissued certificates may be visible before they are used in an >>> attack, >>> > decreasing the detection time. >>> >>> [YN] Someone needs to see the certificate to add it to the log, and >>> someone needs to find the certificate on the log and understand that it= is >>> mis-issued. And then someone needs to add it to the CRL / database that >>> feeds the OCSP responder. And when this is updated, relying parties may >>> have cached copies of older revocation information. Add it up and it ca= n >>> take days on the web. In closed environments there may not be CT at al= l. >>> >>> >> =E2=80=8BSo, here you say: "Add it up and it can take days on the web." = and >> above that you say: "For typical systems I think the likely lifetime wil= l >> be between 1 day and 1 week. [...] , but I don=E2=80=99t think anything= beyond 2 >> weeks would ever count as short." >> >> "1 week" minus "days" is still greater than zero, and so it still *seems= * >> to me that removing revocation is a bad idea -- but, my role is (or shou= ld >> be!) to make sure that this charter doesn't conflict with other work (es= p. >> ops work), that the charter "describes the specific problem or deliverab= les >> (a guideline, standards specification, etc.) it has been formed to addre= ss. >> WG charters state the scope of work for group, and lay out goals and >> milestones that show how this work will be completed." It is (IMO) the >> sponsoring ADs, the WGs and IETFs decision as to if the ideas themselves >> are acceptable. >> I'm not (yet!) so arrogant that I'm sure I know the right answer to >> everything, so I'd like to discuss this with EKR on the call tomorrow, a= nd >> will clear my block once I've been assured process is being followed >> / this has been considered. >> >> >> Warren: >> >> I think the point you are missing is that it take time to process >> revocation and get the CRL published or OCSP responder updated. This is >> always over a week because people do not revoke without doing due >> diligence. So, letting the short-lived certificate expire without issui= ng >> a replacement will actually cause revocation to happen more quickly. >> >> > =E2=80=8BI remain unconvinced -- some years ago I purchased a =E2=80=8BDV= cert and, though > a series of stupidly I managed to delete the private key[0]. The CA / > reseller I was using had a friendly "Revoke" button which let me upload a > new CSR and get a new cert within a few minutes. I'll happily admit that = I > didn't check if they actually added the old one to a CRL, a: I assumed th= at > they did and b: they did let me reissue without more $$$ - which was the > only bit I actually cared about :-). > > Now that I've finished writing this it feels somewhat like: "I just the > other day got=E2=80=A6 an Internet was sent by my staff at 10 o'clock in = the > morning on Friday. I got it yesterday [Tuesday]. Why? Because it got > tangled up with all these things going on the Internet commercially." - T= ed > Stevens. > > W > [0]: ejabberd wants the key, cert and intermediate certs all in a single > .pem file -- while trying to make this I managed to overwrite the key (I > did 'cp * > kumari.net-combined.pem' instead of 'cat * > > kumari.net-combined.pem') > =E2=80=8BRevocation at the request of the subject is easy to automate becau= se they gave consent. Revocation for breach of terms of service is much more involved. The complaint may be valid or it may be a DoS attack on the site. =E2=80=8B --000000000000710b41056ce97b19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Ma= y 23, 2018 at 5:08 PM, Warren Kumari <warren@kumari.net> wro= te:


On Wed, May 23, 2018 at 3:53 PM Russ Housley <= housley@vigilsec.= com> wrote:
Please see my response at the bottom= of the message ...


=
=E2=80=8B... and mine even fu= rther down :-)=E2=80=8B
On May 23, 2018, at 3:31 PM, Warren Kumari <= ;warren@kumari.net> wrote:

On Wed, May 23, 2018 at 1:39 PM Yoav Nir <ynir.ietf@gmail.com> wrote:=
Hi Warren.

Since it was my draft and presentation at SecDispatch that led to this item= , I feel I can answer this.=C2=A0 Inline.

> On 23 May 2018, at 20:10, Warren Kumari <warren@kumari.net> wrote:
>
> Warren Kumari has entered the following ballot position for
> charter-ietf-lamps-02-00: Block
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/cha= rter-ietf-lamps/
>
>
>
> ------------------------------------------------------------= ----------
> BLOCK:
> ------------------------------------------------------------= ----------
>
> "3. Specify the use of short-lived X.509 certificates for which n= o
> revocation information is made available by the Certification Authorit= y.
> Short-lived certificates have a lifespan that is shorter than the time=
> needed to detect, report, and distribute revocation information, as a<= br> > result revoking them pointless."
>
> This makes me twitch -- how short is "short=E2=80=9D?

[YN] I expect this to be contentious within the working group, and I expect= the exact cut-off point to be different from one use-case to another. For = highly reliable systems with good clock synchronization =E2=80=9Cshort=E2= =80=9D could be as low as an hour. For typical systems I think the likely l= ifetime will be between 1 day and 1 week.=C2=A0 IMHO it=E2=80=99s valid for= the working group to leave the cut-off between =E2=80=9Cshort=E2=80=9D and= =E2=80=9Cnot short=E2=80=9D to per-domain profiles, but I don=E2=80=99t th= ink anything beyond 2 weeks would ever count as short.

> And how long is the time to
> "detect, report, and distribute revocation information"? Wit= h e.g: CT,
> misissued certificates may be visible before they are used in an attac= k,
> decreasing the detection time.

[YN] Someone needs to see the certificate to add it to the log, and someone= needs to find the certificate on the log and understand that it is mis-iss= ued. And then someone needs to add it to the CRL / database that feeds the = OCSP responder. And when this is updated, relying parties may have cached c= opies of older revocation information. Add it up and it can take days on th= e web.=C2=A0 In closed environments there may not be CT at all.=C2=A0


=E2=80=8BI remain unco= nvinced -- some years ago I purchased a =E2=80=8BDV cert and, though a seri= es of stupidly I managed to delete the private key[0]. The CA / reseller I = was using had a friendly "Revoke" button which let me upload a ne= w CSR and get a new cert within a few minutes. I'll happily admit that = I didn't check if they actually added the old one to a CRL, a: I assume= d that they did and b: they did let me reissue without more $$$ - which was= the only bit I actually cared about :-).

Now that I've finished writing this it feels somewhat like: "= I just the other day got=E2=80=A6 an Internet was sent by my staff at 10 o&= #39;clock in the morning on Friday. I got it yesterday [Tuesday]. Why? Beca= use it got tangled up with all these things going on the Internet commercia= lly." - Ted Stevens.

W
[0]: ejabberd wants the key, cert and i= ntermediate certs all in a single .pem file -- while trying to make this I = managed to overwrite the key=C2=A0 (I did 'cp * > kumari.net-combine= d.pem' instead of 'cat * > kumari.net= -combined.pem')


=E2= =80=8BRevocation at the request of the subject is easy to automate because = they gave consent.

Revoca= tion for breach of terms of service is much more involved. The complaint ma= y be valid or it may be a DoS attack on the site. =E2=80=8B

=

=C2=A0
--000000000000710b41056ce97b19-- From nobody Thu May 24 05:52:22 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7549126D05; Thu, 24 May 2018 05:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 1C_WboXUTwe7; Thu, 24 May 2018 05:52:12 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 9B84612DA4D; Thu, 24 May 2018 05:52:12 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id p144-v6so495121ywg.7; Thu, 24 May 2018 05:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Pc9BntAWsxmaqMednyM1WEUSWghhjrhu067ClwBDOmw=; b=bws83RRKRw+AcoGzIdVRdC4RlO2BbkGsYj+GRWyZYTjKbkDEoRv/YSlkAupNdzkQKm xUsjjoUuKviiKD8HdKhPRh/T0CUyro5Tl8xZJ8NLwb7BBC/FM+o9qtA25Jw6sU/y1gsb 7/aucT+sOK5ZM1Qo8aq80ff+dvyhHa43ObCa0zbNd7+ZK2LgB0y65Yd+4llsWAKrZcUw QbM+B88CAsUiq4HjJ8nuTAFtEZQebe/3x2qYzNGzu7hMPD5H+zHamNUy0msfM42tqVRe iBLioqV0nqRXU09ZvOS3lzVQp9vRmWd3PbaUnrQpeHE5H4cSet4Ma29sr4ul+b6/Up+R /f0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Pc9BntAWsxmaqMednyM1WEUSWghhjrhu067ClwBDOmw=; b=BqiOqI/tSh6czxUx7rCC49OKDC3Lb+mNQ1cqK0hS0imvC4/WML8roqqtvQpXe+z41Z Cb593vahAMU6yzL0zpJQK/S5O4MUFMG7aXeB8h3m2qwe37BAehj6wFBj9gmVmDI0bbhq CRC+PzUcqHplhD10c8jyaPR3TpkrKEnSRciYVYFShH3nikFpHehevtEYRCkFBsSevfe2 1MJatWhOq12baI4YBp2gXWuVmVJP606EGyCY+UxqqIQfWRcboUOJ2EmELj2gPyFrtkCg sufgv7fv4ZiMGWyAf0oFtVKMh+H5EM+A70ykpc+ohJeCAtdPTpvWYuI74yLHZTSqM2j7 oGKw== X-Gm-Message-State: ALKqPwdvLw/yKk6E9/bHb2gI29i71InOFlWEk9GMqsb7LgLkD+nanX7u tWMh/SKPbkDZWIW4Agilhf71Zw++1XLX09FLGb6xSQ== X-Google-Smtp-Source: AB8JxZplmejDnn6OVzfSxumeNTlVITEfRrrMI2iuLalhn+xJcW4Bgo+XlVBLPXJ0vekNXkn6z7KyvL1MIkYQWScaH3s= X-Received: by 2002:a0d:ed06:: with SMTP id w6-v6mr3613649ywe.467.1527166331750; Thu, 24 May 2018 05:52:11 -0700 (PDT) MIME-Version: 1.0 References: <152709922899.26838.11074435093932176947.idtracker@ietfa.amsl.com> <41e7a726-0175-7e3d-d35c-d413bf01ea12@nostrum.com> In-Reply-To: <41e7a726-0175-7e3d-d35c-d413bf01ea12@nostrum.com> From: Spencer Dawkins at IETF Date: Thu, 24 May 2018 07:51:58 -0500 Message-ID: To: Adam Roach Cc: IESG , spasm@ietf.org, lamps-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000b78f8a056cf31e45" Archived-At: Subject: Re: [lamps] Spencer Dawkins' No Objection on charter-ietf-lamps-02-00: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 12:52:15 -0000 --000000000000b78f8a056cf31e45 Content-Type: text/plain; charset="UTF-8" Backing up slightly ... my ballot set off a pretty interesting discussion, but I didn't want to lose sight of my point, which was On Wed, May 23, 2018 at 2:36 PM Adam Roach wrote: > On 5/23/18 1:13 PM, Spencer Dawkins wrote: > > 4. Specify the use of a pre-shared key (PSK) along with other key > > management techniques with supported by the Cryptographic Message > > Syntax (CMS) as a near-term mechanism to protect present day > > communication from the future invention of a large-scale quantum > > computer. > > > > I found it confusing because "near-term" isn't "near-term from now", it's > > "near-term after the invention of quantum computing destroys > civilization. > > My understanding is that the intention is "near-term from now." The idea > is that LAMPS should develop something that you could use, say, next > year to encrypt email you send so that, 15 years from now when someone > finally builds a 4,000 qubit machine, they can't dig out your (then) > 14-year-old email and decrypt it. > OK, that sounds like a plan, but it's not the way I understood the text, and I note that the sentence makes more sense to me without "near-term", resulting in "4. Specify the use of a pre-shared key (PSK) along with other key management techniques with supported by the Cryptographic Message Syntax (CMS) as a mechanism to protect present day communication from the future invention of a large-scale quantum computer." which I would have read as saying what Adam said it means. Do the right thing, of course ;-) Spencer --000000000000b78f8a056cf31e45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Backing up slightly ... my ballot set off a pretty interes= ting discussion, but I didn't want to lose sight of my point, which was= =C2=A0

On Wed, May 23, = 2018 at 2:36 PM Adam Roach <adam@nos= trum.com> wrote:
On 5/23/18 1:13 PM, Spencer Dawkins wrote:
> 4. Specify the use of a pre-shared key (PSK) along with other key
> management techniques with supported by the Cryptographic Message
> Syntax (CMS) as a near-term mechanism to protect present day
> communication from the future invention of a large-scale quantum
> computer.
>
> I found it confusing because "near-term" isn't "nea= r-term from now", it's
> "near-term after the invention of quantum computing destroys civi= lization.

My understanding is that the intention is "near-term from now." T= he idea
is that LAMPS should develop something that you could use, say, next
year to encrypt email you send so that, 15 years from now when someone
finally builds a 4,000 qubit machine, they can't dig out your (then) 14-year-old email and decrypt it.

OK, t= hat sounds like a plan, but it's not the way I understood the text, and= I note that the sentence makes more sense to me without "near-term&qu= ot;, resulting in=C2=A0

=C2=A0"4. Specify the= use of a pre-shared key (PSK) along with other key
management te= chniques with supported by the Cryptographic Message
Syntax (CMS)= as a mechanism to protect present day
communication from the fut= ure invention of a large-scale quantum
computer."
=
which I would have read as saying what Adam said it means.

Do the right thing, of course ;-)

Spencer
--000000000000b78f8a056cf31e45-- From nobody Thu May 24 06:27:26 2018 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE13F12E8AD; Thu, 24 May 2018 06:27:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: lamps-chairs@ietf.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152716843783.29943.18042126690866340208.idtracker@ietfa.amsl.com> Date: Thu, 24 May 2018 06:27:17 -0700 Archived-At: Subject: [lamps] Alissa Cooper's No Objection on charter-ietf-lamps-02-00: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 13:27:18 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-lamps-02-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-lamps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The milestones look aggressive but I'm unfamiliar with how mature the existing drafts are. s/in some environments, such a the/in some environments, such as the/ s/6. Specifies a certificate extension/6. Specify a certificate extension/ From nobody Wed May 30 08:53:12 2018 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E75CF12DA17; Wed, 30 May 2018 08:53:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Cc: spasm@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <152769558491.27675.17812582299995730653.idtracker@ietfa.amsl.com> Date: Wed, 30 May 2018 08:53:04 -0700 Archived-At: Subject: [lamps] WG Review: Limited Additional Mechanisms for PKIX and SMIME (lamps) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 15:53:05 -0000 The Limited Additional Mechanisms for PKIX and SMIME (lamps) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2018-06-06. Limited Additional Mechanisms for PKIX and SMIME (lamps) ----------------------------------------------------------------------- Current status: Active WG Chairs: Russ Housley Timothy Hollebeek Assigned Area Director: Eric Rescorla Security Area Directors: Eric Rescorla Benjamin Kaduk Mailing list: Address: spasm@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/spasm Archive: https://mailarchive.ietf.org/arch/browse/spasm/ Group page: https://datatracker.ietf.org/group/lamps/ Charter: https://datatracker.ietf.org/doc/charter-ietf-lamps/ The PKIX and S/MIME Working Groups have been closed for some time. Some updates have been proposed to the X.509 certificate documents produced by the PKIX Working Group and the electronic mail security documents produced by the S/MIME Working Group. The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working Group is chartered to make updates where there is a known constituency interested in real deployment and there is at least one sufficiently well specified approach to the update so that the working group can sensibly evaluate whether to adopt a proposal. The LAMPS WG is now tackling these topics: 1. Specify a discovery mechanism for CAA records to replace the one described in RFC 6844. Implementation experience has demonstrated an ambiguity in the handling of CNAME and DNAME records during discovery in RFC 6844, and subsequent discussion has suggested that a different discovery approach would resolve limitations inherent in that approach. 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. Unlike the previous hashing standards, the SHA-3 family of functions are the outcome of an open competition. They have a clear design rationale and have received a lot of public analysis, giving great confidence that the SHA-3 family of functions are secure. Also, since SHA-3 uses a very different construction from SHA-2, the SHA-3 family of functions offers an excellent alternative. In particular, SHAKE128/256 and SHAKE256/512 offer security and performance benefits. 3. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information, as a result revoking them pointless. 4. Specify the use of a pre-shared key (PSK) along with other key management techniques with supported by the Cryptographic Message Syntax (CMS) as a near-term mechanism to protect present day communication from the future invention of a large-scale quantum computer. The invention of a such a quantum computer would pose a serious challenge for the key management algorithms that are widely deployed, especially the key transport and key agreement algorithms used today with the CMS to protect S/MIME messages. 5. Specify the use of hash-based signatures with the Cryptographic Message Syntax (CMS). A hash-based signature uses small private and public keys, and it has low computational cost; however, the signature values are quite large. For this reason they might not be used for signing X.509 certificates or S/MIME messages, but they are secure even if a large-scale quantum computer is invented. These properties make hash-based signatures useful in some environments, such a the distribution of software updates. 6. Specifies a certificate extension that is carried in a self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate, to identify the next public key that will be used by the trust anchor. In addition, the LAMPS WG may investigate other updates to documents produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt any of these potential work items without rechartering. Milestones: Jun 2018 - Adopt a draft for short-lived certificate conventions Jun 2018 - Adopt a draft for the CMS with PSK Jun 2018 - Adopt a draft for hash-based signatures with the CMS Jun 2018 - Adopt a draft for root key rollover certificate extension Jul 2018 - rfc6844bis sent to IESG for standards track publication Aug 2018 - Root key rollover certificate extension sent to IESG for informational publication Sep 2018 - SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for standards track publication Sep 2018 - SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for standards track publication Oct 2018 - Short-lived certificate conventions sent to IESG for BCP publication Oct 2018 - The CMS with PSK sent to IESG for standards track publication Dec 2018 - Hash-based signatures with the CMS sent to IESG for standards track publication From nobody Wed May 30 15:21:02 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FFB12D94A for ; Wed, 30 May 2018 15:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YneHwATGIJqn for ; Wed, 30 May 2018 15:20:52 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (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 C5DDF12EB96 for ; Wed, 30 May 2018 15:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=0BBbchuoliRAGYLDRZp5M2GA+m6KLH9nbCV9Rk8XcvI=; b=ecYycOqrWdLZrAHpxgz2Ciz0wF t9HyfE5qVC/XEzMY5arK+pYznlbPy/b/reC966hwHaJVAiG1qyKEQ5VxEfOjLainuQvXtlUwBz9ek iNs4dncJTjpjFGlJoYNlL1HG28PQH3X0Dzmr6qNSgJqgWqpzWLEY3s7aM5tUTcfxuAjA=; Received: ; Wed, 30 May 2018 15:20:52 -0700 To: Corey Bonnell , "spasm@ietf.org" References: <878C91A0-6875-47A4-872F-F5D1F7F7AE7E@trustwave.com> From: Jacob Hoffman-Andrews Message-ID: Date: Wed, 30 May 2018 15:20:51 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------30A0DB75163B0E255ED04EAC" Content-Language: en-US Archived-At: Subject: Re: [lamps] Ambiguities in RFC 6844 regarding CAA resource record sets with no "issue" property tags X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 22:21:02 -0000 This is a multi-part message in MIME format. --------------30A0DB75163B0E255ED04EAC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 03/27/2018 07:27 AM, Corey Bonnell wrote: > As for my original erratum text not specifying "issuewild", that is > because section 5.3 (5.3.  CAA issuewild Property) specifies that "The > issuewild property has the same syntax and semantics as the issue > property except that issuewild properties only grant authorization to > issue certificates that specify a wildcard domain". Given that > issuewild property tags have the same semantics as issue property > tags, the addition of my original erratum text (in section 5.2, which > defines issue property tag semantics) will also address the case of a > resource record set not containing issue property tags and not > containing issuewild property tags (only in the case of wildcard > domain names, since issuewild property tags are otherwise ignored as > per section 5.3). > > If you think that's too vague and it's better to explicitly mention > the lack of issuewild tags, we should qualify the language a bit to > say "A non-empty CAA record set that contains no issue property tags > (and also does not contain any issuewild property tags when performing > issue restriction processing for a wildcard domain) is authorization > to any certificate issuer to issue for the corresponding domain, > provided that no records in the CAA record set otherwise prohibit > issuance." Otherwise, it is unclear how to handle the case of a > non-empty CAA record set for a non-wildcard domain that does not > contain an issue property tag but contains one or more issuewild > property tags. > I updated my PR to reflect this feedback. I decided to go with "more verbose is better," so now the section that describes what to do when there is no "issue" tag specifically excludes wildcard domains. And I added to the "issuewild" section language that say both "issue" and "issuewild" must be absent to be considered authorization to issue: https://github.com/jsha/caa-simplification/pull/1/commits/65a5665c6cc6db6e90c8b43fed4ae0bf5e8f83ee I'll merge this shortly to produce a new draft, but am happy to keep discussing the fine details. :-) --------------30A0DB75163B0E255ED04EAC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 03/27/2018 07:27 AM, Corey Bonnell wrote:
As for my original erratum text not specifying "issuewild", that is because section 5.3 (5.3.  CAA issuewild Property) specifies that "The issuewild property has the same syntax and semantics as the issue property except that issuewild properties only grant authorization to issue certificates that specify a wildcard domain". Given that issuewild property tags have the same semantics as issue property tags, the addition of my original erratum text (in section 5.2, which defines issue property tag semantics) will also address the case of a resource record set not containing issue property tags and not containing issuewild property tags (only in the case of wildcard domain names, since issuewild property tags are otherwise ignored as per section 5.3).

 

If you think that's too vague and it's better to explicitly mention the lack of issuewild tags, we should qualify the language a bit to say "A non-empty CAA record set that contains no issue property tags (and also does not contain any issuewild property tags when performing issue restriction processing for a wildcard domain) is authorization to any certificate issuer to issue for the corresponding domain, provided that no records in the CAA record set otherwise prohibit issuance." Otherwise, it is unclear how to handle the case of a non-empty CAA record set for a non-wildcard domain that does not contain an issue property tag but contains one or more issuewild property tags.

I updated my PR to reflect this feedback. I decided to go with "more verbose is better," so now the section that describes what to do when there is no "issue" tag specifically excludes wildcard domains. And I added to the "issuewild" section language that say both "issue" and "issuewild" must be absent to be considered authorization to issue:

https://github.com/jsha/caa-simplification/pull/1/commits/65a5665c6cc6db6e90c8b43fed4ae0bf5e8f83ee

I'll merge this shortly to produce a new draft, but am happy to keep discussing the fine details. :-)
--------------30A0DB75163B0E255ED04EAC-- From nobody Thu May 31 06:29:47 2018 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F84112EBA5; Thu, 31 May 2018 06:29:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152777337610.22608.6059150273493312369@ietfa.amsl.com> Date: Thu, 31 May 2018 06:29:36 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc6844bis-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 13:29:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : DNS Certification Authority Authorization (CAA) Resource Record Authors : Phillip Hallam-Baker Rob Stradling Jacob Hoffman-Andrews Filename : draft-ietf-lamps-rfc6844bis-00.txt Pages : 18 Date : 2018-05-30 Abstract: The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain. CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc6844bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc6844bis-00 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc6844bis-00 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 31 11:46:54 2018 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CA612EBC8 for ; Thu, 31 May 2018 11:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPt4uMAGRBO0 for ; Thu, 31 May 2018 11:46:49 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (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 97B2E12EC01 for ; Thu, 31 May 2018 11:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:To:Subject:From:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=7SSvJkVHw4EFD9elKR7GELIHbrHZic8OHxVI42LamK0=; b=l4mai/6tu/awQRXzKG54dRRQWL raP+SI92972w1Hj4oPvh8YfR4yf5LRCx21HdTU6VPNz7fG62AwB06B7xlo8z7r6bJxRCphj/Jt8gN BPie3GBkKcbYIYy66UQd4j4AELIUNmiWpc7ycqdMx1RdIuPkm4/6rSnYGcEux+JxoE70=; Received: ; Thu, 31 May 2018 11:46:49 -0700 From: Jacob Hoffman-Andrews To: SPASM Message-ID: Date: Thu, 31 May 2018 11:46:48 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [lamps] New draft: rfc6844bis X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 18:46:52 -0000 Hi all, I've uploaded rfc6844bis (https://tools.ietf.org/html/draft-ietf-lamps-rfc6844bis-00), which is the WG version of https://tools.ietf.org/html/draft-hoffman-andrews-caa-simplification-03. Differences versus the last draft: - Adopted Corey's improved ABNF grammar, which also allows hyphens in property names, and spaces around the equal signs in properties. - Clarified how to handle CAA RRsets that have no issue or issuewild tags, but do have other CAA tags. Thanks for the proposal on this, Corey! - Added a "Differences vs RFC 6844" section. - Emptied the IANA Considerations section, which was copied from RFC6844 but irrelevant because the values in it had already been registered with IANA. - Added a section to "Deployment Considerations" regarding private nameservers. - Improved the wording of "Bogus DNSSEC Responses" section (under "Deployment Considerations"). If you would like to read the individual commits, they are available at https://github.com/jsha/caa-simplification/commits/master. Thanks, Jacob