From nobody Sun Jul 1 12:24: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 53BF6130EEA for ; Sun, 1 Jul 2018 12:24: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=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 Bb75UYriNQ6K for ; Sun, 1 Jul 2018 12:24:08 -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 64F97130ED8 for ; Sun, 1 Jul 2018 12:24:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4F23B300A2C for ; Sun, 1 Jul 2018 15:24:06 -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 cfMN2BH0DM8q for ; Sun, 1 Jul 2018 15:24:05 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 15F85300A2A for ; Sun, 1 Jul 2018 15:24:04 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_C1EF3627-2D5F-4F2C-BD7E-D6BF282B6284" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Message-Id: <72C626CB-B3C1-48C8-82CF-4C8029072C5E@vigilsec.com> References: <153047299821.27349.12556798047605426790.idtracker@ietfa.amsl.com> To: SPASM Date: Sun, 1 Jul 2018 15:24:05 -0400 X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [lamps] Fwd: New Version Notification for draft-housley-cms-mts-hash-sig-10.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 19:24:17 -0000 --Apple-Mail=_C1EF3627-2D5F-4F2C-BD7E-D6BF282B6284 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-housley-cms-mts-hash-sig-10.txt > Date: July 1, 2018 at 3:23:18 PM EDT > To: "Russ Housley" >=20 >=20 > A new version of I-D, draft-housley-cms-mts-hash-sig-10.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. >=20 > Name: draft-housley-cms-mts-hash-sig > Revision: 10 > Title: Use of the Hash-based Merkle Tree Signature = (MTS) Algorithm in the Cryptographic Message Syntax (CMS) > Document date: 2018-07-01 > Group: Individual Submission > Pages: 12 > URL: = https://www.ietf.org/internet-drafts/draft-housley-cms-mts-hash-sig-10.txt= > Status: = https://datatracker.ietf.org/doc/draft-housley-cms-mts-hash-sig/ > Htmlized: = https://tools.ietf.org/html/draft-housley-cms-mts-hash-sig-10 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-housley-cms-mts-hash-sig > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-housley-cms-mts-hash-sig-10 >=20 > Abstract: > This document specifies the conventions for using the Merkle Tree > Signatures (MTS) digital signature algorithm with the Cryptographic > Message Syntax (CMS). The MTS algorithm is one form of hash-based > digital signature. >=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. >=20 > The IETF Secretariat --Apple-Mail=_C1EF3627-2D5F-4F2C-BD7E-D6BF282B6284 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI

From: internet-drafts@ietf.org
Subject: = New Version = Notification for draft-housley-cms-mts-hash-sig-10.txt
Date: = July 1, 2018 at 3:23:18 PM = EDT
To: = "Russ Housley" <housley@vigilsec.com>


A new version = of I-D, draft-housley-cms-mts-hash-sig-10.txt
has been = successfully submitted by Russ Housley and posted to the
IETF repository.

Name: = draft-housley-cms-mts-hash-sig
Revision: 10
Title:= = Use of the Hash-based Merkle Tree Signature (MTS) Algorithm in = the Cryptographic Message Syntax (CMS)
Document date: = 2018-07-01
Group: Individual Submission
Pages:= = 12
URL: =            https://www.ietf.org/internet-drafts/draft-housley-cms-mts-hash= -sig-10.txt
Status: =         https://datatracker.ietf.org/doc/draft-housley-cms-mts-hash-sig= /
Htmlized:       https://tools.ietf.org/html/draft-housley-cms-mts-hash-sig-10
Htmlized:       https://datatracker.ietf.org/doc/html/draft-housley-cms-mts-has= h-sig
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-housley-cms-mts-hash-= sig-10

Abstract:
=   This document specifies the conventions for using the Merkle = Tree
  Signatures (MTS) digital signature = algorithm with the Cryptographic
  Message = Syntax (CMS).  The MTS algorithm is one form of hash-based
  digital signature.

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

= --Apple-Mail=_C1EF3627-2D5F-4F2C-BD7E-D6BF282B6284-- From nobody Mon Jul 2 13:52:48 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 C5612130E18; Mon, 2 Jul 2018 13:52:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-lamps-rfc5751-bis@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153056475779.16504.16273523283477340877.idtracker@ietfa.amsl.com> Date: Mon, 02 Jul 2018 13:52:37 -0700 Archived-At: Subject: [lamps] Adam Roach's Yes on draft-ietf-lamps-rfc5751-bis-10: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 02 Jul 2018 20:52:38 -0000 Adam Roach has entered the following ballot position for draft-ietf-lamps-rfc5751-bis-10: Yes 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to everyone who put work into updating this document. I have one comment that is either substantive or me just being confused, and several editorial nits. --------------------------------------------------------------------------- §3.5.3.2: > The values to be placed in the micalg parameter SHOULD be from the > following: > > 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) The example then goes on to demonstrate the use of "micalg=sha-1". This is probably a misunderstanding on my part, but I thought that this document was intending to mark MD5 and SHA-1 as historic for digesting content (cf. §1.7 and §B.1). Wouldn't that mean they should be annotated as deprecated in some way here? I would have also expected the example to use sha-256 or sha-512. --------------------------------------------------------------------------- §2.2: > - . SHOULD support RSASSA-PSS with SHA-256. There appears to be an extra "." at the beginning of this bullet --------------------------------------------------------------------------- §3.1: > S/MIME is used to secure MIME entities. A MIME message is composed > of a MIME header and a MIME body, the body can consist of a single > part or of multiple parts. Nit: "...MIME body. The body can..." --------------------------------------------------------------------------- §3.3: > The > Enveloped-Only structure does not support authenticated symmetric > algorithms, use the .Authenticated Enveloped structure for these > algorithms. Two nits: "...symmetric algorithms. Use the Authenticated..." ^ ^ --------------------------------------------------------------------------- §6: > S/MIME implementations almost universally use ephemeral-static rather > than static-static key agreement and do not use a shared secret for > encryption, this means that the first precondition is not met. Nit: "...encryption. This means..." From nobody Mon Jul 2 18:07:53 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 713C2130E31; Mon, 2 Jul 2018 18:07:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-lamps-rfc5751-bis@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153058006445.16082.18226541682121469039.idtracker@ietfa.amsl.com> Date: Mon, 02 Jul 2018 18:07:44 -0700 Archived-At: Subject: [lamps] Ben Campbell's Yes on draft-ietf-lamps-rfc5751-bis-10: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 03 Jul 2018 01:07:45 -0000 Ben Campbell has entered the following ballot position for draft-ietf-lamps-rfc5751-bis-10: Yes 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm balloting "yes", but have some minor comments substantive comments and a number of editorial comments. I mainly reviewed the diff from RFC 5751. Substantive Comments: §2.3, 2nd to last paragraph: I don't understand what it means to say recipients MAY enforce a "MUST be supported" requirement. Am I correct to assume the "MUST use the weaker" only applies if the sender used both key-wrap algorithms? §3.1.2, 2nd paragraph: The addition of "As a rule, ..." doesn't seem to add information, but it does undermine the SHOULD that immediately follows. (I'd count this as an editorial comment, but I think undermining a SHOULD is a material issue.) Editorial Comments: - IDNits complains about some unused references. Please check. (They may be due to the specification-group references, which I think are fine). §1.5: I have trouble parsing the first paragraph. Is the comma in "... MUST implement, key wrap algorithm... " intentional? §2.2, Receiving agent requirements, 4th bullet: Spurious "." and white space at beginning. §2.5.2: "The presence of an algorithm based SMIME Capability attribute in this sequence implies that the sender can deal with the algorithm as well as understanding the ASN.1 structures associated with that algorithm." s/understanding/understands §2.5.3, 2nd paragraph: "If a signature is detected to violate these requirements, the signature SHOULD be treated as failing." "detected to violate" is awkward. Perhaps "determined to violate", "detected to be violating", or "detected as violating"? §3.1: - first paragraph: "A MIME entity can be a sub-part, sub-parts of a MIME message, or the whole MIME message with all of its sub-parts." I'm not sure how to parse the first comma. Is the intent of that part that the entity can be sub-part or sub-parts of a message? - 2nd to last paragraph: " It is up to the receiving client to decide how to present this "inner" header along with the unprotected "outer" header. It is RECOMMENDED that a distinction be made between the location of the header." The last sentence partially contradicts the first one. Also, can the last sentence be phrased in active voice, to strengthen the connection to the client as the actor? §3.3, first paragraph: "The Enveloped-Only structure does not support authenticated symmetric algorithms, use the .Authenticated Enveloped structure for these algorithms. " Comma splice. §6: - " Many people assume that the use of an authenticated encryption algorithm is all that is needed to be in a situation where the sender of the message will be authenticated." Convoluted sentence. The phrase "needed to be in a situation where" seems like a complicated way of expressing something like "needed to consider the sender to be authenticated" - "... create a message that the first recipient would believe is from the sender by stripping them as a recipient from the message.": The antecedent of "them" is ambiguous. - "A direct path needs to exist from the starting key to the key used as the content encryption key (CEK) which guarantees that no third party could have seen the resulting CEK." s/which/that - "A direct path needs to exist from the starting key to the key used as the content encryption key (CEK) which guarantees that no third party could have seen the resulting CEK." Comma splice. - "There is a document [RFC6278] which defined how to use static-static key agreement with CMS so that is readably doable. " s/which/that. Also, the _existing_ "that" has an unclear antecedent. - "New key agreement algorithms that directly created the CEK without creating an intervening KEK would need to be defined." Should "would need" simply be "need"? - "Compression oracle attacks require an adaptive input to the process and attack the unknown content of a message based on the length of the compressed output, this means that no attack on the encryption key is necessarily required." Comma splice. - "The other attack that is highlighted in [Efail] is an error in how mail clients deal with HTML and multipart/mixed messages. " I don't think the "error" is the "attack". perhaps s/"is an error"/"involves an error"? - Appendix D: "Some of the examples in this document were stolen from [RFC4134]." Can this say something like "copied from" or "borrowed from"? From nobody Tue Jul 3 08:27: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 36702130E68; Tue, 3 Jul 2018 08:27:38 -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 rNpK6zbk5cUK; Tue, 3 Jul 2018 08:27:35 -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 98CB0130DE1; Tue, 3 Jul 2018 08:27:35 -0700 (PDT) Received: from Jude (12.171.40.194) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 3 Jul 2018 08:24:21 -0700 From: Jim Schaad To: 'Adam Roach' , 'The IESG' CC: , 'Russ Housley' , , , References: <153056475779.16504.16273523283477340877.idtracker@ietfa.amsl.com> In-Reply-To: <153056475779.16504.16273523283477340877.idtracker@ietfa.amsl.com> Date: Tue, 3 Jul 2018 08:27:24 -0700 Message-ID: <046701d412e2$59aee510$0d0caf30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQGT+dy+HKDrVqhJ/ACfEMZIgDiSMqT9wFyQ X-Originating-IP: [12.171.40.194] Archived-At: Subject: Re: [lamps] Adam Roach's Yes on draft-ietf-lamps-rfc5751-bis-10: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 03 Jul 2018 15:27:38 -0000 > -----Original Message----- > From: Adam Roach > Sent: Monday, July 2, 2018 1:53 PM > To: The IESG > Cc: draft-ietf-lamps-rfc5751-bis@ietf.org; Russ Housley > ; lamps-chairs@ietf.org; housley@vigilsec.com; > spasm@ietf.org > Subject: Adam Roach's Yes on draft-ietf-lamps-rfc5751-bis-10: (with > COMMENT) >=20 > Adam Roach has entered the following ballot position for > draft-ietf-lamps-rfc5751-bis-10: Yes >=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 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks to everyone who put work into updating this document. I have = one > comment that is either substantive or me just being confused, and = several > editorial nits. >=20 > = -------------------------------------------------------------------------= -- >=20 > =C2=A73.5.3.2: >=20 > > The values to be placed in the micalg parameter SHOULD be from the > > following: > > > > 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 > The example then goes on to demonstrate the use of "micalg=3Dsha-1". = This is > probably a misunderstanding on my part, but I thought that this = document > was intending to mark MD5 and SHA-1 as historic for digesting content = (cf. > =C2=A71.7 and =C2=A7B.1). Wouldn't that mean they should be annotated = as deprecated > in some way here? I would have also expected the example to use = sha-256 > or sha-512. In terms of the content of the table, this table is the only registry = that exists for the values to be placed here. This means that I have = not removed any of the "historical" values as I believe that they need = to be part of the table. In terms of the following example, it is one = of the examples that I did not re-generate as part of this document and = thus is still setup with a micalg of sha-1. While I could re-generate = this example, it is correct as it is and has been validated. I cannot = have that same assurance if it is replaced. >=20 > = -------------------------------------------------------------------------= -- >=20 > =C2=A72.2: >=20 > > - . SHOULD support RSASSA-PSS with SHA-256. >=20 > There appears to be an extra "." at the beginning of this bullet Fixed >=20 > = -------------------------------------------------------------------------= -- >=20 > =C2=A73.1: >=20 > > S/MIME is used to secure MIME entities. A MIME message is composed > > of a MIME header and a MIME body, the body can consist of a single > > part or of multiple parts. >=20 > Nit: "...MIME body. The body can..." Fixed >=20 > = -------------------------------------------------------------------------= -- >=20 > =C2=A73.3: >=20 > > The > > Enveloped-Only structure does not support authenticated symmetric > > algorithms, use the .Authenticated Enveloped structure for these > > algorithms. >=20 > Two nits: "...symmetric algorithms. Use the Authenticated..." Fixed, but hard to figure out for non-monospaced fonts. > ^ ^ > = -------------------------------------------------------------------------= -- >=20 > =C2=A76: >=20 > > S/MIME implementations almost universally use ephemeral-static = rather > > than static-static key agreement and do not use a shared secret for > > encryption, this means that the first precondition is not met. >=20 > Nit: "...encryption. This means..." Fixed From nobody Tue Jul 3 09:04:08 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 09EFF130FCF; Tue, 3 Jul 2018 09:00:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: spasm@ietf.org, ekr@rtfm.com X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063362003.4893.14943687421454333820.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:20 -0700 Archived-At: Subject: [lamps] lamps - Requested session has been scheduled for IETF 102 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 03 Jul 2018 16:00:31 -0000 Dear Russ Housley, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. lamps Session 1 (2:00 requested) Thursday, 19 July 2018, Afternoon Session II 1550-1750 Room Name: Notre Dame size: 50 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/102/sessions/lamps.ics Request Information: --------------------------------------------------------- Working Group Name: Limited Additional Mechanisms for PKIX and SMIME Area Name: Security Area Session Requester: Russ Housley Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: suit curdle quic perc saag sidrops sipbrandy tls ipwave stir acme ace rtcweb Second Priority: cfrg dprive oauth ipsecme Third Priority: mtgvenue iasa20 People who must be present: Russ Housley Eric Rescorla Sean Turner Jim Schaad Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jul 3 09:15: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 0E1561310E5; Tue, 3 Jul 2018 09:14:50 -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 12NT1PfKZNoX; Tue, 3 Jul 2018 09:14:44 -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 84FBB131065; Tue, 3 Jul 2018 09:10:45 -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 w63GAOGw082281 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 3 Jul 2018 11:10:28 -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: Jim Schaad , "'The IESG'" Cc: draft-ietf-lamps-rfc5751-bis@ietf.org, "'Russ Housley'" , lamps-chairs@ietf.org, spasm@ietf.org References: <153056475779.16504.16273523283477340877.idtracker@ietfa.amsl.com> <046701d412e2$59aee510$0d0caf30$@augustcellars.com> From: Adam Roach Message-ID: <4de6554b-0def-ce1d-5e1f-a02ee572c477@nostrum.com> Date: Tue, 3 Jul 2018 11:10:19 -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: <046701d412e2$59aee510$0d0caf30$@augustcellars.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [lamps] Adam Roach's Yes on draft-ietf-lamps-rfc5751-bis-10: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 03 Jul 2018 16:14:56 -0000 Jim -- Thanks for the quick response. Comments inline. On 7/3/18 10:27 AM, Jim Schaad wrote: > >> §3.5.3.2: >> >>> The values to be placed in the micalg parameter SHOULD be from the >>> following: >>> >>> 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) >> The example then goes on to demonstrate the use of "micalg=sha-1". This is >> probably a misunderstanding on my part, but I thought that this document >> was intending to mark MD5 and SHA-1 as historic for digesting content (cf. >> §1.7 and §B.1). Wouldn't that mean they should be annotated as deprecated >> in some way here? I would have also expected the example to use sha-256 >> or sha-512. > In terms of the content of the table, this table is the only registry that exists for the values to be placed here. This means that I have not removed any of the "historical" values as I believe that they need to be part of the table. Sure; I didn't expect to see them removed. I expected them to be annotated in some way; something like: 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) *Note: MD5 and SHA-1 are historic and no longer considered secure. See section B.1 for details. > In terms of the following example, it is one of the examples that I did not re-generate as part of this document and thus is still setup with a micalg of sha-1. While I could re-generate this example, it is correct as it is and has been validated. I cannot have that same assurance if it is replaced. I have a lot of sympathy for the challenges involved with generating correct examples. At the same time, I think it's  problematic to publish a document that deprecates an algorithm while simultaneously demonstrating its use. On the balance between these two factors, I think this document really needs to be updated so that the examples are consistent with the text. /a From nobody Tue Jul 3 09:41: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 B726312F1AB; Tue, 3 Jul 2018 09:40:59 -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 Xw0ZihBj5aat; Tue, 3 Jul 2018 09:40:56 -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 1997312F1A6; Tue, 3 Jul 2018 09:40:56 -0700 (PDT) Received: from Jude (12.171.40.194) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 3 Jul 2018 09:37:42 -0700 From: Jim Schaad To: 'Ben Campbell' , 'The IESG' CC: , 'Russ Housley' , , , References: <153058006445.16082.18226541682121469039.idtracker@ietfa.amsl.com> In-Reply-To: <153058006445.16082.18226541682121469039.idtracker@ietfa.amsl.com> Date: Tue, 3 Jul 2018 09:40:45 -0700 Message-ID: <047301d412ec$992cd120$cb867360$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQKzE2WuXPI8gUgKsTXEY6+/X3085aK/nu/w X-Originating-IP: [12.171.40.194] Archived-At: Subject: Re: [lamps] Ben Campbell's Yes on draft-ietf-lamps-rfc5751-bis-10: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 03 Jul 2018 16:41:00 -0000 > -----Original Message----- > From: Ben Campbell > Sent: Monday, July 2, 2018 6:08 PM > To: The IESG > Cc: draft-ietf-lamps-rfc5751-bis@ietf.org; Russ Housley > ; lamps-chairs@ietf.org; housley@vigilsec.com; > spasm@ietf.org > Subject: Ben Campbell's Yes on draft-ietf-lamps-rfc5751-bis-10: (with > COMMENT) >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-lamps-rfc5751-bis-10: Yes >=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 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I'm balloting "yes", but have some minor comments substantive comments > and a number of editorial comments. I mainly reviewed the diff from = RFC > 5751. >=20 > Substantive Comments: >=20 > =C2=A72.3, 2nd to last paragraph: I don't understand what it means to = say > recipients MAY enforce a "MUST be supported" requirement. Am I correct = to > assume the "MUST use the weaker" only applies if the sender used both > key-wrap algorithms? No, it is possible that one could use a 128-bit content encryption = algorithm, but use a 256-bit key wrap algorithm (or the reverse). The = text would apply in this case and allows for a recipient to avoid the = MUST be the same length requirement if they wish. >=20 > =C2=A73.1.2, 2nd paragraph: The addition of "As a rule, ..." doesn't = seem to add > information, but it does undermine the SHOULD that immediately = follows. > (I'd count this as an editorial comment, but I think undermining a = SHOULD is a > material issue.) There have actually been some people who have requested that this SHOULD = be removed from the document altogether. The feeling by some is that in = the last 20 years the number of gateways which are not 8-bit compatible = is now sufficiently small that there is no reason to even recommend that = 7-bit transfer encoding be used here. I don't really have any problems = with undermining the SHOULD, but I would want to see some numbers about = 8-bit ubiquity before removing the requirement completely. >=20 > Editorial Comments: >=20 > - IDNits complains about some unused references. Please check. (They = may > be due to the specification-group references, which I think are fine). Done - With any luck the V3 xml2rfc will do a better job of letting one = do these group references. =20 >=20 > =C2=A71.5: I have trouble parsing the first paragraph. Is the comma in = "... MUST > implement, key wrap algorithm... " intentional? Yes that comma is intentional. However I am going to change it to a = period. >=20 > =C2=A72.2, Receiving agent requirements, 4th bullet: Spurious "." and = white space > at beginning. Fixed >=20 > =C2=A72.5.2: "The presence > of an algorithm based SMIME Capability attribute in this sequence > implies that the sender can deal with the algorithm as well as > understanding the ASN.1 structures associated with that algorithm." > s/understanding/understands Fixed - but I made it singular which I think is grammatically correct. >=20 > =C2=A72.5.3, 2nd paragraph: "If a signature is detected to violate > these requirements, the signature SHOULD be treated as failing." >=20 > "detected to violate" is awkward. Perhaps "determined to violate", > "detected to be violating", or "detected as violating"? Fixed - I used the last one >=20 > =C2=A73.1: > - first paragraph: "A MIME entity can be a sub-part, sub-parts of a > MIME message, or the whole MIME message with all of its sub-parts." >=20 > I'm not sure how to parse the first comma. Is the intent of that part = that the > entity can be sub-part or sub-parts of a message? Yes. It can be one, two, a tree or the entire message. >=20 > - 2nd to last paragraph: " It is up to the receiving client to decide = how to > present > this "inner" header along with the unprotected "outer" header. It = is > RECOMMENDED that a distinction be made between the location of the > header." > The last sentence partially contradicts the first one. Also, can the = last > sentence be phrased in active voice, to strengthen the connection to = the > client as the actor? Given the security difference between headers, it is RECOMMENDED that = client provide a distinction between header fields depending on where = they are located. Is that better? >=20 > =C2=A73.3, first paragraph: "The > Enveloped-Only structure does not support authenticated symmetric > algorithms, use the .Authenticated Enveloped structure for these > algorithms. " > Comma splice. Fixed >=20 > =C2=A76: >=20 > - " Many people assume that the use of an authenticated encryption > algorithm is all that is needed to be in a situation where the = sender > of the message will be authenticated." > Convoluted sentence. The phrase "needed to be in a situation where" = seems > like a complicated way of expressing something like "needed to = consider the > sender to be authenticated" Many people assume that the use of an authenticated encryption algorithm = is all that is needed for the sender of the message to be = authenticated. >=20 > - "... create a message that the first recipient would > believe is from the sender by stripping them as a recipient from > the message.": The antecedent of "them" is ambiguous. s/them as a recipient/the second recipient/ >=20 > - "A direct path needs to exist from the starting key to the key used > as the content encryption key (CEK) which guarantees that no = third > party could have seen the resulting CEK." > s/which/that I have never gotten which/that correct=20 >=20 > - "A direct path needs to exist from the starting key to the key used > as the content encryption key (CEK) which guarantees that no = third > party could have seen the resulting CEK." > Comma splice. How can it be a comma splice if there is no comma? A direct path needs to exist from the starting key to the key used as = the content encryption key (CEK). That path needs to guarantees that = no third party could have seen the resulting CEK. >=20 > - "There > is a document [RFC6278] which defined how to use static-static key > agreement with CMS so that is readably doable. " > s/which/that. Also, the _existing_ "that" has an unclear antecedent. There is a document which defined how to use = static-static key agreement with CMS, so the first precondition can be = met. >=20 > - "New key agreement algorithms that directly > created the CEK without creating an intervening KEK would need to = be > defined." >=20 > Should "would need" simply be "need"? I think "would need" is correct here. This only needs to happen if you = are interested in doing this. There is no direct requirement at the = moment to do so. >=20 > - "Compression oracle attacks require an adaptive > input to the process and attack the unknown content of a message > based on the length of the compressed output, this means that no > attack on the encryption key is necessarily required." > Comma splice. Fixed >=20 > - "The other attack that is highlighted in [Efail] is an error in how > mail clients deal with HTML and multipart/mixed messages. " > I don't think the "error" is the "attack". perhaps s/"is an = error"/"involves an > error"? /is an error/is due to an error/ >=20 > - Appendix D: "Some of the examples in this document were stolen from > [RFC4134]." >=20 > Can this say something like "copied from" or "borrowed from"? Hey - I just stole them - but changed to copied. From nobody Tue Jul 3 09:43: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 37DAD12F1AB; Tue, 3 Jul 2018 09:43:50 -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 FhsuWjWfJE4r; Tue, 3 Jul 2018 09:43:48 -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 0982F130E30; Tue, 3 Jul 2018 09:43:48 -0700 (PDT) Received: from Jude (12.171.40.194) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 3 Jul 2018 09:40:32 -0700 From: Jim Schaad To: 'Adam Roach' , 'The IESG' CC: , 'Russ Housley' , , References: <153056475779.16504.16273523283477340877.idtracker@ietfa.amsl.com> <046701d412e2$59aee510$0d0caf30$@augustcellars.com> <4de6554b-0def-ce1d-5e1f-a02ee572c477@nostrum.com> In-Reply-To: <4de6554b-0def-ce1d-5e1f-a02ee572c477@nostrum.com> Date: Tue, 3 Jul 2018 09:43:36 -0700 Message-ID: <047401d412ec$fec06330$fc412990$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQGT+dy+HKDrVqhJ/ACfEMZIgDiSMgCffCvaA8Dtjoak2uJeAA== X-Originating-IP: [12.171.40.194] Archived-At: Subject: Re: [lamps] Adam Roach's Yes on draft-ietf-lamps-rfc5751-bis-10: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 03 Jul 2018 16:43:51 -0000 > -----Original Message----- > From: Adam Roach > Sent: Tuesday, July 3, 2018 9:10 AM > To: Jim Schaad ; 'The IESG' > Cc: draft-ietf-lamps-rfc5751-bis@ietf.org; 'Russ Housley' > ; lamps-chairs@ietf.org; spasm@ietf.org > Subject: Re: Adam Roach's Yes on draft-ietf-lamps-rfc5751-bis-10: = (with > COMMENT) >=20 > Jim -- >=20 > Thanks for the quick response. Comments inline. >=20 > On 7/3/18 10:27 AM, Jim Schaad wrote: > > > >> =C2=A73.5.3.2: > >> > >>> The values to be placed in the micalg parameter SHOULD be from = the > >>> following: > >>> > >>> 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) > >> The example then goes on to demonstrate the use of = "micalg=3Dsha-1". > >> This is probably a misunderstanding on my part, but I thought that > >> this document was intending to mark MD5 and SHA-1 as historic for > digesting content (cf. > >> =C2=A71.7 and =C2=A7B.1). Wouldn't that mean they should be = annotated as > >> deprecated in some way here? I would have also expected the example > >> to use sha-256 or sha-512. > > In terms of the content of the table, this table is the only = registry that exists > for the values to be placed here. This means that I have not removed = any of > the "historical" values as I believe that they need to be part of the = table. >=20 > Sure; I didn't expect to see them removed. I expected them to be = annotated > in some way; something like: >=20 >=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 > *Note: MD5 and SHA-1 are historic and no longer considered secure. > See section B.1 for details. That makes sense. Done >=20 > > In terms of the following example, it is one of the examples that = I did not > re-generate as part of this document and thus is still setup with a = micalg of > sha-1. While I could re-generate this example, it is correct as it is = and has > been validated. I cannot have that same assurance if it is replaced. >=20 > I have a lot of sympathy for the challenges involved with generating > correct examples. At the same time, I think it's problematic to = publish > a document that deprecates an algorithm while simultaneously > demonstrating its use. On the balance between these two factors, I = think > this document really needs to be updated so that the examples are > consistent with the text. Ok - I will put this on my list. It is not a simple think to do. >=20 > /a From nobody Tue Jul 3 14:11: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 29C50130E22 for ; Tue, 3 Jul 2018 14:11:43 -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 mgX7B9KcD0sa for ; Tue, 3 Jul 2018 14:11:42 -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 69E3F130E0F for ; Tue, 3 Jul 2018 14:11:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 60230300A98 for ; Tue, 3 Jul 2018 17:05:49 -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 2swo5vS2ttzj for ; Tue, 3 Jul 2018 17:05:47 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 6B7A7300288; Tue, 3 Jul 2018 17:05:47 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Russ Housley In-Reply-To: <047301d412ec$992cd120$cb867360$@augustcellars.com> Date: Tue, 3 Jul 2018 17:05:47 -0400 Cc: IESG , draft-ietf-lamps-rfc5751-bis@ietf.org, SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <69D03DC2-3FBF-4526-AD87-598DE109F7F5@vigilsec.com> References: <153058006445.16082.18226541682121469039.idtracker@ietfa.amsl.com> <047301d412ec$992cd120$cb867360$@augustcellars.com> To: Jim Schaad , Ben Campbell X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [lamps] Ben Campbell's Yes on draft-ietf-lamps-rfc5751-bis-10: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 03 Jul 2018 21:11:43 -0000 Ben and Jim: >> Substantive Comments: >>=20 >> =C2=A72.3, 2nd to last paragraph: I don't understand what it means to = say >> recipients MAY enforce a "MUST be supported" requirement. Am I = correct to >> assume the "MUST use the weaker" only applies if the sender used both >> key-wrap algorithms? >=20 > No, it is possible that one could use a 128-bit content encryption = algorithm, but use a 256-bit key wrap algorithm (or the reverse). The = text would apply in this case and allows for a recipient to avoid the = MUST be the same length requirement if they wish. It would be safe to allow the key for the key wrap algorithm to be = larger (e.g., AES-256 key wrap algorithm with AES-128 content = encryption algorithm). That said, a long time ago, we settled on this language because it was = very difficult to come up with rules if the key wrap algorithm and the = content encryption algorithm were using very different underlying = ciphers. Russ From nobody Tue Jul 3 21:38:36 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 73A17130E3E; Tue, 3 Jul 2018 21:38:28 -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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 u-GSD-9STNfA; Tue, 3 Jul 2018 21:38:26 -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 2170E130E39; Tue, 3 Jul 2018 21:38:25 -0700 (PDT) Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w644c8UW005825 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 3 Jul 2018 23:38:09 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95] From: Ben Campbell Message-Id: <375E416C-9FBE-4E95-BF6D-29EFD70F4B8D@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_660B4620-685B-4D78-A1C9-31EAE19BFE01"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 3 Jul 2018 23:38:07 -0500 In-Reply-To: <047301d412ec$992cd120$cb867360$@augustcellars.com> Cc: The IESG , draft-ietf-lamps-rfc5751-bis@ietf.org, Russ Housley , lamps-chairs@ietf.org, spasm@ietf.org To: Jim Schaad References: <153058006445.16082.18226541682121469039.idtracker@ietfa.amsl.com> <047301d412ec$992cd120$cb867360$@augustcellars.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [lamps] Ben Campbell's Yes on draft-ietf-lamps-rfc5751-bis-10: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 04 Jul 2018 04:38:29 -0000 --Apple-Mail=_660B4620-685B-4D78-A1C9-31EAE19BFE01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 3, 2018, at 11:40 AM, Jim Schaad = wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: Ben Campbell >> Sent: Monday, July 2, 2018 6:08 PM >> To: The IESG >> Cc: draft-ietf-lamps-rfc5751-bis@ietf.org; Russ Housley >> ; lamps-chairs@ietf.org; housley@vigilsec.com; >> spasm@ietf.org >> Subject: Ben Campbell's Yes on draft-ietf-lamps-rfc5751-bis-10: (with >> COMMENT) >>=20 >> Ben Campbell has entered the following ballot position for >> draft-ietf-lamps-rfc5751-bis-10: Yes >>=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 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I'm balloting "yes", but have some minor comments substantive = comments >> and a number of editorial comments. I mainly reviewed the diff from = RFC >> 5751. >>=20 >> Substantive Comments: >>=20 >> =C2=A72.3, 2nd to last paragraph: I don't understand what it means to = say >> recipients MAY enforce a "MUST be supported" requirement. Am I = correct to >> assume the "MUST use the weaker" only applies if the sender used both >> key-wrap algorithms? >=20 > No, it is possible that one could use a 128-bit content encryption = algorithm, but use a 256-bit key wrap algorithm (or the reverse). The = text would apply in this case and allows for a recipient to avoid the = MUST be the same length requirement if they wish. Okay, I think the issue is the antecedent of =E2=80=9Cthis=E2=80=9D in = =E2=80=9C=E2=80=A6 MAY enforce this=E2=80=9D is ambiguous. I read it as = referring to the previous sentence=E2=80=99s statement that both key = sizes MUST be supported. >=20 >>=20 >> =C2=A73.1.2, 2nd paragraph: The addition of "As a rule, ..." doesn't = seem to add >> information, but it does undermine the SHOULD that immediately = follows. >> (I'd count this as an editorial comment, but I think undermining a = SHOULD is a >> material issue.) >=20 > There have actually been some people who have requested that this = SHOULD be removed from the document altogether. The feeling by some is = that in the last 20 years the number of gateways which are not 8-bit = compatible is now sufficiently small that there is no reason to even = recommend that 7-bit transfer encoding be used here. I don't really = have any problems with undermining the SHOULD, but I would want to see = some numbers about 8-bit ubiquity before removing the requirement = completely. >=20 I suggest that adding some text to that effect, even if you keep the = SHOULD for now. [=E2=80=A6] >>=20 >> =C2=A71.5: I have trouble parsing the first paragraph. Is the comma = in "... MUST >> implement, key wrap algorithm... " intentional? >=20 > Yes that comma is intentional. However I am going to change it to a = period. Ah, I was trying to read it as =E2=80=9C=E2=80=A6 algorithm was changed = to a MUST-implement key wrap algorithm=E2=80=9D. The problem was not the = comma so much as =E2=80=9Cchanged to a MUST implement=E2=80=9D. I = suggest changing that to =E2=80=9Cchanged to be MUST implement=E2=80=9D. = (I agree on the period.) [=E2=80=A6] >=20 >>=20 >> =C2=A73.1: >> - first paragraph: "A MIME entity can be a sub-part, sub-parts of a >> MIME message, or the whole MIME message with all of its sub-parts." >>=20 >> I'm not sure how to parse the first comma. Is the intent of that part = that the >> entity can be sub-part or sub-parts of a message? >=20 > Yes. It can be one, two, a tree or the entire message. How about =E2=80=9CA MIME entity can one or more sub-parts of a MIME = message, or a whole MIME message with all of its sub-parts=E2=80=9D. >=20 >>=20 >> - 2nd to last paragraph: " It is up to the receiving client to decide = how to >> present >> this "inner" header along with the unprotected "outer" header. It = is >> RECOMMENDED that a distinction be made between the location of the >> header." >> The last sentence partially contradicts the first one. Also, can the = last >> sentence be phrased in active voice, to strengthen the connection to = the >> client as the actor? >=20 > Given the security difference between headers, it is RECOMMENDED that = client provide a distinction between header fields depending on where = they are located. >=20 > Is that better? yes. [=E2=80=A6] >=20 >>=20 >> - "A direct path needs to exist from the starting key to the key used >> as the content encryption key (CEK) which guarantees that no = third >> party could have seen the resulting CEK." >> Comma splice. >=20 > How can it be a comma splice if there is no comma? >=20 Ah, that was a copy-paste error. I meant this: " S/MIME implementations almost universally use ephemeral-static rather than static-static key agreement and do not use a shared secret for encryption, this means that the first precondition is not met. =E2=80=9C [=E2=80=A6] Thanks! Ben. --Apple-Mail=_660B4620-685B-4D78-A1C9-31EAE19BFE01 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAls8Ty8ACgkQgFZKbJXz 1A1JjRAAyQydb2Ww6Fge/J5Xnlv0bfTkIv1Md2ypOuGJKrmruviDkP0fpHGNX64x 37nIKglulJLicaxKL6KCL3fgWq64fPMnZhrpRnZFFYcD70qrAEtEmRCg7b06XLxj ZRbbbPkeJ9dGM4rX/V0qcyyzxZeAEZ+kH7Ck6wyVtmEBt60Y4DPgOU/snLBFgw6g Minqa9n0s61jshyJleZ+0yz0ch+LIHXEYW5Pk0Du6OCHhPIM2AY+PgV3cqieoBv1 RfweT6C7QkVnSH/cwh06iM/6fqS1MkMczcZmbIziS6R2P1rxF/yIsPYWaBuwMOmh aHRNLjl3Tn9Qp7mdGQj9DpQVF+fTjBaiZSTSjU429sawXDDZ7EuNkcus5utA7JdK b46CVlcpTbL++ThfXuDrxrBy05qB1QU16H3yu4ZPBcKJKCwwvamWDlRVjmAMC5Kj tC72pqH0DCYufWXW8vSY1SiEonPHDs3XGJ+v36bz84NsoMe2st6ciJazIsAeIfYB fx6b3to7ZHqG7ry0T3SqrBg1naFwa5brHzHgW8rNyWNMMl/+iXq3Aqu5m8xGP41V u/sELfQ8PC3l613ADwcWtcjz5B+ZtP5pEpkG/S56eiT9hTVi0saL3OQY9EjamUqC iFNyZRd6LdRnOS5fJFGTiC5E+BgG0eS8o98E8E7tBydcjC9svRk= =E/Zs -----END PGP SIGNATURE----- --Apple-Mail=_660B4620-685B-4D78-A1C9-31EAE19BFE01-- From nobody Thu Jul 5 06:31:07 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 D57C91277D2; Thu, 5 Jul 2018 06:31:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-lamps-rfc5751-bis@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153079746086.11265.4187169970043321882.idtracker@ietfa.amsl.com> Date: Thu, 05 Jul 2018 06:31:00 -0700 Archived-At: Subject: [lamps] Alissa Cooper's Yes on draft-ietf-lamps-rfc5751-bis-10: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jul 2018 13:31:01 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-lamps-rfc5751-bis-10: Yes 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Appendix B: This is a sentence fragment: "the fact they are no longer considered to be collision resistant the security levels of the signatures are generally considered suspect. also s/that it it/that is it/ From nobody Thu Jul 5 07:04:22 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 00B0C129385; Thu, 5 Jul 2018 07:04:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-lamps-rfc5751-bis@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153079945499.11322.17868589339590763702.idtracker@ietfa.amsl.com> Date: Thu, 05 Jul 2018 07:04:14 -0700 Archived-At: Subject: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jul 2018 14:04:16 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lamps-rfc5751-bis-10: Discuss 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is not necessarily a flaw in the document, I just want to ensure that the decision to use the phrase "for political reasons" to describe a technical decision made in an IETF-stream RFC is a decision that is consciously approved by the IESG. (I could not find any precedent for such a usage.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I suspect it's too late for changing this to be a good idea, but using "authenticated enveloped" and in the same breath talking about how it does not provide proof of origination ("wait, isn't that authentication?), but it does provide "a level of authentication", is kind of confusing for the reader. Could "integrity protection" be used to distinguish the AEAD property from proof-of-origin authentication? Similarly, it might be helpful to use the term "AEAD" before the security considerations section. Should the Abstract/Introduction mention that AEAD encryption provides non-malleability? Section-by-Section comments follow. Section 1 nit: Does FAX need to be all-caps? Section 1.1 In order to create S/MIME messages, an S/MIME agent MUST follow the specifications in this document, as well as the specifications listed in the Cryptographic Message Syntax document [CMS], [RFC3370], [RFC4056], [RFC3560], and [RFC5754]. nit: is that "[CMS] documents" plural? I have been observing growing unease with Postel's Principle over time; it's less clear that blindly repeating it is the best position to take. Section 1.2 BER does not appear to be used in the body text? Section 1.5 I recognize this is historical text, but to modern readers, there is not a single "the AES symmetric encryption algorithm" -- there are CBC modes and GCM modes, and v4.0 distinguishes between them. Should this text get clarified about the difference? Section 2.5.2 The OIDs that correspond to algorithms SHOULD use the same OID as the actual algorithm, except in the case where the algorithm usage is ambiguous from the OID. For instance, in an earlier specification, rsaEncryption was ambiguous because it could refer to either a signature algorithm or a key encipherment algorithm. In the event that an OID is ambiguous, it needs to be arbitrated by the maintainer of the registered SMIMECapabilities list as to which type of algorithm will use the OID, and a new OID MUST be allocated under the smimeCapabilities OID to satisfy the other use of the OID. (nit?) "the other use" implies there will only ever be one other (two total), which is perhaps needlessly limiting. Section 2.7.2 With "Algorithms such as RC2"; "Algorithms such as TripleDES", I'm not sure what to make of "such as" in these statements -- what are the attributes that would qualify for sufficient similarity to match the "such as", other than equality? Section 3.1 In order to protect outer, non-content-related message header fields (for instance, the "Subject", "To", "From", and "Cc" fields), the sending client MAY wrap a full MIME message in a message/rfc822 wrapper in order to apply S/MIME security services to these header fields. It is up to the receiving client to decide how to present this "inner" header along with the unprotected "outer" header. It is RECOMMENDED that a distinction be made between the location of the header. nit: I'm not sure this last sentence is grammatical. Do we want "between the locations", or "a visible distinction be made for the different possible locations of the header", or something else? Section 3.1.2 In the case where S/MIME implementations can determine that all intended recipients are capable of handling inner (all but the outermost) binary MIME objects SHOULD use binary encoding as opposed to a 7-bit-safe transfer encoding for the inner entities. nit: I think that some words got dropped in here; the sentence doesn't really parse. I guess there's a missing "implementations" in "implementations SHOULD use"? Section 3.3 but not signed messages does not provide for data integrity. The Enveloped-Only structure does not support authenticated symmetric algorithms, use the .Authenticated Enveloped structure for these algorithms. [...] nit: Is the '.' in ".Authenticated" correct? (Also, that sentence looks like a comma splice.) Section 3.5.3.2 I agree with Adam that there should be some notation in the table or adjacent to it that some algorithms are present only for historical compatibility and should be considered deprecated/insecure/risky/whatever. Section 6 Some cryptographic algorithms such as RC2 offer little actual security over sending plaintext. Other algorithms such as TripleDES, provide security but are no longer considered to be state of the art. S/MIME requires the use of current state of the art algorithms such as AES and provides the ability to announce starter cryptographic capabilities to parties with whom you communicate. [...] I can't figure out what "starter" means, here. Modification of the ciphertext in EnvelopedData can go undetected if authentication is not also used, which is the case when sending EnvelopedData without wrapping it in SignedData or enclosing SignedData within it. This is one of the reasons for moving from EnvelopedData to AuthEnvelopedData as the authenticated encryption algorithms provide the authentication without needing the SignedData layer. nit: I think a comma before "as the" would help the last sentence. When talking about compression oracles, do we want to explicitly say that a common way to do so is to compress attacker-controlled data in the same corpus as the attacker's target data? mail clients deal with HTML and multipart/mixed messages. Clients MUST require that a text/html content type is a complete HTML document (per [RFC1866]). Clients SHOULD treat each of the different pieces of the multipart/mixed construct as being of different origins. Clients MUST treat each encrypted or signed piece of a MIME message as being of different origins both from unprotected content and from each other. Do we need to cite RFC 6454 for the specific "web origin" concept (as opposed to just the normal English usage of the word)? Appendix B This appendix contains a number of references to documents that have been obsoleted or replaced, this is intentional as frequently the updated documents do not have the same information in them. nit: comma splice Appendix B.2 - Hash functions used to validate signatures on historic messages may longer be considered to be secure. (See below.) While there are not currently any known practical pre-image or second pre- image attacks against MD5 or SHA-1, the fact they are no longer considered to be collision resistant the security levels of the signatures are generally considered suspect. [...] nit: there seems to be (at least) a missing verb in this last sentence. [...] If a message is known to be historic, that it it has been in the possession of the client for some time, then it might still be considered to be secure. nit: maybe "and it has been" From nobody Thu Jul 5 07:23: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 83D18130E2A; Thu, 5 Jul 2018 07:23:37 -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, 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=cooperw.in header.b=xg+04vVZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MYg5M41I 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 9YsvWiCnTno1; Thu, 5 Jul 2018 07:23:33 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EFAE120049; Thu, 5 Jul 2018 07:23:33 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9B1D721D07; Thu, 5 Jul 2018 10:23:32 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 05 Jul 2018 10:23:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=LCJq9v9mygne2G4wdgBWqTbiRAn9Hcnedu+CYt5kIYo=; b=xg+04vVZ vZ/u8A9LOL5Fq/Im4MKbLV+YOAA5sk0m+PnReHvkLPKBGv0rQUv/wEQNfCBoWAfo /zsadPaehEsJ0WdCuB3e+mrE8U1mIpHEWC83FAfdFpi4H4zTBz5Sl6Je6fdIOGTU ApZC4nJPVuNJikWt/xKHjddnJpvrRvzBvuVfUJyggMtoAI3V8WRn8Y66coRu+QDK iHzx3D1QoTmg5gL/FTc9FZyBAZ4zbkFOof47mjcgk3rAkMUPLX1kOozxpPMlteMX oA69iEkuOzytXG8GzEbm/xSpsZhUkCJRTISauexO7ltU9lTU4fK2rhj1LWuNKYIT wftK+sti/9DKqA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=LCJq9v9mygne2G4wdgBWqTbiRAn9H cnedu+CYt5kIYo=; b=MYg5M41IrUcnHqisfF5euzi60A2EGJlFOXu7wFG6fAJG8 1RXh3ARikpUKh7SuX0ku3fgJmmuydEr+Ol8xyKOCd6NVz5X0iRmIj+13jTd1gPWH okBD6ficUbcsO9GK5LhSEIUFbtpWbWemk24hnjY85Ipn4vT9pGsY+vw09kHtwBx6 Tt4tOPLZhaISOhbpk+oGjbei/EhaUzOpexQEHimzExLDQyfyNwEjSKJZqhMEiPLB KiMo2zwboEDj+VEwO0bCYoK6xVLNlt011Ycx4G2rbrGHZKmkUogqIBUsZBFIAUuS RNh5WOdgwtVx3ulqvQGwsu6tyH1VIl5xt2HlMJTBQ== X-ME-Proxy: X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.88]) by mail.messagingengine.com (Postfix) with ESMTPA id CDC8810273; Thu, 5 Jul 2018 10:23:31 -0400 (EDT) From: Alissa Cooper Message-Id: <8F51506C-5FD0-4E43-9165-5941104C260E@cooperw.in> Content-Type: multipart/alternative; boundary="Apple-Mail=_0BD3AA21-C1E9-4016-8002-3048FBF8632D" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Thu, 5 Jul 2018 10:23:30 -0400 In-Reply-To: <052101d3e247$09dd2680$1d977380$@augustcellars.com> Cc: David Schinazi , General Area Review Team , spasm@ietf.org, draft-ietf-lamps-rfc5751-bis.all@ietf.org To: Jim Schaad References: <152480069184.6083.13015201919417586774@ietfa.amsl.com> <052101d3e247$09dd2680$1d977380$@augustcellars.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [lamps] [Gen-art] Genart last call review of draft-ietf-lamps-rfc5751-bis-07 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jul 2018 14:23:38 -0000 --Apple-Mail=_0BD3AA21-C1E9-4016-8002-3048FBF8632D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii David, thanks for your review. Jim, thanks for your response. I entered = a Yes ballot. Alissa > On May 2, 2018, at 2:54 PM, Jim Schaad wrote: >=20 > I have published a -08 with these changes. >=20 >> -----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. >=20 > I have tried to clear this up. The following sentence has been added >=20 > 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 >>=20 >> Nits/editorial comments: >> I believe the RFC2119 reference should also mention RFC8174. >=20 > Done >=20 > Jim >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art = --Apple-Mail=_0BD3AA21-C1E9-4016-8002-3048FBF8632D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii David, thanks for your review. Jim, thanks for your response. = I entered a Yes ballot.

Alissa

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

I have published a -08 with = these changes.

-----Original Message-----
From: David Schinazi <dschinazi@apple.com>
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

Reviewer: = David Schinazi
Review result: Ready

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

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

Summary:
   This document is = clearly written and does a nice job of explaining the
   rationale and historical context of the = decisions it made.

Major issues:
   None noticed during this review

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

          &nb= sp;In order to distribute the symmetric key, a sender needs to have = access to a public key for each intended
          &nb= sp;message recipient to use this service.


Nits/editorial = comments:
   I believe the RFC2119 = reference should also mention RFC8174.

Done

Jim


_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_0BD3AA21-C1E9-4016-8002-3048FBF8632D-- From nobody Thu Jul 5 07:29: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 1454F130E65 for ; Thu, 5 Jul 2018 07:29: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] 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 dpzFx7wDuUJE for ; Thu, 5 Jul 2018 07:29:53 -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 AD994130DE5 for ; Thu, 5 Jul 2018 07:29:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 743E1300A30 for ; Thu, 5 Jul 2018 10:29:51 -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 Ydcbhb3L1Ugu for ; Thu, 5 Jul 2018 10:29:49 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id CEB7D300A20 for ; Thu, 5 Jul 2018 10:29:49 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Thu, 5 Jul 2018 10:29:50 -0400 References: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> To: LAMPS In-Reply-To: <1D329233-AFCE-421B-81FE-EDDC30386260@vigilsec.com> Message-Id: <105D40E2-151B-4335-BEDD-3017B508D579@vigilsec.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [lamps] Potential Topics for LAMPS Recharter X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jul 2018 14:29:56 -0000 Comments on the LAMPS revised charter can be found here: https://datatracker.ietf.org/doc/charter-ietf-lamps/ballot/ I have proposed to the IESG the following text to address these comments. 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 the approach used in RFC 6844. 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 short-lived certificates is unnecessary and 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 mechanism to protect present day communication from the future invention of a large-scale quantum computer. The invention of a large-scale quantum computer poses a serious challenge for the key management algorithms that are widely deployed today, 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). Hash-based signature use small private and public keys, and they have 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; however, sine hash-based signature algorithms are secure even if a large-scale quantum computer is invented. The low computational cost for signature verification makes hash-based signatures attractive in the Internt of Things environments, and the quantum resistance makes them attractive for 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 DONE: Adopt a draft for rfc6844bis DONE: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512 DONE: 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 Thu Jul 5 10:18: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 87CAE130DE1; Thu, 5 Jul 2018 10:18:36 -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 6uJQ91Einy2K; Thu, 5 Jul 2018 10:18:34 -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 774B11274D0; Thu, 5 Jul 2018 10:18:33 -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, 5 Jul 2018 10:14:58 -0700 From: Jim Schaad To: 'Benjamin Kaduk' , 'The IESG' CC: , 'Russ Housley' , , , References: <153079945499.11322.17868589339590763702.idtracker@ietfa.amsl.com> In-Reply-To: <153079945499.11322.17868589339590763702.idtracker@ietfa.amsl.com> Date: Thu, 5 Jul 2018 10:18:04 -0700 Message-ID: <00a901d41484$2494b0f0$6dbe12d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQIi+HNCTYWwO8773Uu0GB5YWNsIoKPi5myA X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jul 2018 17:18:37 -0000 > -----Original Message----- > From: Benjamin Kaduk > Sent: Thursday, July 5, 2018 7:04 AM > To: The IESG > Cc: draft-ietf-lamps-rfc5751-bis@ietf.org; Russ Housley > ; lamps-chairs@ietf.org; housley@vigilsec.com; > spasm@ietf.org > Subject: Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: = (with > DISCUSS and COMMENT) >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-lamps-rfc5751-bis-10: Discuss >=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 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This is not necessarily a flaw in the document, I just want to ensure = that the > decision to use the phrase "for political reasons" to describe a = technical > decision made in an IETF-stream RFC is a decision that is consciously > approved by the IESG. (I could not find any precedent for such a = usage.) >From my point of view this is a "political" decision. To the best of my = knowledge there is nobody who has ever found any technical reason to say = that any of the NIST curves are in any way problematic. Despite the = mistrust by some, they are still required in many situations. =20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I suspect it's too late for changing this to be a good idea, but using > "authenticated enveloped" and in the same breath talking about how it = does > not provide proof of origination ("wait, isn't that authentication?), = but it does > provide "a level of authentication", is kind of confusing for the = reader. Could > "integrity protection" be used to distinguish the AEAD property from = proof- > of-origin authentication? I have lamented in the past that this is was called "authenticated = encryption" rather than "integrity protected encryption" but that ship = has sailed a long time ago. If nothing else the name change would have = reduced the number of times that I needed to explain to people that = authenticated encryption does not imply proof of origination.=20 >=20 > Similarly, it might be helpful to use the term "AEAD" before the = security > considerations section. >=20 > Should the Abstract/Introduction mention that AEAD encryption provides > non-malleability? I don't think that is the correct thing. I would add the following = sentence to the abstract. Authenticated Encryption provides both message integrity and data = confidentiality. >=20 > Section-by-Section comments follow. >=20 > Section 1 >=20 > nit: Does FAX need to be all-caps? Probably not, but that is the was it was and is the way that I normally = use it when not a verb. >=20 > Section 1.1 >=20 > In order to create S/MIME messages, an S/MIME agent MUST follow the > specifications in this document, as well as the specifications = listed > in the Cryptographic Message Syntax document [CMS], [RFC3370], > [RFC4056], [RFC3560], and [RFC5754]. >=20 > nit: is that "[CMS] documents" plural? It depends on what you mean by CMS documents. There is one syntax = document [CMS] and then a number of associated documents which describe = how to use various cryptographic algorithms with CMS. >=20 > I have been observing growing unease with Postel's Principle over = time; it's > less clear that blindly repeating it is the best position to take. And..... >=20 > Section 1.2 >=20 > BER does not appear to be used in the body text? And neither is DER. Not sure that I want to remove them anyway as they = are concepts that people need to understand to talk to others about = ASN.1 and CMS >=20 > Section 1.5 >=20 > I recognize this is historical text, but to modern readers, there is = not a single > "the AES symmetric encryption algorithm" -- there are CBC modes and = GCM > modes, and v4.0 distinguishes between them. Should this text get = clarified > about the difference? I don't believe that this needs to be clarified. But that may be = because of how I approach things thing. The block encryption algorithm = is completely different to me than the mode. =20 >=20 > Section 2.5.2 >=20 > The OIDs that correspond to algorithms SHOULD use the same OID as = the > actual algorithm, except in the case where the algorithm usage is > ambiguous from the OID. For instance, in an earlier specification, > rsaEncryption was ambiguous because it could refer to either a > signature algorithm or a key encipherment algorithm. In the event > that an OID is ambiguous, it needs to be arbitrated by the = maintainer > of the registered SMIMECapabilities list as to which type of > algorithm will use the OID, and a new OID MUST be allocated under = the > smimeCapabilities OID to satisfy the other use of the OID. >=20 > (nit?) "the other use" implies there will only ever be one other (two = total), > which is perhaps needlessly limiting. Given that I cannot think of a case where this a been a problem yet, I = am not too worried about the language possibly being restrictive here. =20 >=20 > Section 2.7.2 >=20 > With "Algorithms such as RC2"; "Algorithms such as TripleDES", I'm not = sure > what to make of "such as" in these statements -- what are the = attributes that > would qualify for sufficient similarity to match the "such as", other = than > equality? I would probably put DES in the same category as RC2 and Camellia in the = same category as TripleDES. The first category is basically - this is = better than nothing but is not secure. The second category is basically = it is not known to be unsecure, but neither is it something that we = recommend as using any more. (In this case 64-bit blocks vs 128-bit = blocks). >=20 > Section 3.1 >=20 > In order to protect outer, non-content-related message header = fields > (for instance, the "Subject", "To", "From", and "Cc" fields), the > sending client MAY wrap a full MIME message in a message/rfc822 > wrapper in order to apply S/MIME security services to these header > fields. It is up to the receiving client to decide how to present > this "inner" header along with the unprotected "outer" header. It = is > RECOMMENDED that a distinction be made between the location of the > header. >=20 > nit: I'm not sure this last sentence is grammatical. Do we want = "between the > locations", or "a visible distinction be made for the different = possible > locations of the header", or something else? See the response to Ben >=20 > Section 3.1.2 >=20 > In the case where S/MIME implementations can determine that all > intended recipients are capable of handling inner (all but the > outermost) binary MIME objects SHOULD use binary encoding as = opposed > to a 7-bit-safe transfer encoding for the inner entities. >=20 > nit: I think that some words got dropped in here; the sentence doesn't = really > parse. I guess there's a missing "implementations" in = "implementations > SHOULD use"? I have no problem with that - fixed. >=20 > Section 3.3 >=20 > but not signed messages does not provide for data integrity. The > Enveloped-Only structure does not support authenticated symmetric > algorithms, use the .Authenticated Enveloped structure for these > algorithms. [...] >=20 > nit: Is the '.' in ".Authenticated" correct? (Also, that sentence = looks like a > comma splice.) Already fixed >=20 > Section 3.5.3.2 >=20 > I agree with Adam that there should be some notation in the table or > adjacent to it that some algorithms are present only for historical > compatibility and should be considered > deprecated/insecure/risky/whatever. Already fixed >=20 > Section 6 >=20 > Some cryptographic algorithms such as RC2 offer little actual > security over sending plaintext. Other algorithms such as = TripleDES, > provide security but are no longer considered to be state of the = art. > S/MIME requires the use of current state of the art algorithms such > as AES and provides the ability to announce starter cryptographic > capabilities to parties with whom you communicate. [...] >=20 > I can't figure out what "starter" means, here. Good question - gone. >=20 > Modification of the ciphertext in EnvelopedData can go undetected = if > authentication is not also used, which is the case when sending > EnvelopedData without wrapping it in SignedData or enclosing > SignedData within it. This is one of the reasons for moving from > EnvelopedData to AuthEnvelopedData as the authenticated encryption > algorithms provide the authentication without needing the = SignedData > layer. >=20 > nit: I think a comma before "as the" would help the last sentence. Done >=20 > When talking about compression oracles, do we want to explicitly say = that a > common way to do so is to compress attacker-controlled data in the = same > corpus as the attacker's target data? >=20 > mail clients deal with HTML and multipart/mixed messages. Clients > MUST require that a text/html content type is a complete HTML > document (per [RFC1866]). Clients SHOULD treat each of the = different > pieces of the multipart/mixed construct as being of different > origins. Clients MUST treat each encrypted or signed piece of a = MIME > message as being of different origins both from unprotected content > and from each other. I put this in as part of a response to EKR's AD review. I will be = honest in that I am completely unsure how one would do a compression = attack as it assumes that you are going to do iterative things which is = not the normal S/MIME way of thinking. Also the fact that almost nobody = has implemented compression is also a factor. >=20 > Do we need to cite RFC 6454 for the specific "web origin" concept (as > opposed to just the normal English usage of the word)? At this point in time I don't know that the idea of "web origin" is = going to match what is needed for S/MIME. I would prefer to punt this = to a new document which addresses the problem directly >=20 > Appendix B >=20 > This appendix contains a number of references to documents that = have > been obsoleted or replaced, this is intentional as frequently the > updated documents do not have the same information in them. >=20 > nit: comma splice Not sure that I agree - but fixed >=20 > Appendix B.2 >=20 > - Hash functions used to validate signatures on historic messages > may longer be considered to be secure. (See below.) While = there > are not currently any known practical pre-image or second pre- > image attacks against MD5 or SHA-1, the fact they are no longer > considered to be collision resistant the security levels of the > signatures are generally considered suspect. [...] >=20 > nit: there seems to be (at least) a missing verb in this last = sentence. While there are not currently any known practical = pre-image or second pre-image attacks against MD5 or SHA&nbhy;1, the = fact they are no longer considered to be collision resistant implies = that the security levels of the signatures are generally considered = suspect. >=20 > [...] If a message is > known to be historic, that it it has been in the possession of = the > client for some time, then it might still be considered to be > secure. >=20 > nit: maybe "and it has been" >=20 Fixed From nobody Thu Jul 5 10: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 6EFDF130F08 for ; Thu, 5 Jul 2018 10:24: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 piNg6fDOf3Hf for ; Thu, 5 Jul 2018 10:24:04 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002: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 72683130DE1 for ; Thu, 5 Jul 2018 10:24:04 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id r3-v6so3509939ybo.4 for ; Thu, 05 Jul 2018 10:24:04 -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=9gL+VCHgmWY3W//glWGuM6Z9jx+T2+BckvoxAZLhWoo=; b=TnRuDvDrOjcjVgaqwGkCc++3WoL1J7H1Agyb/CG6OaKTxlcONMUHlFnjo+MUbYYWqK Wv+ZouZsY2FczuQ/B66UjzWz4265iXCMoZf2eO5072w2xIXbuLikLGYHUfRyXKx9HWJP 1/MA8+wTIEvT814FvUsdH8aUOEl5V/OijupANtngBvhiWCGz3VjjEjyJWzqTVK2KpxV8 6dCnNy9sL9k9g5z+2EKCIhvZbtYyniFkOk2N2XSU+05acbvLt+7dUnIoiqywRZBlTSET FmvxLtlU5vvgILfcQQNveMbiVcliWO2pdfQk1VAaVD5fNAxrL9v2SHCVZpwT5kZNlfIl nyuw== 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=9gL+VCHgmWY3W//glWGuM6Z9jx+T2+BckvoxAZLhWoo=; b=XunjI1vKgsjt7JHfLxl3dBlQ7Yp0I06cB/IL73sIWacBAJnZvuXDwKDFUgronrjJQu Vl9+aCmAqbvYWTtMgsaZ5wStvQ2VM3mRaYSlg2S6RC6udtgYZuHHpYcN6WuM/0iseR+R QABOAb3zdgUwgeu1pbYq2mbFHiQunrtP+KYv27eQCtfU9TlHQYlCpPwCoAju/EgqlOJJ EfPs2RGU6c5JzzSpLYMlDeXWT10VvZvH4++5BBdEVn/8XKW3CKvxrYO/IGNpXMsV3uTV +uQrqPIERsWPYxXSPgOD0rsgo4amvfNOwsF8uNxthC5c38prawL+HbOT1YsHz/7ut1lO fHqQ== X-Gm-Message-State: APt69E02zxOo6OihS4AJmg0NE0O5Hi8D3G2vR3dsNYYhUceSdLJB9zSp 2o8c8kqYbRgVAB+rkkO4/7LVbDVJcVjrMSyxRp/N2Q== X-Google-Smtp-Source: AAOMgpf8NyUebPaT7BSUJGPYefueH7eV6JVAIJp41E7a1TBIC3CzdmY5SlwCzw+oBZm64/F2NYwqnfCHFBAYpQ4ROEo= X-Received: by 2002:a25:3496:: with SMTP id b144-v6mr3729963yba.275.1530811443596; Thu, 05 Jul 2018 10:24:03 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 10:23:23 -0700 (PDT) In-Reply-To: <00a901d41484$2494b0f0$6dbe12d0$@augustcellars.com> References: <153079945499.11322.17868589339590763702.idtracker@ietfa.amsl.com> <00a901d41484$2494b0f0$6dbe12d0$@augustcellars.com> From: Eric Rescorla Date: Thu, 5 Jul 2018 10:23:23 -0700 Message-ID: To: Jim Schaad Cc: Benjamin Kaduk , The IESG , draft-ietf-lamps-rfc5751-bis@ietf.org, lamps-chairs@ietf.org, SPASM , Russ Housley Content-Type: multipart/alternative; boundary="00000000000050658d057043d022" Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jul 2018 17:24:09 -0000 --00000000000050658d057043d022 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 5, 2018 at 10:18 AM, Jim Schaad wrote: > > > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: Thursday, July 5, 2018 7:04 AM > > To: The IESG > > Cc: draft-ietf-lamps-rfc5751-bis@ietf.org; Russ Housley > > ; lamps-chairs@ietf.org; housley@vigilsec.com; > > spasm@ietf.org > > Subject: Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: > (with > > DISCUSS and COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-lamps-rfc5751-bis-10: Discuss > > > > 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.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This is not necessarily a flaw in the document, I just want to ensure > that the > > decision to use the phrase "for political reasons" to describe a > technical > > decision made in an IETF-stream RFC is a decision that is consciously > > approved by the IESG. (I could not find any precedent for such a usage.) > > >From my point of view this is a "political" decision. To the best of my > knowledge there is nobody who has ever found any technical reason to say > that any of the NIST curves are in any way problematic. Despite the > mistrust by some, they are still required in many situations. > What is a political decision? - Supporting the NIST curves? - Supporting the CFRG curves? - Supporting both? -Ekr > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I suspect it's too late for changing this to be a good idea, but using > > "authenticated enveloped" and in the same breath talking about how it > does > > not provide proof of origination ("wait, isn't that authentication?), > but it does > > provide "a level of authentication", is kind of confusing for the > reader. Could > > "integrity protection" be used to distinguish the AEAD property from > proof- > > of-origin authentication? > > I have lamented in the past that this is was called "authenticated > encryption" rather than "integrity protected encryption" but that ship has > sailed a long time ago. If nothing else the name change would have reduced > the number of times that I needed to explain to people that authenticated > encryption does not imply proof of origination. > > > > > Similarly, it might be helpful to use the term "AEAD" before the security > > considerations section. > > > > Should the Abstract/Introduction mention that AEAD encryption provides > > non-malleability? > > I don't think that is the correct thing. I would add the following > sentence to the abstract. > > Authenticated Encryption provides both message integrity and data > confidentiality. > > > > > Section-by-Section comments follow. > > > > Section 1 > > > > nit: Does FAX need to be all-caps? > > Probably not, but that is the was it was and is the way that I normally > use it when not a verb. > > > > > Section 1.1 > > > > In order to create S/MIME messages, an S/MIME agent MUST follow the > > specifications in this document, as well as the specifications listed > > in the Cryptographic Message Syntax document [CMS], [RFC3370], > > [RFC4056], [RFC3560], and [RFC5754]. > > > > nit: is that "[CMS] documents" plural? > > It depends on what you mean by CMS documents. There is one syntax > document [CMS] and then a number of associated documents which describe how > to use various cryptographic algorithms with CMS. > > > > > I have been observing growing unease with Postel's Principle over time; > it's > > less clear that blindly repeating it is the best position to take. > > And..... > > > > > Section 1.2 > > > > BER does not appear to be used in the body text? > > And neither is DER. Not sure that I want to remove them anyway as they > are concepts that people need to understand to talk to others about ASN.1 > and CMS > > > > > Section 1.5 > > > > I recognize this is historical text, but to modern readers, there is not > a single > > "the AES symmetric encryption algorithm" -- there are CBC modes and GCM > > modes, and v4.0 distinguishes between them. Should this text get > clarified > > about the difference? > > I don't believe that this needs to be clarified. But that may be because > of how I approach things thing. The block encryption algorithm is > completely different to me than the mode. > > > > > Section 2.5.2 > > > > The OIDs that correspond to algorithms SHOULD use the same OID as the > > actual algorithm, except in the case where the algorithm usage is > > ambiguous from the OID. For instance, in an earlier specification, > > rsaEncryption was ambiguous because it could refer to either a > > signature algorithm or a key encipherment algorithm. In the event > > that an OID is ambiguous, it needs to be arbitrated by the maintainer > > of the registered SMIMECapabilities list as to which type of > > algorithm will use the OID, and a new OID MUST be allocated under the > > smimeCapabilities OID to satisfy the other use of the OID. > > > > (nit?) "the other use" implies there will only ever be one other (two > total), > > which is perhaps needlessly limiting. > > Given that I cannot think of a case where this a been a problem yet, I am > not too worried about the language possibly being restrictive here. > > > > > Section 2.7.2 > > > > With "Algorithms such as RC2"; "Algorithms such as TripleDES", I'm not > sure > > what to make of "such as" in these statements -- what are the attributes > that > > would qualify for sufficient similarity to match the "such as", other > than > > equality? > > I would probably put DES in the same category as RC2 and Camellia in the > same category as TripleDES. The first category is basically - this is > better than nothing but is not secure. The second category is basically it > is not known to be unsecure, but neither is it something that we recommend > as using any more. (In this case 64-bit blocks vs 128-bit blocks). > > > > > Section 3.1 > > > > In order to protect outer, non-content-related message header fields > > (for instance, the "Subject", "To", "From", and "Cc" fields), the > > sending client MAY wrap a full MIME message in a message/rfc822 > > wrapper in order to apply S/MIME security services to these header > > fields. It is up to the receiving client to decide how to present > > this "inner" header along with the unprotected "outer" header. It is > > RECOMMENDED that a distinction be made between the location of the > > header. > > > > nit: I'm not sure this last sentence is grammatical. Do we want > "between the > > locations", or "a visible distinction be made for the different possible > > locations of the header", or something else? > > See the response to Ben > > > > > Section 3.1.2 > > > > In the case where S/MIME implementations can determine that all > > intended recipients are capable of handling inner (all but the > > outermost) binary MIME objects SHOULD use binary encoding as opposed > > to a 7-bit-safe transfer encoding for the inner entities. > > > > nit: I think that some words got dropped in here; the sentence doesn't > really > > parse. I guess there's a missing "implementations" in "implementations > > SHOULD use"? > > I have no problem with that - fixed. > > > > > Section 3.3 > > > > but not signed messages does not provide for data integrity. The > > Enveloped-Only structure does not support authenticated symmetric > > algorithms, use the .Authenticated Enveloped structure for these > > algorithms. [...] > > > > nit: Is the '.' in ".Authenticated" correct? (Also, that sentence looks > like a > > comma splice.) > > Already fixed > > > > > Section 3.5.3.2 > > > > I agree with Adam that there should be some notation in the table or > > adjacent to it that some algorithms are present only for historical > > compatibility and should be considered > > deprecated/insecure/risky/whatever. > > Already fixed > > > > > Section 6 > > > > Some cryptographic algorithms such as RC2 offer little actual > > security over sending plaintext. Other algorithms such as TripleDES, > > provide security but are no longer considered to be state of the art. > > S/MIME requires the use of current state of the art algorithms such > > as AES and provides the ability to announce starter cryptographic > > capabilities to parties with whom you communicate. [...] > > > > I can't figure out what "starter" means, here. > > Good question - gone. > > > > > Modification of the ciphertext in EnvelopedData can go undetected if > > authentication is not also used, which is the case when sending > > EnvelopedData without wrapping it in SignedData or enclosing > > SignedData within it. This is one of the reasons for moving from > > EnvelopedData to AuthEnvelopedData as the authenticated encryption > > algorithms provide the authentication without needing the SignedData > > layer. > > > > nit: I think a comma before "as the" would help the last sentence. > > Done > > > > > When talking about compression oracles, do we want to explicitly say > that a > > common way to do so is to compress attacker-controlled data in the same > > corpus as the attacker's target data? > > > > mail clients deal with HTML and multipart/mixed messages. Clients > > MUST require that a text/html content type is a complete HTML > > document (per [RFC1866]). Clients SHOULD treat each of the different > > pieces of the multipart/mixed construct as being of different > > origins. Clients MUST treat each encrypted or signed piece of a MIME > > message as being of different origins both from unprotected content > > and from each other. > > I put this in as part of a response to EKR's AD review. I will be honest > in that I am completely unsure how one would do a compression attack as it > assumes that you are going to do iterative things which is not the normal > S/MIME way of thinking. Also the fact that almost nobody has implemented > compression is also a factor. > > > > > Do we need to cite RFC 6454 for the specific "web origin" concept (as > > opposed to just the normal English usage of the word)? > > At this point in time I don't know that the idea of "web origin" is going > to match what is needed for S/MIME. I would prefer to punt this to a new > document which addresses the problem directly > > > > > Appendix B > > > > This appendix contains a number of references to documents that have > > been obsoleted or replaced, this is intentional as frequently the > > updated documents do not have the same information in them. > > > > nit: comma splice > > Not sure that I agree - but fixed > > > > > Appendix B.2 > > > > - Hash functions used to validate signatures on historic messages > > may longer be considered to be secure. (See below.) While there > > are not currently any known practical pre-image or second pre- > > image attacks against MD5 or SHA-1, the fact they are no longer > > considered to be collision resistant the security levels of the > > signatures are generally considered suspect. [...] > > > > nit: there seems to be (at least) a missing verb in this last sentence. > > While there are not currently any known practical pre-image > or second pre-image attacks against MD5 or SHA&nbhy;1, the fact they are no > longer considered to be collision resistant implies that the security > levels of the signatures are generally considered suspect. > > > > > [...] If a message is > > known to be historic, that it it has been in the possession of the > > client for some time, then it might still be considered to be > > secure. > > > > nit: maybe "and it has been" > > > > Fixed > > > > --00000000000050658d057043d022 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jul 5, 2018 at 10:18 AM, Jim Schaad <ietf@augustcellars.c= om> wrote:


> -----Original Message-----
> From: Benjamin Kaduk <kaduk@mit.ed= u>
> Sent: Thursday, July 5, 2018 7:04 AM
> To: The IESG <iesg@ietf.org>= ;
> Cc: draft-iet= f-lamps-rfc5751-bis@ietf.org; Russ Housley
> <housley@vigilsec.com&g= t;; lamps-chairs@ietf.org; housley@vigilsec.com;
> spasm@ietf.org
> Subject: Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-= 10: (with
> DISCUSS and COMMENT)
>
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-lamps-rfc5751-bis-10: Discuss
>
> 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 intr= oductory
> paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/
>
>
>
> ------------------------------------------------------------= ----------
> DISCUSS:
> ------------------------------------------------------------= ----------
>
> This is not necessarily a flaw in the document, I just want to ensure = that the
> decision to use the phrase "for political reasons" to descri= be a technical
> decision made in an IETF-stream RFC is a decision that is consciously<= br> > approved by the IESG.=C2=A0 (I could not find any precedent for such a= usage.)

>From my point of view this is a "political" decis= ion.=C2=A0 To the best of my knowledge there is nobody who has ever found a= ny technical reason to say that any of the NIST curves are in any way probl= ematic.=C2=A0 Despite the mistrust by some, they are still required in many= situations.=C2=A0

What is a political= decision?

- Supporting the NIST curves?
- Supporting the CFRG curves?
- Supporting both?

<= /div>
-Ekr


>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> I suspect it's too late for changing this to be a good idea, but u= sing
> "authenticated enveloped" and in the same breath talking abo= ut how it does
> not provide proof of origination ("wait, isn't that authentic= ation?), but it does
> provide "a level of authentication", is kind of confusing fo= r the reader.=C2=A0 Could
> "integrity protection" be used to distinguish the AEAD prope= rty from proof-
> of-origin authentication?

I have lamented in the past that this is was called "authentica= ted encryption" rather than "integrity protected encryption"= but that ship has sailed a long time ago.=C2=A0 If nothing else the name c= hange would have reduced the number of times that I needed to explain to pe= ople that authenticated encryption does not imply proof of origination.
>
> Similarly, it might be helpful to use the term "AEAD" before= the security
> considerations section.
>
> Should the Abstract/Introduction mention that AEAD encryption provides=
> non-malleability?

I don't think that is the correct thing.=C2=A0 I would add the f= ollowing sentence to the abstract.

Authenticated Encryption provides both message integrity and data confident= iality.

>
> Section-by-Section comments follow.
>
> Section 1
>
> nit: Does FAX need to be all-caps?

Probably not, but that is the was it was and is the way that I norma= lly use it when not a verb.

>
> Section 1.1
>
>=C2=A0 =C2=A0 In order to create S/MIME messages, an S/MIME agent MUST = follow the
>=C2=A0 =C2=A0 specifications in this document, as well as the specifica= tions listed
>=C2=A0 =C2=A0 in the Cryptographic Message Syntax document [CMS], [RFC3= 370],
>=C2=A0 =C2=A0 [RFC4056], [RFC3560], and [RFC5754].
>
> nit: is that "[CMS] documents" plural?

It depends on what you mean by CMS documents.=C2=A0 There is one syn= tax document [CMS] and then a number of associated documents which describe= how to use various cryptographic algorithms with CMS.

>
> I have been observing growing unease with Postel's Principle over = time; it's
> less clear that blindly repeating it is the best position to take.

And.....

>
> Section 1.2
>
> BER does not appear to be used in the body text?

And neither is DER.=C2=A0 Not sure that I want to remove them anyway= as they are concepts that people need to understand to talk to others abou= t ASN.1 and CMS

>
> Section 1.5
>
> I recognize this is historical text, but to modern readers, there is n= ot a single
> "the AES symmetric encryption algorithm" -- there are CBC mo= des and GCM
> modes, and v4.0 distinguishes between them.=C2=A0 Should this text get= clarified
> about the difference?

I don't believe that this needs to be clarified.=C2=A0 But that = may be because of how I approach things thing.=C2=A0 The block encryption a= lgorithm is completely different to me than the mode.=C2=A0

>
> Section 2.5.2
>
>=C2=A0 =C2=A0 The OIDs that correspond to algorithms SHOULD use the sam= e OID as the
>=C2=A0 =C2=A0 actual algorithm, except in the case where the algorithm = usage is
>=C2=A0 =C2=A0 ambiguous from the OID.=C2=A0 For instance, in an earlier= specification,
>=C2=A0 =C2=A0 rsaEncryption was ambiguous because it could refer to eit= her a
>=C2=A0 =C2=A0 signature algorithm or a key encipherment algorithm.=C2= =A0 In the event
>=C2=A0 =C2=A0 that an OID is ambiguous, it needs to be arbitrated by th= e maintainer
>=C2=A0 =C2=A0 of the registered SMIMECapabilities list as to which type= of
>=C2=A0 =C2=A0 algorithm will use the OID, and a new OID MUST be allocat= ed under the
>=C2=A0 =C2=A0 smimeCapabilities OID to satisfy the other use of the OID= .
>
> (nit?) "the other use" implies there will only ever be one o= ther (two total),
> which is perhaps needlessly limiting.

Given that I cannot think of a case where this a been a problem yet,= I am not too worried about the language possibly being restrictive here.= =C2=A0

>
> Section 2.7.2
>
> With "Algorithms such as RC2"; "Algorithms such as Trip= leDES", I'm not sure
> what to make of "such as" in these statements -- what are th= e attributes that
> would qualify for sufficient similarity to match the "such as&quo= t;, other than
> equality?

I would probably put DES in the same category as RC2 and Camellia in= the same category as TripleDES.=C2=A0 The first category is basically - th= is is better than nothing but is not secure.=C2=A0 The second category is b= asically it is not known to be unsecure, but neither is it something that w= e recommend as using any more.=C2=A0 (In this case 64-bit blocks vs 128-bit= blocks).

>
> Section 3.1
>
>=C2=A0 =C2=A0 In order to protect outer, non-content-related message he= ader fields
>=C2=A0 =C2=A0 (for instance, the "Subject", "To", &= quot;From", and "Cc" fields), the
>=C2=A0 =C2=A0 sending client MAY wrap a full MIME message in a message/= rfc822
>=C2=A0 =C2=A0 wrapper in order to apply S/MIME security services to the= se header
>=C2=A0 =C2=A0 fields.=C2=A0 It is up to the receiving client to decide = how to present
>=C2=A0 =C2=A0 this "inner" header along with the unprotected = "outer" header.=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.
>
> nit: I'm not sure this last sentence is grammatical.=C2=A0 Do we w= ant "between the
> locations", or "a visible distinction be made for the differ= ent possible
> locations of the header", or something else?

See the response to Ben

>
> Section 3.1.2
>
>=C2=A0 =C2=A0 In the case where S/MIME implementations can determine th= at all
>=C2=A0 =C2=A0 intended recipients are capable of handling inner (all bu= t the
>=C2=A0 =C2=A0 outermost) binary MIME objects SHOULD use binary encoding= as opposed
>=C2=A0 =C2=A0 to a 7-bit-safe transfer encoding for the inner entities.=
>
> nit: I think that some words got dropped in here; the sentence doesn&#= 39;t really
> parse.=C2=A0 I guess there's a missing "implementations"= in "implementations
> SHOULD use"?

I have no problem with that - fixed.

>
> Section 3.3
>
>=C2=A0 =C2=A0 but not signed messages does not provide for data integri= ty.=C2=A0 The
>=C2=A0 =C2=A0 Enveloped-Only structure does not support authenticated s= ymmetric
>=C2=A0 =C2=A0 algorithms, use the .Authenticated Enveloped structure fo= r these
>=C2=A0 =C2=A0 algorithms.=C2=A0 [...]
>
> nit: Is the '.' in ".Authenticated" correct?=C2=A0 (= Also, that sentence looks like a
> comma splice.)

Already fixed

>
> Section 3.5.3.2
>
> I agree with Adam that there should be some notation in the table or > adjacent to it that some algorithms are present only for historical > compatibility and should be considered
> deprecated/insecure/risky/whatever.

Already fixed

>
> Section 6
>
>=C2=A0 =C2=A0 Some cryptographic algorithms such as RC2 offer little ac= tual
>=C2=A0 =C2=A0 security over sending plaintext.=C2=A0 Other algorithms s= uch as TripleDES,
>=C2=A0 =C2=A0 provide security but are no longer considered to be state= of the art.
>=C2=A0 =C2=A0 S/MIME requires the use of current state of the art algor= ithms such
>=C2=A0 =C2=A0 as AES and provides the ability to announce starter crypt= ographic
>=C2=A0 =C2=A0 capabilities to parties with whom you communicate. [...]<= br> >
> I can't figure out what "starter" means, here.

Good question - gone.

>
>=C2=A0 =C2=A0 Modification of the ciphertext in EnvelopedData can go un= detected if
>=C2=A0 =C2=A0 authentication is not also used, which is the case when s= ending
>=C2=A0 =C2=A0 EnvelopedData without wrapping it in SignedData or enclos= ing
>=C2=A0 =C2=A0 SignedData within it.=C2=A0 This is one of the reasons fo= r moving from
>=C2=A0 =C2=A0 EnvelopedData to AuthEnvelopedData as the authenticated e= ncryption
>=C2=A0 =C2=A0 algorithms provide the authentication without needing the= SignedData
>=C2=A0 =C2=A0 layer.
>
> nit: I think a comma before "as the" would help the last sen= tence.

Done

>
> When talking about compression oracles, do we want to explicitly say t= hat a
> common way to do so is to compress attacker-controlled data in the sam= e
> corpus as the attacker's target data?
>
>=C2=A0 =C2=A0 mail clients deal with HTML and multipart/mixed messages.= =C2=A0 Clients
>=C2=A0 =C2=A0 MUST require that a text/html content type is a complete = HTML
>=C2=A0 =C2=A0 document (per [RFC1866]).=C2=A0 Clients SHOULD treat each= of the different
>=C2=A0 =C2=A0 pieces of the multipart/mixed construct as being of diffe= rent
>=C2=A0 =C2=A0 origins.=C2=A0 Clients MUST treat each encrypted or signe= d piece of a MIME
>=C2=A0 =C2=A0 message as being of different origins both from unprotect= ed content
>=C2=A0 =C2=A0 and from each other.

I put this in as part of a response to EKR's AD review.=C2=A0 I = will be honest in that I am completely unsure how one would do a compressio= n attack as it assumes that you are going to do iterative things which is n= ot the normal S/MIME way of thinking.=C2=A0 Also the fact that almost nobod= y has implemented compression is also a factor.

>
> Do we need to cite RFC 6454 for the specific "web origin" co= ncept (as
> opposed to just the normal English usage of the word)?

At this point in time I don't know that the idea of "web or= igin" is going to match what is needed for S/MIME.=C2=A0 I would prefe= r to punt this to a new document which addresses the problem directly

>
> Appendix B
>
>=C2=A0 =C2=A0 This appendix contains a number of references to document= s that have
>=C2=A0 =C2=A0 been obsoleted or replaced, this is intentional as freque= ntly the
>=C2=A0 =C2=A0 updated documents do not have the same information in the= m.
>
> nit: comma splice

Not sure that I agree - but fixed

>
> Appendix B.2
>
>=C2=A0 =C2=A0 -=C2=A0 Hash functions used to validate signatures on his= toric messages
>=C2=A0 =C2=A0 =C2=A0 =C2=A0may longer be considered to be secure.=C2=A0= (See below.)=C2=A0 While there
>=C2=A0 =C2=A0 =C2=A0 =C2=A0are not currently any known practical pre-im= age or second pre-
>=C2=A0 =C2=A0 =C2=A0 =C2=A0image attacks against MD5 or SHA-1, the fact= they are no longer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0considered to be collision resistant the sec= urity levels of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0signatures are generally considered suspect.= =C2=A0 [...]
>
> nit: there seems to be (at least) a missing verb in this last sentence= .

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 While there are not= currently any known practical pre-image or second pre-image attacks agains= t MD5 or SHA&nbhy;1, the fact they are no longer considered to be colli= sion resistant implies that the security levels of the signatures are gener= ally considered suspect.

>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[...] If a message is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0known to be historic, that it it has been in= the possession of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0client for some time, then it might still be= considered to be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0secure.
>
> nit: maybe "and it has been"
>

Fixed




--00000000000050658d057043d022-- From nobody Thu Jul 5 10:50: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 A6ADD130EA5; Thu, 5 Jul 2018 10:50:40 -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 D-CKEcvjnUIl; Thu, 5 Jul 2018 10:50:33 -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 F0B36130F14; Thu, 5 Jul 2018 10:50:32 -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, 5 Jul 2018 10:47:15 -0700 From: Jim Schaad To: 'Eric Rescorla' CC: 'Benjamin Kaduk' , 'The IESG' , , , 'SPASM' , 'Russ Housley' References: <153079945499.11322.17868589339590763702.idtracker@ietfa.amsl.com> <00a901d41484$2494b0f0$6dbe12d0$@augustcellars.com> In-Reply-To: Date: Thu, 5 Jul 2018 10:50:21 -0700 Message-ID: <00ac01d41488$a71cfe70$f556fb50$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AD_01D4144D.FAC02240" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQIi+HNCTYWwO8773Uu0GB5YWNsIoAJRu5EBAdQwKyajwfDCQA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jul 2018 17:50:41 -0000 ------=_NextPart_000_00AD_01D4144D.FAC02240 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Eric Rescorla =20 Sent: Thursday, July 5, 2018 10:23 AM To: Jim Schaad Cc: Benjamin Kaduk ; The IESG ; = draft-ietf-lamps-rfc5751-bis@ietf.org; lamps-chairs@ietf.org; SPASM = ; Russ Housley Subject: Re: Benjamin Kaduk's Discuss on = draft-ietf-lamps-rfc5751-bis-10: (with DISCUSS and COMMENT) =20 =20 =20 On Thu, Jul 5, 2018 at 10:18 AM, Jim Schaad > wrote: > -----Original Message----- > From: Benjamin Kaduk > > Sent: Thursday, July 5, 2018 7:04 AM > To: The IESG > > Cc: draft-ietf-lamps-rfc5751-bis@ietf.org = ; Russ Housley > >; = lamps-chairs@ietf.org ; = housley@vigilsec.com ; > spasm@ietf.org =20 > Subject: Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: = (with > DISCUSS and COMMENT) >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-lamps-rfc5751-bis-10: Discuss >=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 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This is not necessarily a flaw in the document, I just want to ensure = that the > decision to use the phrase "for political reasons" to describe a = technical > decision made in an IETF-stream RFC is a decision that is consciously > approved by the IESG. (I could not find any precedent for such a = usage.) >From my point of view this is a "political" decision. To the best of = my knowledge there is nobody who has ever found any technical reason to = say that any of the NIST curves are in any way problematic. Despite the = mistrust by some, they are still required in many situations. =20 =20 What is a political decision? =20 - Supporting the NIST curves? - Supporting the CFRG curves? - Supporting both? =20 -Ekr =20 [JLS] Do you remove the NIST curves or at least demote the requirements = to implement them as there are people who believe that they are not = secure. =20 Jim =20 =20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I suspect it's too late for changing this to be a good idea, but using > "authenticated enveloped" and in the same breath talking about how it = does > not provide proof of origination ("wait, isn't that authentication?), = but it does > provide "a level of authentication", is kind of confusing for the = reader. Could > "integrity protection" be used to distinguish the AEAD property from = proof- > of-origin authentication? I have lamented in the past that this is was called "authenticated = encryption" rather than "integrity protected encryption" but that ship = has sailed a long time ago. If nothing else the name change would have = reduced the number of times that I needed to explain to people that = authenticated encryption does not imply proof of origination.=20 >=20 > Similarly, it might be helpful to use the term "AEAD" before the = security > considerations section. >=20 > Should the Abstract/Introduction mention that AEAD encryption provides > non-malleability? I don't think that is the correct thing. I would add the following = sentence to the abstract. Authenticated Encryption provides both message integrity and data = confidentiality. >=20 > Section-by-Section comments follow. >=20 > Section 1 >=20 > nit: Does FAX need to be all-caps? Probably not, but that is the was it was and is the way that I normally = use it when not a verb. >=20 > Section 1.1 >=20 > In order to create S/MIME messages, an S/MIME agent MUST follow the > specifications in this document, as well as the specifications = listed > in the Cryptographic Message Syntax document [CMS], [RFC3370], > [RFC4056], [RFC3560], and [RFC5754]. >=20 > nit: is that "[CMS] documents" plural? It depends on what you mean by CMS documents. There is one syntax = document [CMS] and then a number of associated documents which describe = how to use various cryptographic algorithms with CMS. >=20 > I have been observing growing unease with Postel's Principle over = time; it's > less clear that blindly repeating it is the best position to take. And..... >=20 > Section 1.2 >=20 > BER does not appear to be used in the body text? And neither is DER. Not sure that I want to remove them anyway as they = are concepts that people need to understand to talk to others about = ASN.1 and CMS >=20 > Section 1.5 >=20 > I recognize this is historical text, but to modern readers, there is = not a single > "the AES symmetric encryption algorithm" -- there are CBC modes and = GCM > modes, and v4.0 distinguishes between them. Should this text get = clarified > about the difference? I don't believe that this needs to be clarified. But that may be = because of how I approach things thing. The block encryption algorithm = is completely different to me than the mode. =20 >=20 > Section 2.5.2 >=20 > The OIDs that correspond to algorithms SHOULD use the same OID as = the > actual algorithm, except in the case where the algorithm usage is > ambiguous from the OID. For instance, in an earlier specification, > rsaEncryption was ambiguous because it could refer to either a > signature algorithm or a key encipherment algorithm. In the event > that an OID is ambiguous, it needs to be arbitrated by the = maintainer > of the registered SMIMECapabilities list as to which type of > algorithm will use the OID, and a new OID MUST be allocated under = the > smimeCapabilities OID to satisfy the other use of the OID. >=20 > (nit?) "the other use" implies there will only ever be one other (two = total), > which is perhaps needlessly limiting. Given that I cannot think of a case where this a been a problem yet, I = am not too worried about the language possibly being restrictive here. =20 >=20 > Section 2.7.2 >=20 > With "Algorithms such as RC2"; "Algorithms such as TripleDES", I'm not = sure > what to make of "such as" in these statements -- what are the = attributes that > would qualify for sufficient similarity to match the "such as", other = than > equality? I would probably put DES in the same category as RC2 and Camellia in the = same category as TripleDES. The first category is basically - this is = better than nothing but is not secure. The second category is basically = it is not known to be unsecure, but neither is it something that we = recommend as using any more. (In this case 64-bit blocks vs 128-bit = blocks). >=20 > Section 3.1 >=20 > In order to protect outer, non-content-related message header = fields > (for instance, the "Subject", "To", "From", and "Cc" fields), the > sending client MAY wrap a full MIME message in a message/rfc822 > wrapper in order to apply S/MIME security services to these header > fields. It is up to the receiving client to decide how to present > this "inner" header along with the unprotected "outer" header. It = is > RECOMMENDED that a distinction be made between the location of the > header. >=20 > nit: I'm not sure this last sentence is grammatical. Do we want = "between the > locations", or "a visible distinction be made for the different = possible > locations of the header", or something else? See the response to Ben >=20 > Section 3.1.2 >=20 > In the case where S/MIME implementations can determine that all > intended recipients are capable of handling inner (all but the > outermost) binary MIME objects SHOULD use binary encoding as = opposed > to a 7-bit-safe transfer encoding for the inner entities. >=20 > nit: I think that some words got dropped in here; the sentence doesn't = really > parse. I guess there's a missing "implementations" in = "implementations > SHOULD use"? I have no problem with that - fixed. >=20 > Section 3.3 >=20 > but not signed messages does not provide for data integrity. The > Enveloped-Only structure does not support authenticated symmetric > algorithms, use the .Authenticated Enveloped structure for these > algorithms. [...] >=20 > nit: Is the '.' in ".Authenticated" correct? (Also, that sentence = looks like a > comma splice.) Already fixed >=20 > Section 3.5.3.2 >=20 > I agree with Adam that there should be some notation in the table or > adjacent to it that some algorithms are present only for historical > compatibility and should be considered > deprecated/insecure/risky/whatever. Already fixed >=20 > Section 6 >=20 > Some cryptographic algorithms such as RC2 offer little actual > security over sending plaintext. Other algorithms such as = TripleDES, > provide security but are no longer considered to be state of the = art. > S/MIME requires the use of current state of the art algorithms such > as AES and provides the ability to announce starter cryptographic > capabilities to parties with whom you communicate. [...] >=20 > I can't figure out what "starter" means, here. Good question - gone. >=20 > Modification of the ciphertext in EnvelopedData can go undetected = if > authentication is not also used, which is the case when sending > EnvelopedData without wrapping it in SignedData or enclosing > SignedData within it. This is one of the reasons for moving from > EnvelopedData to AuthEnvelopedData as the authenticated encryption > algorithms provide the authentication without needing the = SignedData > layer. >=20 > nit: I think a comma before "as the" would help the last sentence. Done >=20 > When talking about compression oracles, do we want to explicitly say = that a > common way to do so is to compress attacker-controlled data in the = same > corpus as the attacker's target data? >=20 > mail clients deal with HTML and multipart/mixed messages. Clients > MUST require that a text/html content type is a complete HTML > document (per [RFC1866]). Clients SHOULD treat each of the = different > pieces of the multipart/mixed construct as being of different > origins. Clients MUST treat each encrypted or signed piece of a = MIME > message as being of different origins both from unprotected content > and from each other. I put this in as part of a response to EKR's AD review. I will be = honest in that I am completely unsure how one would do a compression = attack as it assumes that you are going to do iterative things which is = not the normal S/MIME way of thinking. Also the fact that almost nobody = has implemented compression is also a factor. >=20 > Do we need to cite RFC 6454 for the specific "web origin" concept (as > opposed to just the normal English usage of the word)? At this point in time I don't know that the idea of "web origin" is = going to match what is needed for S/MIME. I would prefer to punt this = to a new document which addresses the problem directly >=20 > Appendix B >=20 > This appendix contains a number of references to documents that = have > been obsoleted or replaced, this is intentional as frequently the > updated documents do not have the same information in them. >=20 > nit: comma splice Not sure that I agree - but fixed >=20 > Appendix B.2 >=20 > - Hash functions used to validate signatures on historic messages > may longer be considered to be secure. (See below.) While = there > are not currently any known practical pre-image or second pre- > image attacks against MD5 or SHA-1, the fact they are no longer > considered to be collision resistant the security levels of the > signatures are generally considered suspect. [...] >=20 > nit: there seems to be (at least) a missing verb in this last = sentence. While there are not currently any known practical = pre-image or second pre-image attacks against MD5 or SHA&nbhy;1, the = fact they are no longer considered to be collision resistant implies = that the security levels of the signatures are generally considered = suspect. >=20 > [...] If a message is > known to be historic, that it it has been in the possession of = the > client for some time, then it might still be considered to be > secure. >=20 > nit: maybe "and it has been" >=20 Fixed =20 ------=_NextPart_000_00AD_01D4144D.FAC02240 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Eric = Rescorla <ekr@rtfm.com>
Sent: Thursday, July 5, 2018 = 10:23 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: Benjamin Kaduk = <kaduk@mit.edu>; The IESG <iesg@ietf.org>; = draft-ietf-lamps-rfc5751-bis@ietf.org; lamps-chairs@ietf.org; SPASM = <spasm@ietf.org>; Russ Housley = <housley@vigilsec.com>
Subject: Re: Benjamin Kaduk's = Discuss on draft-ietf-lamps-rfc5751-bis-10: (with DISCUSS and = COMMENT)

 

 

 

On Thu, = Jul 5, 2018 at 10:18 AM, Jim Schaad <ietf@augustcellars.com> = wrote:



> -----Original = Message-----
> From: Benjamin Kaduk <kaduk@mit.edu>
> Sent: = Thursday, July 5, 2018 7:04 AM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-lamps-rf= c5751-bis@ietf.org; Russ Housley
> <housley@vigilsec.com>; lamps-chairs@ietf.org; housley@vigilsec.com;
> = spasm@ietf.org
> Subject: = Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: = (with
> DISCUSS and COMMENT)
>
> Benjamin Kaduk has = entered the following ballot position for
> = draft-ietf-lamps-rfc5751-bis-10: Discuss
>
> 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.)
>
> =
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml
> for more information about IESG DISCUSS and COMMENT = positions.
>
>
> The document, along with other = ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc57= 51-bis/
>
>
>
> = ----------------------------------------------------------------------> DISCUSS:
> = ---------------------------------------------------------------------->
> This is not necessarily a flaw in the document, I just = want to ensure that the
> decision to use the phrase "for = political reasons" to describe a technical
> decision made in = an IETF-stream RFC is a decision that is consciously
> approved by = the IESG.  (I could not find any precedent for such a = usage.)

>From my point = of view this is a "political" decision.  To the best of = my knowledge there is nobody who has ever found any technical reason to = say that any of the NIST curves are in any way problematic.  = Despite the mistrust by some, they are still required in many = situations. 

 

What is a political = decision?

 

- = Supporting the NIST curves?

- Supporting the CFRG = curves?

- Supporting = both?

 

-Ekr

 

[JLS]=C2=A0 = Do you remove the NIST curves or at least demote the requirements to = implement them as there are people who believe that they are not = secure.

 

Jim

 

 


>
>
> = ----------------------------------------------------------------------> COMMENT:
> = ---------------------------------------------------------------------->
> I suspect it's too late for changing this to be a good = idea, but using
> "authenticated enveloped" and in the = same breath talking about how it does
> not provide proof of = origination ("wait, isn't that authentication?), but it = does
> provide "a level of authentication", is kind of = confusing for the reader.  Could
> "integrity = protection" be used to distinguish the AEAD property from = proof-
> of-origin authentication?

I have lamented in the = past that this is was called "authenticated encryption" rather = than "integrity protected encryption" but that ship has sailed = a long time ago.  If nothing else the name change would have = reduced the number of times that I needed to explain to people that = authenticated encryption does not imply proof of origination. =

>
> Similarly, it might be helpful to use the term = "AEAD" before the security
> considerations = section.
>
> Should the Abstract/Introduction mention that = AEAD encryption provides
> non-malleability?

I don't think = that is the correct thing.  I would add the following sentence to = the abstract.

Authenticated Encryption provides both message = integrity and data confidentiality.

>
> = Section-by-Section comments follow.
>
> Section 1
> =
> nit: Does FAX need to be all-caps?

Probably not, but = that is the was it was and is the way that I normally use it when not a = verb.

>
> Section 1.1
>
>    In = order to create S/MIME messages, an S/MIME agent MUST follow = the
>    specifications in this document, as well as the = specifications listed
>    in the Cryptographic Message = Syntax document [CMS], [RFC3370],
>    [RFC4056], = [RFC3560], and [RFC5754].
>
> nit: is that "[CMS] = documents" plural?

It depends on what you mean by CMS = documents.  There is one syntax document [CMS] and then a number of = associated documents which describe how to use various cryptographic = algorithms with CMS.

>
> I have been observing growing = unease with Postel's Principle over time; it's
> less clear that = blindly repeating it is the best position to = take.

And.....

>
> Section 1.2
>
> = BER does not appear to be used in the body text?

And neither is = DER.  Not sure that I want to remove them anyway as they are = concepts that people need to understand to talk to others about ASN.1 = and CMS

>
> Section 1.5
>
> I recognize = this is historical text, but to modern readers, there is not a = single
> "the AES symmetric encryption algorithm" -- = there are CBC modes and GCM
> modes, and v4.0 distinguishes = between them.  Should this text get clarified
> about the = difference?

I don't believe that this needs to be = clarified.  But that may be because of how I approach things = thing.  The block encryption algorithm is completely different to = me than the mode. 

>
> Section 2.5.2
> =
>    The OIDs that correspond to algorithms SHOULD use = the same OID as the
>    actual algorithm, except in the = case where the algorithm usage is
>    ambiguous from = the OID.  For instance, in an earlier specification,
>  =   rsaEncryption was ambiguous because it could refer to either = a
>    signature algorithm or a key encipherment = algorithm.  In the event
>    that an OID is = ambiguous, it needs to be arbitrated by the maintainer
>  =   of the registered SMIMECapabilities list as to which type = of
>    algorithm will use the OID, and a new OID MUST = be allocated under the
>    smimeCapabilities OID to = satisfy the other use of the OID.
>
> (nit?) "the = other use" implies there will only ever be one other (two = total),
> which is perhaps needlessly limiting.

Given that = I cannot think of a case where this a been a problem yet, I am not too = worried about the language possibly being restrictive here.  =

>
> Section 2.7.2
>
> With = "Algorithms such as RC2"; "Algorithms such as = TripleDES", I'm not sure
> what to make of "such = as" in these statements -- what are the attributes that
> = would qualify for sufficient similarity to match the "such = as", other than
> equality?

I would probably put DES = in the same category as RC2 and Camellia in the same category as = TripleDES.  The first category is basically - this is better than = nothing but is not secure.  The second category is basically it is = not known to be unsecure, but neither is it something that we recommend = as using any more.  (In this case 64-bit blocks vs 128-bit = blocks).

>
> Section 3.1
>
>    = In order to protect outer, non-content-related message header = fields
>    (for instance, the "Subject", = "To", "From", and "Cc" fields), = the
>    sending client MAY wrap a full MIME message in = a message/rfc822
>    wrapper in order to apply S/MIME = security services to these header
>    fields.  It = is up to the receiving client to decide how to present
>  =   this "inner" header along with the unprotected = "outer" header.  It is
>    RECOMMENDED = that a distinction be made between the location of the
>  =   header.
>
> nit: I'm not sure this last sentence is = grammatical.  Do we want "between the
> locations", = or "a visible distinction be made for the different = possible
> locations of the header", or something = else?

See the response to Ben

>
> Section = 3.1.2
>
>    In the case where S/MIME = implementations can determine that all
>    intended = recipients are capable of handling inner (all but the
>  =   outermost) binary MIME objects SHOULD use binary encoding as = opposed
>    to a 7-bit-safe transfer encoding for the = inner entities.
>
> nit: I think that some words got = dropped in here; the sentence doesn't really
> parse.  I = guess there's a missing "implementations" in = "implementations
> SHOULD use"?

I have no problem = with that - fixed.

>
> Section 3.3
> =
>    but not signed messages does not provide for data = integrity.  The
>    Enveloped-Only structure does = not support authenticated symmetric
>    algorithms, use = the .Authenticated Enveloped structure for these
>    = algorithms.  [...]
>
> nit: Is the '.' in = ".Authenticated" correct?  (Also, that sentence looks = like a
> comma splice.)

Already fixed

>
> = Section 3.5.3.2
>
> I agree with Adam that there should be = some notation in the table or
> adjacent to it that some = algorithms are present only for historical
> compatibility and = should be considered
> = deprecated/insecure/risky/whatever.

Already fixed

> =
> Section 6
>
>    Some cryptographic = algorithms such as RC2 offer little actual
>    security = over sending plaintext.  Other algorithms such as = TripleDES,
>    provide security but are no longer = considered to be state of the art.
>    S/MIME requires = the use of current state of the art algorithms such
>    = as AES and provides the ability to announce starter = cryptographic
>    capabilities to parties with whom you = communicate. [...]
>
> I can't figure out what = "starter" means, here.

Good question - = gone.

>
>    Modification of the ciphertext = in EnvelopedData can go undetected if
>    = authentication is not also used, which is the case when = sending
>    EnvelopedData without wrapping it in = SignedData or enclosing
>    SignedData within it.  = This is one of the reasons for moving from
>    = EnvelopedData to AuthEnvelopedData as the authenticated = encryption
>    algorithms provide the authentication = without needing the SignedData
>    layer.
> =
> nit: I think a comma before "as the" would help the = last sentence.

Done

>
> When talking about = compression oracles, do we want to explicitly say that a
> common = way to do so is to compress attacker-controlled data in the same
> = corpus as the attacker's target data?
>
>    mail = clients deal with HTML and multipart/mixed messages.  = Clients
>    MUST require that a text/html content type = is a complete HTML
>    document (per [RFC1866]).  = Clients SHOULD treat each of the different
>    pieces = of the multipart/mixed construct as being of different
>  =   origins.  Clients MUST treat each encrypted or signed piece = of a MIME
>    message as being of different origins = both from unprotected content
>    and from each = other.

I put this in as part of a response to EKR's AD = review.  I will be honest in that I am completely unsure how one = would do a compression attack as it assumes that you are going to do = iterative things which is not the normal S/MIME way of thinking.  = Also the fact that almost nobody has implemented compression is also a = factor.

>
> Do we need to cite RFC 6454 for the = specific "web origin" concept (as
> opposed to just the = normal English usage of the word)?

At this point in time I don't = know that the idea of "web origin" is going to match what is = needed for S/MIME.  I would prefer to punt this to a new document = which addresses the problem directly

>
> Appendix = B
>
>    This appendix contains a number of = references to documents that have
>    been obsoleted or = replaced, this is intentional as frequently the
>    = updated documents do not have the same information in them.
> =
> nit: comma splice

Not sure that I agree - but = fixed

>
> Appendix B.2
>
>    = -  Hash functions used to validate signatures on historic = messages
>       may longer be considered to = be secure.  (See below.)  While there
>    =    are not currently any known practical pre-image or second = pre-
>       image attacks against MD5 or = SHA-1, the fact they are no longer
>      =  considered to be collision resistant the security levels of = the
>       signatures are generally = considered suspect.  [...]
>
> nit: there seems to be = (at least) a missing verb in this last sentence.

    =           While there are not currently any = known practical pre-image or second pre-image attacks against MD5 or = SHA&nbhy;1, the fact they are no longer considered to be collision = resistant implies that the security levels of the signatures are = generally considered suspect.

>
>      =  [...] If a message is
>       known to = be historic, that it it has been in the possession of the
>  =      client for some time, then it might still be = considered to be
>       secure.
> =
> nit: maybe "and it has been"
> =

Fixed


 

------=_NextPart_000_00AD_01D4144D.FAC02240-- From nobody Thu Jul 5 11:24: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 2B682130F32 for ; Thu, 5 Jul 2018 11:24:35 -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 GaSNWGn05Hk0 for ; Thu, 5 Jul 2018 11:24:30 -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 D7458130F1D for ; Thu, 5 Jul 2018 11:24:29 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id j68-v6so3297199ywg.1 for ; Thu, 05 Jul 2018 11:24:29 -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=KnF7BBTUsFzDJIu9P12EaqE3NYFKtedBQ59bskFk23Y=; b=cLGur1iFvadmN4Hg/ibx1Eeh9xlsvZ7l7cfUWKVFQPgCwlgSg+dpAnjUoxCAK3VPwP NIq3HicdpJ3otYLCzLDDL4e1EbImRwxyRtRvee6ZLquG16dH5Jv2peQXDYwjMmSOXf5T +CvQ3hUn7hq5yJmSN/+vJYg4wZV42s9pr0KmGjewTRGisVEGBLGq6Z35k8K7x3jBg27h bq466ntfL0bCRTKA2CS9l/k5SjnR0N9z1llwVD5/ZAs336cppw9ubWFLzz/cpp/ZTmme cNKh2n1XmQYqnSNkmBY2xqyriOW/IFUBaeK0+s3qlGxJ6YYFbPz25gLRUN3WHXvimKEO KNaw== 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=KnF7BBTUsFzDJIu9P12EaqE3NYFKtedBQ59bskFk23Y=; b=lKsbr6OzVx7S4tMF/iLGwbzQBJtkgmiaBrT34bWWMk+EwYh4xKaksVWmFJna9Cf57l JhILL+7C17Uz4O+SdduMfQY9UI5oWPbzVHAju0Sb306YuMeTd5Gkix0MJjw7qU4FNlSX 3+AReK6fyl9UVdcUOJkvmUDEQC8Fr6kVJQYMAUSAIGYsGOIEdJTkVc8bEsq8vlaHpvzh vB/NswQB9NfNLjQ94Wr8MWUMP+F3lTM2XlBkFBzslcSzG7EvObbomrfUrTJdqFJDhVsZ UBwRNGdAgA/C41XQfuciQ61THLyROxwDqI5wukvEYr0oHJmQvNSAkc8P5h30pBO+YphL 25sw== X-Gm-Message-State: APt69E2bjwcj4cTNiisG7RtIN/sYJ35zTXXCakl7+HOb2X7yBArkwR02 vHP8ON5XOvx1kyL844o++AYL5/k0bK9b+G7JhnNOfw== X-Google-Smtp-Source: AAOMgpdKbkaWpyBhq8hKL2pOw2MrnJFhxJV8ipk8dQNnZiOtpU4I7KeBG1gpy7PmyKpBtjYIINsgPvaxMfKl1a8YYxg= X-Received: by 2002:a81:a9c4:: with SMTP id g187-v6mr1083035ywh.238.1530815068885; Thu, 05 Jul 2018 11:24:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 11:23:48 -0700 (PDT) In-Reply-To: <00ac01d41488$a71cfe70$f556fb50$@augustcellars.com> References: <153079945499.11322.17868589339590763702.idtracker@ietfa.amsl.com> <00a901d41484$2494b0f0$6dbe12d0$@augustcellars.com> <00ac01d41488$a71cfe70$f556fb50$@augustcellars.com> From: Eric Rescorla Date: Thu, 5 Jul 2018 11:23:48 -0700 Message-ID: To: Jim Schaad Cc: Benjamin Kaduk , The IESG , draft-ietf-lamps-rfc5751-bis@ietf.org, lamps-chairs@ietf.org, SPASM , Russ Housley Content-Type: multipart/alternative; boundary="00000000000065f1e1057044a8bd" Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jul 2018 18:24:36 -0000 --00000000000065f1e1057044a8bd Content-Type: text/plain; charset="UTF-8" Sorry, I'm still confused. I believe that standard IETF policy is to prefer the CFRG curves going forward, with protocols needing various levels of support for the NIST curves. I think that that's uncontroversial and only depends on the fact that the CFRG curves are more modern, but there are environments where the NIST curves are needed. I guess any point in this space is political in the sense that it's more about balancing competing interests than any particular technical decision, but lots of things are like that. What makes this special? As a side note, who actually is claiming that the NIST curves aren't secure? -Ekr On Thu, Jul 5, 2018 at 10:50 AM, Jim Schaad wrote: > > > > > *From:* Eric Rescorla > *Sent:* Thursday, July 5, 2018 10:23 AM > *To:* Jim Schaad > *Cc:* Benjamin Kaduk ; The IESG ; > draft-ietf-lamps-rfc5751-bis@ietf.org; lamps-chairs@ietf.org; SPASM < > spasm@ietf.org>; Russ Housley > *Subject:* Re: Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: > (with DISCUSS and COMMENT) > > > > > > > > On Thu, Jul 5, 2018 at 10:18 AM, Jim Schaad > wrote: > > > > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: Thursday, July 5, 2018 7:04 AM > > To: The IESG > > Cc: draft-ietf-lamps-rfc5751-bis@ietf.org; Russ Housley > > ; lamps-chairs@ietf.org; housley@vigilsec.com; > > spasm@ietf.org > > Subject: Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: > (with > > DISCUSS and COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-lamps-rfc5751-bis-10: Discuss > > > > 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.) > > > > > > Please refer to https://www.ietf.org/iesg/stat > ement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This is not necessarily a flaw in the document, I just want to ensure > that the > > decision to use the phrase "for political reasons" to describe a > technical > > decision made in an IETF-stream RFC is a decision that is consciously > > approved by the IESG. (I could not find any precedent for such a usage.) > > >From my point of view this is a "political" decision. To the best of my > knowledge there is nobody who has ever found any technical reason to say > that any of the NIST curves are in any way problematic. Despite the > mistrust by some, they are still required in many situations. > > > > What is a political decision? > > > > - Supporting the NIST curves? > > - Supporting the CFRG curves? > > - Supporting both? > > > > -Ekr > > > > [JLS] Do you remove the NIST curves or at least demote the requirements > to implement them as there are people who believe that they are not secure. > > > > Jim > > > > > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I suspect it's too late for changing this to be a good idea, but using > > "authenticated enveloped" and in the same breath talking about how it > does > > not provide proof of origination ("wait, isn't that authentication?), > but it does > > provide "a level of authentication", is kind of confusing for the > reader. Could > > "integrity protection" be used to distinguish the AEAD property from > proof- > > of-origin authentication? > > I have lamented in the past that this is was called "authenticated > encryption" rather than "integrity protected encryption" but that ship has > sailed a long time ago. If nothing else the name change would have reduced > the number of times that I needed to explain to people that authenticated > encryption does not imply proof of origination. > > > > > Similarly, it might be helpful to use the term "AEAD" before the security > > considerations section. > > > > Should the Abstract/Introduction mention that AEAD encryption provides > > non-malleability? > > I don't think that is the correct thing. I would add the following > sentence to the abstract. > > Authenticated Encryption provides both message integrity and data > confidentiality. > > > > > Section-by-Section comments follow. > > > > Section 1 > > > > nit: Does FAX need to be all-caps? > > Probably not, but that is the was it was and is the way that I normally > use it when not a verb. > > > > > Section 1.1 > > > > In order to create S/MIME messages, an S/MIME agent MUST follow the > > specifications in this document, as well as the specifications listed > > in the Cryptographic Message Syntax document [CMS], [RFC3370], > > [RFC4056], [RFC3560], and [RFC5754]. > > > > nit: is that "[CMS] documents" plural? > > It depends on what you mean by CMS documents. There is one syntax > document [CMS] and then a number of associated documents which describe how > to use various cryptographic algorithms with CMS. > > > > > I have been observing growing unease with Postel's Principle over time; > it's > > less clear that blindly repeating it is the best position to take. > > And..... > > > > > Section 1.2 > > > > BER does not appear to be used in the body text? > > And neither is DER. Not sure that I want to remove them anyway as they > are concepts that people need to understand to talk to others about ASN.1 > and CMS > > > > > Section 1.5 > > > > I recognize this is historical text, but to modern readers, there is not > a single > > "the AES symmetric encryption algorithm" -- there are CBC modes and GCM > > modes, and v4.0 distinguishes between them. Should this text get > clarified > > about the difference? > > I don't believe that this needs to be clarified. But that may be because > of how I approach things thing. The block encryption algorithm is > completely different to me than the mode. > > > > > Section 2.5.2 > > > > The OIDs that correspond to algorithms SHOULD use the same OID as the > > actual algorithm, except in the case where the algorithm usage is > > ambiguous from the OID. For instance, in an earlier specification, > > rsaEncryption was ambiguous because it could refer to either a > > signature algorithm or a key encipherment algorithm. In the event > > that an OID is ambiguous, it needs to be arbitrated by the maintainer > > of the registered SMIMECapabilities list as to which type of > > algorithm will use the OID, and a new OID MUST be allocated under the > > smimeCapabilities OID to satisfy the other use of the OID. > > > > (nit?) "the other use" implies there will only ever be one other (two > total), > > which is perhaps needlessly limiting. > > Given that I cannot think of a case where this a been a problem yet, I am > not too worried about the language possibly being restrictive here. > > > > > Section 2.7.2 > > > > With "Algorithms such as RC2"; "Algorithms such as TripleDES", I'm not > sure > > what to make of "such as" in these statements -- what are the attributes > that > > would qualify for sufficient similarity to match the "such as", other > than > > equality? > > I would probably put DES in the same category as RC2 and Camellia in the > same category as TripleDES. The first category is basically - this is > better than nothing but is not secure. The second category is basically it > is not known to be unsecure, but neither is it something that we recommend > as using any more. (In this case 64-bit blocks vs 128-bit blocks). > > > > > Section 3.1 > > > > In order to protect outer, non-content-related message header fields > > (for instance, the "Subject", "To", "From", and "Cc" fields), the > > sending client MAY wrap a full MIME message in a message/rfc822 > > wrapper in order to apply S/MIME security services to these header > > fields. It is up to the receiving client to decide how to present > > this "inner" header along with the unprotected "outer" header. It is > > RECOMMENDED that a distinction be made between the location of the > > header. > > > > nit: I'm not sure this last sentence is grammatical. Do we want > "between the > > locations", or "a visible distinction be made for the different possible > > locations of the header", or something else? > > See the response to Ben > > > > > Section 3.1.2 > > > > In the case where S/MIME implementations can determine that all > > intended recipients are capable of handling inner (all but the > > outermost) binary MIME objects SHOULD use binary encoding as opposed > > to a 7-bit-safe transfer encoding for the inner entities. > > > > nit: I think that some words got dropped in here; the sentence doesn't > really > > parse. I guess there's a missing "implementations" in "implementations > > SHOULD use"? > > I have no problem with that - fixed. > > > > > Section 3.3 > > > > but not signed messages does not provide for data integrity. The > > Enveloped-Only structure does not support authenticated symmetric > > algorithms, use the .Authenticated Enveloped structure for these > > algorithms. [...] > > > > nit: Is the '.' in ".Authenticated" correct? (Also, that sentence looks > like a > > comma splice.) > > Already fixed > > > > > Section 3.5.3.2 > > > > I agree with Adam that there should be some notation in the table or > > adjacent to it that some algorithms are present only for historical > > compatibility and should be considered > > deprecated/insecure/risky/whatever. > > Already fixed > > > > > Section 6 > > > > Some cryptographic algorithms such as RC2 offer little actual > > security over sending plaintext. Other algorithms such as TripleDES, > > provide security but are no longer considered to be state of the art. > > S/MIME requires the use of current state of the art algorithms such > > as AES and provides the ability to announce starter cryptographic > > capabilities to parties with whom you communicate. [...] > > > > I can't figure out what "starter" means, here. > > Good question - gone. > > > > > Modification of the ciphertext in EnvelopedData can go undetected if > > authentication is not also used, which is the case when sending > > EnvelopedData without wrapping it in SignedData or enclosing > > SignedData within it. This is one of the reasons for moving from > > EnvelopedData to AuthEnvelopedData as the authenticated encryption > > algorithms provide the authentication without needing the SignedData > > layer. > > > > nit: I think a comma before "as the" would help the last sentence. > > Done > > > > > When talking about compression oracles, do we want to explicitly say > that a > > common way to do so is to compress attacker-controlled data in the same > > corpus as the attacker's target data? > > > > mail clients deal with HTML and multipart/mixed messages. Clients > > MUST require that a text/html content type is a complete HTML > > document (per [RFC1866]). Clients SHOULD treat each of the different > > pieces of the multipart/mixed construct as being of different > > origins. Clients MUST treat each encrypted or signed piece of a MIME > > message as being of different origins both from unprotected content > > and from each other. > > I put this in as part of a response to EKR's AD review. I will be honest > in that I am completely unsure how one would do a compression attack as it > assumes that you are going to do iterative things which is not the normal > S/MIME way of thinking. Also the fact that almost nobody has implemented > compression is also a factor. > > > > > Do we need to cite RFC 6454 for the specific "web origin" concept (as > > opposed to just the normal English usage of the word)? > > At this point in time I don't know that the idea of "web origin" is going > to match what is needed for S/MIME. I would prefer to punt this to a new > document which addresses the problem directly > > > > > Appendix B > > > > This appendix contains a number of references to documents that have > > been obsoleted or replaced, this is intentional as frequently the > > updated documents do not have the same information in them. > > > > nit: comma splice > > Not sure that I agree - but fixed > > > > > Appendix B.2 > > > > - Hash functions used to validate signatures on historic messages > > may longer be considered to be secure. (See below.) While there > > are not currently any known practical pre-image or second pre- > > image attacks against MD5 or SHA-1, the fact they are no longer > > considered to be collision resistant the security levels of the > > signatures are generally considered suspect. [...] > > > > nit: there seems to be (at least) a missing verb in this last sentence. > > While there are not currently any known practical pre-image > or second pre-image attacks against MD5 or SHA&nbhy;1, the fact they are no > longer considered to be collision resistant implies that the security > levels of the signatures are generally considered suspect. > > > > > [...] If a message is > > known to be historic, that it it has been in the possession of the > > client for some time, then it might still be considered to be > > secure. > > > > nit: maybe "and it has been" > > > > Fixed > > > > --00000000000065f1e1057044a8bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, I'm still confused. I believe that standar= d IETF policy is to prefer the CFRG curves going forward, with protocols ne= eding various levels of support for the NIST curves. I think that that'= s uncontroversial and only depends on the fact that the CFRG curves are mor= e modern, but there are environments where the NIST curves are needed. I gu= ess any point in this space is political in the sense that it's more ab= out balancing competing interests than any particular technical decision, b= ut lots of things are like that. What makes this special?

As a side note, who actually is claiming that the NIST curves aren&= #39;t secure?

-Ekr


On Thu, Jul 5, 2018 at 10:5= 0 AM, Jim Schaad <ietf@augustcellars.com> wrote:
=

=C2=A0

=C2=A0

From:= Eric Rescorla <ekr@rt= fm.com>
Sent: Thursday, July 5, 2018 10:23 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>; The IESG= <iesg@ietf.org&g= t;; draft-ietf-lamps-rfc5751-bis@ietf.org; lamps-chairs@ietf.org; SPASM <spasm@ietf.org>; R= uss Housley <h= ousley@vigilsec.com>
Subject: Re: Benjamin Kaduk's Dis= cuss on draft-ietf-lamps-rfc5751-bis-10: (with DISCUSS and COMMENT)=

=C2=A0

<= div>

=C2=A0

=C2=A0

On Thu, Jul 5, 2018 at 10:18 AM, Jim Schaad <<= a href=3D"mailto:ietf@augustcellars.com" target=3D"_blank">ietf@augustcella= rs.com> wrote:



> -----Original Message-----
> From: Benjamin Kaduk &= lt;kaduk@mit.edu>=
> Sent: Thursday, July 5, 2018 7:04 AM
> To: The IESG <iesg@ietf.org>
>= ; Cc: draft-ietf-lamps-rfc5751-bis@ietf.org; Russ Housley
> = <housley@vigil= sec.com>; lamps-chairs@ietf.org; housley@vigilsec.com;
> spasm@ietf.org
> Subject: Benjamin Kaduk&#= 39;s Discuss on draft-ietf-lamps-rfc5751-bis-10: (with
> DISCUSS= and COMMENT)
>
> Benjamin Kaduk has entered the following bal= lot position for
> draft-ietf-lamps-rfc5751-bis-10: Discuss
&= gt;
> 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.)
>
> > Please refer to https://www.ietf.org/iesg/statement= /discuss-criteria.html
> for more information about IESG DISCUSS = and COMMENT positions.
>
>
> The document, along with o= ther ballot positions, can be found here:
> https:/= /datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/
&g= t;
>
>
> ----------------------------------------= ------------------------------
> DISCUSS:
> --------------= --------------------------------------------------------
> =
> This is not necessarily a flaw in the document, I just want to ens= ure that the
> decision to use the phrase "for political reasons= " to describe a technical
> decision made in an IETF-stream RFC = is a decision that is consciously
> approved by the IESG.=C2=A0 (I co= uld not find any precedent for such a usage.)

=

>From my point of view this is a "political&= quot; decision.=C2=A0 To the best of my knowledge there is nobody who has e= ver found any technical reason to say that any of the NIST curves are in an= y way problematic.=C2=A0 Despite the mistrust by some, they are still requi= red in many situations.=C2=A0

=C2=A0

Wh= at is a political decision?

=C2=A0

- Supporting = the NIST curves?

- Suppo= rting the CFRG curves?

-= Supporting both?

=C2=A0

-Ekr=

=C2=A0

[JLS]=C2=A0 Do you remove the NIST curves or at least demote the requ= irements to implement them as there are people who believe that they are no= t secure.

=C2=A0

Jim

= =C2=A0

=C2=A0


>
>
> ---------------------------= -------------------------------------------
> COMMENT:
&= gt; -------------------------------------------------------------= ---------
>
> I suspect it's too late for changing this to= be a good idea, but using
> "authenticated enveloped" and = in the same breath talking about how it does
> not provide proof of o= rigination ("wait, isn't that authentication?), but it does
>= ; provide "a level of authentication", is kind of confusing for t= he reader.=C2=A0 Could
> "integrity protection" be used to = distinguish the AEAD property from proof-
> of-origin authentication?=

I have lamented in the past that this is was called "authentic= ated encryption" rather than "integrity protected encryption"= ; but that ship has sailed a long time ago.=C2=A0 If nothing else the name = change would have reduced the number of times that I needed to explain to p= eople that authenticated encryption does not imply proof of origination.
>
> Similarly, it might be helpful to use the term "AE= AD" before the security
> considerations section.
>
&g= t; Should the Abstract/Introduction mention that AEAD encryption provides> non-malleability?

I don't think that is the correct thing= .=C2=A0 I would add the following sentence to the abstract.

Authenti= cated Encryption provides both message integrity and data confidentiality.<= br>
>
> Section-by-Section comments follow.
>
> S= ection 1
>
> nit: Does FAX need to be all-caps?

Probabl= y not, but that is the was it was and is the way that I normally use it whe= n not a verb.

>
> Section 1.1
>
>=C2=A0 =C2= =A0 In order to create S/MIME messages, an S/MIME agent MUST follow the
= >=C2=A0 =C2=A0 specifications in this document, as well as the specifica= tions listed
>=C2=A0 =C2=A0 in the Cryptographic Message Syntax docum= ent [CMS], [RFC3370],
>=C2=A0 =C2=A0 [RFC4056], [RFC3560], and [RFC57= 54].
>
> nit: is that "[CMS] documents" plural?
<= br>It depends on what you mean by CMS documents.=C2=A0 There is one syntax = document [CMS] and then a number of associated documents which describe how= to use various cryptographic algorithms with CMS.

>
> I h= ave been observing growing unease with Postel's Principle over time; it= 's
> less clear that blindly repeating it is the best position to= take.

And.....

>
> Section 1.2
>
> BE= R does not appear to be used in the body text?

And neither is DER.= =C2=A0 Not sure that I want to remove them anyway as they are concepts that= people need to understand to talk to others about ASN.1 and CMS

>= ;
> Section 1.5
>
> I recognize this is historical text= , but to modern readers, there is not a single
> "the AES symmet= ric encryption algorithm" -- there are CBC modes and GCM
> modes= , and v4.0 distinguishes between them.=C2=A0 Should this text get clarified=
> about the difference?

I don't believe that this needs t= o be clarified.=C2=A0 But that may be because of how I approach things thin= g.=C2=A0 The block encryption algorithm is completely different to me than = the mode.=C2=A0

>
> Section 2.5.2
>
>=C2=A0 = =C2=A0 The OIDs that correspond to algorithms SHOULD use the same OID as th= e
>=C2=A0 =C2=A0 actual algorithm, except in the case where the algor= ithm usage is
>=C2=A0 =C2=A0 ambiguous from the OID.=C2=A0 For instan= ce, in an earlier specification,
>=C2=A0 =C2=A0 rsaEncryption was amb= iguous because it could refer to either a
>=C2=A0 =C2=A0 signature al= gorithm or a key encipherment algorithm.=C2=A0 In the event
>=C2=A0 = =C2=A0 that an OID is ambiguous, it needs to be arbitrated by the maintaine= r
>=C2=A0 =C2=A0 of the registered SMIMECapabilities list as to which= type of
>=C2=A0 =C2=A0 algorithm will use the OID, and a new OID MUS= T be allocated under the
>=C2=A0 =C2=A0 smimeCapabilities OID to sati= sfy the other use of the OID.
>
> (nit?) "the other use&q= uot; implies there will only ever be one other (two total),
> which i= s perhaps needlessly limiting.

Given that I cannot think of a case w= here this a been a problem yet, I am not too worried about the language pos= sibly being restrictive here.=C2=A0

>
> Section 2.7.2
= >
> With "Algorithms such as RC2"; "Algorithms suc= h as TripleDES", I'm not sure
> what to make of "such a= s" in these statements -- what are the attributes that
> would q= ualify for sufficient similarity to match the "such as", other th= an
> equality?

I would probably put DES in the same category a= s RC2 and Camellia in the same category as TripleDES.=C2=A0 The first categ= ory is basically - this is better than nothing but is not secure.=C2=A0 The= second category is basically it is not known to be unsecure, but neither i= s it something that we recommend as using any more.=C2=A0 (In this case 64-= bit blocks vs 128-bit blocks).

>
> Section 3.1
> >=C2=A0 =C2=A0 In order to protect outer, non-content-related message h= eader fields
>=C2=A0 =C2=A0 (for instance, the "Subject", &= quot;To", "From", and "Cc" fields), the
>=C2= =A0 =C2=A0 sending client MAY wrap a full MIME message in a message/rfc822<= br>>=C2=A0 =C2=A0 wrapper in order to apply S/MIME security services to = these header
>=C2=A0 =C2=A0 fields.=C2=A0 It is up to the receiving c= lient to decide how to present
>=C2=A0 =C2=A0 this "inner" = header along with the unprotected "outer" header.=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.
>
> nit: I'm not su= re this last sentence is grammatical.=C2=A0 Do we want "between the> locations", or "a visible distinction be made for the diffe= rent possible
> locations of the header", or something else?
=
See the response to Ben

>
> Section 3.1.2
>
= >=C2=A0 =C2=A0 In the case where S/MIME implementations can determine th= at all
>=C2=A0 =C2=A0 intended recipients are capable of handling inn= er (all but the
>=C2=A0 =C2=A0 outermost) binary MIME objects SHOULD = use binary encoding as opposed
>=C2=A0 =C2=A0 to a 7-bit-safe transfe= r encoding for the inner entities.
>
> nit: I think that some = words got dropped in here; the sentence doesn't really
> parse.= =C2=A0 I guess there's a missing "implementations" in "i= mplementations
> SHOULD use"?

I have no problem with that= - fixed.

>
> Section 3.3
>
>=C2=A0 =C2=A0 bu= t not signed messages does not provide for data integrity.=C2=A0 The
>= ;=C2=A0 =C2=A0 Enveloped-Only structure does not support authenticated symm= etric
>=C2=A0 =C2=A0 algorithms, use the .Authenticated Enveloped str= ucture for these
>=C2=A0 =C2=A0 algorithms.=C2=A0 [...]
>
&= gt; nit: Is the '.' in ".Authenticated" correct?=C2=A0 (A= lso, that sentence looks like a
> comma splice.)

Already fixed=

>
> Section 3.5.3.2
>
> I agree with Adam th= at there should be some notation in the table or
> adjacent to it tha= t some algorithms are present only for historical
> compatibility and= should be considered
> deprecated/insecure/risky/whatever.
<= br>Already fixed

>
> Section 6
>
>=C2=A0 =C2= =A0 Some cryptographic algorithms such as RC2 offer little actual
>= =C2=A0 =C2=A0 security over sending plaintext.=C2=A0 Other algorithms such = as TripleDES,
>=C2=A0 =C2=A0 provide security but are no longer consi= dered to be state of the art.
>=C2=A0 =C2=A0 S/MIME requires the use = of current state of the art algorithms such
>=C2=A0 =C2=A0 as AES and= provides the ability to announce starter cryptographic
>=C2=A0 =C2= =A0 capabilities to parties with whom you communicate. [...]
>
&g= t; I can't figure out what "starter" means, here.

Good= question - gone.

>
>=C2=A0 =C2=A0 Modification of the cip= hertext in EnvelopedData can go undetected if
>=C2=A0 =C2=A0 authenti= cation is not also used, which is the case when sending
>=C2=A0 =C2= =A0 EnvelopedData without wrapping it in SignedData or enclosing
>=C2= =A0 =C2=A0 SignedData within it.=C2=A0 This is one of the reasons for movin= g from
>=C2=A0 =C2=A0 EnvelopedData to AuthEnvelopedData as the authe= nticated encryption
>=C2=A0 =C2=A0 algorithms provide the authenticat= ion without needing the SignedData
>=C2=A0 =C2=A0 layer.
>
= > nit: I think a comma before "as the" would help the last sen= tence.

Done

>
> When talking about compression orac= les, do we want to explicitly say that a
> common way to do so is to = compress attacker-controlled data in the same
> corpus as the attacke= r's target data?
>
>=C2=A0 =C2=A0 mail clients deal with H= TML and multipart/mixed messages.=C2=A0 Clients
>=C2=A0 =C2=A0 MUST r= equire that a text/html content type is a complete HTML
>=C2=A0 =C2= =A0 document (per [RFC1866]).=C2=A0 Clients SHOULD treat each of the differ= ent
>=C2=A0 =C2=A0 pieces of the multipart/mixed construct as being o= f different
>=C2=A0 =C2=A0 origins.=C2=A0 Clients MUST treat each enc= rypted or signed piece of a MIME
>=C2=A0 =C2=A0 message as being of d= ifferent origins both from unprotected content
>=C2=A0 =C2=A0 and fro= m each other.

I put this in as part of a response to EKR's AD re= view.=C2=A0 I will be honest in that I am completely unsure how one would d= o a compression attack as it assumes that you are going to do iterative thi= ngs which is not the normal S/MIME way of thinking.=C2=A0 Also the fact tha= t almost nobody has implemented compression is also a factor.

> <= br>> Do we need to cite RFC 6454 for the specific "web origin"= concept (as
> opposed to just the normal English usage of the word)?=

At this point in time I don't know that the idea of "web o= rigin" is going to match what is needed for S/MIME.=C2=A0 I would pref= er to punt this to a new document which addresses the problem directly
<= br>>
> Appendix B
>
>=C2=A0 =C2=A0 This appendix con= tains a number of references to documents that have
>=C2=A0 =C2=A0 be= en obsoleted or replaced, this is intentional as frequently the
>=C2= =A0 =C2=A0 updated documents do not have the same information in them.
&= gt;
> nit: comma splice

Not sure that I agree - but fixed
=
>
> Appendix B.2
>
>=C2=A0 =C2=A0 -=C2=A0 Hash f= unctions used to validate signatures on historic messages
>=C2=A0 =C2= =A0 =C2=A0 =C2=A0may longer be considered to be secure.=C2=A0 (See below.)= =C2=A0 While there
>=C2=A0 =C2=A0 =C2=A0 =C2=A0are not currently any = known practical pre-image or second pre-
>=C2=A0 =C2=A0 =C2=A0 =C2=A0= image attacks against MD5 or SHA-1, the fact they are no longer
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0considered to be collision resistant the security l= evels of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0signatures are generally con= sidered suspect.=C2=A0 [...]
>
> nit: there seems to be (at le= ast) a missing verb in this last sentence.

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 While there are not currently any known practical = pre-image or second pre-image attacks against MD5 or SHA&nbhy;1, the fa= ct they are no longer considered to be collision resistant implies that the= security levels of the signatures are generally considered suspect.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[...] If a message is
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0known to be historic, that it it has been in the po= ssession of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0client for some time, the= n it might still be considered to be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0secu= re.
>
> nit: maybe "and it has been"
>
Fixed


=C2=A0


--00000000000065f1e1057044a8bd-- From nobody Thu Jul 5 14:27: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 927D6130DD3; Thu, 5 Jul 2018 14:27:27 -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 tb8d1LmWiEoE; Thu, 5 Jul 2018 14:27:24 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 58430124D68; Thu, 5 Jul 2018 14:27:24 -0700 (PDT) X-AuditID: 12074423-60bff700000039bd-ad-5b3e8d3b140d Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id AE.85.14781.B3D8E3B5; Thu, 5 Jul 2018 17:27:23 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w65LRLkW023471; Thu, 5 Jul 2018 17:27:22 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w65LRGLF001123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Jul 2018 17:27:19 -0400 Date: Thu, 5 Jul 2018 16:27:16 -0500 From: Benjamin Kaduk To: Jim Schaad Cc: The IESG , draft-ietf-lamps-rfc5751-bis@ietf.org, lamps-chairs@ietf.org, SPASM , Russ Housley , Eric Rescorla Message-ID: <20180705212716.GQ60996@kduck.kaduk.org> References: <153079945499.11322.17868589339590763702.idtracker@ietfa.amsl.com> <00a901d41484$2494b0f0$6dbe12d0$@augustcellars.com> <00ac01d41488$a71cfe70$f556fb50$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixG6nomvdaxdtsPISq8XtH7uZLVa8Psdu 8erFTXaLGX8mMlusnv6dzeLy3LVsFvOuJTuwe2ycM53NY8mSn0wekx+3MXusuvOFNYAlissm JTUnsyy1SN8ugSvj8fZVjAUbKiraW34zNjDeiO5i5OSQEDCRaOt9yNbFyMUhJLCYSaJr9W4W CGcDo0T3ppesEM4VJom1m+YDlXFwsAioSKw4WgXSzQZkNnRfZgaxRQTUJbauvskEYjMLHGeU mLU4FcQWFkiTmP92AxuIzQu07e+7M4wQM08wSXzt3wyVEJQ4OfMJC0SzlsSNfy+ZQHYxC0hL LP/HARLmFAiUOL93B1iJqICyxN6+Q+wTGAVmIemehaR7FkL3AkbmVYyyKblVurmJmTnFqcm6 xcmJeXmpRbpmermZJXqpKaWbGMGh7qK8g/Fln/chRgEORiUeXgZpu2gh1sSy4srcQ4ySHExK orz+7UAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrx7A4FyvCmJlVWpRfkwKWkOFiVx3pxFjNFC AumJJanZqakFqUUwWRkODiUJ3jfdQI2CRanpqRVpmTklCGkmDk6Q4TxAw3+A1PAWFyTmFmem Q+RPMepy/Hk/dRKzEEtefl6qlDjvK5AiAZCijNI8uDmgFCWRvb/mFaM40FvCEKN4gOkNbtIr oCVMQEsmCoAtKUlESEk1MDKG+UQKu7Vuzrqs/+r3o8J531bM2Ss5J6E5uuE/+5uY3oafP9Mk /W9tbm6YWbNn2URmv2a36dNup8xPeNm/Y9+0r9kT7vbPmxVWpRXDEMh89FDUqdQFX17paLw1 XOwfwMGWV3y3Zz1DqlmM0/zfqTqHwyU3an57Ye8sX3vdUt7konqdqmUKtxJLcUaioRZzUXEi AGjns4IsAwAA Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jul 2018 21:27:28 -0000 In particular, on the call, we had multiple conflicting interpretations/guesses as to what the political decision was, so the current text is at best unclear. But I think Ekr's point about the text perhaps not even being needed is also pretty accurate. -Benjamin On Thu, Jul 05, 2018 at 11:23:48AM -0700, Eric Rescorla wrote: > Sorry, I'm still confused. I believe that standard IETF policy is to prefer > the CFRG curves going forward, with protocols needing various levels of > support for the NIST curves. I think that that's uncontroversial and only > depends on the fact that the CFRG curves are more modern, but there are > environments where the NIST curves are needed. I guess any point in this > space is political in the sense that it's more about balancing competing > interests than any particular technical decision, but lots of things are > like that. What makes this special? > > As a side note, who actually is claiming that the NIST curves aren't secure? > > -Ekr > > > On Thu, Jul 5, 2018 at 10:50 AM, Jim Schaad wrote: > > > > > > > > > > > *From:* Eric Rescorla > > *Sent:* Thursday, July 5, 2018 10:23 AM > > *To:* Jim Schaad > > *Cc:* Benjamin Kaduk ; The IESG ; > > draft-ietf-lamps-rfc5751-bis@ietf.org; lamps-chairs@ietf.org; SPASM < > > spasm@ietf.org>; Russ Housley > > *Subject:* Re: Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: > > (with DISCUSS and COMMENT) > > > > > > > > > > > > > > > > On Thu, Jul 5, 2018 at 10:18 AM, Jim Schaad > > wrote: > > > > > > > > > -----Original Message----- > > > From: Benjamin Kaduk > > > Sent: Thursday, July 5, 2018 7:04 AM > > > To: The IESG > > > Cc: draft-ietf-lamps-rfc5751-bis@ietf.org; Russ Housley > > > ; lamps-chairs@ietf.org; housley@vigilsec.com; > > > spasm@ietf.org > > > Subject: Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: > > (with > > > DISCUSS and COMMENT) > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-lamps-rfc5751-bis-10: Discuss > > > > > > 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.) > > > > > > > > > Please refer to https://www.ietf.org/iesg/stat > > ement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ > > > > > > > > > > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > This is not necessarily a flaw in the document, I just want to ensure > > that the > > > decision to use the phrase "for political reasons" to describe a > > technical > > > decision made in an IETF-stream RFC is a decision that is consciously > > > approved by the IESG. (I could not find any precedent for such a usage.) > > > > >From my point of view this is a "political" decision. To the best of my > > knowledge there is nobody who has ever found any technical reason to say > > that any of the NIST curves are in any way problematic. Despite the > > mistrust by some, they are still required in many situations. > > > > > > > > What is a political decision? > > > > > > > > - Supporting the NIST curves? > > > > - Supporting the CFRG curves? > > > > - Supporting both? > > > > > > > > -Ekr > > > > > > > > [JLS] Do you remove the NIST curves or at least demote the requirements > > to implement them as there are people who believe that they are not secure. > > > > > > > > Jim > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > I suspect it's too late for changing this to be a good idea, but using > > > "authenticated enveloped" and in the same breath talking about how it > > does > > > not provide proof of origination ("wait, isn't that authentication?), > > but it does > > > provide "a level of authentication", is kind of confusing for the > > reader. Could > > > "integrity protection" be used to distinguish the AEAD property from > > proof- > > > of-origin authentication? > > > > I have lamented in the past that this is was called "authenticated > > encryption" rather than "integrity protected encryption" but that ship has > > sailed a long time ago. If nothing else the name change would have reduced > > the number of times that I needed to explain to people that authenticated > > encryption does not imply proof of origination. > > > > > > > > Similarly, it might be helpful to use the term "AEAD" before the security > > > considerations section. > > > > > > Should the Abstract/Introduction mention that AEAD encryption provides > > > non-malleability? > > > > I don't think that is the correct thing. I would add the following > > sentence to the abstract. > > > > Authenticated Encryption provides both message integrity and data > > confidentiality. > > > > > > > > Section-by-Section comments follow. > > > > > > Section 1 > > > > > > nit: Does FAX need to be all-caps? > > > > Probably not, but that is the was it was and is the way that I normally > > use it when not a verb. > > > > > > > > Section 1.1 > > > > > > In order to create S/MIME messages, an S/MIME agent MUST follow the > > > specifications in this document, as well as the specifications listed > > > in the Cryptographic Message Syntax document [CMS], [RFC3370], > > > [RFC4056], [RFC3560], and [RFC5754]. > > > > > > nit: is that "[CMS] documents" plural? > > > > It depends on what you mean by CMS documents. There is one syntax > > document [CMS] and then a number of associated documents which describe how > > to use various cryptographic algorithms with CMS. > > > > > > > > I have been observing growing unease with Postel's Principle over time; > > it's > > > less clear that blindly repeating it is the best position to take. > > > > And..... > > > > > > > > Section 1.2 > > > > > > BER does not appear to be used in the body text? > > > > And neither is DER. Not sure that I want to remove them anyway as they > > are concepts that people need to understand to talk to others about ASN.1 > > and CMS > > > > > > > > Section 1.5 > > > > > > I recognize this is historical text, but to modern readers, there is not > > a single > > > "the AES symmetric encryption algorithm" -- there are CBC modes and GCM > > > modes, and v4.0 distinguishes between them. Should this text get > > clarified > > > about the difference? > > > > I don't believe that this needs to be clarified. But that may be because > > of how I approach things thing. The block encryption algorithm is > > completely different to me than the mode. > > > > > > > > Section 2.5.2 > > > > > > The OIDs that correspond to algorithms SHOULD use the same OID as the > > > actual algorithm, except in the case where the algorithm usage is > > > ambiguous from the OID. For instance, in an earlier specification, > > > rsaEncryption was ambiguous because it could refer to either a > > > signature algorithm or a key encipherment algorithm. In the event > > > that an OID is ambiguous, it needs to be arbitrated by the maintainer > > > of the registered SMIMECapabilities list as to which type of > > > algorithm will use the OID, and a new OID MUST be allocated under the > > > smimeCapabilities OID to satisfy the other use of the OID. > > > > > > (nit?) "the other use" implies there will only ever be one other (two > > total), > > > which is perhaps needlessly limiting. > > > > Given that I cannot think of a case where this a been a problem yet, I am > > not too worried about the language possibly being restrictive here. > > > > > > > > Section 2.7.2 > > > > > > With "Algorithms such as RC2"; "Algorithms such as TripleDES", I'm not > > sure > > > what to make of "such as" in these statements -- what are the attributes > > that > > > would qualify for sufficient similarity to match the "such as", other > > than > > > equality? > > > > I would probably put DES in the same category as RC2 and Camellia in the > > same category as TripleDES. The first category is basically - this is > > better than nothing but is not secure. The second category is basically it > > is not known to be unsecure, but neither is it something that we recommend > > as using any more. (In this case 64-bit blocks vs 128-bit blocks). > > > > > > > > Section 3.1 > > > > > > In order to protect outer, non-content-related message header fields > > > (for instance, the "Subject", "To", "From", and "Cc" fields), the > > > sending client MAY wrap a full MIME message in a message/rfc822 > > > wrapper in order to apply S/MIME security services to these header > > > fields. It is up to the receiving client to decide how to present > > > this "inner" header along with the unprotected "outer" header. It is > > > RECOMMENDED that a distinction be made between the location of the > > > header. > > > > > > nit: I'm not sure this last sentence is grammatical. Do we want > > "between the > > > locations", or "a visible distinction be made for the different possible > > > locations of the header", or something else? > > > > See the response to Ben > > > > > > > > Section 3.1.2 > > > > > > In the case where S/MIME implementations can determine that all > > > intended recipients are capable of handling inner (all but the > > > outermost) binary MIME objects SHOULD use binary encoding as opposed > > > to a 7-bit-safe transfer encoding for the inner entities. > > > > > > nit: I think that some words got dropped in here; the sentence doesn't > > really > > > parse. I guess there's a missing "implementations" in "implementations > > > SHOULD use"? > > > > I have no problem with that - fixed. > > > > > > > > Section 3.3 > > > > > > but not signed messages does not provide for data integrity. The > > > Enveloped-Only structure does not support authenticated symmetric > > > algorithms, use the .Authenticated Enveloped structure for these > > > algorithms. [...] > > > > > > nit: Is the '.' in ".Authenticated" correct? (Also, that sentence looks > > like a > > > comma splice.) > > > > Already fixed > > > > > > > > Section 3.5.3.2 > > > > > > I agree with Adam that there should be some notation in the table or > > > adjacent to it that some algorithms are present only for historical > > > compatibility and should be considered > > > deprecated/insecure/risky/whatever. > > > > Already fixed > > > > > > > > Section 6 > > > > > > Some cryptographic algorithms such as RC2 offer little actual > > > security over sending plaintext. Other algorithms such as TripleDES, > > > provide security but are no longer considered to be state of the art. > > > S/MIME requires the use of current state of the art algorithms such > > > as AES and provides the ability to announce starter cryptographic > > > capabilities to parties with whom you communicate. [...] > > > > > > I can't figure out what "starter" means, here. > > > > Good question - gone. > > > > > > > > Modification of the ciphertext in EnvelopedData can go undetected if > > > authentication is not also used, which is the case when sending > > > EnvelopedData without wrapping it in SignedData or enclosing > > > SignedData within it. This is one of the reasons for moving from > > > EnvelopedData to AuthEnvelopedData as the authenticated encryption > > > algorithms provide the authentication without needing the SignedData > > > layer. > > > > > > nit: I think a comma before "as the" would help the last sentence. > > > > Done > > > > > > > > When talking about compression oracles, do we want to explicitly say > > that a > > > common way to do so is to compress attacker-controlled data in the same > > > corpus as the attacker's target data? > > > > > > mail clients deal with HTML and multipart/mixed messages. Clients > > > MUST require that a text/html content type is a complete HTML > > > document (per [RFC1866]). Clients SHOULD treat each of the different > > > pieces of the multipart/mixed construct as being of different > > > origins. Clients MUST treat each encrypted or signed piece of a MIME > > > message as being of different origins both from unprotected content > > > and from each other. > > > > I put this in as part of a response to EKR's AD review. I will be honest > > in that I am completely unsure how one would do a compression attack as it > > assumes that you are going to do iterative things which is not the normal > > S/MIME way of thinking. Also the fact that almost nobody has implemented > > compression is also a factor. > > > > > > > > Do we need to cite RFC 6454 for the specific "web origin" concept (as > > > opposed to just the normal English usage of the word)? > > > > At this point in time I don't know that the idea of "web origin" is going > > to match what is needed for S/MIME. I would prefer to punt this to a new > > document which addresses the problem directly > > > > > > > > Appendix B > > > > > > This appendix contains a number of references to documents that have > > > been obsoleted or replaced, this is intentional as frequently the > > > updated documents do not have the same information in them. > > > > > > nit: comma splice > > > > Not sure that I agree - but fixed > > > > > > > > Appendix B.2 > > > > > > - Hash functions used to validate signatures on historic messages > > > may longer be considered to be secure. (See below.) While there > > > are not currently any known practical pre-image or second pre- > > > image attacks against MD5 or SHA-1, the fact they are no longer > > > considered to be collision resistant the security levels of the > > > signatures are generally considered suspect. [...] > > > > > > nit: there seems to be (at least) a missing verb in this last sentence. > > > > While there are not currently any known practical pre-image > > or second pre-image attacks against MD5 or SHA&nbhy;1, the fact they are no > > longer considered to be collision resistant implies that the security > > levels of the signatures are generally considered suspect. > > > > > > > > [...] If a message is > > > known to be historic, that it it has been in the possession of the > > > client for some time, then it might still be considered to be > > > secure. > > > > > > nit: maybe "and it has been" > > > > > > > Fixed > > > > > > > > From nobody Thu Jul 5 14:37: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 77012130F94; Thu, 5 Jul 2018 14:37:10 -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 fl4-QJd203cq; Thu, 5 Jul 2018 14:37:07 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 21C39130F8E; Thu, 5 Jul 2018 14:37:07 -0700 (PDT) X-AuditID: 1209190c-0bbff700000037cf-81-5b3e8f8191a5 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id F4.97.14287.18F8E3B5; Thu, 5 Jul 2018 17:37:05 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w65Lb3gp020725; Thu, 5 Jul 2018 17:37:04 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w65LawQG003670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Jul 2018 17:37:01 -0400 Date: Thu, 5 Jul 2018 16:36:59 -0500 From: Benjamin Kaduk To: Jim Schaad Cc: "'The IESG'" , draft-ietf-lamps-rfc5751-bis@ietf.org, "'Russ Housley'" , lamps-chairs@ietf.org, spasm@ietf.org Message-ID: <20180705213656.GR60996@kduck.kaduk.org> References: <153079945499.11322.17868589339590763702.idtracker@ietfa.amsl.com> <00a901d41484$2494b0f0$6dbe12d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00a901d41484$2494b0f0$6dbe12d0$@augustcellars.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixCmqrdvYbxdtsPS3mcXtH7uZLV69uMlu MePPRGaL1dO/s1lcnruWzWLetWQHNo+Nc6azeSxZ8pPJY9WdL6wBzFFcNimpOZllqUX6dglc GUvf/2Au6Mir2L/6PVsD4+zQLkZODgkBE4nH/TPYuxi5OIQEFjNJtP/bzAjhbGCUuH3oDBuE c4VJYuXeKcwgLSwCKhKNP16xg9hsQHZD92WwuIiAusTW1TeZQBqYBVYyStxfMpsJJCEskCYx /+0GNhCbF2jfkhd7ofa1MEqse9XJCJEQlDg58wkLiM0soCVx499LoGYOIFtaYvk/DpAwp4CD xO8ty8HKRQWUJfb2HWKfwCgwC0n3LCTdsxC6FzAyr2KUTcmt0s1NzMwpTk3WLU5OzMtLLdI1 1MvNLNFLTSndxAgObUmeHYxn3ngdYhTgYFTi4Y2QtYsWYk0sK67MPcQoycGkJMrr3w4U4kvK T6nMSCzOiC8qzUktPsQowcGsJMK7NxAox5uSWFmVWpQPk5LmYFES581exBgtJJCeWJKanZpa kFoEk5Xh4FCS4H3RB9QoWJSanlqRlplTgpBm4uAEGc4DNJy9H2R4cUFibnFmOkT+FKMux5/3 UycxC7Hk5eelSonzfgIZJABSlFGaBzcHlJIksvfXvGIUB3pLmHcCSBUPMJ3BTXoFtIQJaMlE AbAlJYkIKakGxkMaYRsC9367tlQrVbCfb3fOZJ1PHAJ31B5779FqZt5x0+/Fwd+vjok37378 9fTCWJ2z611vXFmz3PB9ZHqNy7vMdFPjiZ0zj578IvHT+6FG2+GSgDONfeU3Kmpe/XFp3r1h efFqXc6Izb6OElZqvZM+J+7X4u6O/jjza9qGrkhn85VSb95xcCuxFGckGmoxFxUnAgDrI2xA JAMAAA== Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.26 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, 05 Jul 2018 21:37:11 -0000 On Thu, Jul 05, 2018 at 10:18:04AM -0700, Jim Schaad wrote: > > > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: Thursday, July 5, 2018 7:04 AM > > To: The IESG > > Cc: draft-ietf-lamps-rfc5751-bis@ietf.org; Russ Housley > > ; lamps-chairs@ietf.org; housley@vigilsec.com; > > spasm@ietf.org > > Subject: Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: (with > > DISCUSS and COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-lamps-rfc5751-bis-10: Discuss > > > > 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.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This is not necessarily a flaw in the document, I just want to ensure that the > > decision to use the phrase "for political reasons" to describe a technical > > decision made in an IETF-stream RFC is a decision that is consciously > > approved by the IESG. (I could not find any precedent for such a usage.) > > From my point of view this is a "political" decision. To the best of my knowledge there is nobody who has ever found any technical reason to say that any of the NIST curves are in any way problematic. Despite the mistrust by some, they are still required in many situations. [punting this to the other branch of the thread that's ongoing] > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I suspect it's too late for changing this to be a good idea, but using > > "authenticated enveloped" and in the same breath talking about how it does > > not provide proof of origination ("wait, isn't that authentication?), but it does > > provide "a level of authentication", is kind of confusing for the reader. Could > > "integrity protection" be used to distinguish the AEAD property from proof- > > of-origin authentication? > > I have lamented in the past that this is was called "authenticated encryption" rather than "integrity protected encryption" but that ship has sailed a long time ago. If nothing else the name change would have reduced the number of times that I needed to explain to people that authenticated encryption does not imply proof of origination. Yup. But, "I suspect it's too late", so we'll just have to lament about it at the hotel bar. > > > > Similarly, it might be helpful to use the term "AEAD" before the security > > considerations section. > > > > Should the Abstract/Introduction mention that AEAD encryption provides > > non-malleability? > > I don't think that is the correct thing. I would add the following sentence to the abstract. > > Authenticated Encryption provides both message integrity and data confidentiality. Sure, that's the sort of thing I was looking for. > > > > Section-by-Section comments follow. > > > > Section 1 > > > > nit: Does FAX need to be all-caps? > > Probably not, but that is the was it was and is the way that I normally use it when not a verb. > > > > > Section 1.1 > > > > In order to create S/MIME messages, an S/MIME agent MUST follow the > > specifications in this document, as well as the specifications listed > > in the Cryptographic Message Syntax document [CMS], [RFC3370], > > [RFC4056], [RFC3560], and [RFC5754]. > > > > nit: is that "[CMS] documents" plural? > > It depends on what you mean by CMS documents. There is one syntax document [CMS] and then a number of associated documents which describe how to use various cryptographic algorithms with CMS. Ah, now I see the other way to parse the sentence, thanks. > > > > I have been observing growing unease with Postel's Principle over time; it's > > less clear that blindly repeating it is the best position to take. > > And..... Maybe when v4.1 happens the WG should discuss taking it out. > > > > Section 1.2 > > > > BER does not appear to be used in the body text? > > And neither is DER. Not sure that I want to remove them anyway as they are concepts that people need to understand to talk to others about ASN.1 and CMS Okay. > > > > Section 1.5 > > > > I recognize this is historical text, but to modern readers, there is not a single > > "the AES symmetric encryption algorithm" -- there are CBC modes and GCM > > modes, and v4.0 distinguishes between them. Should this text get clarified > > about the difference? > > I don't believe that this needs to be clarified. But that may be because of how I approach things thing. The block encryption algorithm is completely different to me than the mode. Well, we have MUST support GCM but MUST- support CBC; they are treated differently in the current version. So I would not be surprised for a reader to be confused. But, this remains a COMMENT-level position, so you're free to do what you want. > > > > Section 2.5.2 > > > > The OIDs that correspond to algorithms SHOULD use the same OID as the > > actual algorithm, except in the case where the algorithm usage is > > ambiguous from the OID. For instance, in an earlier specification, > > rsaEncryption was ambiguous because it could refer to either a > > signature algorithm or a key encipherment algorithm. In the event > > that an OID is ambiguous, it needs to be arbitrated by the maintainer > > of the registered SMIMECapabilities list as to which type of > > algorithm will use the OID, and a new OID MUST be allocated under the > > smimeCapabilities OID to satisfy the other use of the OID. > > > > (nit?) "the other use" implies there will only ever be one other (two total), > > which is perhaps needlessly limiting. > > Given that I cannot think of a case where this a been a problem yet, I am not too worried about the language possibly being restrictive here. Okay. > > > > Section 2.7.2 > > > > With "Algorithms such as RC2"; "Algorithms such as TripleDES", I'm not sure > > what to make of "such as" in these statements -- what are the attributes that > > would qualify for sufficient similarity to match the "such as", other than > > equality? > > I would probably put DES in the same category as RC2 and Camellia in the same category as TripleDES. The first category is basically - this is better than nothing but is not secure. The second category is basically it is not known to be unsecure, but neither is it something that we recommend as using any more. (In this case 64-bit blocks vs 128-bit blocks). My question is more, "how do we expect the reader to make these classifications?" You and I can agree on what they should be based on our prior experience in the field, but not all readers will share that background information. > > > > Section 3.1 > > > > In order to protect outer, non-content-related message header fields > > (for instance, the "Subject", "To", "From", and "Cc" fields), the > > sending client MAY wrap a full MIME message in a message/rfc822 > > wrapper in order to apply S/MIME security services to these header > > fields. It is up to the receiving client to decide how to present > > this "inner" header along with the unprotected "outer" header. It is > > RECOMMENDED that a distinction be made between the location of the > > header. > > > > nit: I'm not sure this last sentence is grammatical. Do we want "between the > > locations", or "a visible distinction be made for the different possible > > locations of the header", or something else? > > See the response to Ben Okay. (Sorry, I meant to do more deduplication of grammar nits before submitting, but things got pretty rushed at the end.) > > > > Section 3.1.2 > > > > In the case where S/MIME implementations can determine that all > > intended recipients are capable of handling inner (all but the > > outermost) binary MIME objects SHOULD use binary encoding as opposed > > to a 7-bit-safe transfer encoding for the inner entities. > > > > nit: I think that some words got dropped in here; the sentence doesn't really > > parse. I guess there's a missing "implementations" in "implementations > > SHOULD use"? > > I have no problem with that - fixed. > > > > > Section 3.3 > > > > but not signed messages does not provide for data integrity. The > > Enveloped-Only structure does not support authenticated symmetric > > algorithms, use the .Authenticated Enveloped structure for these > > algorithms. [...] > > > > nit: Is the '.' in ".Authenticated" correct? (Also, that sentence looks like a > > comma splice.) > > Already fixed > > > > > Section 3.5.3.2 > > > > I agree with Adam that there should be some notation in the table or > > adjacent to it that some algorithms are present only for historical > > compatibility and should be considered > > deprecated/insecure/risky/whatever. > > Already fixed > > > > > Section 6 > > > > Some cryptographic algorithms such as RC2 offer little actual > > security over sending plaintext. Other algorithms such as TripleDES, > > provide security but are no longer considered to be state of the art. > > S/MIME requires the use of current state of the art algorithms such > > as AES and provides the ability to announce starter cryptographic > > capabilities to parties with whom you communicate. [...] > > > > I can't figure out what "starter" means, here. > > Good question - gone. Works for me! > > > > Modification of the ciphertext in EnvelopedData can go undetected if > > authentication is not also used, which is the case when sending > > EnvelopedData without wrapping it in SignedData or enclosing > > SignedData within it. This is one of the reasons for moving from > > EnvelopedData to AuthEnvelopedData as the authenticated encryption > > algorithms provide the authentication without needing the SignedData > > layer. > > > > nit: I think a comma before "as the" would help the last sentence. > > Done > > > > > When talking about compression oracles, do we want to explicitly say that a > > common way to do so is to compress attacker-controlled data in the same > > corpus as the attacker's target data? > > > > mail clients deal with HTML and multipart/mixed messages. Clients > > MUST require that a text/html content type is a complete HTML > > document (per [RFC1866]). Clients SHOULD treat each of the different > > pieces of the multipart/mixed construct as being of different > > origins. Clients MUST treat each encrypted or signed piece of a MIME > > message as being of different origins both from unprotected content > > and from each other. > > I put this in as part of a response to EKR's AD review. I will be honest in that I am completely unsure how one would do a compression attack as it assumes that you are going to do iterative things which is not the normal S/MIME way of thinking. Also the fact that almost nobody has implemented compression is also a factor. That's true, the iterative approach doesn't really mesh with normal S/MIME approaches. So I'm seeing less need for such a comment than I did when I first balloted. > > > > Do we need to cite RFC 6454 for the specific "web origin" concept (as > > opposed to just the normal English usage of the word)? > > At this point in time I don't know that the idea of "web origin" is going to match what is needed for S/MIME. I would prefer to punt this to a new document which addresses the problem directly How would a reader of this document know to look for this hypothetical new document? > > > > Appendix B > > > > This appendix contains a number of references to documents that have > > been obsoleted or replaced, this is intentional as frequently the > > updated documents do not have the same information in them. > > > > nit: comma splice > > Not sure that I agree - but fixed > > > > > Appendix B.2 > > > > - Hash functions used to validate signatures on historic messages > > may longer be considered to be secure. (See below.) While there > > are not currently any known practical pre-image or second pre- > > image attacks against MD5 or SHA-1, the fact they are no longer > > considered to be collision resistant the security levels of the > > signatures are generally considered suspect. [...] > > > > nit: there seems to be (at least) a missing verb in this last sentence. > > While there are not currently any known practical pre-image or second pre-image attacks against MD5 or SHA&nbhy;1, the fact they are no longer considered to be collision resistant implies that the security levels of the signatures are generally considered suspect. That's what I expected, thanks. (I might go with "the fact that they are", but that's way into editorial territory and the RFC Editor probably has house style on it anyway.) > > > > [...] If a message is > > known to be historic, that it it has been in the possession of the > > client for some time, then it might still be considered to be > > secure. > > > > nit: maybe "and it has been" > > > > Fixed Thanks for the updates! -Benjamin From nobody Mon Jul 9 17:28: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 B1B3A130EC4; Mon, 9 Jul 2018 17:28:54 -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 br1K0RvsZ6M7; Mon, 9 Jul 2018 17:28:46 -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 84D11130EB3; Mon, 9 Jul 2018 17:28:44 -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, 9 Jul 2018 17:25:12 -0700 From: Jim Schaad To: 'Benjamin Kaduk' CC: 'The IESG' , , 'Russ Housley' , , References: <153079945499.11322.17868589339590763702.idtracker@ietfa.amsl.com> <00a901d41484$2494b0f0$6dbe12d0$@augustcellars.com> <20180705213656.GR60996@kduck.kaduk.org> In-Reply-To: <20180705213656.GR60996@kduck.kaduk.org> Date: Mon, 9 Jul 2018 17:28:33 -0700 Message-ID: <039a01d417e4$f1228260$d3678720$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQIi+HNCTYWwO8773Uu0GB5YWNsIoAJRu5EBATEQR2CjzcC+AA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 10 Jul 2018 00:28:56 -0000 > -----Original Message----- > From: Benjamin Kaduk > Sent: Thursday, July 5, 2018 2:37 PM > To: Jim Schaad > Cc: 'The IESG' ; draft-ietf-lamps-rfc5751-bis@ietf.org; 'Russ > Housley' ; lamps-chairs@ietf.org; spasm@ietf.org > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: > (with DISCUSS and COMMENT) > > On Thu, Jul 05, 2018 at 10:18:04AM -0700, Jim Schaad wrote: > > > > > > > -----Original Message----- > > > From: Benjamin Kaduk > > > Sent: Thursday, July 5, 2018 7:04 AM > > > To: The IESG > > > Cc: draft-ietf-lamps-rfc5751-bis@ietf.org; Russ Housley > > > ; lamps-chairs@ietf.org; housley@vigilsec.com; > > > spasm@ietf.org > > > Subject: Benjamin Kaduk's Discuss on > > > draft-ietf-lamps-rfc5751-bis-10: (with DISCUSS and COMMENT) > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-lamps-rfc5751-bis-10: Discuss > > > > > > 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.) > > > > > > > > > Please refer to > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > COMMENT: > > > -------------------------------------------------------------------- > > > -- > > > > > > Section 2.7.2 > > > > > > With "Algorithms such as RC2"; "Algorithms such as TripleDES", I'm > > > not sure what to make of "such as" in these statements -- what are > > > the attributes that would qualify for sufficient similarity to match > > > the "such as", other than equality? > > > > I would probably put DES in the same category as RC2 and Camellia in the > same category as TripleDES. The first category is basically - this is better than > nothing but is not secure. The second category is basically it is not known to > be unsecure, but neither is it something that we recommend as using any > more. (In this case 64-bit blocks vs 128-bit blocks). > > My question is more, "how do we expect the reader to make these > classifications?" You and I can agree on what they should be based on our > prior experience in the field, but not all readers will share that background > information. I'll be honest, I don't expect readers who are not part of the world of cryptographic algorithms to make this type of classification. I expect them to use the recommendations for what algorithms to use in the document and leave it at that. I expect that this explains where things are for those who do know cryptographic algorithms and thus can understand some of the differences. > > > > Do we need to cite RFC 6454 for the specific "web origin" concept > > > (as opposed to just the normal English usage of the word)? > > > > At this point in time I don't know that the idea of "web origin" is > > going to match what is needed for S/MIME. I would prefer to punt this > > to a new document which addresses the problem directly > > How would a reader of this document know to look for this hypothetical new > document? Given that we can't point to this hypothetical document I don't think we can. I think it will get some publicity when it is finally published. In the mean time I expect people to slog through the eprint document and need to go several iterations to understand what is being said their. They talk about same origin in that document. Jim > > > Thanks for the updates! > > -Benjamin From nobody Mon Jul 9 19:49: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 B551B1310EA; Mon, 9 Jul 2018 19:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 co3si0ud0X3N; Mon, 9 Jul 2018 19:49:12 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 D08591310E3; Mon, 9 Jul 2018 19:49:11 -0700 (PDT) X-AuditID: 1209190c-2f7ff70000002bf1-2d-5b441ea64688 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 96.82.11249.6AE144B5; Mon, 9 Jul 2018 22:49:10 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w6A2n8ZK019829; Mon, 9 Jul 2018 22:49:09 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w6A2n3Aa000817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Jul 2018 22:49:06 -0400 Date: Mon, 9 Jul 2018 21:49:03 -0500 From: Benjamin Kaduk To: Jim Schaad Cc: "'The IESG'" , draft-ietf-lamps-rfc5751-bis@ietf.org, "'Russ Housley'" , lamps-chairs@ietf.org, spasm@ietf.org Message-ID: <20180710024903.GI59001@kduck.kaduk.org> References: <153079945499.11322.17868589339590763702.idtracker@ietfa.amsl.com> <00a901d41484$2494b0f0$6dbe12d0$@augustcellars.com> <20180705213656.GR60996@kduck.kaduk.org> <039a01d417e4$f1228260$d3678720$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <039a01d417e4$f1228260$d3678720$@augustcellars.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUixCmqrLtMziXa4M8MA4vbP3YzW7x6cZPd YsaficwWq6d/Z7O4PHctm8W8a8kObB4b50xn81iy5CeTx6o7X1gDmKO4bFJSczLLUov07RK4 Mo68msFSMEux4nfLG9YGxm6pLkZODgkBE4krN64zdzFycQgJLGaSmNx0jgnC2cAocfXsTRYI 5wqTxLG1PxhBWlgEVCTmPt3PDGKzAdkN3ZfBbBEBdYmtq2+CdTMLrGSUuL9kNhNIQlggTWL+ 2w1sIDYv0L7Gn8ehVjxllHjRd5UJIiEocXLmExYQm1lAS+LGv5dAcQ4gW1pi+T8OEJNTwEFi zxsnkApRAWWJvX2H2CcwCsxC0jwLSfMshOYFjMyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdA31 cjNL9FJTSjcxggNbkmcH45k3XocYBTgYlXh4N6Q6RwuxJpYVV+YeYpTkYFIS5Z1wCSjEl5Sf UpmRWJwRX1Sak1p8iFGCg1lJhNcgByjHm5JYWZValA+TkuZgURLnzV7EGC0kkJ5YkpqdmlqQ WgSTleHgUJLgrZF1iRYSLEpNT61Iy8wpQUgzcXCCDOcBGi4LUsNbXJCYW5yZDpE/xajL8ef9 1EnMQix5+XmpUuK8/CBFAiBFGaV5cHNACUkie3/NK0ZxoLeEeSeAVPEAkxncpFdAS5iAlmgv BPmguCQRISXVwHj0mt3TU/q+O3ckCd85sm/WgbVP3Rbx6Ol9uq61Y7PrzXN7V3SsvlByfa1A Yjj/fq+P+sw3qto+yjcHBk6VuOS/5YSZ9puml+/dgv/NqklOXy3580HMDtPJ+5isRWyncOWE B/f9Nr7q3RZ7y3tl6Gy9CT6TQ/pCXEXOe1mXP6jbeUetTSBcPkSJpTgj0VCLuag4EQDkxWwe IwMAAA== Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 10 Jul 2018 02:49:16 -0000 On Mon, Jul 09, 2018 at 05:28:33PM -0700, Jim Schaad wrote: > > > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: Thursday, July 5, 2018 2:37 PM > > To: Jim Schaad > > Cc: 'The IESG' ; draft-ietf-lamps-rfc5751-bis@ietf.org; > 'Russ > > Housley' ; lamps-chairs@ietf.org; spasm@ietf.org > > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: > > (with DISCUSS and COMMENT) > > > > On Thu, Jul 05, 2018 at 10:18:04AM -0700, Jim Schaad wrote: > > > > > > > > > > -----Original Message----- > > > > From: Benjamin Kaduk > > > > Sent: Thursday, July 5, 2018 7:04 AM > > > > To: The IESG > > > > Cc: draft-ietf-lamps-rfc5751-bis@ietf.org; Russ Housley > > > > ; lamps-chairs@ietf.org; housley@vigilsec.com; > > > > spasm@ietf.org > > > > Subject: Benjamin Kaduk's Discuss on > > > > draft-ietf-lamps-rfc5751-bis-10: (with DISCUSS and COMMENT) > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > draft-ietf-lamps-rfc5751-bis-10: Discuss > > > > > > > > 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.) > > > > > > > > > > > > Please refer to > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > -- > > > > COMMENT: > > > > -------------------------------------------------------------------- > > > > -- > > > > > > > > Section 2.7.2 > > > > > > > > With "Algorithms such as RC2"; "Algorithms such as TripleDES", I'm > > > > not sure what to make of "such as" in these statements -- what are > > > > the attributes that would qualify for sufficient similarity to match > > > > the "such as", other than equality? > > > > > > I would probably put DES in the same category as RC2 and Camellia in the > > same category as TripleDES. The first category is basically - this is > better than > > nothing but is not secure. The second category is basically it is not > known to > > be unsecure, but neither is it something that we recommend as using any > > more. (In this case 64-bit blocks vs 128-bit blocks). > > > > My question is more, "how do we expect the reader to make these > > classifications?" You and I can agree on what they should be based on our > > prior experience in the field, but not all readers will share that > background > > information. > > I'll be honest, I don't expect readers who are not part of the world of > cryptographic algorithms to make this type of classification. I expect them > to use the recommendations for what algorithms to use in the document and > leave it at that. I expect that this explains where things are for those > who do know cryptographic algorithms and thus can understand some of the > differences. Okay. (This is just a COMMENT, so I will trust your judgment.) > > > > > > Do we need to cite RFC 6454 for the specific "web origin" concept > > > > (as opposed to just the normal English usage of the word)? > > > > > > At this point in time I don't know that the idea of "web origin" is > > > going to match what is needed for S/MIME. I would prefer to punt this > > > to a new document which addresses the problem directly > > > > How would a reader of this document know to look for this hypothetical new > > document? > > Given that we can't point to this hypothetical document I don't think we > can. I think it will get some publicity when it is finally published. In > the mean time I expect people to slog through the eprint document and need > to go several iterations to understand what is being said their. They talk > about same origin in that document. Okay. -Benjamin From nobody Tue Jul 10 06:58: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 29311130FB1 for ; Tue, 10 Jul 2018 06:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=trustwave.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 vQMwnVIs00Gm for ; Tue, 10 Jul 2018 06:58:37 -0700 (PDT) Received: from seg-node-elk-02.trustwave.com (seg-node-elk-02.trustwave.com [204.13.202.188]) (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 0B923130ED8 for ; Tue, 10 Jul 2018 06:58:36 -0700 (PDT) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (Not Verified[216.32.181.85]) by seg-node-elk-02.trustwave.com with Trustwave SEG (v8, 0, 6, 10791) (using TLS: TLSv1.2, AES256-SHA256) id ; Tue, 10 Jul 2018 08:58:34 -0500 Received: from SN6PR07MB4575.namprd07.prod.outlook.com (52.135.95.19) by SN6PR07MB4941.namprd07.prod.outlook.com (52.135.119.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.20; Tue, 10 Jul 2018 13:58:32 +0000 Received: from SN6PR07MB4575.namprd07.prod.outlook.com ([fe80::d0e2:e12:541d:c131]) by SN6PR07MB4575.namprd07.prod.outlook.com ([fe80::d0e2:e12:541d:c131%2]) with mapi id 15.20.0930.022; Tue, 10 Jul 2018 13:58:32 +0000 From: Corey Bonnell To: Jacob Hoffman-Andrews , SPASM Thread-Topic: [lamps] New draft: rfc6844bis Thread-Index: AQHT+Q/DosfAyanL40+VifZ4n+PYpqSIdv2A Date: Tue, 10 Jul 2018 13:58:32 +0000 Message-ID: <0EA657BD-8E44-4173-8059-8A312998DAA4@trustwave.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=CBonnell@trustwave.com; x-originating-ip: [204.13.202.248] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR07MB4941; 7:MORnrk5sbe6XP5XussqNvqiIs8iPk3oqjre4R/DXSKJBkJJYj0FiUpkO7lHdndvGVlw7a55hRqHAkzaH2TodetOjc7Ozki00jfmIL5aPs8xTV1UsjdOkGX5bY1AjaMgIiha+dvgTNM0nAVixsz4MwIVLS/AgbGG5cLEHNW9l2wj4z8xni/RKteUStSupgMYKRI0rNKMcM57ogvhkGAFvssb1mtunWzwq9i7ozfiPILPFQw/mrVkVEx2K2r684bcr x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: aa70415b-c53e-4cc3-657c-08d5e66d38e8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:SN6PR07MB4941; x-ms-traffictypediagnostic: SN6PR07MB4941: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(232896897485771)(158342451672863)(192374486261705)(171964332516350); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231311)(944501410)(52105095)(10201501046)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:SN6PR07MB4941; BCL:0; PCL:0; RULEID:; SRVR:SN6PR07MB4941; x-forefront-prvs: 0729050452 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(39860400002)(376002)(136003)(366004)(51914003)(199004)(189003)(53754006)(36756003)(53936002)(6506007)(81156014)(82746002)(81166006)(66066001)(8936002)(8676002)(478600001)(72206003)(83716003)(25786009)(68736007)(446003)(11346002)(256004)(105586002)(14444005)(305945005)(80792005)(3846002)(316002)(76176011)(7736002)(110136005)(102836004)(186003)(6116002)(26005)(86362001)(2616005)(476003)(966005)(6486002)(6512007)(6306002)(97736004)(5250100002)(486006)(14454004)(2906002)(6246003)(561944003)(33656002)(106356001)(99286004)(6436002)(15974865002)(229853002)(5660300001)(2900100001)(19400905002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR07MB4941; H:SN6PR07MB4575.namprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: trustwave.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: KGNNjEO41VpOCvPihHg2MCujwZnacb1M8LG1JA/53jsEZ3aFU9K9FiGTZRpD5h1trv7B7UrNNtYY9/hYU+WnwuFDkDd6+rLhm3R4aLK1kYRHgr/ejbJnekhE4gk+WQIfRB4VAAhsJRLKtRNt3rFmJ5jFrlS2ea63F06e8PQ15VB6WXeOq0xDqQHHZCgNm7RrwmSTvWpZ9aB/WPZhndYGCmovRvx2DGODwtPr7TX9Tj1Iz0wykL0/UgO7/vQPFNgfDcky0Kkl6Y7qtd2iNmzy+jS6xhv2WAGBel8FBLgltJrppYMjB7VmsdRVtsBlP7JFOeq42qwPfLBgL30722F6eQMvZYAhxe/Pv9eLE9oWPcE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trustwave.com X-MS-Exchange-CrossTenant-Network-Message-Id: aa70415b-c53e-4cc3-657c-08d5e66d38e8 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2018 13:58:32.2277 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cb1dab68-a067-4b6b-ae7e-c012e8c33f6a X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR07MB4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=trustwave.com; s=080318_segcloud; t=1531231115; bh=FJ0CCl7NX+2pWUEyKYmQ2Is670iXHdwC3UMnmm9VV4Y=; h=From:To:Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:authentication-results: x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-ms-exchange-senderadcheck: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf: x-microsoft-antispam-message-info:spamdiagnosticoutput: spamdiagnosticmetadata:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version:X-OriginatorOrg: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id: X-MS-Exchange-Transport-CrossTenantHeadersStamped; b=j+W7CFIc6BUuwBTMNdyJVapTlZhRQjGDksAvD2q9nm4X4wLXkQjL1QTfFOQL9nB06 TjmkRBvBHmmvJYYkJjCtuRXzVvmIiMt8HAIXcnfAxIwdbXpFprEKIW5qgx+X0qr/yo uClta4Zhf3RzO5Gjz7niQ/mCS9Bnl05u+qgn5li7LFhqJaX1NcNjlBeFzMD0omHHjd mju+amXs9umfil9JVAtckH/GeqVww6KQSOo+htefC1YsHEFYVVudHoxz6M2liiPpqT CQaDUPOLIIh/F69ympQ0zv5xkvuYCdL24LYt51AuC512WUV2olFLk29wcVpORfnM+z n9BnPfe9YWBYQ== Archived-At: Subject: Re: [lamps] New draft: rfc6844bis X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 10 Jul 2018 13:58:40 -0000 SGkgSmFjb2IsDQpUaGFua3MgZm9yIGdldHRpbmcgdGhlIDY4NDQtYmlzIGRyYWZ0IHRvZ2V0aGVy LiBZb3VyIHBocmFzaW5nIG9uIHRoZSBwcm9wZXIgaGFuZGxpbmcgb2Ygbm9uLWVtcHR5IENBQSBy ZWNvcmQgc2V0cyB0aGF0IGRvbid0IGNvbnRhaW4gaXNzdWUvaXNzdWV3aWxkIHRhZ3MgaXMgY2xl YXIgYW5kIHNob3VsZCBtYWtlIHRoaXMgcGFydGljdWxhciBzY2VuYXJpbyB1bmFtYmlndW91cy4N Cg0KSXQgbG9va3MgbGlrZSB0aGUgdXBkYXRlZCBBQk5GIGdyYW1tYXIgZm9yIHRoZSBpc3N1ZSBw cm9wZXJ0eSB0YWcgaXMgbWlzc2luZyBzb21lIGxpbmUgYnJlYWtzLCBhcyBzZXZlcmFsIG9mIHRo ZSBwcm9kdWN0aW9uIHJ1bGVzIGFyZSBub3cgb24gdGhlIHNhbWUgbGluZS4NCg0KVGhlcmUgaXMg b25lIG1vcmUgaXNzdWUgdGhhdCB3ZSBtaWdodCB3YW50IHRvIHRhY2tsZSBhcyBwYXJ0IG9mIHRo ZSA2ODQ0LWJpcyBlZmZvcnQ6IGNoYW5naW5nIHRoZSAiU0hPVUxEIiBmb3IgbWFraW5nIENBQSBx dWVyaWVzIGFnYWluc3QgYXV0aG9yaXRhdGl2ZSBuYW1lc2VydmVycyB0byBhICJNVVNUIiAoc2Vj dGlvbiA2LjM6IEZvciBleGFtcGxlLCBhbGwgcG9ydGlvbnMgb2YgdGhlIEROUyBsb29rdXAgcHJv Y2VzcyBTSE9VTEQgYmUgcGVyZm9ybWVkIGFnYWluc3QgdGhlIGF1dGhvcml0YXRpdmUgbmFtZSBz ZXJ2ZXIpLiBUaGlzIHdhcyBvcmlnaW5hbGx5IG1lbnRpb25lZCBpbiBodHRwczovL2Jsb2cuY2xv dWRmbGFyZS5jb20vY2FhLW9mLXRoZS13aWxkLywgYnV0IEkgZG9uJ3QgdGhpbmsgdGhpcyBoYXMg YmVlbiBicm91Z2h0IHVwIG9uIHRoaXMgbWFpbGluZyBsaXN0IGJlZm9yZSBhbmQgdGhvdWdodCB3 ZSBzaG91bGQgYXQgbGVhc3QgZGlzY3VzcyBpdC4gTXkgb3BpbmlvbiBpcyB0aGF0IGl0IHNob3Vs ZCByZW1haW4gYSAiU0hPVUxEIiBpbiB0aGUgUkZDLCBvdGhlcndpc2UgdGhlIFJGQyBpcyBkaWN0 YXRpbmcgcG9saWN5LiBUaGUgcHJlZmVyYWJsZSByb3V0ZSBpcyB0byBkZWZpbmUgcmVxdWlyZWQg bG9va3VwIHByb3BlcnRpZXMgaW4gcG9saWN5IGV4cGxpY2l0bHkgKGVnLCB0aGUgQmFzZWxpbmUg UmVxdWlyZW1lbnRzIHdvdWxkIGRpY3RhdGUgdGhhdCBhbGwgbG9va3VwcyBNVVNUIGJlIHBlcmZv cm1lZCBhZ2FpbnN0IGFuIGF1dGhvcml0YXRpdmUgbmFtZXNlcnZlcikuDQoNClRoYW5rcywNCkNv cmV5IEJvbm5lbGwNClNlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg0KDQpUcnVzdHdhdmUgfCBTTUFS VCBTRUNVUklUWSBPTiBERU1BTkQNCnd3dy50cnVzdHdhdmUuY29tIDxodHRwOi8vd3d3LnRydXN0 d2F2ZS5jb20vPg0KDQrvu79PbiA1LzMxLzE4LCAyOjQ3IFBNLCAiU3Bhc20gb24gYmVoYWxmIG9m IEphY29iIEhvZmZtYW4tQW5kcmV3cyIgPHNwYXNtLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxm IG9mIGpzaGFAZWZmLm9yZz4gd3JvdGU6DQoNCiAgICBIaSBhbGwsDQogICAgDQogICAgSSd2ZSB1 cGxvYWRlZCByZmM2ODQ0YmlzIA0KICAgIChodHRwczovL3NjYW5tYWlsLnRydXN0d2F2ZS5jb20v P2M9NDA2MiZkPW84T1EyeXVqZ1ZFZUZsVjVibF9PcDR5U0FkdUdMM0M1VG1HV3pVamdxUSZzPTUm dT1odHRwcyUzYSUyZiUyZnRvb2xzJTJlaWV0ZiUyZW9yZyUyZmh0bWwlMmZkcmFmdC1pZXRmLWxh bXBzLXJmYzY4NDRiaXMtMDAlMjkgd2hpY2ggaXMgDQogICAgdGhlIFdHIHZlcnNpb24gb2YgDQog ICAgaHR0cHM6Ly9zY2FubWFpbC50cnVzdHdhdmUuY29tLz9jPTQwNjImZD1vOE9RMnl1amdWRWVG bFY1YmxfT3A0eVNBZHVHTDNDNVRtUEVuRWkzcEEmcz01JnU9aHR0cHMlM2ElMmYlMmZ0b29scyUy ZWlldGYlMmVvcmclMmZodG1sJTJmZHJhZnQtaG9mZm1hbi1hbmRyZXdzLWNhYS1zaW1wbGlmaWNh dGlvbi0wMyANCiAgICBEaWZmZXJlbmNlcyB2ZXJzdXMgdGhlIGxhc3QgZHJhZnQ6DQogICAgDQog ICAgLSBBZG9wdGVkIENvcmV5J3MgaW1wcm92ZWQgQUJORiBncmFtbWFyLCB3aGljaCBhbHNvIGFs bG93cyBoeXBoZW5zIGluIA0KICAgIHByb3BlcnR5IG5hbWVzLCBhbmQgc3BhY2VzIGFyb3VuZCB0 aGUgZXF1YWwgc2lnbnMgaW4gcHJvcGVydGllcy4NCiAgICAtIENsYXJpZmllZCBob3cgdG8gaGFu ZGxlIENBQSBSUnNldHMgdGhhdCBoYXZlIG5vIGlzc3VlIG9yIGlzc3Vld2lsZCANCiAgICB0YWdz LCBidXQgZG8gaGF2ZSBvdGhlciBDQUEgdGFncy4gVGhhbmtzIGZvciB0aGUgcHJvcG9zYWwgb24g dGhpcywgQ29yZXkhDQogICAgLSBBZGRlZCBhICJEaWZmZXJlbmNlcyB2cyBSRkMgNjg0NCIgc2Vj dGlvbi4NCiAgICAtIEVtcHRpZWQgdGhlIElBTkEgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiwgd2hp Y2ggd2FzIGNvcGllZCBmcm9tIFJGQzY4NDQgDQogICAgYnV0IGlycmVsZXZhbnQgYmVjYXVzZSB0 aGUgdmFsdWVzIGluIGl0IGhhZCBhbHJlYWR5IGJlZW4gcmVnaXN0ZXJlZCB3aXRoIA0KICAgIElB TkEuDQogICAgLSBBZGRlZCBhIHNlY3Rpb24gdG8gIkRlcGxveW1lbnQgQ29uc2lkZXJhdGlvbnMi IHJlZ2FyZGluZyBwcml2YXRlIA0KICAgIG5hbWVzZXJ2ZXJzLg0KICAgIC0gSW1wcm92ZWQgdGhl IHdvcmRpbmcgb2YgIkJvZ3VzIEROU1NFQyBSZXNwb25zZXMiIHNlY3Rpb24gKHVuZGVyIA0KICAg ICJEZXBsb3ltZW50IENvbnNpZGVyYXRpb25zIikuDQogICAgDQogICAgSWYgeW91IHdvdWxkIGxp a2UgdG8gcmVhZCB0aGUgaW5kaXZpZHVhbCBjb21taXRzLCB0aGV5IGFyZSBhdmFpbGFibGUgYXQg DQogICAgaHR0cHM6Ly9zY2FubWFpbC50cnVzdHdhdmUuY29tLz9jPTQwNjImZD1vOE9RMnl1amdW RWVGbFY1YmxfT3A0eVNBZHVHTDNDNVRqS1p5azI5cmcmcz01JnU9aHR0cHMlM2ElMmYlMmZnaXRo dWIlMmVjb20lMmZqc2hhJTJmY2FhLXNpbXBsaWZpY2F0aW9uJTJmY29tbWl0cyUyZm1hc3Rlcg0K ICAgIA0KICAgIFRoYW5rcywNCiAgICBKYWNvYg0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgU3Bhc20gbWFpbGluZyBsaXN0DQog ICAgU3Bhc21AaWV0Zi5vcmcNCiAgICBodHRwczovL3NjYW5tYWlsLnRydXN0d2F2ZS5jb20vP2M9 NDA2MiZkPW84T1EyeXVqZ1ZFZUZsVjVibF9PcDR5U0FkdUdMM0M1VGo2U25rbmtfQSZzPTUmdT1o dHRwcyUzYSUyZiUyZnd3dyUyZWlldGYlMmVvcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZzcGFz bQ0KICAgIA0KDQo= From nobody Wed Jul 11 12:46: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 42079130F83 for ; Wed, 11 Jul 2018 12:46:11 -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 UL3fE8xzPrxI for ; Wed, 11 Jul 2018 12:46:09 -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 943E0130F84 for ; Wed, 11 Jul 2018 12:46:09 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1F408B8196E; Wed, 11 Jul 2018 12:46:08 -0700 (PDT) To: alexey.melnikov@isode.com, weihaw@google.com, kaduk@mit.edu, ekr@rtfm.com, housley@vigilsec.com, tim.hollebeek@digicert.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: beldmit@gmail.com, spasm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180711194608.1F408B8196E@rfc-editor.org> Date: Wed, 11 Jul 2018 12:46:08 -0700 (PDT) Archived-At: Subject: [lamps] [Technical Errata Reported] RFC8398 (5418) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 11 Jul 2018 19:46:12 -0000 The following errata report has been submitted for RFC8398, "Internationalized Email Addresses in X.509 Certificates". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5418 -------------------------------------- Type: Technical Reported by: Belyavskiy Dmitry Section: Appendix B Original Text ------------- This non-normative example demonstrates using SmtpUTF8Mailbox as an otherName in GeneralName to encode the email address "u+8001u+5E2B@example.com". The hexadecimal DER encoding of the email address is: A022060A 2B060105 05070012 0809A014 0C12E880 81E5B8AB 40657861 6D706C65 2E636F6D The text decoding is: 0 34: [0] { 2 10: OBJECT IDENTIFIER '1 3 6 1 5 5 7 0 18 8 9' 14 20: [0] { 16 18: UTF8String '..@example.com' : } : } Figure 2 The example was encoded on the OSS Nokalva ASN.1 Playground and the above text decoding is an output of Peter Gutmann's "dumpasn1" program. Corrected Text -------------- This non-normative example demonstrates using SmtpUTF8Mailbox as an otherName in GeneralName to encode the email address "u+533Bu+751F@u+5927u+5B66.example.com". The hexadecimal DER encoding of the block is: a0330608 2b060105 05070809 a0270c25 c3a5c28c c2bbc3a7 c294c29f 40c3a5c2 a4c2a7c3 a5c2adc2 a62e6578 616d706c 652e636f 6d The text decoding is: 2 51: [0] { 4 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 8 9' 14 39: [0] { 16 37: UTF8String '..@...example.com' : } : } Figure 2 The example was encoded on the OSS Nokalva ASN.1 Playground and the above text decoding is an output of Peter Gutmann's "dumpasn1" program. Notes ----- The OID used in Appendix B does not match the OID for id-on-SmtpUTF8Mailbox defined in "Appendix A. ASN.1 Module" and is not mentioned anywhere in the RFC. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8398 (draft-ietf-lamps-eai-addresses-18) -------------------------------------- Title : Internationalized Email Addresses in X.509 Certificates Publication Date : May 2018 Author(s) : A. Melnikov, Ed., W. Chuang, Ed. Category : PROPOSED STANDARD Source : Limited Additional Mechanisms for PKIX and SMIME Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Jul 11 14:49: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 462AF130DDD for ; Wed, 11 Jul 2018 14:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 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_NONE=-0.0001, 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 ajGmNtoPcTCt for ; Wed, 11 Jul 2018 14:49:29 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 951CA130E29 for ; Wed, 11 Jul 2018 14:49:29 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id d191-v6so337524ite.1 for ; Wed, 11 Jul 2018 14:49:29 -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=otBJO8S4eaSH4y4LWu48RHJyNp+82AI1uI4RPpDCPdA=; b=jLXOSN8lAYQt68LQ01NXsDHZnyMmucXaQkBqulkfG359gwljrMlk3BkjjQA+HhV1O6 PNEzjugg5l1GtO4Tn03rXerQ8XQxNvurz/rihkn+krmlGInUUSNzpgm3iVTMP7w/RnDQ UumPOnz16b0fag6rXmZOgtZFtXyEnZx8ZPZ8wJ8wgm2Xm+/X8eyEQHpKsS681Wd9+UcM Jt9xPFoMRPPBfY1fbzq+iWWO0m7UVgkdD60M/YoJD5LdZHt2wKI9CX4cmvB7VCHn38Sj RhLpZ8a9oTXr8KmD42XIBSB3hiT1WqONCd5mod8EqAZw1scVQay0ALKGXxUcc7p+1oBW a8aA== 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=otBJO8S4eaSH4y4LWu48RHJyNp+82AI1uI4RPpDCPdA=; b=DSK4Pnr3v1YGkkLmRfDuwBGmtmDBMsZvYUu/s4tSbkcdkXhUAj7Y/Y+HCZQE80S69T Tc878suPR+twH0F/O6/DbT5UAv7+8+1FwN/vaSX15r4JrDvtrnQfF2YVIAA5ruUDV6Ro mgmjeUWiY6MyfBE+aBSy+DjpqRm0QmgK66Pscx669adISMvmlG6YdleM6bVyb5OLfBUl o+0Z3ZpJCiVMNKJaYXkHzgcK4fiJei4DD+vEDJWRigamk07W1k0CE97hd8XgheD9RDa6 kshq6S442dAK6DMw3CtaCxzn4MsHhQgnQbyuVb0lpVg0G8g1dzFWe5gsFbKhu/0G87Rp ozdA== X-Gm-Message-State: AOUpUlE3AejZDe9C++YLEkP2vXaVQqP9kgNNNnWv20V7vnmELpNnaqsP AxUHxDOmMLGi6+fhQ1yuDQ5tGYsqkKmloftx2aykxw== X-Google-Smtp-Source: AAOMgpcReJm2JkMQQm59TYFyefPkYY2mhaN1T+Kj//v3HonoVyP8c/NqgRtgW7DtETu3HorkxKDSWOAlDRceGDUgxUQ= X-Received: by 2002:a02:4f92:: with SMTP id r18-v6mr221675jad.9.1531345768433; Wed, 11 Jul 2018 14:49:28 -0700 (PDT) MIME-Version: 1.0 References: <20180711194608.1F408B8196E@rfc-editor.org> In-Reply-To: <20180711194608.1F408B8196E@rfc-editor.org> From: Wei Chuang Date: Wed, 11 Jul 2018 14:49:16 -0700 Message-ID: To: rfc-editor@rfc-editor.org Cc: Alexey Melnikov , kaduk@mit.edu, ekr@rtfm.com, Russ Housley , tim.hollebeek@digicert.com, Dmitry Belyavsky , SPASM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000097d1120570c0383c" Archived-At: Subject: Re: [lamps] [Technical Errata Reported] RFC8398 (5418) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 11 Jul 2018 21:49:32 -0000 --00000000000097d1120570c0383c Content-Type: multipart/alternative; boundary="0000000000008ef7c50570c038f2" --0000000000008ef7c50570c038f2 Content-Type: text/plain; charset="UTF-8" Hi all, I agree with the errata report. Background is that I've already been discussing with Dmitry the bug, and suggested he file the errata so we can make the change. The bug is in the SmtpUTF8Mailbox OID in the example found in the Appendix. I also agree with him that we can update the email address to be consistent with the earlier example on page 6 in case the original is confusing. -Wei On Wed, Jul 11, 2018 at 12:46 PM RFC Errata System < rfc-editor@rfc-editor.org> wrote: > The following errata report has been submitted for RFC8398, > "Internationalized Email Addresses in X.509 Certificates". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5418 > > -------------------------------------- > Type: Technical > Reported by: Belyavskiy Dmitry > > Section: Appendix B > > Original Text > ------------- > This non-normative example demonstrates using SmtpUTF8Mailbox as an > otherName in GeneralName to encode the email address > "u+8001u+5E2B@example.com". > > The hexadecimal DER encoding of the email address is: > A022060A 2B060105 05070012 0809A014 0C12E880 81E5B8AB 40657861 > 6D706C65 2E636F6D > > The text decoding is: > 0 34: [0] { > 2 10: OBJECT IDENTIFIER '1 3 6 1 5 5 7 0 18 8 9' > 14 20: [0] { > 16 18: UTF8String '..@example.com' > : } > : } > > Figure 2 > > The example was encoded on the OSS Nokalva ASN.1 Playground and the > above text decoding is an output of Peter Gutmann's "dumpasn1" > program. > > > Corrected Text > -------------- > This non-normative example demonstrates using SmtpUTF8Mailbox as an > otherName in GeneralName to encode the email address > "u+533Bu+751F@u+5927u+5B66.example.com". > > The hexadecimal DER encoding of the block is: > a0330608 2b060105 05070809 a0270c25 c3a5c28c c2bbc3a7 c294c29f > 40c3a5c2 a4c2a7c3 a5c2adc2 a62e6578 616d706c 652e636f 6d > > > The text decoding is: > 2 51: [0] { > 4 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 8 9' > 14 39: [0] { > 16 37: UTF8String '..@...example.com' > : } > : } > > Figure 2 > > The example was encoded on the OSS Nokalva ASN.1 Playground and the > above text decoding is an output of Peter Gutmann's "dumpasn1" > program. > > Notes > ----- > The OID used in Appendix B does not match the OID for > id-on-SmtpUTF8Mailbox defined in "Appendix A. ASN.1 Module" and is not > mentioned anywhere in the RFC. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8398 (draft-ietf-lamps-eai-addresses-18) > -------------------------------------- > Title : Internationalized Email Addresses in X.509 > Certificates > Publication Date : May 2018 > Author(s) : A. Melnikov, Ed., W. Chuang, Ed. > Category : PROPOSED STANDARD > Source : Limited Additional Mechanisms for PKIX and SMIME > Area : Security > Stream : IETF > Verifying Party : IESG > --0000000000008ef7c50570c038f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I agree with the errata rep= ort.=C2=A0 Background is that I've already been discussing with Dmitry = the bug, and suggested he file the errata so we can make the change.=C2=A0 = The bug is in the=C2=A0SmtpUTF8Mailbox=C2=A0= OID in the e= xample found in the Appendix.=C2=A0 I also agree with him that we can u= pdate the email address to be consistent with the earlier example on page 6= in case the original is confusing.

-Wei

On Wed, Jul 11, 2018 at 1= 2:46 PM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata report has been submitted for = RFC8398,
"Internationalized Email Addresses in X.509 Certificates".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5418

--------------------------------------
Type: Technical
Reported by: Belyavskiy Dmitry <beldmit@gmail.com>

Section: Appendix B

Original Text
-------------
=C2=A0 =C2=A0This non-normative example demonstrates using SmtpUTF8Mailbox = as an
=C2=A0 =C2=A0otherName in GeneralName to encode the email address
=C2=A0 =C2=A0"u+8001u+5E2B@example.com".

=C2=A0 =C2=A0 =C2=A0 The hexadecimal DER encoding of the email address is:<= br> =C2=A0 =C2=A0 =C2=A0 A022060A 2B060105 05070012 0809A014 0C12E880 81E5B8AB = 40657861
=C2=A0 =C2=A0 =C2=A0 6D706C65 2E636F6D

=C2=A0 =C2=A0 =C2=A0 The text decoding is:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 0=C2=A0 34: [0] {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 2=C2=A0 10:=C2=A0 =C2=A0OBJECT IDENTIFIER '= 1 3 6 1 5 5 7 0 18 8 9'
=C2=A0 =C2=A0 =C2=A0 =C2=A014=C2=A0 20:=C2=A0 =C2=A0[0] {
=C2=A0 =C2=A0 =C2=A0 =C2=A016=C2=A0 18:=C2=A0 =C2=A0 =C2=A0UTF8String '= ..@exam= ple.com'
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 2

=C2=A0 =C2=A0The example was encoded on the OSS Nokalva ASN.1 Playground an= d the
=C2=A0 =C2=A0above text decoding is an output of Peter Gutmann's "= dumpasn1"
=C2=A0 =C2=A0program.


Corrected Text
--------------
=C2=A0 =C2=A0This non-normative example demonstrates using SmtpUTF8Mailbox = as an
=C2=A0 =C2=A0otherName in GeneralName to encode the email address
=C2=A0 =C2=A0"u+533Bu+751F@u+5927u+5B66.example.com".

=C2=A0 =C2=A0The hexadecimal DER encoding of the block is:
=C2=A0 =C2=A0a0330608 2b060105 05070809 a0270c25 c3a5c28c c2bbc3a7 c294c29f=
=C2=A0 =C2=A040c3a5c2 a4c2a7c3 a5c2adc2 a62e6578 616d706c 652e636f 6d


=C2=A0 =C2=A0The text decoding is:
=C2=A0 =C2=A0 =C2=A02=C2=A0 51: [0] {
=C2=A0 =C2=A0 =C2=A04=C2=A0 =C2=A08:=C2=A0 =C2=A0OBJECT IDENTIFIER '1 3= 6 1 5 5 7 8 9'
=C2=A0 =C2=A0 14=C2=A0 39:=C2=A0 =C2=A0[0] {
=C2=A0 =C2=A0 16=C2=A0 37:=C2=A0 =C2=A0 =C2=A0UTF8String '..@...example.com'
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 2

=C2=A0 =C2=A0The example was encoded on the OSS Nokalva ASN.1 Playground an= d the
=C2=A0 =C2=A0above text decoding is an output of Peter Gutmann's "= dumpasn1"
=C2=A0 =C2=A0program.

Notes
-----
The OID used in Appendix B does not match the OID for id-on-SmtpUTF8Mailbox= defined in "Appendix A.=C2=A0 ASN.1 Module" and is not mentioned= anywhere in the RFC.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8398 (draft-ietf-lamps-eai-addresses-18)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: International= ized Email Addresses in X.509 Certificates
Publication Date=C2=A0 =C2=A0 : May 2018
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A. Melnikov, Ed., W. Ch= uang, Ed.
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Limited Additional= Mechanisms for PKIX and SMIME
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
--0000000000008ef7c50570c038f2-- --00000000000097d1120570c0383c 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMTZjj07BnE8UdCkPpMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDYxODE4NDI1NFoXDTE4MTIx NTE4NDI1NFowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCT9auzAMJFxJw2nck+6fp27hHYam/2StGY5mIbF6g8b8f6hl5v K6eScLyqimYdQSWUXaG9hGRmqZ4oLCWv5/ybrg55CgNdUea9xe663vqlQ3smSA/AYHToLLZ6YtYC /Xpc9blxrsnJtZ4QY83HOFyiLbysmkwrhlvGaPtN3W/2meTsJsAfSrIbUCBijcwq7GQV20bhj4MG MEJm6a6y+92fzmmG7OHrF1fLofi07yW+3ZXVsK/6PpEbCxd1Ni+eMh96x6Iua5KP+CE8S+vlHyoZ JmiyDntVMpTGuC/P4baHfUouHcqVqw1mevEa3MaIxBWaG5/eSdyqCB4o+4Nbz+NbAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFCkFHZFfStM1ze4EOO/TF2JQ/qnEMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB0JGN5bYsugmrkUIFI ZIeAPT35qf5pCKnOUa5KRNZwcoZknd0KZSb7Z7WAk01drzzRPakei5/BQ2ZErir0q9TrD9slWj7v Bj8OSHZdY4mr/tnm9dTGPnBeAjWiFsK+zfHp6yH7Acn2a7jMrmB5YkRj73AwL6I1o6bES3C4GhHD IwuzcFPOrSArE5sQU2jDsw38+8/dtIGHCbYugIRHRkc4j2uRzppgyJXhV7xRVPQlbO4aIV1+sa6K nMvin8RgAdFONRVt6dPwqjPB+oie8/qV2ZE/azkud1lbdSQn7Q8PjWoBXLXAPsiz/6qzp6M0ZErk Bt1327YAeKyS71oiwO7JMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMTZjj07Bn E8UdCkPpMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCxyYfD4RgxdMbuNIZc1BHg dlFpjco4vkixl68dFbZfIzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA3MTEyMTQ5MjlaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAjLKhJtqxg3Vcq94ch4NimKEWDYtBLbkwULNIvkAz a21qSWAeVMvsuk/5ER/KW/FuEdLntdB/XNUflDcbWIORku5ZcWrB5Kpkr8+/R1kZ8UwbLMBqy3VQ cXUjMgozl9VHi+e0kh0NnCSdfB4AIDcoTjXQiLRVdR6XFrsqaiDDUeA5jtDy1Mp2GjIf7ZL82uQ7 LAowdKnSQXu0ZCFt79oxGjThe1V9ME49Oy3Dk90vClYdHdQI3eduw3OflQxmLo+8QxsFuiYFWhXN ZTRHwyrB24lMgHhLTsVLY3C5lK66wwlGjo31F6OJDkt1PzDT8R5cH4AEUnqegpB4BxioxXKw+A== --00000000000097d1120570c0383c-- From nobody Sat Jul 14 06:38:34 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 ED50E130FD1; Sat, 14 Jul 2018 06:38:17 -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.3 Auto-Submitted: auto-generated Precedence: bulk Cc: spasm@ietf.org, lamps-chairs@ietf.org, The IESG MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <153157549796.12793.7969603954411147098.idtracker@ietfa.amsl.com> Date: Sat, 14 Jul 2018 06:38:17 -0700 Archived-At: Subject: [lamps] WG Action: Rechartered Limited Additional Mechanisms for PKIX and SMIME (lamps) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 14 Jul 2018 13:38:18 -0000 The Limited Additional Mechanisms for PKIX and SMIME (lamps) WG in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. 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 the approach used in RFC 6844. 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 short-lived certificates is unnecessary and 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 mechanism to protect present day communication from the future invention of a large-scale quantum computer. The invention of a large-scale quantum computer poses a serious challenge for the key management algorithms that are widely deployed today, 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). Hash-based signature use small private and public keys, and they have 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; however, since hash-based signature algorithms are secure even if a large-scale quantum computer is invented. The low computational cost for signature verification makes hash-based signatures attractive in the Internt of Things environments, and the quantum resistance makes them attractive for 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 Sat Jul 14 09:01: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 5835C131117 for ; Sat, 14 Jul 2018 09:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=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 PQgM3NV1BiE0 for ; Sat, 14 Jul 2018 09:01:12 -0700 (PDT) Received: from mail1.bemta24.messagelabs.com (mail1.bemta24.messagelabs.com [67.219.250.112]) (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 B535913110A for ; Sat, 14 Jul 2018 09:01:09 -0700 (PDT) Received: from [67.219.250.196] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-b.us-west-2.aws.symcld.net id D4/66-15908-54E1A4B5; Sat, 14 Jul 2018 16:01:09 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTe2xLcRTH/Xr7uNidu27TozqPBsHcak0QJAg SFhJiIhnCnd6tpY+lt4vxlz+YxzybTrJh7RDJZk/KvLZQ722xtawR9rBsxGaKTIhlHvf2V6+b /H75nPM9r5z8Lkko8xRqkst1cg4ba9HKR0ifT/BtYJaNS92oL342bV5xaNtitOL8+W+SNShdZ rZl2HO3ykzBw2Xy7HBabsXjrXvQ4JpDaAQppQ8TcLqxlRANJX1MAoOhIRk22hGc7CkRjOGknN ZDqO6hROQEWg39B2oiHE8bIPD6qgz750D+54ACsw5KAyG5yFJ6MuzrLowwRW+GR4M+QmREj4a vDeWROgStghc9nggDnQBdgUY55kTo7f4hw/Gb4MyAP+rXgr/uM8KcBEFPPhKHBvqKBIYCLQos MPCxoEBoRgq8Grp9dhzzEkH1jfpozHT4GfBGG1ugvtUdbZAKP5uOEZjHQdmRLilOrieguaknG qSB8qb+aJBXBqdOxYmspI3gLhMnFROOE3DLc4TA61JD+7ODCLMG3rbVyY6jqUX/bKBIyCFoL4 KzweuyosjK4uBxYY8UB6XDi70nEGYGbtTfJjCPh9r3p6M8A/I6G6OcDBdK3gmsEHgh+IzYOxH c+V0KzHMg78knuReNLEPzMhzmLJPTypotjEGvZwyGWYwhRTwpOnY3k6HL4ZmdHO9kZunYnbyO 32XdZjHqbJzzEhJe4DDhu4Y6/UY/GkNKtInUU2XqRmVsht24y8Typi2OHAvH+5GGJLVA3dcIW pyDy+JyM80W4Rn/loGM0SZQblGm+GzWypuzsNSAFpHhUpeLIO91uIW7JXIPfShwEUqpzW7j1C rquphGi2mmHNufor9/jyBKUsdTSBhTGZPNOaxm5/96H1KRSBtPPRerxJhtzj+9+4SxJMJYugM rxbGc7F9JvQfZM9dernxlzT7XojRVpd3ZEvM9mD66dsEozc3Cu60fhoW/zG2b4SFzRl7oXX5t 3UDabFX4pMYzxtf8JvFWiks/5cv6RW9Kk7svBjtSx9YUz2TehiQqd0Vcx/xSV+BiedXAJMWO2 M7qpIol+xuODm/2PE0p9D6odNeEt1Or7vYtXRo7TSvlTaxhOuHg2V8zMLXdGQQAAA== X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-2.tower-344.messagelabs.com!1531584067!1376797!1 X-Originating-IP: [216.32.180.87] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12776 invoked from network); 14 Jul 2018 16:01:08 -0000 Received: from mail-sn1nam04lp0087.outbound.protection.outlook.com (HELO NAM04-SN1-obe.outbound.protection.outlook.com) (216.32.180.87) by server-2.tower-344.messagelabs.com with AES256-SHA256 encrypted SMTP; 14 Jul 2018 16:01:08 -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=pQvRW2+zxBx9LdBn9mdWWm5NW1fBp4C+V2/ZsjnWSDI=; b=nmLVNZ8ivyrjdysK9e3WOJka1miMHJ3NjsOcrG3jwxDW2HCeQkvHKiyN3WZ1Nl0Orjvzg8WwDPyHk08IckAVksd/c8lazhvRcNz9oBTYW4BCEOUHt7cPHvp+GAKm43WSgV9d46i1iYZCUFBaSMfk8U/GPacmgX348psFOwMR29Q= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1409.namprd14.prod.outlook.com (10.172.150.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.18; Sat, 14 Jul 2018 16:01:06 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::b914:e52:554d:c7bb]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::b914:e52:554d:c7bb%9]) with mapi id 15.20.0930.016; Sat, 14 Jul 2018 16:01:06 +0000 From: Tim Hollebeek To: SPASM Thread-Topic: Call for adoption of draft-nir-saag-star Thread-Index: AdQbi7TLYfqtpY+TTqSneU/7I8lfxA== Date: Sat, 14 Jul 2018 16:01:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [31.133.155.236] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1409; 7:guf03/HuaUp5S8PUbRTPY7B2T1OtpM/KU+sb8aP8Hd53oDnPU03NtZfwV6yj4CNCOQzf0p7ASliqIY0zMb3BZ1SspOqajKPKN+ebXgpUGFWTnQQZ8hE9aKTPWUvFXPR28fh0vizBbyfxOtzOWScVuV9pg7qDtunetWHK+5A71g+FLFXxqWpoGqtw2z3gm9QLKXQdiqIlDsmlTDqnKeI14s4T6Zb1wDfUcqDi8X084cr1HXtI2E9FC0nsfK2fKk6+ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 8356a59e-b5d7-43eb-daca-08d5e9a301ca x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1409; x-ms-traffictypediagnostic: BN6PR14MB1409: 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)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(149027)(150027)(6041310)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:BN6PR14MB1409; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1409; x-forefront-prvs: 07334CBCCD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(136003)(346002)(366004)(376002)(189003)(199004)(99936001)(3846002)(55016002)(9686003)(53936002)(6916009)(256004)(97736004)(6306002)(54896002)(74316002)(68736007)(5660300001)(66066001)(7736002)(14454004)(8676002)(8936002)(33656002)(106356001)(790700001)(105586002)(81156014)(6116002)(6436002)(478600001)(25786009)(81166006)(186003)(44832011)(2900100001)(26005)(99286004)(5250100002)(476003)(86362001)(2906002)(6506007)(7696005)(102836004)(316002)(14444005)(486006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1409; 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: Jc+VHS5jj0okBdg/xUCoEp6ubOL4ZmlWA65xwV/5iMb//z24ZxUEER9Gx6fWGKDNbMzzauIokW4hYdRrzN1O9tSZr30PSXmpTH+d1SuTBqT9atmEK+WKMkn4gXKEWrE/gGnlZk1XF+hjqHxAswy8sBB10HwQAhhphlxJeglwDBpQ8TdxKeEaVbT+4Jx3QkIMHEkg2K0YqYN/88BquqF0Imzyn7GxwrT2YIdB8lCXNLizmhAsSywkzAf5CkFl3s/h/7r8dwTiIDxNsvyVhIiQCNvy0rrAyzFmRiNHFLZaTZoX9o428l1e+7nvr1v7gj1Dk6GBQFf8ky6UpcPb+IzzOGCvNNsRQVXEqBPY1ewPG8o= 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_0CB7_01D41B6A.4C15D6D0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8356a59e-b5d7-43eb-daca-08d5e9a301ca X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2018 16:01:06.0444 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1409 Archived-At: Subject: [lamps] Call for adoption of draft-nir-saag-star X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 14 Jul 2018 16:01:28 -0000 ------=_NextPart_000_0CB7_01D41B6A.4C15D6D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0CB8_01D41B6A.4C15D6D0" ------=_NextPart_001_0CB8_01D41B6A.4C15D6D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The recently approved LAMPS WG Charter adds this work item: 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 short-lived certificates is unnecessary and pointless. It has been suggested that the WG adopt draft-nir-saag-star as the starting point for this work. Please voice your support or concerns on the list. ------=_NextPart_001_0CB8_01D41B6A.4C15D6D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

The = recently approved LAMPS WG Charter adds this work item:

 

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 short-lived = certificates is unnecessary and pointless.

 

It has = been suggested that the WG adopt draft-nir-saag-star as the starting = point for this work.  Please voice your support or concerns on the = list.

 

------=_NextPart_001_0CB8_01D41B6A.4C15D6D0-- ------=_NextPart_000_0CB7_01D41B6A.4C15D6D0 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 CQUxDxcNMTgwNzE0MTYwMDQ1WjAvBgkqhkiG9w0BCQQxIgQgTFPOPOK/D6lYUWVbBzTBbAn0YVi2 6xY69yiSrfx9byIwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAIWReEC/CX5Mwl8igkb0Y/4u09/hzAFC8ZNDvaAW5ISS7Ww3mUads6ewaz43r8CI9SLmzVve jHetKrY+iZH+dzk2r7Iy80cWc3RTyQ0srpSRQLegzJGzeHijzimMn0s3Q5EmcPVSJABseONqoieC HB1w4SRtoTqcL+9NvBtpsAsh8UN9Uy4cVnUU0kYx/PDE+Ba/Apdy4HBX8gssPP5ofUomaPM18azZ 7v129Vf5yKE1TKehlDCOIVrRmRonFBeakIL6OSi5FaSOKgPSK+ALizhHUkE51nHsPdLpe966TRMu Yi3DSn2t5JisaJE//D+zNxpGFByc1qKAV6833CQZvjIAAAAAAAA= ------=_NextPart_000_0CB7_01D41B6A.4C15D6D0-- From nobody Sat Jul 14 09:02: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 8DB5F1310D6 for ; Sat, 14 Jul 2018 09:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=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 FqbzFF7Y-Ge7 for ; Sat, 14 Jul 2018 09:02:31 -0700 (PDT) Received: from mail1.bemta24.messagelabs.com (mail1.bemta24.messagelabs.com [67.219.250.3]) (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 5435E1277D2 for ; Sat, 14 Jul 2018 09:02:31 -0700 (PDT) Received: from [67.219.250.100] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-a.us-west-2.aws.symcld.net id 54/BC-01617-69E1A4B5; Sat, 14 Jul 2018 16:02:30 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTaUwTQRTHne62XbUlawH7rKBSYzToNi0qomC URI1ijCZ+MYrKQlfapBTSLeH6AmoQQUMDFEJFUIMXHlGsAQ+INl6oEUGDB6BWMVE8ABGPiOJu p3jMh8lv3v+9t/99maEI1S65huIy7ZzNylq0snHk42nn3Uz5lLhN+mfu8VHVHUlL0cra2u+Sd Wij1GxNTM1MkJpqr36Qp3k2ZBZ61blocH0hGkeR9B4Cdn4slYoHFV0sgYd5p+T40I2g5kwFUY jGUjJaDx1NNyUiB9EaeF9w1seBdAy0Htshx/FY6M3bhTDr4HBBLikySc+AN/1uX1xJb4a2yiG ZyIieCF9vn/T1IWg1PO2p8THQQeBtuyPDHAxvX/2S4vx42D/o8ce14Gn6jDCHQntNERJNA31e AiPeU36BgX6nU/gBSuA10PljC87pRFB6rNmfEw7nDl2VYrZA0Ysufzwebpy+SWKeAnV7vSQub iag5VG1XwiBk3ffE1gol8I5Z7Gvk4o2QlmdaFUUHATUOxwyPC8NdD/cjTCHwJuuJqkDzXL9Mw KXUEPQBxCc6KyXuHwzmwAtlT0kTtoIPe4qOWYGLjZfITBPhYYPVX6eA/nP7/h5Nhw5+E5gucA x4DbiaBiUFXn9XSIh/96A7AAaX4eiEm3mZJM9hTVbGINezxgMEYwhIoqJmLtQx2YzrC6dZzI4 3s5E6NgMXsdnpSRZjDorZ69HwhUcI6xG9MRj9KBJlEQbrHygitukCkhMNWaZWN601ZZu4XgPC qEoLSjnhwraBBuXzGVuM1uEezwqA6XQBilXibKST2NTeHMylm6jJdTH4yUlBHXtWZmw3/ftw3 3OEkJFWlOtnEatVIhltFhmSrf+aTr6PtpRqCZQiQSbKkUaZ0sx2//Xe5GaQtpAZbDYRWG22v9 8u1ewJRFs6QpWibbs7F9Jk4sSBlsWOF02qbGCWzR5X84DzZdWiSu7OzJ12RlH5QV5eM7awtLs RvrGvUsNms7rtjUm7iW7OGPaZ/XW6JmXu16PaZ1VnFS9eF76cset2Qmbt6+Oj57uuB8X29HmW HbZOGRdoXBOfHn02vDPqICBT9v6vulrwwL7BofaLxwOOzsyEpn/S0vyJtYQTth49jfpMRlHGg QAAA== X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-8.tower-324.messagelabs.com!1531584149!1710837!1 X-Originating-IP: [216.32.181.180] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4139 invoked from network); 14 Jul 2018 16:02:30 -0000 Received: from mail-by2nam01lp0180.outbound.protection.outlook.com (HELO NAM01-BY2-obe.outbound.protection.outlook.com) (216.32.181.180) by server-8.tower-324.messagelabs.com with AES256-SHA256 encrypted SMTP; 14 Jul 2018 16:02:30 -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=mXPaWu8tR/J997QSM6OpYZZZURfMXGll/02ewN5ikgg=; b=Bn+jTJ+053q3JYqO0SzC67wFQmPwriqXkLH4A8rZUxT8WErWLWZMU7NoMNTepk3QAFTBLF8P8AvxlRbtEvQxyKYR0rKoV+ZyAUEgdxDj3EnzQY5UK2PY2z5l6jXA3+IzUOKiE0yCPQU6KzXoG7uWGH5QZ3k/NruRl9wYvVKQcyA= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1460.namprd14.prod.outlook.com (10.172.151.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.19; Sat, 14 Jul 2018 16:02:27 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::b914:e52:554d:c7bb]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::b914:e52:554d:c7bb%9]) with mapi id 15.20.0930.016; Sat, 14 Jul 2018 16:02:27 +0000 From: Tim Hollebeek To: SPASM Thread-Topic: Call for adoption of draft-housley-cms-mix-with-psk Thread-Index: AdQbi+j7uWfkh4RtSC+OA7IVSzE2sA== Date: Sat, 14 Jul 2018 16:02:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [31.133.155.236] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1460; 7:3HpV67q50IJy1gXLZzS0t98yRt7PYVX8BE+QZvQOzgHg2yxoStH0lvsjN0U0eaFCXKGogfBusayT/Qz9AOMgNxEBVnKQ4bfykRDCtocRzudD9NLuCWnFfv02g1EvON/sD05t4oZOMgOibLSB1JacuDIBoX2kd5ilh8fF7RufUdFOC6DsgcA7VHCKxdOJ/uJYUcejdDH26YFLG0Iwmr6UNW6kBGSlo0gplxbSxHfPP9UGQ3sz/h2iX69C+kI92ihs x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 36af64f1-73bb-4df9-dea5-08d5e9a33223 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1460; x-ms-traffictypediagnostic: BN6PR14MB1460: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(100405760836317)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:BN6PR14MB1460; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1460; x-forefront-prvs: 07334CBCCD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39860400002)(136003)(346002)(396003)(199004)(189003)(97736004)(6116002)(44832011)(2900100001)(5660300001)(66066001)(3846002)(790700001)(26005)(316002)(486006)(478600001)(256004)(99936001)(33656002)(476003)(99286004)(186003)(14454004)(102836004)(68736007)(2906002)(6916009)(9686003)(54896002)(6506007)(86362001)(6306002)(53936002)(6436002)(7696005)(55016002)(8936002)(106356001)(8676002)(5250100002)(7736002)(74316002)(81166006)(105586002)(81156014)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1460; 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: ObmH+p2kP/G8KOWIOTQhfmhqan5AQR44APtzjYNT8KHZbB+IxshjQrZfGSGm+xAU2EZaM8UCB9gLx9Vm8PC17C+YBouBXqC9+YoUDbjsIskEe4zonFJIzWssazdHZTZXAxffCYlp8moPK6IAJ2mc3Q1HHSq+UZYNS1NU6hYim1vWmHUZlc/Avl4tN9D3pwdvelMqE/2zPykz37Qb+ypiE6OUYu9iNh6hG3pU9pr0lBw0oY4XKzUVcB2QFKT3ndTE7rZRW+mMLqTLDy9f36HM7Lxo8yB5p0i/pjNQfhXa4Oshuk+sORhZFI1qfcP0wvbuPIpS2IU/cr1unGPs+lYQXRPtrf07gpz2HeFyihWog0s= 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_0CBF_01D41B6A.7CA61710" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 36af64f1-73bb-4df9-dea5-08d5e9a33223 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2018 16:02:27.1214 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1460 Archived-At: Subject: [lamps] Call for adoption of draft-housley-cms-mix-with-psk X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 14 Jul 2018 16:02:34 -0000 ------=_NextPart_000_0CBF_01D41B6A.7CA61710 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0CC0_01D41B6A.7CA61710" ------=_NextPart_001_0CC0_01D41B6A.7CA61710 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The recently approved LAMPS WG Charter adds this work 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 mechanism to protect present day communication from the future invention of a large-scale quantum computer. The invention of a large-scale quantum computer poses a serious challenge for the key management algorithms that are widely deployed today, especially the key transport and key agreement algorithms used today with the CMS to protect S/MIME messages. It has been suggested that the WG adopt draft-housley-cms-mix-with-psk as the starting point for this work. Since Russ Housley is the author of this draft, Tim Hollebeek will judge consensus for this discussion. Please voice your support or concerns on the list. ------=_NextPart_001_0CC0_01D41B6A.7CA61710 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

The = recently approved LAMPS WG Charter adds this work 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 mechanism to protect present day communication from the = future invention of a large-scale quantum computer.  The invention = of a large-scale quantum computer poses a serious challenge for the key = management algorithms that are widely deployed today, especially the key = transport and key agreement algorithms used today with the CMS to = protect S/MIME messages.

 

It has = been suggested that the WG adopt draft-housley-cms-mix-with-psk as the = starting point for this work.  Since Russ Housley is the author of = this draft, Tim Hollebeek will judge consensus for this = discussion.  Please voice your support or concerns on the = list.

 

------=_NextPart_001_0CC0_01D41B6A.7CA61710-- ------=_NextPart_000_0CBF_01D41B6A.7CA61710 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 CQUxDxcNMTgwNzE0MTYwMjA3WjAvBgkqhkiG9w0BCQQxIgQgAyyugufSRI9BVNsSUCdQUGhJxWD1 9inXUR5aSO8wshIwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAH/AUyeijDhsraTp/NzX0sspo55imsvvNDQpeevD5TJFrdJwhnpx0Smbf9JNRU3v0vMp5WcJ EVUe+fexDxbDK4VargXhDj+iX3PBay+M5bVF2C1mMIkLlCjd/fESeA7agy8SkGB0RSvTlasMANuG gZqdzONpo/ksG6VPqsAd2PJZnI12+fOw5fFhf47u+/GvZMX8fCjybU5Mg19v8Y/40zZp2vjMX+KS aReEyeR06Bkprz7FpDrcg84uGsnUsJLVcbQyd/mZmnbCdRyxsz30+jL/0B6BCXmf+SXfCPpQ7dpF 7SF9GZH0eBJKIGPtbN786tmYwIIRgbYTsQuQSt7H47MAAAAAAAA= ------=_NextPart_000_0CBF_01D41B6A.7CA61710-- From nobody Sat Jul 14 09:03: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 144B3130DF9 for ; Sat, 14 Jul 2018 09:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=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 BUFXHkabqHBK for ; Sat, 14 Jul 2018 09:03:13 -0700 (PDT) Received: from mail1.bemta24.messagelabs.com (mail1.bemta24.messagelabs.com [67.219.250.210]) (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 61AF113112D for ; Sat, 14 Jul 2018 09:03:13 -0700 (PDT) Received: from [67.219.251.52] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-c.us-west-2.aws.symcld.net id BB/FB-01615-0CE1A4B5; Sat, 14 Jul 2018 16:03:12 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTa0gUURTHuzv7mMyRcbU8Lb5aKEKdbdcoLBa sPkSpRRB9UaNGd3IXdlfZGfFRgVSEjyIzJZXSVVRUJLKyQlB0sUwNKzOzzMo0zXeRYQ+JZrzb 68K9/Pj/zzn3cLiXJNRnVBqSSxc4h521apUe8sHgpptMW2BUnL683CuibCBxB9pTVfVNdgDFK iz2hOT0owrz/JcGWcqD2PT+nNNEFnp5KBetJOX0OQKK3kdKrKYvyCBraFsu8hB5GMFAc6lKMp S0HgZaOmUS+9IamMluXGYf2gjVNdUik6K+ExoHt2PUQW1pOC6/HlzF91SSTNGHoa4pQpIRvQY WuxuWixC0H7wcK19moH1h5EmPEvNqmBz9qcDx8XD1s8uta8HVsoAwB0BfeR6SOga6SQZzrQ0E Nhj4WFTk5n3gyh9V4qAhBJdqW93ZIXCzsl2B2Qqvbgy69Xi4f61TjjkQ6s+PyHFyKwFdz8vch j80PJwhsOFUwFxdGcJTNEFhvct9XT4BE9MVCjwtDQz35yDM/vDhVYsiH20s/WcGpWIOQTsRtB eOKyWDor2hq2RMjoNioXKhB2FmoLm1jcAcBHdmr7g5DM6+6XFzKNRUTIusEtkIt0xYXQeFeSM qzFvhbO8npROtqkcRCQ5LklmwsRYrY9DrGYMhnDFs3ibuLTo2k0nUpfJMGscLTLiOTeN1fIYt 0WrS2TnhBhLf3wpx3UU/XCYXWkvKtKupp+qoOLVXQrIpw8zy5iOOVCvHu5A/SWqBmg0QPW8Hl 8SlH7NYxUf82wbSU+tL5Uo2xaewNt6ShK1uFEnO1RUUEGTH60LxfLx8Ls0XFRBquT3Zzmn8qA 9SGi2lmVPtf4r+/hx9KEDjQyGxTbVnCuewWYT//SnkRyKtD9UlVfG02IU/d0+JbcnEtnTZe6W 2BPavpclCttDDJq9D1xZibKHyrLRh2fHi8fMHg7c7W96Zpz0GK+Ymdqt3nbx+e1PlhuIx7XR7 WMz+65OjgvHMzvX39pTtgujJjeTbRWNJZteRuBe5b4IMk/EXrU6u+f5Xqq9ujf6UeuhZdF5kb YB34zjTf3kdbZ7oFYzRft7tHbXfTzxaSurQynkzawghHDz7C8vp05oXBAAA X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-29.tower-364.messagelabs.com!1531584191!1449322!1 X-Originating-IP: [216.32.181.179] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2640 invoked from network); 14 Jul 2018 16:03:12 -0000 Received: from mail-by2nam01lp0179.outbound.protection.outlook.com (HELO NAM01-BY2-obe.outbound.protection.outlook.com) (216.32.181.179) by server-29.tower-364.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 14 Jul 2018 16:03:12 -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=XFXWiS0KchdT56B7Lc8wlXr6ByZKPCd/Sms2q5h0EvA=; b=JP0f5ldR6q8OmuTF5YaY/NVpG67VlDOMQ0Xr1huUnPQq29xDUeurKmGsUxAQb0tPBkFcA05QVAXQDdP21krner14PeJV26EzT9wn6W77tJhjtBQCD2MPHvVtmzwt3whf6YKMw1KWziGRgumZNqOfuG9PR8Vg7ynvOEErZBHJCR4= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1460.namprd14.prod.outlook.com (10.172.151.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.19; Sat, 14 Jul 2018 16:03:10 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::b914:e52:554d:c7bb]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::b914:e52:554d:c7bb%9]) with mapi id 15.20.0930.016; Sat, 14 Jul 2018 16:03:10 +0000 From: Tim Hollebeek To: SPASM Thread-Topic: Call for adoption of draft-housley-cms-mts-hash-sig Thread-Index: AdQbjBFj7t2F2+KdQTaxkFacO6LdDQ== Date: Sat, 14 Jul 2018 16:03:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [31.133.155.236] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1460; 7:Za5pIWqreTGRmiucnQbByCoxR8RuHEgLzcXCrR5REJX5+iJgU8EpVrhW9zCGi2m2bChMzTBoQYghtwhB8YdMJWWS4kMNoqEXQBif/4fOzik13lFqDyisFJ1Hp7jpsXAYDgD26DGasWQVa09kPG6HU1ziZ8cFBYPXAS4/qjvZarhSawnXQLOuGa5LgOwaOwM9S0qQC9ZHlLydtPBmyhg+tKEc1snFBN8Q+0tPryzfL4GJvlNWEgZLLD9MwM0ogZjk x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 50736543-9d11-4061-7cc6-08d5e9a34bef x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1460; x-ms-traffictypediagnostic: BN6PR14MB1460: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(100405760836317)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:BN6PR14MB1460; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1460; x-forefront-prvs: 07334CBCCD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39860400002)(136003)(346002)(396003)(199004)(189003)(97736004)(6116002)(44832011)(2900100001)(5660300001)(66066001)(3846002)(790700001)(26005)(316002)(486006)(478600001)(256004)(99936001)(14444005)(33656002)(476003)(99286004)(186003)(14454004)(102836004)(68736007)(2906002)(6916009)(9686003)(54896002)(6506007)(86362001)(6306002)(53936002)(6436002)(7696005)(55016002)(8936002)(106356001)(8676002)(5250100002)(7736002)(74316002)(81166006)(105586002)(81156014)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1460; 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: SBAOMpgI5/kYX9gHcn964hd8ai8x4Gv/VjeI3tMFn2dHfhjTDMAbtsGKRK/966GIa8O8FVwcpn5tIFpwV9A6pYtXm56KBfjuHNDOahd/xmr8pl7u+hnZs5a3K62kPwReQtoezDfxpGJRfFI35+YMYV7/2n8BX8nDWiombcb8lox2VquYDYlLwoNNcuAq39EgLj6B1PVAGRAHqfJbbTy7VFUP/gkmIBaBR6pdRRzuI6+rvMr16uKE4tpwEbG5MNu202WRCSjGNVoLlFL2kSo+Wcqd+dZ4BmsQuQwwie9JfYYA+/tH9EhEPh73G09HCw40nyipXOqlqP5r0L9CzbA2kULgy6yozdDtC18nkBM4r/o= 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_0CC7_01D41B6A.96693E70" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 50736543-9d11-4061-7cc6-08d5e9a34bef X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2018 16:03:10.3868 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1460 Archived-At: Subject: [lamps] Call for adoption of draft-housley-cms-mts-hash-sig X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 14 Jul 2018 16:03:17 -0000 ------=_NextPart_000_0CC7_01D41B6A.96693E70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0CC8_01D41B6A.96693E70" ------=_NextPart_001_0CC8_01D41B6A.96693E70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The recently approved LAMPS WG Charter adds this work item: 5. Specify the use of hash-based signatures with the Cryptographic Message Syntax (CMS). Hash-based signature use small private and public keys, and they have 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; however, sine hash-based signature algorithms are secure even if a large-scale quantum computer is invented. The low computational cost for signature verification makes hash-based signatures attractive in the Internet of Things environments, and the quantum resistance makes them attractive for the distribution of software updates. It has been suggested that the WG adopt draft-housley-cms-mts-hash-sig as the starting point for this work. Since Russ Housley is the author of this draft, Tim Hollebeek will judge consensus for this discussion. Please voice your support or concerns on the list. ------=_NextPart_001_0CC8_01D41B6A.96693E70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The recently approved LAMPS WG Charter adds this = work item:

 

5. Specify the use of hash-based signatures with = the Cryptographic Message Syntax (CMS).  Hash-based signature use = small private and public keys, and they have 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; however, sine hash-based signature algorithms are secure even = if a large-scale quantum computer is invented.  The low = computational cost for signature verification makes hash-based = signatures attractive in the Internet of Things environments, and the = quantum resistance makes them attractive for the distribution of = software updates.

 

It has = been suggested that the WG adopt draft-housley-cms-mts-hash-sig as the = starting point for this work.  Since Russ Housley is the author of = this draft, Tim Hollebeek will judge consensus for this = discussion.  Please voice your support or concerns on the = list.

 

------=_NextPart_001_0CC8_01D41B6A.96693E70-- ------=_NextPart_000_0CC7_01D41B6A.96693E70 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 CQUxDxcNMTgwNzE0MTYwMjUwWjAvBgkqhkiG9w0BCQQxIgQg/NSnSsH5HHzZz85qQbZ30M++36jm dLtEOx5+MMN0zD0wgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAEnv3cTd6qeKSg6S544G+yer5OdWF6bYyyLjKu/qETYjBP7cBlJAlVSVhJHMwn5cg/Jb8nHN P+f4pk8+6MtJvwPlNBqpoi+1EhU4bUhc4/Aj929q17z9t/K6z4Ke48JlN+S4nHrK0s9W39lrVGay M+cDYD34lGP6Cc4HkN8RuJ/qZ8KSmWYRw8dxRHP14QFNxm6v64AjUbhBF1ZaR/iIH4nyZEZxlTxx FsdmP/68zu3p82SAeSwS7ApdWQgp9Ru9uTOx7U30WLiHqxH3n5KVmeQhhZe5VWlSEbDskddxdJSo oY8XFqriC2tgO+b0s/xT2y45crBANjp3KHzOsfAjTNYAAAAAAAA= ------=_NextPart_000_0CC7_01D41B6A.96693E70-- From nobody Sat Jul 14 09:04: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 EE29F130DE2 for ; Sat, 14 Jul 2018 09:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=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 vCUosnrE_ZGd for ; Sat, 14 Jul 2018 09:04:16 -0700 (PDT) Received: from mail1.bemta24.messagelabs.com (mail1.bemta24.messagelabs.com [67.219.250.114]) (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 9823B1277D2 for ; Sat, 14 Jul 2018 09:04:16 -0700 (PDT) Received: from [67.219.250.196] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-b.us-west-2.aws.symcld.net id CC/71-01618-00F1A4B5; Sat, 14 Jul 2018 16:04:16 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTe0hTURzHO/fe6c28eZ2av5b2WEnPu7akF/T 6o6chGRRhGXV1NzeY03ZnzSgIobW05bItSCrtQaXYWysCK0Zo2RJbaaWpmEallZVKRFHdu7Ne 94/D5/y+v+/vfDmcS5NKe6iKFmxWwWLmTeqQMOrZ2Ops7ufopA3a2wPj5xxvzliElp8+/ZVIQ esVRnN6tm2zwvC26gvKcayxfbz6mdqNilIKUBhNsftJKD/nI+WNknURUOS+psCbNgR7D9ShAj SUDmG10FxTR8gczargneOyxDQdxS6FXs8aXF4JJ0ueKjBroL9vMMAUmwCtxQ2kzAy7EZy+vsA YxI6AL/WVASbZWGjpLg0wsNHQ+ehBCOYYeNv1Q4H70+BYvzdYV4O3ZgBhjgd/aSGSMwNbTUDT QGFwEAcfPR4SczJcKsoncFMrgqdN/lAsTIE9nvdBgwnaz9YEOQ1qL9RRmEdDhbOTwuZbJDQ7G oJT46DS9y7IhxXQUjBKZiWrB3eFHFU2uEj42d4TaIqSrq7tyT6EOQ7evKhRuNCkkn+uoETykG wZgsHrrWRJ4M4i4f6Rbgo3rYfXN2oVmDm4eesOiXkMXH9/NMjTwN7xIMhT4cyJXolDJZ4HVXp cHQfuws5QzLPA3vAppAwNq0Cz0y3GTIM1izeaOJ1Wy+l0MzhdYiI3U6vhd3DpmlyR2y6IVm6G ht8uasS8rAyTXmMWrFeQ9AKHSN8N1ObVe9FImlDHMI+VSRuUw9Oz9XkGXjRssuSaBNGL4mhaD UxVvKRFWoRMwbbFaJKe8W8Z6HB1NPNNlhkxh88SjZlYqkcL6Q/lxcUkfbfdLa2NgfV7n6eYVF LmbLOgimUOyzZWthlyzX+G/v49/CheFcUgKaYyPEewZBmt/+s9KJZG6ijGKU8JN5qtf87ukWI RUiyNY4Ucy8r/lVS70Rjmmf+F0R6XcWz6qoTKvCEtCxqXfeZtuy42OZKbktemtBMnVkccmnDf vjPG9Hyuo2vRPd/GoQ+vJS4e1kgcTJ2/9ZUuOiJ2S8W2aZ7qvL1JEXucSz49z68/PnkquDt+r Cq/7U/NXzf8Yu/Bq6ca9qc5Iwd9g9aX5x9NDOu+dOW8a67rq5oSDbxuCmkR+V/NS722GQQAAA == X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-30.tower-344.messagelabs.com!1531584254!1376302!1 X-Originating-IP: [216.32.181.111] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2818 invoked from network); 14 Jul 2018 16:04:15 -0000 Received: from mail-dm3nam05lp0111.outbound.protection.outlook.com (HELO NAM05-DM3-obe.outbound.protection.outlook.com) (216.32.181.111) by server-30.tower-344.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 14 Jul 2018 16:04:15 -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=KVrD2him231D+a5zlPdAc1LfRHvxabY3sa9mTtLAD4M=; b=f39WD7UgSu0KFHJHuGBUf31cMSjupJhlhvtyaAdYVStIdQf4fSEF74cxQZIAyEp1n7cAAYWQ72VrgQksl/3CjClaSpnK1mSMhyMnWnFYJB86S27fD0eZno61g4BWPnOxS3VRFoC9vHvhZLvGDRL0n1S3u6oxHlpiD2nGJHOaVoA= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1283.namprd14.prod.outlook.com (10.173.162.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.20; Sat, 14 Jul 2018 16:04:12 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::b914:e52:554d:c7bb]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::b914:e52:554d:c7bb%9]) with mapi id 15.20.0930.016; Sat, 14 Jul 2018 16:04:12 +0000 From: Tim Hollebeek To: SPASM Thread-Topic: Call for adoption of draft-housley-hash-of-root-key-cert-extn Thread-Index: AdQbjCs/bb7j0+7hQhSyHSg1NP059Q== Date: Sat, 14 Jul 2018 16:04:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [31.133.155.236] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1283; 7:6K0yNyfaAIA/jMfQ23FG++uDUyMrr/gODW3RZBibqPjvzawCzvtk9Nyamt68lsFXX4bNPGSpSivft/n092S0qZ8Fd3V6btPCAx3MF57c1cgWtB5dGlgW0SE2n5pjoioSWsIrS41WL2WfagJsfNg+JyL4rsmVfny2CknpRxGwXIbzherfYpquiYPheuLRqAO9/HGSWnTphUGihR+cEXHNLLXBr5XAwutsddSSi5xVhWDsgv3UPRPm0vt3Klxl7A1e x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 508ffe01-5518-4cf7-54f6-08d5e9a370c8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1283; x-ms-traffictypediagnostic: BN6PR14MB1283: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(100405760836317)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:BN6PR14MB1283; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1283; x-forefront-prvs: 07334CBCCD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(396003)(376002)(346002)(39860400002)(199004)(189003)(44832011)(476003)(102836004)(186003)(2906002)(81166006)(81156014)(68736007)(6506007)(8676002)(486006)(26005)(5250100002)(2900100001)(7736002)(86362001)(74316002)(7696005)(256004)(66066001)(8936002)(99286004)(53936002)(6436002)(478600001)(5660300001)(99936001)(6916009)(33656002)(55016002)(9686003)(14454004)(106356001)(54896002)(6306002)(25786009)(316002)(97736004)(105586002)(790700001)(3846002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1283; 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: 9AOGceGoaHxM8f/iomD8X17AC7Y/dZt7SG8V3jf0NNueNIS1lulr1uoODotAK9TuRqdIyJZVMFKLiqzegjwUKJhpBTEqZj0HxYyupm0lnsYZvqQuytdzsJ/zmRwsUx1ZJcbjH1Dk5bQDIF91KLMmySEjMaPe0bo4nA6CTIYPrEhpDqN28ofCYsOxdw+Sp1g7GTVU1uOKfH0DtF3G0aKHeVPJNGCw8jyInwPh8Kcs8gOO1RF7YuFXzt44/r++H9fr5RCEdzbWLuN2qaQnPlIYPmMAshvyyWcgnxQKtcXdejU3Yi03b0FcJIhhFNK1B1+PM3TEiu7iZekBBdIQXIL8Y2kBOJGxv6XjFzr9S77p+3U= 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_0CCF_01D41B6A.BB5218B0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 508ffe01-5518-4cf7-54f6-08d5e9a370c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2018 16:04:12.2480 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1283 Archived-At: Subject: [lamps] Call for adoption of draft-housley-hash-of-root-key-cert-extn X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 14 Jul 2018 16:04:19 -0000 ------=_NextPart_000_0CCF_01D41B6A.BB5218B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0CD0_01D41B6A.BB5218B0" ------=_NextPart_001_0CD0_01D41B6A.BB5218B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The recently approved LAMPS WG Charter adds this work item: 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. It has been suggested that the WG adopt draft-housley-hash-of-root-key-cert-extn as the starting point for this work. Since Russ Housley is the author of this draft, Tim Hollebeek will judge consensus for this discussion. Please voice your support or concerns on the list. ------=_NextPart_001_0CD0_01D41B6A.BB5218B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The recently approved LAMPS WG Charter adds this = work item:

 

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.

 

It has = been suggested that the WG adopt = draft-housley-hash-of-root-key-cert-extn as the starting point for this = work.  Since Russ Housley is the author of this draft, Tim = Hollebeek will judge consensus for this discussion.  Please voice = your support or concerns on the list.

 

------=_NextPart_001_0CD0_01D41B6A.BB5218B0-- ------=_NextPart_000_0CCF_01D41B6A.BB5218B0 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 CQUxDxcNMTgwNzE0MTYwMzUyWjAvBgkqhkiG9w0BCQQxIgQgB5jN3PpnQs4blrYMpaUaBnmvf0TN ggAHP5tdrkudEzwwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBALak457g/sN/ZWF0lJir9Lih/eeGHBd30/U078MeXW9sYWEF5HnLDLguFDM/FhmC190mRhbO lS0oPoBU2AHL2/XpfwQ9qr97cTRfuNg6eKbRW3DHlyJX0Bj8X6bJkwDbRITsBQEOTnrsgJKzXYYu NR2f2WMta1PmTG8MHTvJLXLcot1gilxVwCkZAhV/p1GEoRQ02X5hUsMOpWGfC6uWSx3K84gzbhKl rr5mu1OuexDrzbOooAPc/keQxSTgpvPhqCqi1hyCNrQCPs5Y2ix8pko4mek5T4/PI1TBqjypYl/Q p+jzNwbwYMIIsj1LZyLY2CESa3fyAwAU+6oAGozFoIAAAAAAAAA= ------=_NextPart_000_0CCF_01D41B6A.BB5218B0-- From nobody Sat Jul 14 09:16: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 91BA91310D8 for ; Sat, 14 Jul 2018 09:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_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 bTSLjW3T2kg4 for ; Sat, 14 Jul 2018 09:16:34 -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 EA3711277D2 for ; Sat, 14 Jul 2018 09:16:33 -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 w6EGBYCj019602; Sat, 14 Jul 2018 17:16:31 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=E7AsfkGmGYPP+T6t23nAh4kVcLOpmLv77qxS6RcSfLs=; b=Lc7kZK/aqoPtcKF5N8yc1sKvmQtxrIGYPn8Ikw3jU1d3Ptl87o2tV2rjGtowpfNfkgUg cUYUkwM9s/j0SbqmneiHYmajeg6m32ZJhH6JoIFe2VvJZvDRJEM2DfVDARSBiph2XDi4 Fvet0j043gAGpuvGvWQQLQ1bsifbfkJmnEAJJmzJZ9NyYRTC3gi4AQIX37u8OPmb3XV1 noeMMOczPT4J65M1UNHJVIdc8ufm0ajX/dO268OHVfojX8CJHwMDVx6YaairJ5VC6Ren ZgkADf+aovbDrbbPdHKHhANRH7iGrDL5XAUjb/CC8nFMM9y1ZhAlFNzc5EZbtRDhjimw 9Q== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2k7a4u0yec-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 14 Jul 2018 17:16:31 +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 w6EG5XBp031435; Sat, 14 Jul 2018 12:16:31 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2k7cgu1wp8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 14 Jul 2018 12:16:30 -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 Microsoft SMTP Server (TLS) id 15.0.1365.1; Sat, 14 Jul 2018 12:16:30 -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; Sat, 14 Jul 2018 12:16:30 -0400 From: "Salz, Rich" To: Tim Hollebeek , SPASM Thread-Topic: [lamps] Call for adoption of draft-housley-cms-mts-hash-sig Thread-Index: AQHUG44F2gDQUUXoFU6I7/DYB/ls4Q== Date: Sat, 14 Jul 2018 16:16:29 +0000 Message-ID: <38BBF538-F0FD-4BAB-BF5B-76E59143A5D4@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.f.0.180709 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.232] Content-Type: multipart/alternative; boundary="_000_38BBF538F0FD4BABBF5B76E59143A5D4akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-14_05:, , 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=903 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807140196 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-14_05:, , 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=820 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807140197 Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-cms-mts-hash-sig X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 14 Jul 2018 16:16:36 -0000 --_000_38BBF538F0FD4BABBF5B76E59143A5D4akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pkl0IGhhcyBiZWVuIHN1Z2dlc3RlZCB0aGF0IHRoZSBXRyBhZG9wdCBkcmFmdC1ob3VzbGV5LWNt cy1tdHMtaGFzaC1zaWcgYXMgdGhlIHN0YXJ0aW5nIHBvaW50IGZvciB0aGlzIHdvcmsNCg0KDQoN ClNlbnNpYmxlLg0KDQo= --_000_38BBF538F0FD4BABBF5B76E59143A5D4akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <144094E191F5F34AA16B36859017D64D@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNv bm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtJdCBoYXMgYmVlbiBzdWdnZXN0ZWQgdGhh dCB0aGUgV0cgYWRvcHQgZHJhZnQtaG91c2xleS1jbXMtbXRzLWhhc2gtc2lnIGFzIHRoZSBzdGFy dGluZyBwb2ludCBmb3IgdGhpcyB3b3JrPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlNl bnNpYmxlLiZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_38BBF538F0FD4BABBF5B76E59143A5D4akamaicom_-- From nobody Sat Jul 14 09:18: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 94AA6130E4B for ; Sat, 14 Jul 2018 09:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_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 LPysVOOgQKnH for ; Sat, 14 Jul 2018 09:18:07 -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 379CD1277D2 for ; Sat, 14 Jul 2018 09:18:07 -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 w6EGH8a9023708; Sat, 14 Jul 2018 17:18:06 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=bHED/aqpNBJ6aaTys6+4ySgDgGsUEjBToplIPZRGjdI=; b=Ze97c77y4kmBqlKH3jjxngTYi6YKfodpwa6LBnlXpPyuu6P7elIXFY3XLqCSCsQ0m82W SXb4q0sWvbP26WSYt2dOriLMo4EZiSBI1c/QnF/zKyNETY1I+CeLux6NeNXzQNWb7L97 c0wspaI09GX592JIQIUar4azttmayXAeytTOVTXVn19S1uuwnJKxee5fXZQwlx6qHjBC xroY3QdYAgl6C6HfryPZRD5AWD7mJfDR1PMDnlmn3Rk5PWVn2TT3LxaT26UTcq3LM79h 2gERUgzK0CVKjJ9t4V9p8vSN6ds0y3IRUq5GQEaYduJ/y2r/Bltoq1LfZHJJlskE7S5m vw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2k7a4u0yg3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 14 Jul 2018 17:18:05 +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 w6EG5XjC031432; Sat, 14 Jul 2018 12:18:05 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2k7cgu1wvd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 14 Jul 2018 12:18:05 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sat, 14 Jul 2018 12:18:04 -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; Sat, 14 Jul 2018 12:18:04 -0400 From: "Salz, Rich" To: Tim Hollebeek , SPASM Thread-Topic: [lamps] Call for adoption of draft-housley-hash-of-root-key-cert-extn Thread-Index: AQHUG4494u0SOYAdo0adUU4zXQPkpA== Date: Sat, 14 Jul 2018 16:18:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.f.0.180709 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.232] Content-Type: multipart/alternative; boundary="_000_F47E0433EC98456DA909A35B1476C7DFakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-14_05:, , 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-1806210000 definitions=main-1807140196 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-14_05:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=923 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807140198 Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-hash-of-root-key-cert-extn X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 14 Jul 2018 16:18:09 -0000 --_000_F47E0433EC98456DA909A35B1476C7DFakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pkl0IGhhcyBiZWVuIHN1Z2dlc3RlZCB0aGF0IHRoZSBXRyBhZG9wdCBkcmFmdC1ob3VzbGV5LWhh c2gtb2Ytcm9vdC1rZXktY2VydC1leHRuIGFzIHRoZSBzdGFydGluZyBwb2ludCBmb3IgdGhpcyB3 b3JrLg0KDQpTRVQgZGlkIHRoaXMgZm9yIHRoZWlyIHJvb3QgYSBsb25nIHRpbWUgYWdvLiAgTWF5 YmUgcmUtdXNlIHRoZSBPSUQ/DQoNCkF0IGFueSByYXRlLCBJIHN1cHBvcnQgdGhpcy4NCg== --_000_F47E0433EC98456DA909A35B1476C7DFakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <30B01B538E8B2C47B065DE656B3E29D3@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNv bm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtJdCBoYXMgYmVlbiBzdWdnZXN0ZWQgdGhh dCB0aGUgV0cgYWRvcHQgZHJhZnQtaG91c2xleS1oYXNoLW9mLXJvb3Qta2V5LWNlcnQtZXh0biBh cyB0aGUgc3RhcnRpbmcgcG9pbnQgZm9yIHRoaXMgd29yay48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U0VUIGRpZCB0aGlzIGZvciB0aGVpciByb290IGEgbG9uZyB0aW1lIGFnby4mbmJzcDsgTWF5 YmUgcmUtdXNlIHRoZSBPSUQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0IGFueSByYXRlLCBJ IHN1cHBvcnQgdGhpcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F47E0433EC98456DA909A35B1476C7DFakamaicom_-- From nobody Sat Jul 14 09:19: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 9A0871310EA for ; Sat, 14 Jul 2018 09:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_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 75JLY4G5heuI for ; Sat, 14 Jul 2018 09:19:21 -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 3B549131103 for ; Sat, 14 Jul 2018 09:19:21 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6EGH7XC022841; Sat, 14 Jul 2018 17:19:19 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=NYl4vykz7R8oDL3GsZ5msLPy6zJ+dY/3gmdmOaPF6m8=; b=cFRAmvebyzT2bQVzT6SaLf1SvWFJWLBMPlJpegEkowSVUh4fft1vMDszqqSt/zVcSZZa TJd6rEUJCuv0jsFKFPu3588YDeqPMQnD7oWW6pthq2gah2WJSpxcYAPuo2p0pHftTn/P tDnvdVjcy1ggjV+DwfVcUxJ0/Y6mM9V6s8euuft41RNe0tgYb2a/1eGEh/uAkmw6FSpg xQ4SWOMD7WSgyF+HXRRSMG444l88msrFm4EctrkIw2GLyFNDih6a0U8hG22N8KGPVL6H iyaaYvPsvnHw5Zk1yUCg5Uooo0JOhAGnihgXoHVOpM393fLIZhLjsHScb091w2I8bBhE dg== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2k7a42gykf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 14 Jul 2018 17:19:18 +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 w6EG5wiN006279; Sat, 14 Jul 2018 12:19:18 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint4.akamai.com with ESMTP id 2k7cgw0y4h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 14 Jul 2018 12:19:18 -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; Sat, 14 Jul 2018 12:19:17 -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; Sat, 14 Jul 2018 12:19:17 -0400 From: "Salz, Rich" To: Tim Hollebeek , SPASM Thread-Topic: [lamps] Call for adoption of draft-housley-cms-mix-with-psk Thread-Index: AQHUG45p4DyT/klal0S3XBvgW9gRRQ== Date: Sat, 14 Jul 2018 16:19:16 +0000 Message-ID: <82888B6A-94B6-489D-B7ED-90A9BEC78385@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.f.0.180709 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.232] Content-Type: multipart/alternative; boundary="_000_82888B6A94B6489DB7ED90A9BEC78385akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-14_05:, , 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=872 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807140196 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-14_05:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=784 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807140198 Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-cms-mix-with-psk X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 14 Jul 2018 16:19:32 -0000 --_000_82888B6A94B6489DB7ED90A9BEC78385akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCj5JdCBoYXMgYmVlbiBzdWdnZXN0ZWQgdGhhdCB0aGUgV0cgYWRvcHQgZHJhZnQtaG91c2xl eS1jbXMtbWl4LXdpdGgtcHNrIGFzIHRoZSBzdGFydGluZyBwb2ludCBmb3IgdGhpcyB3b3JrDQoN Cg0KDQpJIHN1cHBvcnQgYWRvcHRpb24uDQoNCg0KDQpJZiwgYXMgc2VlbXMgbGlrZWx5LCB3ZSBh ZG9wdCBhbGwgb2YgUnVzc+KAmXMgZHJhZnRzLCBpcyBoZSBwbGFubmluZyBvbiBzdGVwcGluZyBh c2lkZSBvciBhcHBvaW50aW5nIGNvLWF1dGhvcnM/DQo= --_000_82888B6A94B6489DB7ED90A9BEC78385akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNv bm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0O0l0IGhhcyBiZWVuIHN1Z2dlc3RlZCB0aGF0IHRoZSBXRyBhZG9w dCBkcmFmdC1ob3VzbGV5LWNtcy1taXgtd2l0aC1wc2sgYXMgdGhlIHN0YXJ0aW5nIHBvaW50IGZv ciB0aGlzIHdvcms8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBzdXBwb3J0IGFkb3B0 aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JZiwgYXMgc2VlbXMgbGlrZWx5LCB3 ZSBhZG9wdCBhbGwgb2YgUnVzc+KAmXMgZHJhZnRzLCBpcyBoZSBwbGFubmluZyBvbiBzdGVwcGlu ZyBhc2lkZSBvciBhcHBvaW50aW5nIGNvLWF1dGhvcnM/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_82888B6A94B6489DB7ED90A9BEC78385akamaicom_-- From nobody Sat Jul 14 09:22:59 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 5A130130EF5 for ; Sat, 14 Jul 2018 09:22:57 -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, 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=nomountain-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 VwFvohbrRkqb for ; Sat, 14 Jul 2018 09:22:56 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001: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 1F5A3130E55 for ; Sat, 14 Jul 2018 09:22:56 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id k3-v6so33922893iog.3 for ; Sat, 14 Jul 2018 09:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=AOedJxEGKhvoWDUBEZq83/w2iq20j6NFxSl6A/yWsDI=; b=IYOM2BI30ck0QnrKc4HvN5VfSNzrHoTXymfqagS4SH9RxRHFG940J7xsIs3zk+uiNL kunXzAoGrPu8N9EjIuWzzcMhEvpSLao52n5akhqi/Gb9rfV+4+aOp+zy2eTo3876dFt+ zgg1Jr12rxmp6OgsYQWrfyr5mzWR3XzONXOKTimqj9555u2Jy4VwCbOhTIvfNeAQypqU iZ380v9XvbJWkXaDdw+v9zYTYMx7nE9sIrD0dXPzt1wyths1yJShNX+9OiKprpRVhoNK t/CdMavS69kz88qReVVKfeXqjIkTzjScvnURUniMyMnfPVYmTI5KIh/dU+cY9VbXtRHd yLmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AOedJxEGKhvoWDUBEZq83/w2iq20j6NFxSl6A/yWsDI=; b=cy3unOyUlbMJxLu/D2PkG1aRjVZzuVUBN8s2SDpcNEHWtCMIFjZyiUt5lvHL+0CYVV z/MtcDXFJwGldB8cSh+nIdaGx5MPYFQ5cGVk4d66cMpdUqTnNuWCQ/P/LFNbb+EFghLM FdtI0SL0XpS9XFihFnZnfb3PKAOst72ZAFB4jg7AlfVh8toGmC+CLV64LPROE4l/IVLh j7tk/Ee/J8ERD9RaFvuNf0SZYxIcWNji7Bc/ol5OKAdtNo02fO7iR6oggUWnozFcjX6+ IRV9PrRJOronv0HFj1SdJnHr3prPUE/5yHZImuzA+p55LPW/yv4ZENs2BFPsC+QiHHI8 iy4w== X-Gm-Message-State: AOUpUlEbt45KR8RwTw+L4vUD5mzJG30txhQ3XxKVAGQFD6IdTuLFrQ5L diaggjlxn9aTX9+MAHqa4fs/a6FCEQ== X-Google-Smtp-Source: AAOMgpc07M3LwU745Ex1HqNLtjNZ2c5bSAhB7ScmAgQbya7RdebsFFOoIEW9fMJ0JnIWivFQF+CVhw== X-Received: by 2002:a6b:a192:: with SMTP id k140-v6mr34102336ioe.130.1531585375293; Sat, 14 Jul 2018 09:22:55 -0700 (PDT) Received: from dhcp-90a0.meeting.ietf.org ([2001:67c:1232:144:3149:3c62:ad70:8fea]) by smtp.gmail.com with ESMTPSA id v190-v6sm5401789itc.30.2018.07.14.09.22.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Jul 2018 09:22:54 -0700 (PDT) To: spasm@ietf.org References: From: Melinda Shore Message-ID: Date: Sat, 14 Jul 2018 12:22:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lamps] Call for adoption of draft-nir-saag-star X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 14 Jul 2018 16:22:57 -0000 On 7/14/18 12:01 PM, Tim Hollebeek wrote: > It has been suggested that the WG adopt draft-nir-saag-star as the > starting point for this work.  Please voice your support or concerns on > the list. I've read it and think it's a good place to start. Melinda -- Software longa, hardware brevis PGP key fingerprint 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F From nobody Sat Jul 14 11:28: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 8FBAC130E77 for ; Sat, 14 Jul 2018 11:28:21 -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 wDCMwr4-daQw for ; Sat, 14 Jul 2018 11:28: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 CB9C5130E34 for ; Sat, 14 Jul 2018 11:28:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 44153300A44 for ; Sat, 14 Jul 2018 14:28:17 -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 c_lq_T9aVQuT for ; Sat, 14 Jul 2018 14:28:15 -0400 (EDT) Received: from dhcp-8ced.meeting.ietf.org (dhcp-8ced.meeting.ietf.org [31.133.140.237]) by mail.smeinc.net (Postfix) with ESMTPSA id 683A43005C6; Sat, 14 Jul 2018 14:28:15 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6682B964-B02A-4EC5-B6C6-491A421B358B" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Sat, 14 Jul 2018 14:28:15 -0400 In-Reply-To: Cc: Tim Hollebeek , SPASM To: Rich Salz References: X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-hash-of-root-key-cert-extn X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 14 Jul 2018 18:28:22 -0000 --Apple-Mail=_6682B964-B02A-4EC5-B6C6-491A421B358B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Rich: Thanks for the support. > >It has been suggested that the WG adopt = draft-housley-hash-of-root-key-cert-extn as the starting point for this = work. > =20 > SET did this for their root a long time ago. Maybe re-use the OID? > =20 > At any rate, I support this. I looked at this, and they used a cumbersome syntax. hashedRootKey EXTENSION ::=3D { -- Only in root = certificates SYNTAX HashedRootKeySyntax CRITICAL TRUE IDENTIFIED BY id-set-hashedRootKey } HashedRootKeySyntax ::=3D RootKeyThumb RootKeyThumb ::=3D SEQUENCE { rootKeyThumbprint DD { SubjectPublicKeyInfo{{SupportedAlgorithms}} } } Where DD expands to a CMS DigestedData. I think you will find the syntax in the Internet-Draft much more = straightforward. Russ --Apple-Mail=_6682B964-B02A-4EC5-B6C6-491A421B358B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Rich:

Thanks for the support.

>It has been suggested that the WG adopt = draft-housley-hash-of-root-key-cert-extn as the starting point for this = work.
 
SET did = this for their root a long time ago.  Maybe re-use the OID?
 
At any = rate, I support this.

I looked at this, and they used a cumbersome = syntax.

hashedRootKey EXTENSION = ::=3D {               -- Only in root = certificates
   SYNTAX         = HashedRootKeySyntax
   CRITICAL       = TRUE
   IDENTIFIED BY = id-set-hashedRootKey
}

HashedRootKeySyntax ::=3D = RootKeyThumb

RootKeyThumb ::=3D = SEQUENCE {
   rootKeyThumbprint  DD { = SubjectPublicKeyInfo{{SupportedAlgorithms}} }
}

Where DD expands to a CMS = DigestedData.

I think you will find = the syntax in the Internet-Draft much more = straightforward.

Russ

= --Apple-Mail=_6682B964-B02A-4EC5-B6C6-491A421B358B-- From nobody Sat Jul 14 11:30: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 CC818130E34 for ; Sat, 14 Jul 2018 11:30:53 -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 sILQUpUb9G9F for ; Sat, 14 Jul 2018 11:30:52 -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 7DA8F129C6B for ; Sat, 14 Jul 2018 11:30:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5239F3005C9 for ; Sat, 14 Jul 2018 14:30:50 -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 AZdY56fZHK3n for ; Sat, 14 Jul 2018 14:30:49 -0400 (EDT) Received: from dhcp-8ced.meeting.ietf.org (dhcp-8ced.meeting.ietf.org [31.133.140.237]) by mail.smeinc.net (Postfix) with ESMTPSA id AABD23005C6; Sat, 14 Jul 2018 14:30:48 -0400 (EDT) From: Russ Housley Message-Id: <8F6336E6-19A2-4722-8C0E-9E786FB5D09E@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BAC9435A-7C60-4095-82F4-AA2F8BCBED43" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Sat, 14 Jul 2018 14:30:48 -0400 In-Reply-To: <82888B6A-94B6-489D-B7ED-90A9BEC78385@akamai.com> Cc: Tim Hollebeek , SPASM To: Rich Salz References: <82888B6A-94B6-489D-B7ED-90A9BEC78385@akamai.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-cms-mix-with-psk X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 14 Jul 2018 18:30:54 -0000 --Apple-Mail=_BAC9435A-7C60-4095-82F4-AA2F8BCBED43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Rich: >=20 > If, as seems likely, we adopt all of Russ=E2=80=99s drafts, is he = planning on stepping aside or appointing co-authors? I will not judge consensus for any document with my name on it. Tim = will make such consensus calls and handle any other chair actions. Russ= --Apple-Mail=_BAC9435A-7C60-4095-82F4-AA2F8BCBED43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Rich:

If, as = seems likely, we adopt all of Russ=E2=80=99s drafts, is he planning on = stepping aside or appointing co-authors?

I will = not judge consensus for any document with my name on it.  Tim will = make such consensus calls and handle any other chair = actions.

Russ
= --Apple-Mail=_BAC9435A-7C60-4095-82F4-AA2F8BCBED43-- From nobody Sat Jul 14 17:40: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 82BA8130E65 for ; Sat, 14 Jul 2018 17:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.336 X-Spam-Level: * X-Spam-Status: No, score=1.336 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_SBL_CSS=3.335] autolearn=no 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 fPgLxAojFB_B for ; Sat, 14 Jul 2018 17:40:00 -0700 (PDT) Received: from homiemail-a106.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 8E79E1292AD for ; Sat, 14 Jul 2018 17:40:00 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id B398F30000C07 for ; Sat, 14 Jul 2018 17:39:59 -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=628zo3g50zj8p3HhH6MxfxLBfo8=; b= JNbWgJgmt7qMpysfD/vzFSWLA0094144f9sgLiU8LK8Kw2XGD5zwYZb9yTUkK0dh KzOAmr1lj6+j91C8TEfrrlFVLGwZ5aJHvfTsWIaH2EIZTv2UXSGXmbrVMLVHE09w ENuBGz91BcjwxvwDCq1K/Tl+YeSxukT1OYQEUHFN384= Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPSA id A69833000293D for ; Sat, 14 Jul 2018 17:39:59 -0700 (PDT) Received: by mail-io0-f171.google.com with SMTP id l7-v6so34576756ioj.1 for ; Sat, 14 Jul 2018 17:39:59 -0700 (PDT) X-Gm-Message-State: AOUpUlGJjygCHDzyfe7Ku6v7oMBYKCEglD7toBOFURkCZl4qVZ7bX/GI lKyBDM+xYn3w5XrGlUDkbd01QcOAG6G8rJRBuAA= X-Google-Smtp-Source: AAOMgpcQwraswPgABvlDiyXI3PeEzkh+NeprzdMPI7N8ks3AhIe6TppxKEFoBYBCxY5M7w3TSnOJpGnQyZ7DWooFmq4= X-Received: by 2002:a6b:a2cf:: with SMTP id l198-v6mr8215245ioe.282.1531615199123; Sat, 14 Jul 2018 17:39:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ryan Sleevi Date: Sun, 15 Jul 2018 09:39:48 +0900 X-Gmail-Original-Message-ID: Message-ID: To: Tim Hollebeek Cc: SPASM Content-Type: multipart/alternative; boundary="000000000000e0641c0570fef3e2" Archived-At: Subject: Re: [lamps] Call for adoption of draft-nir-saag-star X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 00:40:03 -0000 --000000000000e0641c0570fef3e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jul 15, 2018 at 1:01 AM Tim Hollebeek wrote: > > > The recently approved LAMPS WG Charter adds this work item: > > > > 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 short-lived certificates is unnecessary and pointless. > > > > It has been suggested that the WG adopt draft-nir-saag-star as the > starting point for this work. Please voice your support or concerns on t= he > list. > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm I have read it, and as expressed during the charter discussion, do not support it as a place to start in its current form. The problem statement that it seems to address is still ill-defined, and it=E2=80=99s explanations for certain design choices are still contradictor= y and inconsistent. As such, it=E2=80=99s technical proposals lack merit for the = problem or cohesion as a solution, and more work should be done to clearly articulate the problem and solution space prior to adoption. > > --000000000000e0641c0570fef3e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=C2=A0

The re= cently approved LAMPS WG Charter adds this work item:

=C2=A0

3. Specify the use of short-lived X.= 509 certificates for which no revocation information is made available by t= he Certification Authority.

=C2=A0

Short-lived certificates have a lifespan that is shorter than = the time needed to detect, report, and distribute revocation information.= =C2=A0 As a result, revoking short-lived certificates is unnecessary and po= intless.

=C2=A0

It has= been suggested that the WG adopt draft-nir-saag-star as the starting point= for this work.=C2=A0 Please voice your support or concerns on the list.=

=C2=A0

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

I have read it, and as exp= ressed during the charter discussion, do not support it as a place to start= in its current form.

Th= e problem statement that it seems to address is still ill-defined, and it= =E2=80=99s explanations for certain design choices are still contradictory = and inconsistent. As such, it=E2=80=99s technical proposals lack merit for = the problem or cohesion as a solution, and more work should be done to clea= rly articulate the problem and solution space prior to adoption.
=C2=A0
<= /a>
--000000000000e0641c0570fef3e2-- From nobody Sun Jul 15 09:10: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 31BD6130E2C for ; Sun, 15 Jul 2018 09:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_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 N8wtrNh6j0jr for ; Sun, 15 Jul 2018 09:10:36 -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 76495130DF3 for ; Sun, 15 Jul 2018 09:10:35 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w6FG7off013917; Sun, 15 Jul 2018 17:10:33 +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 : mime-version; s=jan2016.eng; bh=fcmDspTmId2ioEJ+x+cY6dlXoeqNNp6Byap8Ni/YIhk=; b=KBIMLmclou9nwxgSMwsuhr45OC3PuofK8a9V3XfhNCyqwx4eH1LpFcOBg5m77Nb84n4i zqU/A/oI8u1VDwC/bVIengJ7eqABvbkdxgNiZgEhaRvaTMBPGTkfeFOklqLTU1HSTroy d1O0WAVFRbOWFxDvV7MCWZJcPrP47Yp04yAxAC+EDRZ5MIfXGWGAPBJSd8jSl9lln9zi eYZBejFCtWUqftjSBUW5aUmfzkP5xhU09IeL6d8mqnQGbXWylAfJMuFoDdqwLLPjDm9M n7URt9b++T7qrhWLfFIGlKKlZSFy/W2/BNJs1mOrbDLanwD9IEPBCJ4vsRp7C+iOTR2D VQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050095.ppops.net-00190b01. with ESMTP id 2k7a4uuc6s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 15 Jul 2018 17:10:33 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w6FG4wfW019481; Sun, 15 Jul 2018 12:10:32 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2k7cgty1k9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 15 Jul 2018 12:10:32 -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; Sun, 15 Jul 2018 12:10:31 -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; Sun, 15 Jul 2018 12:10:31 -0400 From: "Salz, Rich" To: Russ Housley CC: Tim Hollebeek , SPASM Thread-Topic: [lamps] Call for adoption of draft-housley-hash-of-root-key-cert-extn Thread-Index: AQHUG4494u0SOYAdo0adUU4zXQPkpKSPTM2AgAEoy4A= Date: Sun, 15 Jul 2018 16:10:31 +0000 Message-ID: <0F6D47B5-2537-452B-935A-E172B9CDC0C5@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.f.0.180709 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.112] Content-Type: multipart/alternative; boundary="_000_0F6D47B52537452B935AE172B9CDC0C5akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-15_06:, , 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-1806210000 definitions=main-1807150195 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-15_06:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807150195 Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-hash-of-root-key-cert-extn X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 16:10:38 -0000 --_000_0F6D47B52537452B935AE172B9CDC0C5akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBkaWdnaW5nIGl0IHVwLiAgSSBhZ3JlZSwgdGhlIGRyYWZ0IHN5bnRheCBtYWtl cyBhIGxvdCBvZiBzZW5zZSwgbXkgY29uY2VybiBpcyBnb25lLiA6KQ0KDQpTRVQgY29udm9sdXRl ZDsgd2hvIHdvdWxkIGhhdmUgdGhvdWdodD8NCg== --_000_0F6D47B52537452B935AE172B9CDC0C5akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <3BE09CC23E37804392AEC644946F4845@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIj MDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciBkaWdnaW5nIGl0IHVwLiZuYnNwOyBJIGFncmVl LCB0aGUgZHJhZnQgc3ludGF4IG1ha2VzIGEgbG90IG9mIHNlbnNlLCBteSBjb25jZXJuIGlzIGdv bmUuIDopPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TRVQgY29udm9s dXRlZDsgd2hvIHdvdWxkIGhhdmUgdGhvdWdodD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0F6D47B52537452B935AE172B9CDC0C5akamaicom_-- From nobody Sun Jul 15 09:11:38 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 B6D8C130E2C for ; Sun, 15 Jul 2018 09:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_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 WrC7K6ZpWqye for ; Sun, 15 Jul 2018 09:11:34 -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 AD719130DF3 for ; Sun, 15 Jul 2018 09:11:21 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w6FG8A6U001110; Sun, 15 Jul 2018 17:11:19 +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 : mime-version; s=jan2016.eng; bh=fUBJ/DDRje+WRQqmW8br/vrV8JK0j73HtBx8H3XAM3w=; b=NSwFkOXJngaoHRg+oUTdXcAOP5z1/SKXy6t2oiTM2bSiys3QjHHrdsOZDXybgSfW6hCl /5f5WyFoRFCF6NYNPD8ZSPdA/NWd05CpHq4Js968hM69wvU0STMoHvjWh3f1kUK/e8bd k0endGz8iXqK4GXHkqdUabtLApuLJxvrkMkw3jgjwUYAOYyN88UORKET9Kjr5QVrAXH3 oSndsABY9Rf/pFXO2z/WSKoKfnv2Vw95qlGPK3f8WfBidYgBq4Ox9dqikE3NHpeZnBLD PA9gStMpVPScqStUIRNPLE6lx48MAGpJ4AR0G34e/TnYNzXE77JOXiZg039o1zOZ9ZUz Kg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2k7a4sbbgh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 15 Jul 2018 17:11:19 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w6FG4qDH019395; Sun, 15 Jul 2018 12:11:18 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint1.akamai.com with ESMTP id 2k7cgty1nw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 15 Jul 2018 12:11:18 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sun, 15 Jul 2018 12:11:17 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sun, 15 Jul 2018 12:11:17 -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; Sun, 15 Jul 2018 12:11:16 -0400 From: "Salz, Rich" To: Russ Housley CC: Tim Hollebeek , SPASM Thread-Topic: [lamps] Call for adoption of draft-housley-cms-mix-with-psk Thread-Index: AQHUG45p4DyT/klal0S3XBvgW9gRRaSPTYMAgAEoSYA= Date: Sun, 15 Jul 2018 16:11:16 +0000 Message-ID: References: <82888B6A-94B6-489D-B7ED-90A9BEC78385@akamai.com> <8F6336E6-19A2-4722-8C0E-9E786FB5D09E@vigilsec.com> In-Reply-To: <8F6336E6-19A2-4722-8C0E-9E786FB5D09E@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.f.0.180709 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.112] Content-Type: multipart/alternative; boundary="_000_EE62F8D93B1143FF9B23CC70FFC0B4FEakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-15_06:, , 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=987 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807150195 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-15_06:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=903 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807150195 Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-cms-mix-with-psk X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 16:11:36 -0000 --_000_EE62F8D93B1143FF9B23CC70FFC0B4FEakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSB3aWxsIG5vdCBqdWRnZSBjb25zZW5zdXMgZm9yIGFueSBkb2N1bWVudCB3aXRoIG15 IG5hbWUgb24gaXQuICBUaW0gd2lsbCBtYWtlIHN1Y2ggY29uc2Vuc3VzIGNhbGxzIGFuZCBoYW5k bGUgYW55IG90aGVyIGNoYWlyIGFjdGlvbnMuDQoNClRoYW5rcyBmb3IgbWFraW5nIGl0IGV4cGxp Y2l0LiAgSSBmaWd1cmVkIHlvdeKAmWQgYmUgZG9pbmcgdGhlIHJpZ2h0IHRoaW5nLCBidXQganVz dCB3YW50ZWQgaXQgb24gdGhlIHJlY29yZC4gIEkgaGF2ZSBubyBjb25jZXJucyBhYm91dCB0aGlz Lg0K --_000_EE62F8D93B1143FF9B23CC70FFC0B4FEakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <1867EA22265D1245B3B1687C5D658D2E@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6 MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxl ZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTkxOTE3NTAzNzsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6ODkxMTcwMjY4IC0xMjk0MDQ3 NDAwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQt YXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYW5z aS1mb250LXdlaWdodDpib2xkO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGww OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30N Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIg dmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjx1bCBzdHlsZT0i bWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5JIHdpbGwg bm90IGp1ZGdlIGNvbnNlbnN1cyBmb3IgYW55IGRvY3VtZW50IHdpdGggbXkgbmFtZSBvbiBpdC4g Jm5ic3A7VGltIHdpbGwgbWFrZSBzdWNoIGNvbnNlbnN1cyBjYWxscyBhbmQgaGFuZGxlIGFueSBv dGhlciBjaGFpciBhY3Rpb25zLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NClRoYW5rcyBmb3IgbWFraW5nIGl0IGV4cGxpY2l0LiZuYnNwOyBJ IGZpZ3VyZWQgeW914oCZZCBiZSBkb2luZyB0aGUgcmlnaHQgdGhpbmcsIGJ1dCBqdXN0IHdhbnRl ZCBpdCBvbiB0aGUgcmVjb3JkLiZuYnNwOyBJIGhhdmUgbm8gY29uY2VybnMgYWJvdXQgdGhpcy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_EE62F8D93B1143FF9B23CC70FFC0B4FEakamaicom_-- From nobody Tue Jul 17 06:00: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 53F76130DF5; Tue, 17 Jul 2018 06:00: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 fAKSJzMeF7vC; Tue, 17 Jul 2018 06:00:09 -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 2D52F130EAC; Tue, 17 Jul 2018 06:00:09 -0700 (PDT) Received: from Jude (31.133.140.188) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 17 Jul 2018 05:56:33 -0700 From: Jim Schaad To: 'Benjamin Kaduk' CC: 'The IESG' , , 'Russ Housley' , , References: <153079945499.11322.17868589339590763702.idtracker@ietfa.amsl.com> <00a901d41484$2494b0f0$6dbe12d0$@augustcellars.com> <20180705213656.GR60996@kduck.kaduk.org> <039a01d417e4$f1228260$d3678720$@augustcellars.com> <20180710024903.GI59001@kduck.kaduk.org> In-Reply-To: <20180710024903.GI59001@kduck.kaduk.org> Date: Tue, 17 Jul 2018 09:00:00 -0400 Message-ID: <01ca01d41dce$14512e00$3cf38a00$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQIi+HNCTYWwO8773Uu0GB5YWNsIoAJRu5EBATEQR2ABmT7ZPQHd+rMTo73a8LA= X-Originating-IP: [31.133.140.188] Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 17 Jul 2018 13:00:12 -0000 I still think that it is and was correct text. However the entire paragraph is now gone > -----Original Message----- > From: Benjamin Kaduk > Sent: Monday, July 9, 2018 10:49 PM > To: Jim Schaad > Cc: 'The IESG' ; draft-ietf-lamps-rfc5751-bis@ietf.org; 'Russ > Housley' ; lamps-chairs@ietf.org; spasm@ietf.org > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: (with > DISCUSS and COMMENT) > > On Mon, Jul 09, 2018 at 05:28:33PM -0700, Jim Schaad wrote: > > > > > > > -----Original Message----- > > > From: Benjamin Kaduk > > > Sent: Thursday, July 5, 2018 2:37 PM > > > To: Jim Schaad > > > Cc: 'The IESG' ; > > > draft-ietf-lamps-rfc5751-bis@ietf.org; > > 'Russ > > > Housley' ; lamps-chairs@ietf.org; > > > spasm@ietf.org > > > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: > > > (with DISCUSS and COMMENT) > > > > > > On Thu, Jul 05, 2018 at 10:18:04AM -0700, Jim Schaad wrote: > > > > > > > > > > > > > -----Original Message----- > > > > > From: Benjamin Kaduk > > > > > Sent: Thursday, July 5, 2018 7:04 AM > > > > > To: The IESG > > > > > Cc: draft-ietf-lamps-rfc5751-bis@ietf.org; Russ Housley > > > > > ; lamps-chairs@ietf.org; > > > > > housley@vigilsec.com; spasm@ietf.org > > > > > Subject: Benjamin Kaduk's Discuss on > > > > > draft-ietf-lamps-rfc5751-bis-10: (with DISCUSS and COMMENT) > > > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > > draft-ietf-lamps-rfc5751-bis-10: Discuss > > > > > > > > > > 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.) > > > > > > > > > > > > > > > Please refer to > > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > ---- > > > > > -- > > > > > COMMENT: > > > > > ---------------------------------------------------------------- > > > > > ---- > > > > > -- > > > > > > > > > > Section 2.7.2 > > > > > > > > > > With "Algorithms such as RC2"; "Algorithms such as TripleDES", > > > > > I'm not sure what to make of "such as" in these statements -- > > > > > what are the attributes that would qualify for sufficient > > > > > similarity to match the "such as", other than equality? > > > > > > > > I would probably put DES in the same category as RC2 and Camellia > > > > in the > > > same category as TripleDES. The first category is basically - this > > > is > > better than > > > nothing but is not secure. The second category is basically it is > > > not > > known to > > > be unsecure, but neither is it something that we recommend as using > > > any more. (In this case 64-bit blocks vs 128-bit blocks). > > > > > > My question is more, "how do we expect the reader to make these > > > classifications?" You and I can agree on what they should be based > > > on our prior experience in the field, but not all readers will share > > > that > > background > > > information. > > > > I'll be honest, I don't expect readers who are not part of the world > > of cryptographic algorithms to make this type of classification. I > > expect them to use the recommendations for what algorithms to use in > > the document and leave it at that. I expect that this explains where > > things are for those who do know cryptographic algorithms and thus can > > understand some of the differences. > > Okay. (This is just a COMMENT, so I will trust your judgment.) > > > > > > > > > Do we need to cite RFC 6454 for the specific "web origin" > > > > > concept (as opposed to just the normal English usage of the word)? > > > > > > > > At this point in time I don't know that the idea of "web origin" > > > > is going to match what is needed for S/MIME. I would prefer to > > > > punt this to a new document which addresses the problem directly > > > > > > How would a reader of this document know to look for this > > > hypothetical new document? > > > > Given that we can't point to this hypothetical document I don't think > > we can. I think it will get some publicity when it is finally > > published. In the mean time I expect people to slog through the > > eprint document and need to go several iterations to understand what > > is being said their. They talk about same origin in that document. > > Okay. > > -Benjamin From nobody Tue Jul 17 06:04:00 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 12297130DF5; Tue, 17 Jul 2018 06:03:53 -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.82.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <153183263300.12756.8762067007052009288@ietfa.amsl.com> Date: Tue, 17 Jul 2018 06:03:53 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc5751-bis-11.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 17 Jul 2018 13:03:53 -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-11.txt Pages : 59 Date : 2018-07-17 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-11 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5751-bis-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5751-bis-11 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 Jul 17 06: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 A236A130EF4 for ; Tue, 17 Jul 2018 06:50:46 -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 G5EKZRljXC-h for ; Tue, 17 Jul 2018 06:50:44 -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 4E04C129385 for ; Tue, 17 Jul 2018 06:50:44 -0700 (PDT) Received: from Jude (31.133.140.188) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 17 Jul 2018 06:47:08 -0700 From: Jim Schaad To: 'Eric Rescorla' CC: References: <153183263328.12756.4193233562136480421.idtracker@ietfa.amsl.com> In-Reply-To: <153183263328.12756.4193233562136480421.idtracker@ietfa.amsl.com> Date: Tue, 17 Jul 2018 09:50:35 -0400 Message-ID: <01d701d41dd5$250b3cc0$6f21b640$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQHl4NceyE1BNntisbIkMVtPYumFHKRv6IWQ X-Originating-IP: [31.133.140.188] Archived-At: Subject: [lamps] FW: New Version Notification for draft-ietf-lamps-rfc5751-bis-11.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 17 Jul 2018 13:50:47 -0000 EKR, This should be everything from the IESG. -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Tuesday, July 17, 2018 9:04 AM To: Jim Schaad ; Blake Ramsdell = ; Sean Turner Subject: New Version Notification for = draft-ietf-lamps-rfc5751-bis-11.txt A new version of I-D, draft-ietf-lamps-rfc5751-bis-11.txt has been successfully submitted by Jim Schaad and posted to the IETF = repository. Name: draft-ietf-lamps-rfc5751-bis Revision: 11 Title: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version = 4.0 Message Specification Document date: 2018-07-17 Group: lamps Pages: 59 URL: = https://www.ietf.org/internet-drafts/draft-ietf-lamps-rfc5751-bis-11.txt Status: = https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ Htmlized: = https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-11 Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5751-bis Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-rfc5751-bis-11 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 Tue Jul 17 07:40: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 F2434130DFE for ; Tue, 17 Jul 2018 07:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.272 X-Spam-Level: X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-fly4g4gFRU for ; Tue, 17 Jul 2018 07:40:03 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 419B7130E14 for ; Tue, 17 Jul 2018 07:40:03 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 1DF903741012 for ; Tue, 17 Jul 2018 14:40:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UOhDkfhjagpH for ; Tue, 17 Jul 2018 10:40:02 -0400 (EDT) Received: from Maxs-MacBook-Pro.local (dhcp-8f30.meeting.ietf.org [31.133.143.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id F2D183740FF1 for ; Tue, 17 Jul 2018 10:40:01 -0400 (EDT) To: spasm@ietf.org References: From: "Dr. Pala" Organization: OpenCA Labs Message-ID: Date: Tue, 17 Jul 2018 08:40:00 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040609070401070101040602" Archived-At: Subject: Re: [lamps] Call for adoption of draft-nir-saag-star X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 17 Jul 2018 14:40:05 -0000 This is a cryptographically signed message in MIME format. --------------ms040609070401070101040602 Content-Type: multipart/alternative; boundary="------------110E4D3D070A26B6478B58D1" Content-Language: en-US This is a multi-part message in MIME format. --------------110E4D3D070A26B6478B58D1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I have expressed my concerns about this work in the past and I agree with the conclusion from Ryan. Therefore I do not support its adoption as well in its current form. Cheers, Max On 7/14/18 6:39 PM, Ryan Sleevi wrote: > > > [...] > > I have read it, and as expressed during the charter discussion, do not > support it as a place to start in its current form. > > The problem statement that it seems to address is still ill-defined, > and it=E2=80=99s explanations for certain design choices are still > contradictory and inconsistent. As such, it=E2=80=99s technical proposa= ls lack > merit for the problem or cohesion as a solution, and more work should > be done to clearly articulate the problem and solution space prior to > adoption. > =C2=A0 > --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------110E4D3D070A26B6478B58D1 Content-Type: multipart/related; boundary="------------54EBC8EF4D8D0F16FDF0D74F" --------------54EBC8EF4D8D0F16FDF0D74F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi all,

I have expressed my concerns about this work in the past and I agree with the conclusion from Ryan. Therefore I do not support its adoption as well in its current form.

Cheers,
Max


On 7/14/18 6:39 PM, Ryan Sleevi wrote:=


[...]

I have read it, and as expressed during the charter discussion, do not support it as a place to start in its current form.

The problem statement that it seems to addres= s is still ill-defined, and it=E2=80=99s explanations for certa= in design choices are still contradictory and inconsistent. As such, it=E2=80=99s technical proposals lack merit for the pro= blem or cohesion as a solution, and more work should be done to clearly articulate the problem and solution space prior to adoption.
=C2=A0


--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--------------54EBC8EF4D8D0F16FDF0D74F Content-Type: image/png; name="ejdkaelccaailofe.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ejdkaelccaailofe.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------54EBC8EF4D8D0F16FDF0D74F-- --------------110E4D3D070A26B6478B58D1-- --------------ms040609070401070101040602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CyAwggUyMIIEGqADAgECAhEAu2YCW4tRQdGHMc0S/FQsNDANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTcxMjAxMDAw MDAwWhcNMTgxMjAxMjM1OTU5WjAkMSIwIAYJKoZIhvcNAQkBFhNkaXJlY3RvckBvcGVuY2Eu b3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyEDKYfy+DFhtDn8bIXyP25Xe DjUIkMQDm90A1JPoQ4tuTk6kXwulPvAmvtLGuRAzEqFpV/fqz4sAlx8FgxvRZ5PunZ1H1/lJ CNEdir53Xv8TEf+R/n+Ca5RNUR+GhS72zhp9xx8uDRZds2DeXvW9uhYp9nsbX6rWIFT5YfWF 1SukFXwXSnHuXc9nDT6p0Kp6UNzusn/lMhXhIwgpNA26/mHAdScYyMoB4yaZeMpdZN75XGWO slhXcXdeGJo93E48kffdu0yo4WTbpLwhs/IrkG4OXB1N3Bf+9oHZwVun1hlCZEfuSit0mvrx x8wzPCPiggXu6j6VqPoJqecV6xKCHwIDAQABo4IB6TCCAeUwHwYDVR0jBBgwFoAUgq9sjPjF /pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFEPV9allspkmYqkQRx2BlAdbOrjhMA4GA1UdDwEB /wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggr BgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2g S4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3BlbmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEA g+REupW946f7esdYmE1QxsYlkubErxz8JLovVDSKTHwxR1/VxF/B7rGeiSPBHTmKQYwlWCrp eHZNfzaDDkDamwLXm7v4+brNfQKRpOLnYPQQffp7xim72INakLgts8d5I7bic785dj4M5JP4 XA2qUD9wduwNwquua6v7zM3chpoRjapumzLNDDr47GccOKAZYaaqFwbpwJPQYuiC07WWnn7g FzdNKYN6VM6Re6wVEHP6fEvNrleV0pf1iFjLKugnriGKL9wj6xX25JsMmGmqZcfdpnkTE4Zf eQBEZVnn8s7HBX+MA/K+YnHxRwA2c5XwNbEhZ2rvh2uFIMXBDlt+tDCCBeYwggPOoAMCAQIC EGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQ PTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivl JTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG 9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoS WY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQAB o4IBPDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKv bIz4xf6WYXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEA MBEGA1UdIAQKMAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9k b2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcB AQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFk ZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJ KoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo 7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaB Q+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKS TvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+E2pvOUtY +hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnMrwfHM5td hYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9hz9D0S0U4 jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5PDEJ M/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJU mpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTK TlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIEODCCBDQCAQEw ga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01P RE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAu2YC W4tRQdGHMc0S/FQsNDANBglghkgBZQMEAgEFAKCCAlswGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwNzE3MTQ0MDAwWjAvBgkqhkiG9w0BCQQxIgQgnEDC X52X1LB0cRFhTY20czAtkpqa4MYKAxiUsehBPc4wbAYJKoZIhvcNAQkPMV8wXTALBglghkgB ZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGwMIGtMIGX MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJT QSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRALtmAluLUUHR hzHNEvxULDQwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRALtmAluLUUHRhzHNEvxULDQwDQYJKoZIhvcNAQEB BQAEggEAhgYTHAkGcHggRNiobPIY5EWDkOMRYw0MzocbMOoyvgdXlyuoPnYNWiJLNbyNOLyc DfMG9lXGnGne3HUAdjuFQeKsChUDK04MnQpBflpDKhrYoQq+DWYXtCBmkhMJrMt8JwLQmgjT ixm8jamP4nCE06az9xPy+nfeCTM3B2LFHeIA4PpZLgvlwdNYnzd6hyEg2gMCB9Im7nC8vacD qxCp12VU48iZ2rjBoyHvUJezN/VW/2VYgM2iJppMVVr0kJLwhI0zthZJVTXxRrqbRGcNsjlw 0Mx4NNRFhRm7WFHVTLZ2F6uaTfz5l1N55xPq6vdhV6JGA4WsH2ZxHixAgDSn+gAAAAAAAA== --------------ms040609070401070101040602-- From nobody Tue Jul 17 08:15: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 17DE2130DFE for ; Tue, 17 Jul 2018 08:15:52 -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, SPF_PASS=-0.001, T_HK_NAME_DR=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 q2v2W21v-Ol0 for ; Tue, 17 Jul 2018 08:15:44 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 3B82F124C04 for ; Tue, 17 Jul 2018 08:15:42 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 1B6993741029 for ; Tue, 17 Jul 2018 15:15:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BUIpngBm7nj6 for ; Tue, 17 Jul 2018 11:15:41 -0400 (EDT) Received: from dhcp-8f30.meeting.ietf.org (dhcp-8f30.meeting.ietf.org [31.133.143.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id A85673740FF1 for ; Tue, 17 Jul 2018 11:15:35 -0400 (EDT) To: spasm@ietf.org References: From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <755f5620-f0c3-5425-9cad-1f432eeae683@openca.org> Date: Tue, 17 Jul 2018 09:15:32 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050505070303010800060403" Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-cms-mts-hash-sig X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 17 Jul 2018 15:15:52 -0000 This is a cryptographically signed message in MIME format. --------------ms050505070303010800060403 Content-Type: multipart/alternative; boundary="------------16C9248C2820932F264A3439" Content-Language: en-US This is a multi-part message in MIME format. --------------16C9248C2820932F264A3439 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I support the adoption of this draft. On 7/14/18 10:03 AM, Tim Hollebeek wrote: > > The recently approved LAMPS WG Charter adds this work item: > > =A0 > > 5. Specify the use of hash-based signatures with the Cryptographic > Message Syntax (CMS).=A0 Hash-based signature use small private and > public keys, and they have low computational cost; however, the > signature values are quite large.=A0 For this reason they might not be > used for signing X.509 certificates or S/MIME messages; however, sine > hash-based signature algorithms are secure even if a large-scale > quantum computer is invented.=A0 The low computational cost for > signature verification makes hash-based signatures attractive in the > Internet of Things environments, and the quantum resistance makes them > attractive for the distribution of software updates. > > =A0 > > It has been suggested that the WG adopt draft-housley-cms-mts-hash-sig > as the starting point for this work.=A0 Since Russ Housley is the autho= r > of this draft, Tim Hollebeek will judge consensus for this > discussion.=A0 Please voice your support or concerns on the list. > --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------16C9248C2820932F264A3439 Content-Type: multipart/related; boundary="------------88BF493B27C1C7B8B393AAE4" --------------88BF493B27C1C7B8B393AAE4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I support the adoption of this draft.


On 7/14/18 10:03 AM, Tim Hollebeek wrote:

The recently approved LAMPS WG Charter adds this work item:

=A0

5. Specify the use of hash-based signatures with the Cryptographic Message Syntax (CMS).=A0 Hash-based signature use small private and public keys, and they have low computational cost; however, the signature values are quite large.=A0 For this reason they might not be used for signing X.509 certificates or S/MIME messages; however, sine hash-based signature algorithms are secure even if a large-scale quantum computer is invented.=A0 The low computational cost for signature verification makes hash-based signatures attractive in the Internet of Things environments, and the quantum resistance makes them attractive for the distribution of software updates.

=A0

It has been suggested that the WG adopt draft-housley-cms-mts-hash-sig as the starting point for this work.=A0 Since Russ Housley is the author of this draft, Tim Hollebeek will judge consensus for this discussion.=A0 Please voice your support or concerns on the list.


--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--------------88BF493B27C1C7B8B393AAE4 Content-Type: image/png; name="kncghkihogkgjgjc.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="kncghkihogkgjgjc.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------88BF493B27C1C7B8B393AAE4-- --------------16C9248C2820932F264A3439-- --------------ms050505070303010800060403 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CyAwggUyMIIEGqADAgECAhEAu2YCW4tRQdGHMc0S/FQsNDANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTcxMjAxMDAw MDAwWhcNMTgxMjAxMjM1OTU5WjAkMSIwIAYJKoZIhvcNAQkBFhNkaXJlY3RvckBvcGVuY2Eu b3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyEDKYfy+DFhtDn8bIXyP25Xe DjUIkMQDm90A1JPoQ4tuTk6kXwulPvAmvtLGuRAzEqFpV/fqz4sAlx8FgxvRZ5PunZ1H1/lJ CNEdir53Xv8TEf+R/n+Ca5RNUR+GhS72zhp9xx8uDRZds2DeXvW9uhYp9nsbX6rWIFT5YfWF 1SukFXwXSnHuXc9nDT6p0Kp6UNzusn/lMhXhIwgpNA26/mHAdScYyMoB4yaZeMpdZN75XGWO slhXcXdeGJo93E48kffdu0yo4WTbpLwhs/IrkG4OXB1N3Bf+9oHZwVun1hlCZEfuSit0mvrx x8wzPCPiggXu6j6VqPoJqecV6xKCHwIDAQABo4IB6TCCAeUwHwYDVR0jBBgwFoAUgq9sjPjF /pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFEPV9allspkmYqkQRx2BlAdbOrjhMA4GA1UdDwEB /wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggr BgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2g S4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3BlbmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEA g+REupW946f7esdYmE1QxsYlkubErxz8JLovVDSKTHwxR1/VxF/B7rGeiSPBHTmKQYwlWCrp eHZNfzaDDkDamwLXm7v4+brNfQKRpOLnYPQQffp7xim72INakLgts8d5I7bic785dj4M5JP4 XA2qUD9wduwNwquua6v7zM3chpoRjapumzLNDDr47GccOKAZYaaqFwbpwJPQYuiC07WWnn7g FzdNKYN6VM6Re6wVEHP6fEvNrleV0pf1iFjLKugnriGKL9wj6xX25JsMmGmqZcfdpnkTE4Zf eQBEZVnn8s7HBX+MA/K+YnHxRwA2c5XwNbEhZ2rvh2uFIMXBDlt+tDCCBeYwggPOoAMCAQIC EGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQ PTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivl JTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG 9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoS WY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQAB o4IBPDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKv bIz4xf6WYXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEA MBEGA1UdIAQKMAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9k b2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcB AQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFk ZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJ KoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo 7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaB Q+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKS TvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+E2pvOUtY +hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnMrwfHM5td hYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9hz9D0S0U4 jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5PDEJ M/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJU mpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTK TlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIEODCCBDQCAQEw ga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01P RE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAu2YC W4tRQdGHMc0S/FQsNDANBglghkgBZQMEAgEFAKCCAlswGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwNzE3MTUxNTMyWjAvBgkqhkiG9w0BCQQxIgQg7Yku /UJ/soPsTRPca/SjVLD7ut8ZrlJ/Go3rHHSH3D8wbAYJKoZIhvcNAQkPMV8wXTALBglghkgB ZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGwMIGtMIGX MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJT QSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRALtmAluLUUHR hzHNEvxULDQwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRALtmAluLUUHRhzHNEvxULDQwDQYJKoZIhvcNAQEB BQAEggEAr9imKo4O91RyBOBflkJrHPC4aQaXaswc26C22lJfdVhu4VUd8IyI/9X8VRNYnUKY BQRnrjTewroguAzy9v9kviZ3q7oWDAY34ClLtPg7IJeu9u/ZAtQuSEj+s82dIH+nmQenlyNu HSAzHvJ1F/lIYPglO3REjm8Tm6OACIgYBUt1fTa6CK589sMwrAJ8uKOOxQY6LBiKQy6MiKDl ay4gZpR/XE6UNwzagNd757yePD133Hg2/eMRMZ0Z3VLH61Mj6v0dLrB0lY1SkheS/M78YNzk JLWTqBkGGhF3DNI0gq5Vv8Yjp6Y6/l+BaL1Ei9nmrQX0QP7fI/P40s2/KiPCyQAAAAAAAA== --------------ms050505070303010800060403-- From nobody Tue Jul 17 08:18:38 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 9C167126CB6 for ; Tue, 17 Jul 2018 08:18:35 -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, SPF_PASS=-0.001, T_HK_NAME_DR=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 I81jymPJxyGo for ; Tue, 17 Jul 2018 08:18:34 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 1608C126DBF for ; Tue, 17 Jul 2018 08:18:34 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id EA7F83741029 for ; Tue, 17 Jul 2018 15:18:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id s0GLDhs_P3iV for ; Tue, 17 Jul 2018 11:18:33 -0400 (EDT) Received: from dhcp-8f30.meeting.ietf.org (dhcp-8f30.meeting.ietf.org [31.133.143.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 620FA3740FF1 for ; Tue, 17 Jul 2018 11:18:33 -0400 (EDT) To: spasm@ietf.org References: From: "Dr. Pala" Message-ID: <564cbb44-366a-7a53-61e0-faf4266ccd24@openca.org> Date: Tue, 17 Jul 2018 09:18:32 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------99727E33E6853EBFEB1763E6" Content-Language: en-US Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-hash-of-root-key-cert-extn X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 17 Jul 2018 15:18:36 -0000 This is a multi-part message in MIME format. --------------99727E33E6853EBFEB1763E6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit I support the adoption of this work. On 7/14/18 10:04 AM, Tim Hollebeek wrote: > > The recently approved LAMPS WG Charter adds this work item: > >   > > 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. > >   > > It has been suggested that the WG adopt > draft-housley-hash-of-root-key-cert-extn as the starting point for > this work.  Since Russ Housley is the author of this draft, Tim > Hollebeek will judge consensus for this discussion.  Please voice your > support or concerns on the list. > >   > --------------99727E33E6853EBFEB1763E6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I support the adoption of this work.


On 7/14/18 10:04 AM, Tim Hollebeek wrote:

The recently approved LAMPS WG Charter adds this work item:

 

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.

 

It has been suggested that the WG adopt draft-housley-hash-of-root-key-cert-extn as the starting point for this work.  Since Russ Housley is the author of this draft, Tim Hollebeek will judge consensus for this discussion.  Please voice your support or concerns on the list.

 

--------------99727E33E6853EBFEB1763E6-- From nobody Tue Jul 17 09:00: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 7C583130E61 for ; Tue, 17 Jul 2018 09:00:32 -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.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_IMAGE_ONLY_32=0.001, 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 BtHtESu76NkK for ; Tue, 17 Jul 2018 09:00:30 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E83130E6B for ; Tue, 17 Jul 2018 09:00:30 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id v22-v6so1225371lfe.8 for ; Tue, 17 Jul 2018 09:00: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; bh=rCizU6i56V9HHZneJZAwXEUVqcvbi+89XSFxlDLaNKo=; b=Jpu546YOnZC2H55KeGdncW8c4tELcw2m289O65fWRt0lJprd6VctyFkoNV5OaNEG1n 7jaZwTh0WibW0IIuQ7g2JczokES+ykcXAJxJNdtGIMZOQQE2KrZeZvJDMa25wQ7pAOLw apYWP7LOcvtm7d24+0cfs8ksDYCglAyxGQz+W6gXkhWBEfOUPu8KjwTsAcM8wZH/ebUQ BFsiPLUpZegRCA6pvq87UeU0nhD3OF29BU4fCGyXej2SQW9uZJGltUDibUknJtHXxhG6 VNzPV9v4GcachBh7abpH0C7EtAYuvzXkHFB/WELIW3XV2WatHxW3cOmPW3AxpCjRqlAA 2o5g== 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; bh=rCizU6i56V9HHZneJZAwXEUVqcvbi+89XSFxlDLaNKo=; b=iqXEInEW0zEBLVJjikU2caP5zf1DZkk3DS91pwTNba8SexXLv5pOTdWKisVFV8I4gj Ifgd1CJQrqPxwfnDbsHSxI/A0rfZ6URCYrwK2pxGpnzIyhI3DEQclmLu+RKX72gFV3qo Fs73SaOifvX+PU3McGEqI6ooIyhNd8ivw0SwjDl65A4KLpef47SxVhOSjHoyxJnOQL1r sKOVwE8jv2700+W0AK7lKVgu9fA9NKTbXmTqVPQy7O0VJoXNLkaO+DE/5j0uUVxwgePn cZrYMt60HIdl4jtsebY05Yr6avogUFO/WrT8azS16c+61GTlOP6m50hc4+7yCPuAWeJj V4yQ== X-Gm-Message-State: AOUpUlHhGfz6RJMDl1mMyTENTXWL+qgwJzG6gkSVaH2zhhIzTdlmxjMu fWz/tYcNa9CJt0wz64wS/2Lzb5jei6JdlSpVvZY= X-Google-Smtp-Source: AAOMgpe8TyHsUCjxG97cYJz8TnDx4qULluu5fwCTP/1S0KZ+ogQfDdI/WNHHJezbEO3aqiBK5+AlhqH1MwiBbRjr3ws= X-Received: by 2002:a19:501e:: with SMTP id e30-v6mr1623823lfb.71.1531843228057; Tue, 17 Jul 2018 09:00:28 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 2002:a2e:119d:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 09:00:27 -0700 (PDT) In-Reply-To: References: From: Daniel Migault Date: Tue, 17 Jul 2018 12:00:27 -0400 X-Google-Sender-Auth: CJrz8w5q7lwzEKc3DM2M5CUZ6HE Message-ID: To: SPASM Content-Type: multipart/related; boundary="0000000000007746cb0571340b04" Archived-At: Subject: Re: [lamps] Call for adoption of draft-nir-saag-star X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 17 Jul 2018 16:00:46 -0000 --0000000000007746cb0571340b04 Content-Type: multipart/alternative; boundary="0000000000007746c90571340b03" --0000000000007746c90571340b03 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I see the draft as a good placeholder for the discussion to happen. I support its adoption. Yours, Daniel On Tue, Jul 17, 2018 at 10:40 AM, Dr. Pala wrote: > Hi all, > > I have expressed my concerns about this work in the past and I agree with > the conclusion from Ryan. Therefore I do not support its adoption as well > in its current form. > > Cheers, > Max > > On 7/14/18 6:39 PM, Ryan Sleevi wrote: > > > > [...] > > I have read it, and as expressed during the charter discussion, do not > support it as a place to start in its current form. > > The problem statement that it seems to address is still ill-defined, and > it=E2=80=99s explanations for certain design choices are still contradict= ory and > inconsistent. As such, it=E2=80=99s technical proposals lack merit for th= e problem > or cohesion as a solution, and more work should be done to clearly > articulate the problem and solution space prior to adoption. > > > > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > [image: OpenCA Logo] > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > --0000000000007746c90571340b03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I see the draft as a good placeholder for the discuss= ion to happen. I support its adoption.

Yours,=
Daniel


On Tue, Jul 17, 2018 at 10:40 AM, Dr. Pala <dir= ector@openca.org> wrote:
=20 =20 =20

Hi all,

I have expressed my concerns about this work in the past and I agree with the conclusion from Ryan. Therefore I do not support its adoption as well in its current form.

Cheers,
Max


On 7/14/18 6:39 PM,= Ryan Sleevi wrote:
=20


[...]

I have read it, and as expressed during the charter discussion, do not support it as a place to start in its current form.

The problem statement that it seems to address is still ill-defined, and it=E2=80=99s explanations for certain design choices are still contradictory and inconsistent. As such, it=E2=80=99s technical proposals lack merit for the probl= em or cohesion as a solution, and more work should be done to clearly articulate the problem and solution space prior to adoption.
=C2=A0


--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA

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


--0000000000007746c90571340b03-- --0000000000007746cb0571340b04 Content-Type: image/png; name="ejdkaelccaailofe.png" Content-Disposition: inline; filename="ejdkaelccaailofe.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 1a6a5111d108982_0.0.0.1.1 iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoXBwES CQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAqMjpXKgs/ MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1SGdDR0lDSFJf RDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27PgCaSANtUT57VBer SQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXaeVR+lVRZrYld1ZiB7YEuS YQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDVWQJ1blapYjbXWgDRXACMaU6W bgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3WqaS6BcGeobwndXwzkXwLgYgDaYwyM eCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuvcEPrZQDQaSyockrFbSvmZwnabQLvZwDp aQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqK gnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXleSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQ iwCximixim/EkAORkZGVkYrOh0rPiVL5giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvK lGqpnJLdlF2boKy+m324nImkoZ+eo6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/S rI7dq4bqqXTOrpWttL+6s6uwtbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfR wbXFyMvbxbPNyMP8zgTczMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp 7/Hy9PHw9fj6/v3YktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPX GT6E+l9BZ0EFsTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+U SgFL4r9gEaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqE SrMplYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75UjLZf p6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/85sH2KeX vj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf70RPUPjxLouB EgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxcAwyWTbacW0sTDGoJ en4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+NpuKpq32qLVaexOCCJB91 aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq1LzUMQ4uxxycjl0LWO1bBsY6 yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XOcajZb6GDu7PTFEdPkVu0k4vQyd3J c/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV 2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRbjuxtfqRypNACK28+j3FsqcilAD0ADuIWCt0y Ra7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7 QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxar lr0grlQn92DQt1vBUk+nUFeHGZmegUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJ o+2PGLb2d9WE5bw1L4DcnOco9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bF zhw3eZylM2dgwkbWW3IyJp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwd ElJmarxedr/u3P6CNn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivo BjrfUgNB69zfb6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toV EevCi9/ffmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzS Y3FuBkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/dY1p7 qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1RgrYlfrRe SqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxHdRJFGJkhfKxg mM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3luaLNe1F++bjXGyWyz ZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCmGIzpqKlm27KTSWUcAX1g oBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJCBVkrrBJ1BewMmlVpgRUQF7wp ItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQYIOhklDKzo2C1IV2sijzdhjorqwef NdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41qKFl02YaswYNkULTeLC9CFFK4bDHDMmZb hnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYvJpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkc Hz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkhmt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlC XaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7Wfg ZOv4uLLl0w8wUah71QLBpJeXq/eMVVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6 vjt1z/ghMehVKiUpyt1VYBXCN6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oE DQ6jB9Wc3Z6bm6zLTtLlgLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgX s2kV4WUC0YR/KOLvPby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP 7LnTfsd42at3+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw90 1G+ttVlTJa34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K +f59qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a8XoA AAAASUVORK5CYII= --0000000000007746cb0571340b04-- From nobody Tue Jul 17 12:23: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 0395212F295 for ; Tue, 17 Jul 2018 12:23:14 -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 5OE1Hq8pn56C for ; Tue, 17 Jul 2018 12:23:12 -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 64414124BE5 for ; Tue, 17 Jul 2018 12:23:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4CC26300A0A for ; Tue, 17 Jul 2018 15:23:10 -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 WgTxiycoMB0r for ; Tue, 17 Jul 2018 15:23:09 -0400 (EDT) Received: from [5.5.33.207] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 5E7A3300288 for ; Tue, 17 Jul 2018 15:23:09 -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 11.4 \(3445.8.2\)) Message-Id: <6527E23C-5BD0-454E-B7DF-3D46A8C812BF@vigilsec.com> Date: Tue, 17 Jul 2018 15:23:08 -0400 To: SPASM X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [lamps] Minutes and jabber scribe X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 17 Jul 2018 19:23:14 -0000 We need someone to take notes and and another person to be jabber scribe = for the LAMPS session Thursday afternoon. Please volunteer now so that = we do not need to spend valuable meeting time twisting arms. Russ & Tim From nobody Tue Jul 17 12:24: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 72C221310AB for ; Tue, 17 Jul 2018 12:24:41 -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 O2XthKxOaT5p for ; Tue, 17 Jul 2018 12:24:39 -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 5B162131084 for ; Tue, 17 Jul 2018 12:24:39 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6HJLWod008706; Tue, 17 Jul 2018 20:24:39 +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=0y62Zfg1Zig8MJ2JzEprfzBRXxshL5fbBvhfVCVCtgE=; b=dG2c1LjVGglsWxvpXApqN7eBmxUQEDiP8FV8IX+z6kAQTSIbkOzGJUnoWP1TH8wi5hHC 2/QM3DZEGufQJUfeRkMFfAYwBnLvB/y7WC8cueuP4WkndhcF799yYTYDSDQIE3iACAoH bfurmJhA7Os+0++SRHEkn9jlfMdy91BsQVnx98jsqJtqZdlP4boTrNhVMFeHOjMYhqnT TTtLXfhcuhbtLCKcj5zGg0RMuU8iQUtsxiIdSuGClPaisWriCNzlTAuIRrCZjMYnmtM9 o1NGIdEk05ZC9I/TdeyPzi0PQ2gjhhXE3qwPFY06MPGwrXfYvZRcR9qV84DujX6VDQtm bQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2k9nmyg44s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Jul 2018 20:24:38 +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 w6HJJtoJ020909; Tue, 17 Jul 2018 15:24:37 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2k7cguka4p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 17 Jul 2018 15:24:37 -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; Tue, 17 Jul 2018 15:24:36 -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; Tue, 17 Jul 2018 15:24:36 -0400 From: "Salz, Rich" To: Russ Housley , SPASM Thread-Topic: [lamps] Minutes and jabber scribe Thread-Index: AQHUHgOgFgpzqCZaakaG5eCVPYaX9aSTy5EA Date: Tue, 17 Jul 2018 19:24:36 +0000 Message-ID: <16C5A8C4-B65C-4676-8629-814555177C35@akamai.com> References: <6527E23C-5BD0-454E-B7DF-3D46A8C812BF@vigilsec.com> In-Reply-To: <6527E23C-5BD0-454E-B7DF-3D46A8C812BF@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.f.0.180709 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.42.203] Content-Type: text/plain; charset="utf-8" Content-ID: <62D5B7B62039194DB451A889B6291A13@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-17_05:, , 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=991 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807170201 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-17_05:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=905 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807170201 Archived-At: Subject: Re: [lamps] Minutes and jabber scribe X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 17 Jul 2018 19:24:49 -0000 SSdsbCBkbyBqYWJiZXINCg0K77u/T24gNy8xNy8xOCwgMzoyMyBQTSwgIlJ1c3MgSG91c2xleSIg PGhvdXNsZXlAdmlnaWxzZWMuY29tPiB3cm90ZToNCg0KICAgIFdlIG5lZWQgc29tZW9uZSB0byB0 YWtlIG5vdGVzIGFuZCBhbmQgYW5vdGhlciBwZXJzb24gdG8gYmUgamFiYmVyIHNjcmliZSBmb3Ig dGhlIExBTVBTIHNlc3Npb24gVGh1cnNkYXkgYWZ0ZXJub29uLiAgUGxlYXNlIHZvbHVudGVlciBu b3cgc28gdGhhdCB3ZSBkbyBub3QgbmVlZCB0byBzcGVuZCB2YWx1YWJsZSBtZWV0aW5nIHRpbWUg dHdpc3RpbmcgYXJtcy4NCiAgICANCiAgICBSdXNzICYgVGltDQogICAgDQogICAgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBTcGFzbSBtYWlsaW5n IGxpc3QNCiAgICBTcGFzbUBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc3Bhc20NCiAgICANCg0K From nobody Tue Jul 17 15:45: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 B59C7130F1D for ; Tue, 17 Jul 2018 15:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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] 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 iolZDcHSJyTk for ; Tue, 17 Jul 2018 15:45:29 -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 4B217130DF4 for ; Tue, 17 Jul 2018 15:45:29 -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:In-Reply-To:MIME-Version: Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: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=qSCfzx7vncWWjAg3iVXz/KfZGRpYcKoA7SLNz4FSAZo=; b=HMdPKSOHpfq82DziPPP5Ix3iPX fPK3EFQpm6ajI+InrddTiCoXesm3FZsiplrO7F0s7vWfC1KRYPnUzQtvIzHddGGAYzsG2diXP+ggF eG6SW9kvLTbXSf9Z2IaJgW6FEQhoRxCPfca9Upk1SIx1imOXC6hp7eAhJYwmjgmx0voE=; Received: ; Tue, 17 Jul 2018 15:45:28 -0700 To: Corey Bonnell , SPASM References: <0EA657BD-8E44-4173-8059-8A312998DAA4@trustwave.com> From: Jacob Hoffman-Andrews Message-ID: <171ce08e-3700-45e8-8208-08bb15077f72@eff.org> Date: Tue, 17 Jul 2018 15:45:28 -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: <0EA657BD-8E44-4173-8059-8A312998DAA4@trustwave.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [lamps] New draft: rfc6844bis X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 17 Jul 2018 22:45:32 -0000 On 07/10/2018 06:58 AM, Corey Bonnell wrote: > It looks like the updated ABNF grammar for the issue property tag is missing some line breaks, as several of the production rules are now on the same line. Thanks. I've fixed this in my working copy, and it will make it into the next revision. > There is one more issue that we might want to tackle as part of the 6844-bis effort: changing the "SHOULD" for making CAA queries against authoritative nameservers to a "MUST" (section 6.3: For example, all portions of the DNS lookup process SHOULD be performed against the authoritative name server). This was originally mentioned in https://blog.cloudflare.com/caa-of-the-wild/, but I don't think this has been brought up on this mailing list before and thought we should at least discuss it. My opinion is that it should remain a "SHOULD" in the RFC, otherwise the RFC is dictating policy. The preferable route is to define required lookup properties in policy explicitly (eg, the Baseline Requirements would dictate that all lookups MUST be performed against an authoritative nameserver). Yeah, I agree we should keep this as a SHOULD. I think defining what exactly it means could get messy. For instance, CAs are likely to use an internal recursive resolver, which in turn contacts a series of authoritative resolvers. From nobody Wed Jul 18 09:04:32 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 007B413120F for ; Wed, 18 Jul 2018 09:04:23 -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, 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=trustwave.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 ujM2kZ-r88KN for ; Wed, 18 Jul 2018 09:04:20 -0700 (PDT) Received: from seg-node-chi-03.trustwave.com (seg-node-chi-03.trustwave.com [204.13.200.108]) (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 4073A131236 for ; Wed, 18 Jul 2018 09:04:18 -0700 (PDT) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (Not Verified[216.32.181.119]) by seg-node-chi-03.trustwave.com with Trustwave SEG (v8, 0, 6, 10791) (using TLS: TLSv1.2, AES256-SHA256) id ; Wed, 18 Jul 2018 11:04:14 -0500 Received: from SN6PR07MB4575.namprd07.prod.outlook.com (52.135.95.19) by SN6PR07MB4766.namprd07.prod.outlook.com (52.135.77.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.18; Wed, 18 Jul 2018 16:04:13 +0000 Received: from SN6PR07MB4575.namprd07.prod.outlook.com ([fe80::d0e2:e12:541d:c131]) by SN6PR07MB4575.namprd07.prod.outlook.com ([fe80::d0e2:e12:541d:c131%2]) with mapi id 15.20.0952.021; Wed, 18 Jul 2018 16:04:13 +0000 From: Corey Bonnell To: Jacob Hoffman-Andrews , SPASM Thread-Topic: [lamps] New draft: rfc6844bis Thread-Index: AQHT+Q/DosfAyanL40+VifZ4n+PYpqSIdv2AgAvWmgCAAN8pgA== Date: Wed, 18 Jul 2018 16:04:12 +0000 Message-ID: References: <0EA657BD-8E44-4173-8059-8A312998DAA4@trustwave.com> <171ce08e-3700-45e8-8208-08bb15077f72@eff.org> In-Reply-To: <171ce08e-3700-45e8-8208-08bb15077f72@eff.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=CBonnell@trustwave.com; x-originating-ip: [204.13.202.248] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR07MB4766; 7:mn9s5nr1VehdcxCXMLCndNLTDiz2bogTzB4eFWD0zCqbNURm/LlvPD+PFDSR+2EvbYt9xFC/AYu3N7tdrovKZNFxA5bZUq3ZDc+vzULwlrMS3XZbwYrQgfX2asSYDXkIJg5k7BEOI6A9cA82OoQho996v9kU7m/00D/QvlBgnSJ4YExrWEGqrMOecl798Yz/vQZK3fJpSwgBckEm5gstfppN+6W4Fbs2Yc7KZrwsH4rGgFWj3ceKR9ocnP6ZxCQb x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 207d76ba-7576-48ef-608a-08d5ecc81ad0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:SN6PR07MB4766; x-ms-traffictypediagnostic: SN6PR07MB4766: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(232896897485771)(158342451672863); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231311)(944501410)(52105095)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:SN6PR07MB4766; BCL:0; PCL:0; RULEID:; SRVR:SN6PR07MB4766; x-forefront-prvs: 0737B96801 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(39860400002)(366004)(346002)(376002)(199004)(189003)(106356001)(72206003)(53936002)(2906002)(80792005)(105586002)(7736002)(476003)(446003)(2616005)(26005)(256004)(305945005)(102836004)(99286004)(2900100001)(68736007)(53546011)(83716003)(76176011)(5250100002)(97736004)(478600001)(6116002)(14454004)(186003)(6506007)(3846002)(966005)(11346002)(486006)(86362001)(81156014)(33656002)(36756003)(6436002)(81166006)(8676002)(5660300001)(316002)(66066001)(82746002)(8936002)(6306002)(6512007)(25786009)(6246003)(6486002)(229853002)(110136005)(19400905002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR07MB4766; H:SN6PR07MB4575.namprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: trustwave.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: l7F7K3MY3VELLe/xJlovO3E0+Ta0ABvysEKDU0XEqFXNChF6T/Xplvc257kIpLquhpA5w/wxTbCFrWvazy69JUTRyUmw/8WGavYtv9L//GkFrO/AFzoiLPWbFCIq4yOL/fVPj0rJM9bnaJrE3LctCdHbU9BAsWosospN0hiwsIKnkbQdIx+dDFSRp+PudE95XnYI0ncmvjptqdfXnX6sh5CeMvFW33Jz3yOz9ysdULuMwbV0C3Wy4JXUXm36PNvPFlQOsdw4Z3IOA1CcOxkdO8ghWvji0fg0jXrhXU6mIwjCQyogRh2NemVf/TP8dg5yniWeP7KpefeCC8nuYFi69IKlgHwWgxxyE97gsR7j4R8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trustwave.com X-MS-Exchange-CrossTenant-Network-Message-Id: 207d76ba-7576-48ef-608a-08d5ecc81ad0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2018 16:04:12.8700 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cb1dab68-a067-4b6b-ae7e-c012e8c33f6a X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR07MB4766 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=trustwave.com; s=080318_segcloud; t=1531929856; bh=qqCvHQfqwBNiGEK/sLtCiLqLC6/0lWsV1DnzcBRVu4Y=; h=From:To:Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:authentication-results: x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-ms-exchange-senderadcheck: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf: x-microsoft-antispam-message-info:spamdiagnosticoutput: spamdiagnosticmetadata:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version:X-OriginatorOrg: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id: X-MS-Exchange-Transport-CrossTenantHeadersStamped; b=GyjEVZf2SlUYBIDVj5iVo13ekSmYeyPyKVJ8wp6wqV5Xmz03rYH7EROpZOwcVustK draT6BM9UdWnjR5Qhk3COST1x7S4UfTjKvWfWt9Cp5DZqTH3/n70pRCpt1GbYU4frf 6fAJ5dBf0uAaAfjZvlqptIayvGsaKxorJw2G/SG5yGdyiKre5oWU3LStQPiqbI3r0m ilXp5S+t+27f4JlUR1LC/jaBjukB2YqGcU6qoj6BqKXTsloSefAVsdJ7jNZ4meK/Bi SlbhOgpGhcV1pIvLB/wqBtZ2pEAQC+3ZvO7rNpHWM44Tkzb4FF38f5oBbA3CztsxWt MJR1J/74G85Ww== Archived-At: Subject: Re: [lamps] New draft: rfc6844bis X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 18 Jul 2018 16:04:31 -0000 QSBiaXQgYWdvLCBJbGFyaSBMaXVzdmFhcmEgcG9pbnRlZCBvdXQgb24gdGhlIEFDTUUgV0cgbGlz dCAoaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hY21lL2N1cnJlbnQvbXNn MDI4NDUuaHRtbCkgdGhhdCB0aGUgZ3JhbW1hciBpbiA2ODQ0LWJpcyBoYXMgYSBtaW5vciBpc3N1 ZSBpbiByZWdhcmQgdG8gbXVsdGlwbGUgd2hpdGVzcGFjZSBjaGFyYWN0ZXIgc2VxdWVuY2VzLCBh cyB0aGUgZ3JhbW1hciBwcm9kdWNlcyBhbWJpZ3VvdXMgcGFyc2VzIGluIHRoYXQgY2FzZS4gSSBh Z3JlZSB3aXRoIGhpcyBhbmFseXNpcyBhbmQgcHJvcG9zZWQgZml4IHRvIHRoZSBpc3N1ZXZhbHVl IHByb2R1Y3Rpb24gcnVsZToNCg0KaXNzdWV2YWx1ZSA9ICpXU1AgW2RvbWFpbiAqV1NQXSBbIjsi ICpXU1AgW3BhcmFtZXRlcnMgKldTUF1dDQoNClRoYW5rcywgDQpDb3JleQ0KDQrvu79PbiA3LzE3 LzE4LCA2OjQ1IFBNLCAiSmFjb2IgSG9mZm1hbi1BbmRyZXdzIiA8anNoYUBlZmYub3JnPiB3cm90 ZToNCg0KICAgIE9uIDA3LzEwLzIwMTggMDY6NTggQU0sIENvcmV5IEJvbm5lbGwgd3JvdGU6DQog ICAgPiBJdCBsb29rcyBsaWtlIHRoZSB1cGRhdGVkIEFCTkYgZ3JhbW1hciBmb3IgdGhlIGlzc3Vl IHByb3BlcnR5IHRhZyBpcyBtaXNzaW5nIHNvbWUgbGluZSBicmVha3MsIGFzIHNldmVyYWwgb2Yg dGhlIHByb2R1Y3Rpb24gcnVsZXMgYXJlIG5vdyBvbiB0aGUgc2FtZSBsaW5lLg0KICAgIFRoYW5r cy4gSSd2ZSBmaXhlZCB0aGlzIGluIG15IHdvcmtpbmcgY29weSwgYW5kIGl0IHdpbGwgbWFrZSBp dCBpbnRvIHRoZSANCiAgICBuZXh0IHJldmlzaW9uLg0KICAgIA0KICAgID4gVGhlcmUgaXMgb25l IG1vcmUgaXNzdWUgdGhhdCB3ZSBtaWdodCB3YW50IHRvIHRhY2tsZSBhcyBwYXJ0IG9mIHRoZSA2 ODQ0LWJpcyBlZmZvcnQ6IGNoYW5naW5nIHRoZSAiU0hPVUxEIiBmb3IgbWFraW5nIENBQSBxdWVy aWVzIGFnYWluc3QgYXV0aG9yaXRhdGl2ZSBuYW1lc2VydmVycyB0byBhICJNVVNUIiAoc2VjdGlv biA2LjM6IEZvciBleGFtcGxlLCBhbGwgcG9ydGlvbnMgb2YgdGhlIEROUyBsb29rdXAgcHJvY2Vz cyBTSE9VTEQgYmUgcGVyZm9ybWVkIGFnYWluc3QgdGhlIGF1dGhvcml0YXRpdmUgbmFtZSBzZXJ2 ZXIpLiBUaGlzIHdhcyBvcmlnaW5hbGx5IG1lbnRpb25lZCBpbiBodHRwczovL3NjYW5tYWlsLnRy dXN0d2F2ZS5jb20vP2M9NDA2MiZkPWl2SE8yeG1VQmZwcEZLaDFkYU8yS2VkeTlGc1Nuc1ZYS1BL b3VDVXE1USZzPTUmdT1odHRwcyUzYSUyZiUyZmJsb2clMmVjbG91ZGZsYXJlJTJlY29tJTJmY2Fh LW9mLXRoZS13aWxkJTJmIGJ1dCBJIGRvbid0IHRoaW5rIHRoaXMgaGFzIGJlZW4gYnJvdWdodCB1 cCBvbiB0aGlzIG1haWxpbmcgbGlzdCBiZWZvcmUgYW5kIHRob3VnaHQgd2Ugc2hvdWxkIGF0IGxl YXN0IGRpc2N1c3MgaXQuIE15IG9waW5pb24gaXMgdGhhdCBpdCBzaG91bGQgcmVtYWluIGEgIlNI T1VMRCIgaW4gdGhlIFJGQywgb3RoZXJ3aXNlIHRoZSBSRkMgaXMgZGljdGF0aW5nIHBvbGljeS4g VGhlIHByZWZlcmFibGUgcm91dGUgaXMgdG8gZGVmaW5lIHJlcXVpcmVkIGxvb2t1cCBwcm9wZXJ0 aWVzIGluIHBvbGljeSBleHBsaWNpdGx5IChlZywgdGhlIEJhc2VsaW5lIFJlcXVpcmVtZW50cyB3 b3VsZCBkaWN0YXRlIHRoYXQgYWxsIGxvb2t1cHMgTVVTVCBiZSBwZXJmb3JtZWQgYWdhaW5zdCBh biBhdXRob3JpdGF0aXZlIG5hbWVzZXJ2ZXIpLg0KICAgIFllYWgsIEkgYWdyZWUgd2Ugc2hvdWxk IGtlZXAgdGhpcyBhcyBhIFNIT1VMRC4gSSB0aGluayBkZWZpbmluZyB3aGF0IA0KICAgIGV4YWN0 bHkgaXQgbWVhbnMgY291bGQgZ2V0IG1lc3N5LiBGb3IgaW5zdGFuY2UsIENBcyBhcmUgbGlrZWx5 IHRvIHVzZSBhbiANCiAgICBpbnRlcm5hbCByZWN1cnNpdmUgcmVzb2x2ZXIsIHdoaWNoIGluIHR1 cm4gY29udGFjdHMgYSBzZXJpZXMgb2YgDQogICAgYXV0aG9yaXRhdGl2ZSByZXNvbHZlcnMuDQog ICAgDQoNCg== From nobody Thu Jul 19 05:39: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 3273F130DCC for ; Thu, 19 Jul 2018 05:39:17 -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 xMbuU8bBr2Qa for ; Thu, 19 Jul 2018 05:39:15 -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 2753C129619 for ; Thu, 19 Jul 2018 05:39:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EC860300A1D for ; Thu, 19 Jul 2018 08:39: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 1WDQJS5ERa74 for ; Thu, 19 Jul 2018 08:39:11 -0400 (EDT) Received: from [172.20.7.12] (unknown [207.96.246.27]) by mail.smeinc.net (Postfix) with ESMTPSA id 0E1C2300260; Thu, 19 Jul 2018 08:39:10 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Russ Housley In-Reply-To: <16C5A8C4-B65C-4676-8629-814555177C35@akamai.com> Date: Thu, 19 Jul 2018 08:39:11 -0400 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <7458FF33-4579-496B-BA14-61EC669191C2@vigilsec.com> References: <6527E23C-5BD0-454E-B7DF-3D46A8C812BF@vigilsec.com> <16C5A8C4-B65C-4676-8629-814555177C35@akamai.com> To: Rich Salz X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] Minutes and jabber scribe X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 19 Jul 2018 12:39:17 -0000 Thanks Rich. We still need one or two people to take notes for the = minutes. Russ > On Jul 17, 2018, at 3:24 PM, Salz, Rich wrote: >=20 > I'll do jabber >=20 > =EF=BB=BFOn 7/17/18, 3:23 PM, "Russ Housley" = wrote: >=20 > We need someone to take notes and and another person to be jabber = scribe for the LAMPS session Thursday afternoon. Please volunteer now = so that we do not need to spend valuable meeting time twisting arms. >=20 > Russ & Tim >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 >=20 From nobody Thu Jul 19 05:51: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 22C73130DD5 for ; Thu, 19 Jul 2018 05:51:45 -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 bbK4AaYVOWsy for ; Thu, 19 Jul 2018 05:51:42 -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 10B76129619 for ; Thu, 19 Jul 2018 05:51:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D1528300A0A for ; Thu, 19 Jul 2018 08:51:39 -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 9zSLVV30-fii for ; Thu, 19 Jul 2018 08:51:37 -0400 (EDT) Received: from [172.20.7.12] (unknown [207.96.246.27]) by mail.smeinc.net (Postfix) with ESMTPSA id 543B5300260; Thu, 19 Jul 2018 08:51:37 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_F82BA849-BF0B-4F29-A8FD-1A5DD433045F" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 19 Jul 2018 08:51:35 -0400 References: Cc: SPASM To: Eric Rescorla Message-Id: <717C4D29-AF97-4836-9F19-9E41E1646AF3@vigilsec.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [lamps] Fwd: [Technical Errata Reported] RFC8398 (5418) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 19 Jul 2018 12:51:45 -0000 --Apple-Mail=_F82BA849-BF0B-4F29-A8FD-1A5DD433045F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It looks like you should approve this errata. Do you need anything else = from the WG? Russ > From: Wei Chuang > Subject: Re: [lamps] [Technical Errata Reported] RFC8398 (5418) > Date: July 11, 2018 at 5:49:16 PM EDT > To: rfc-editor@rfc-editor.org > Cc: ekr@rtfm.com, Russ Housley , SPASM = , kaduk@mit.edu, Alexey Melnikov = , Dmitry Belyavsky , = tim.hollebeek@digicert.com >=20 > Hi all, >=20 > I agree with the errata report. Background is that I've already been = discussing with Dmitry the bug, and suggested he file the errata so we = can make the change. The bug is in the SmtpUTF8Mailbox OID = in the example = found in the Appendix. = I also agree with him that we can update the email address to be = consistent with the earlier example on page 6 in case the original is = confusing. >=20 > -Wei >=20 > On Wed, Jul 11, 2018 at 12:46 PM RFC Errata System = > wrote: > The following errata report has been submitted for RFC8398, > "Internationalized Email Addresses in X.509 Certificates". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5418 = >=20 > -------------------------------------- > Type: Technical > Reported by: Belyavskiy Dmitry > >=20 > Section: Appendix B >=20 > Original Text > ------------- > This non-normative example demonstrates using SmtpUTF8Mailbox as an > otherName in GeneralName to encode the email address > "u+8001u+5E2B@example.com ". >=20 > The hexadecimal DER encoding of the email address is: > A022060A 2B060105 05070012 0809A014 0C12E880 81E5B8AB 40657861 > 6D706C65 2E636F6D >=20 > The text decoding is: > 0 34: [0] { > 2 10: OBJECT IDENTIFIER '1 3 6 1 5 5 7 0 18 8 9' > 14 20: [0] { > 16 18: UTF8String '...@example.com ' > : } > : } >=20 > Figure 2 >=20 > The example was encoded on the OSS Nokalva ASN.1 Playground and the > above text decoding is an output of Peter Gutmann's "dumpasn1" > program. >=20 >=20 > Corrected Text > -------------- > This non-normative example demonstrates using SmtpUTF8Mailbox as an > otherName in GeneralName to encode the email address > "u+533Bu+751F@u+5927u+5B66.example.com ". >=20 > The hexadecimal DER encoding of the block is: > a0330608 2b060105 05070809 a0270c25 c3a5c28c c2bbc3a7 c294c29f=20 > 40c3a5c2 a4c2a7c3 a5c2adc2 a62e6578 616d706c 652e636f 6d >=20 >=20 > The text decoding is: > 2 51: [0] { > 4 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 8 9' > 14 39: [0] { > 16 37: UTF8String '..@...example.com ' > : } > : } >=20 > Figure 2 >=20 > The example was encoded on the OSS Nokalva ASN.1 Playground and the > above text decoding is an output of Peter Gutmann's "dumpasn1" > program. >=20 > Notes > ----- > The OID used in Appendix B does not match the OID for = id-on-SmtpUTF8Mailbox defined in "Appendix A. ASN.1 Module" and is not = mentioned anywhere in the RFC. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC8398 (draft-ietf-lamps-eai-addresses-18) > -------------------------------------- > Title : Internationalized Email Addresses in X.509 = Certificates > Publication Date : May 2018 > Author(s) : A. Melnikov, Ed., W. Chuang, Ed. > Category : PROPOSED STANDARD > Source : Limited Additional Mechanisms for PKIX and SMIME > Area : Security > Stream : IETF > Verifying Party : IESG > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --Apple-Mail=_F82BA849-BF0B-4F29-A8FD-1A5DD433045F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii It = looks like you should approve this errata.  Do you need anything = else from the WG?

Russ


Subject: = Re: [lamps] = [Technical Errata Reported] RFC8398 (5418)
Date: = July 11, 2018 at 5:49:16 PM = EDT
To: = rfc-editor@rfc-editor.org
Cc: ekr@rtfm.com, Russ Housley <housley@vigilsec.com>, SPASM <spasm@ietf.org>, kaduk@mit.edu, Alexey = Melnikov <alexey.melnikov@isode.com>, Dmitry Belyavsky <beldmit@gmail.com>, = tim.hollebeek@digicert.com

Hi all,

I agree = with the errata report.  Background is that I've already been = discussing with Dmitry the bug, and suggested he file the errata so we = can make the change.  The bug is in the SmtpUTF8Mailbox OID in the example found in the Appendix.  I also agree with = him that we can update the email address to be consistent with the = earlier example on page 6 in case the original is confusing.

-Wei

On = Wed, Jul 11, 2018 at 12:46 PM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata = report has been submitted for RFC8398,
"Internationalized Email Addresses in X.509 Certificates".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5418

--------------------------------------
Type: Technical
Reported by: Belyavskiy Dmitry <beldmit@gmail.com>

Section: Appendix B

Original Text
-------------
   This non-normative example demonstrates using = SmtpUTF8Mailbox as an
   otherName in GeneralName to encode the email address
   "u+8001u+5E2B@example.com".
=
      The hexadecimal DER encoding of the email address = is:
      A022060A 2B060105 05070012 0809A014 0C12E880 = 81E5B8AB 40657861
      6D706C65 2E636F6D

      The text decoding is:
        0  34: [0] {
        2  10:   OBJECT IDENTIFIER '1 = 3 6 1 5 5 7 0 18 8 9'
       14  20:   [0] {
       16  18:     UTF8String = '...@example.com'
             :    =  }
             :   }

                    =              Figure 2

   The example was encoded on the OSS Nokalva ASN.1 Playground = and the
   above text decoding is an output of Peter Gutmann's = "dumpasn1"
   program.


Corrected Text
--------------
   This non-normative example demonstrates using = SmtpUTF8Mailbox as an
   otherName in GeneralName to encode the email address
   "u+533Bu+751F@u+5927u+5B66.example.com".

   The hexadecimal DER encoding of the block is:
   a0330608 2b060105 05070809 a0270c25 c3a5c28c c2bbc3a7 = c294c29f
   40c3a5c2 a4c2a7c3 a5c2adc2 a62e6578 616d706c 652e636f 6d


   The text decoding is:
     2  51: [0] {
     4   8:   OBJECT IDENTIFIER '1 3 = 6 1 5 5 7 8 9'
    14  39:   [0] {
    16  37:     UTF8String '..@...example.com'
          :     }
          :   }

                    =              Figure 2

   The example was encoded on the OSS Nokalva ASN.1 Playground = and the
   above text decoding is an output of Peter Gutmann's = "dumpasn1"
   program.

Notes
-----
The OID used in Appendix B does not match the OID for = id-on-SmtpUTF8Mailbox defined in "Appendix A.  ASN.1 Module" and is = not mentioned anywhere in the RFC.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
= rejected. When a decision is reached, the verifying party 
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8398 (draft-ietf-lamps-eai-addresses-18)
--------------------------------------
Title               : = Internationalized Email Addresses in X.509 Certificates
Publication Date    : May 2018
Author(s)           : A. Melnikov, Ed., W. = Chuang, Ed.
Category            : PROPOSED STANDARD
Source              : Limited = Additional Mechanisms for PKIX and SMIME
Area                : = Security
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
Spasm = mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

= --Apple-Mail=_F82BA849-BF0B-4F29-A8FD-1A5DD433045F-- From nobody Thu Jul 19 06:52: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 32091130E50 for ; Thu, 19 Jul 2018 06:52:02 -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] 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 4drNsrsCcmT3 for ; Thu, 19 Jul 2018 06:51:58 -0700 (PDT) Received: from smtp-out-2.mxes.net (smtp-out-2.mxes.net [67.222.241.118]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB6D130E0D for ; Thu, 19 Jul 2018 06:51:58 -0700 (PDT) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D152C2758D; Thu, 19 Jul 2018 09:51:56 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Leonard In-Reply-To: Date: Thu, 19 Jul 2018 09:51:46 -0400 Cc: Jacob Hoffman-Andrews , SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <6736C993-99C8-465B-BD0A-DF4ABC197085@seantek.com> References: <0EA657BD-8E44-4173-8059-8A312998DAA4@trustwave.com> <171ce08e-3700-45e8-8208-08bb15077f72@eff.org> To: Corey Bonnell X-Mailer: Apple Mail (2.3445.6.18) X-Sent-To: Archived-At: Subject: Re: [lamps] New draft: rfc6844bis X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 19 Jul 2018 13:52:03 -0000 Looks like a good fix. Please confirm results with abnfgen . Sean > On Jul 18, 2018, at 12:04 PM, Corey Bonnell = wrote: >=20 > A bit ago, Ilari Liusvaara pointed out on the ACME WG list = (https://www.ietf.org/mail-archive/web/acme/current/msg02845.html) that = the grammar in 6844-bis has a minor issue in regard to multiple = whitespace character sequences, as the grammar produces ambiguous parses = in that case. I agree with his analysis and proposed fix to the = issuevalue production rule: >=20 > issuevalue =3D *WSP [domain *WSP] [";" *WSP [parameters *WSP]] >=20 > Thanks,=20 > Corey >=20 > =EF=BB=BFOn 7/17/18, 6:45 PM, "Jacob Hoffman-Andrews" = wrote: >=20 > On 07/10/2018 06:58 AM, Corey Bonnell wrote: >> It looks like the updated ABNF grammar for the issue property tag is = missing some line breaks, as several of the production rules are now on = the same line. > Thanks. I've fixed this in my working copy, and it will make it = into the=20 > next revision. >=20 >> There is one more issue that we might want to tackle as part of the = 6844-bis effort: changing the "SHOULD" for making CAA queries against = authoritative nameservers to a "MUST" (section 6.3: For example, all = portions of the DNS lookup process SHOULD be performed against the = authoritative name server). This was originally mentioned in = https://scanmail.trustwave.com/?c=3D4062&d=3DivHO2xmUBfppFKh1daO2Kedy9FsSn= sVXKPKouCUq5Q&s=3D5&u=3Dhttps%3a%2f%2fblog%2ecloudflare%2ecom%2fcaa-of-the= -wild%2f but I don't think this has been brought up on this mailing list = before and thought we should at least discuss it. My opinion is that it = should remain a "SHOULD" in the RFC, otherwise the RFC is dictating = policy. The preferable route is to define required lookup properties in = policy explicitly (eg, the Baseline Requirements would dictate that all = lookups MUST be performed against an authoritative nameserver). > Yeah, I agree we should keep this as a SHOULD. I think defining = what=20 > exactly it means could get messy. For instance, CAs are likely to = use an=20 > internal recursive resolver, which in turn contacts a series of=20 > authoritative resolvers. >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Jul 19 10:15:01 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 A0D91130F72 for ; Thu, 19 Jul 2018 10:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 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_NONE=-0.0001, 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 DlcwVYclbfj0 for ; Thu, 19 Jul 2018 10:14:51 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78A94130F81 for ; Thu, 19 Jul 2018 10:14:51 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id q9-v6so7679779ioj.8 for ; Thu, 19 Jul 2018 10:14:51 -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=sUTPlcGcuxEI9IN5qtMkCFU4TyXOotSBZWSSFxz8Cs0=; b=MLvfDOFwk7xTJKlg3XYJal6CvUpGS08xuVH9ViwX/WGNQC8KyDgxddUfz3GKtGXpjH 4PfS0xMuOLtPJ60zuf1wsJJ7FrZB5i3ODLDCcZn5AiIaNwlPTLJWhmhM6I5FvdLH7GxO UYuiCyAeYA9OAXvAKLyIKkvyP55q9AS55uQAyGH7RqyS3R3UOzNrhkKXlW9cKWLW5+EM t8Oq6eDBfAflmvzwBnjFZ/lEvjLxcWe8EuGCmBq4w/2kfZHThoMetebDo+zvEqHHzEVz zPM8n0AJ1JwrZGYv+c9JwZ7h/onXxnY9Is2pMNTHyUiW1nwsTzWqk9YihJ8f2kACJzu1 X+JQ== 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=sUTPlcGcuxEI9IN5qtMkCFU4TyXOotSBZWSSFxz8Cs0=; b=lYzDoofE+wV9MK9ms4SKCEXzX0up+Ikf/PBeEnVBFzHWBdbmm281acEkyK89VedsfU rSMuWs+ItSRcdYJktvVAASoXHUglZhe7d/oEkRxzh1myeeYtxdpYbEqeRLes8s19mifk ELpE6E05+RSLxBOGiRYluFOB8oSeH5xsOW5BT37HCkz14v0zWcFsKDAMvNRZ9gsHjfeB KJrjVbV0FPoC7w7kLl64V2wLIAjmUoMD8xUzi4EHdEv7d+ncE5Pl2zVliqFCAEbctPEd BSFYkIDDR/CrMetZjORWoGRYKGnorS8DmMIU0xnuSTjTeFgGQYqqq/CXE3HgktQMF8/N oCSA== X-Gm-Message-State: AOUpUlEtYLnxC2nV1ZkvMtZqiPm08faqvVf0rf3GEf5iZyXAjFRL9y6W +pOXaWjeqYkqRV9sg2hywJxKM96fGd9d4jAJhXH9CEuz0Ck= X-Google-Smtp-Source: AAOMgpdXC1WFWtGoMVK9vZpcXqRggTzIdGkk6dG/yQG/ZvtBeUXvWT9PbocQdJbhDQ01k5r6mL+XcHACeLI564R5Lxk= X-Received: by 2002:a6b:9c09:: with SMTP id f9-v6mr9329908ioe.179.1532020490197; Thu, 19 Jul 2018 10:14:50 -0700 (PDT) MIME-Version: 1.0 References: <717C4D29-AF97-4836-9F19-9E41E1646AF3@vigilsec.com> In-Reply-To: <717C4D29-AF97-4836-9F19-9E41E1646AF3@vigilsec.com> From: Wei Chuang Date: Thu, 19 Jul 2018 10:14:38 -0700 Message-ID: To: Russ Housley Cc: ekr@rtfm.com, SPASM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000026b48d05715d517e" Archived-At: Subject: Re: [lamps] Fwd: [Technical Errata Reported] RFC8398 (5418) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 19 Jul 2018 17:14:55 -0000 --00000000000026b48d05715d517e Content-Type: multipart/alternative; boundary="0000000000001bfa1805715d51e9" --0000000000001bfa1805715d51e9 Content-Type: text/plain; charset="UTF-8" Apologies as I'm new to the errata process. Do I get nominated to be a errata verifier? as there appears to be a login page before I can review which it sounds like the WG sets up. The documentation here says "The verifying party (or stream-specific party) is determined by the stream that produced the RFC: IETF, IAB, IRTF, or Independent Submission" which I assume is the WG. -Wei On Thu, Jul 19, 2018 at 5:51 AM Russ Housley wrote: > It looks like you should approve this errata. Do you need anything else > from the WG? > > Russ > > > *From: *Wei Chuang > *Subject: **Re: [lamps] [Technical Errata Reported] RFC8398 (5418)* > *Date: *July 11, 2018 at 5:49:16 PM EDT > *To: *rfc-editor@rfc-editor.org > *Cc: *ekr@rtfm.com, Russ Housley , SPASM < > spasm@ietf.org>, kaduk@mit.edu, Alexey Melnikov , > Dmitry Belyavsky , tim.hollebeek@digicert.com > > Hi all, > > I agree with the errata report. Background is that I've already been > discussing with Dmitry the bug, and suggested he file the errata so we can > make the change. The bug is in the SmtpUTF8Mailbox OID > > in the example found in > the Appendix. I also agree with him that we can update the email address > to be consistent with the earlier example on page 6 in case the original is > confusing. > > -Wei > > On Wed, Jul 11, 2018 at 12:46 PM RFC Errata System < > rfc-editor@rfc-editor.org> wrote: > >> The following errata report has been submitted for RFC8398, >> "Internationalized Email Addresses in X.509 Certificates". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5418 >> >> -------------------------------------- >> Type: Technical >> Reported by: Belyavskiy Dmitry >> >> Section: Appendix B >> >> Original Text >> ------------- >> This non-normative example demonstrates using SmtpUTF8Mailbox as an >> otherName in GeneralName to encode the email address >> "u+8001u+5E2B@example.com". >> >> The hexadecimal DER encoding of the email address is: >> A022060A 2B060105 05070012 0809A014 0C12E880 81E5B8AB 40657861 >> 6D706C65 2E636F6D >> >> The text decoding is: >> 0 34: [0] { >> 2 10: OBJECT IDENTIFIER '1 3 6 1 5 5 7 0 18 8 9' >> 14 20: [0] { >> 16 18: UTF8String '...@example.com' >> : } >> : } >> >> Figure 2 >> >> The example was encoded on the OSS Nokalva ASN.1 Playground and the >> above text decoding is an output of Peter Gutmann's "dumpasn1" >> program. >> >> >> Corrected Text >> -------------- >> This non-normative example demonstrates using SmtpUTF8Mailbox as an >> otherName in GeneralName to encode the email address >> "u+533Bu+751F@u+5927u+5B66.example.com ". >> >> The hexadecimal DER encoding of the block is: >> a0330608 2b060105 05070809 a0270c25 c3a5c28c c2bbc3a7 c294c29f >> 40c3a5c2 a4c2a7c3 a5c2adc2 a62e6578 616d706c 652e636f 6d >> >> >> The text decoding is: >> 2 51: [0] { >> 4 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 8 9' >> 14 39: [0] { >> 16 37: UTF8String '..@...example.com' >> : } >> : } >> >> Figure 2 >> >> The example was encoded on the OSS Nokalva ASN.1 Playground and the >> above text decoding is an output of Peter Gutmann's "dumpasn1" >> program. >> >> Notes >> ----- >> The OID used in Appendix B does not match the OID for >> id-on-SmtpUTF8Mailbox defined in "Appendix A. ASN.1 Module" and is not >> mentioned anywhere in the RFC. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC8398 (draft-ietf-lamps-eai-addresses-18) >> -------------------------------------- >> Title : Internationalized Email Addresses in X.509 >> Certificates >> Publication Date : May 2018 >> Author(s) : A. Melnikov, Ed., W. Chuang, Ed. >> Category : PROPOSED STANDARD >> Source : Limited Additional Mechanisms for PKIX and SMIME >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> > _______________________________________________ > 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 > --0000000000001bfa1805715d51e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies as I'm new to the errata process.=C2=A0 Do I= get nominated to be a errata verifier? as there appears to be a login page= before I can review which it sounds like the WG sets up.

The documentation h= ere says "The verifying party (or stream-specific party) is determ= ined by the stream that produced the RFC: IETF, IAB, IRTF, or Independent S= ubmission" which I assume is the WG.

-We= i

On Thu, = Jul 19, 2018 at 5:51 AM Russ Housley <housley@vigilsec.com> wrote:
It = looks like you should approve this errata.=C2=A0 Do you need anything else = from the WG?

Russ


From: weihaw=3D40google.com@dmarc.ietf.org>
Subject: Re: [lamps] [Technical Errata Reported] RFC8398 (5418)
Date: July 11,= 2018 at 5:49:16 PM EDT
Cc: ekr@rtfm.com, Russ Housley <housley@vigilsec.com>= , SPASM <spasm@ietf.= org>, kaduk@mit.= edu, Alexey Melnikov <alexey.melnikov@isode.com>, Dmitry Belyavsky <beldmit@gmail.com&= gt;, tim.ho= llebeek@digicert.com

Hi all,<= br>

I agree with the errata report.=C2=A0 Background is = that I've already been discussing with Dmitry the bug, and suggested he= file the errata so we can make the change.=C2=A0 The bug is in the=C2=A0SmtpUTF8= Mailbox=C2=A0OID i= n the example found in the Appendix.=C2=A0 I also agree with him that= we can update the email address to be consistent with the earlier example = on page 6 in case the original is confusing.

-Wei<= /div>

On Wed, Jul 11, = 2018 at 12:46 PM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata report has been su= bmitted for RFC8398,
"Internationalized Email Addresses in X.509 Certificates".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5418

--------------------------------------
Type: Technical
Reported by: Belyavskiy Dmitry <beldmit@gmail.com>

Section: Appendix B

Original Text
-------------
=C2=A0 =C2=A0This non-normative example demonstrates using SmtpUTF8Mailbox = as an
=C2=A0 =C2=A0otherName in GeneralName to encode the email address
=C2=A0 =C2=A0"u+8001u+5E2B@example.com".

=C2=A0 =C2=A0 =C2=A0 The hexadecimal DER encoding of the email address is:<= br> =C2=A0 =C2=A0 =C2=A0 A022060A 2B060105 05070012 0809A014 0C12E880 81E5B8AB = 40657861
=C2=A0 =C2=A0 =C2=A0 6D706C65 2E636F6D

=C2=A0 =C2=A0 =C2=A0 The text decoding is:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 0=C2=A0 34: [0] {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 2=C2=A0 10:=C2=A0 =C2=A0OBJECT IDENTIFIER '= 1 3 6 1 5 5 7 0 18 8 9'
=C2=A0 =C2=A0 =C2=A0 =C2=A014=C2=A0 20:=C2=A0 =C2=A0[0] {
=C2=A0 =C2=A0 =C2=A0 =C2=A016=C2=A0 18:=C2=A0 =C2=A0 =C2=A0UTF8String '= ...@ex= ample.com'
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 2

=C2=A0 =C2=A0The example was encoded on the OSS Nokalva ASN.1 Playground an= d the
=C2=A0 =C2=A0above text decoding is an output of Peter Gutmann's "= dumpasn1"
=C2=A0 =C2=A0program.


Corrected Text
--------------
=C2=A0 =C2=A0This non-normative example demonstrates using SmtpUTF8Mailbox = as an
=C2=A0 =C2=A0otherName in GeneralName to encode the email address
=C2=A0 =C2=A0"u+533Bu+751F@u+5927u+5B66.example.com".

=C2=A0 =C2=A0The hexadecimal DER encoding of the block is:
=C2=A0 =C2=A0a0330608 2b060105 05070809 a0270c25 c3a5c28c c2bbc3a7 c294c29f=
=C2=A0 =C2=A040c3a5c2 a4c2a7c3 a5c2adc2 a62e6578 616d706c 652e636f 6d


=C2=A0 =C2=A0The text decoding is:
=C2=A0 =C2=A0 =C2=A02=C2=A0 51: [0] {
=C2=A0 =C2=A0 =C2=A04=C2=A0 =C2=A08:=C2=A0 =C2=A0OBJECT IDENTIFIER '1 3= 6 1 5 5 7 8 9'
=C2=A0 =C2=A0 14=C2=A0 39:=C2=A0 =C2=A0[0] {
=C2=A0 =C2=A0 16=C2=A0 37:=C2=A0 =C2=A0 =C2=A0UTF8String '..@...example.com'
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 2

=C2=A0 =C2=A0The example was encoded on the OSS Nokalva ASN.1 Playground an= d the
=C2=A0 =C2=A0above text decoding is an output of Peter Gutmann's "= dumpasn1"
=C2=A0 =C2=A0program.

Notes
-----
The OID used in Appendix B does not match the OID for id-on-SmtpUTF8Mailbox= defined in "Appendix A.=C2=A0 ASN.1 Module" and is not mentioned= anywhere in the RFC.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8398 (draft-ietf-lamps-eai-addresses-18)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: International= ized Email Addresses in X.509 Certificates
Publication Date=C2=A0 =C2=A0 : May 2018
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A. Melnikov, Ed., W. Ch= uang, Ed.
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Limited Additional= Mechanisms for PKIX and SMIME
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
_______________________________________________
Spasm mailing list
Spasm@ietf.org
http= s://www.ietf.org/mailman/listinfo/spasm
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--0000000000001bfa1805715d51e9-- --00000000000026b48d05715d517e 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMTZjj07BnE8UdCkPpMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDYxODE4NDI1NFoXDTE4MTIx NTE4NDI1NFowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCT9auzAMJFxJw2nck+6fp27hHYam/2StGY5mIbF6g8b8f6hl5v K6eScLyqimYdQSWUXaG9hGRmqZ4oLCWv5/ybrg55CgNdUea9xe663vqlQ3smSA/AYHToLLZ6YtYC /Xpc9blxrsnJtZ4QY83HOFyiLbysmkwrhlvGaPtN3W/2meTsJsAfSrIbUCBijcwq7GQV20bhj4MG MEJm6a6y+92fzmmG7OHrF1fLofi07yW+3ZXVsK/6PpEbCxd1Ni+eMh96x6Iua5KP+CE8S+vlHyoZ JmiyDntVMpTGuC/P4baHfUouHcqVqw1mevEa3MaIxBWaG5/eSdyqCB4o+4Nbz+NbAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFCkFHZFfStM1ze4EOO/TF2JQ/qnEMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB0JGN5bYsugmrkUIFI ZIeAPT35qf5pCKnOUa5KRNZwcoZknd0KZSb7Z7WAk01drzzRPakei5/BQ2ZErir0q9TrD9slWj7v Bj8OSHZdY4mr/tnm9dTGPnBeAjWiFsK+zfHp6yH7Acn2a7jMrmB5YkRj73AwL6I1o6bES3C4GhHD IwuzcFPOrSArE5sQU2jDsw38+8/dtIGHCbYugIRHRkc4j2uRzppgyJXhV7xRVPQlbO4aIV1+sa6K nMvin8RgAdFONRVt6dPwqjPB+oie8/qV2ZE/azkud1lbdSQn7Q8PjWoBXLXAPsiz/6qzp6M0ZErk Bt1327YAeKyS71oiwO7JMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMTZjj07Bn E8UdCkPpMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCB8ts6BzN+StOmJGIJdPVMC 5hpVPpH5SV1JaQ+Fx0pefDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA3MTkxNzE0NTBaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAB8osC35FiQXLsiFUQMqDc/1OUCsiX1HbsaX8xy1J KklLPnhsIcQXZQNbLLVbfRcsRpBrl5ofIEmyyP+LtiaiBynru7PHHpLbL8sbDl6yYK6czcUjOLAN OxJR6pu6BFVzdZM1oSBqqZg2Tq/0reXcGzlLBVbJ1qYjBiKsRKCic+y6NwUo5yGpFoSZ1s5o2BjK px70qt9zOYEHt1CTKpAOunV3gzulx4NQVBt1tunA+HMy1IQhvvoPjm58T+b+IcIJRWGwKeM77jjW DlSCzNkh+M0TEijLHtadx6WDGYzB9rZOJrxWqsyfnndn1iiwAfgjfeplhRPenkt1x9fczy51nA== --00000000000026b48d05715d517e-- From nobody Thu Jul 19 10:38: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 5DCB3130ECA for ; Thu, 19 Jul 2018 10:38:04 -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 ptx7sKJN9zx3 for ; Thu, 19 Jul 2018 10:37:59 -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 6C130130FC1 for ; Thu, 19 Jul 2018 10:37:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0B74C300A81 for ; Thu, 19 Jul 2018 13:37: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 x-rVkKH3UCa4 for ; Thu, 19 Jul 2018 13:37:54 -0400 (EDT) Received: from dhcp-8ced.meeting.ietf.org (dhcp-8ced.meeting.ietf.org [31.133.140.237]) by mail.smeinc.net (Postfix) with ESMTPSA id F3E463005A8; Thu, 19 Jul 2018 13:37:53 -0400 (EDT) From: Russ Housley Message-Id: <79595F35-4F84-49EF-AF9D-6BD4F7FBE711@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1ACC0297-00B4-482C-A2EE-176E744F1D47" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 19 Jul 2018 13:37:54 -0400 In-Reply-To: Cc: Eric Rescorla , SPASM To: Wei Chuang References: <717C4D29-AF97-4836-9F19-9E41E1646AF3@vigilsec.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] Fwd: [Technical Errata Reported] RFC8398 (5418) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 19 Jul 2018 17:38:05 -0000 --Apple-Mail=_1ACC0297-00B4-482C-A2EE-176E744F1D47 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Wei: No, but the WG is providing input to the errata reviewer, who is the = Area Director. Russ > On Jul 19, 2018, at 1:14 PM, Wei Chuang wrote: >=20 > Apologies as I'm new to the errata process. Do I get nominated to be = a errata verifier? as there appears to be a login page before I can = review which it sounds like the WG sets up. >=20 > The documentation here = says "The verifying party (or stream-specific party) is determined by = the stream that produced the RFC: IETF, IAB, IRTF, or Independent = Submission" which I assume is the WG. >=20 > -Wei >=20 > On Thu, Jul 19, 2018 at 5:51 AM Russ Housley > wrote: > It looks like you should approve this errata. Do you need anything = else from the WG? >=20 > Russ >=20 >=20 >> From: Wei Chuang > >> Subject: Re: [lamps] [Technical Errata Reported] RFC8398 (5418) >> Date: July 11, 2018 at 5:49:16 PM EDT >> To: rfc-editor@rfc-editor.org >> Cc: ekr@rtfm.com , Russ Housley = >, SPASM = >, kaduk@mit.edu = , Alexey Melnikov >, Dmitry Belyavsky >, tim.hollebeek@digicert.com = >>=20 >> Hi all, >>=20 >> I agree with the errata report. Background is that I've already been = discussing with Dmitry the bug, and suggested he file the errata so we = can make the change. The bug is in the SmtpUTF8Mailbox OID = in the example = found in the Appendix. = I also agree with him that we can update the email address to be = consistent with the earlier example on page 6 in case the original is = confusing. >>=20 >> -Wei >>=20 >> On Wed, Jul 11, 2018 at 12:46 PM RFC Errata System = > wrote: >> The following errata report has been submitted for RFC8398, >> "Internationalized Email Addresses in X.509 Certificates". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5418 = >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Belyavskiy Dmitry > >>=20 >> Section: Appendix B >>=20 >> Original Text >> ------------- >> This non-normative example demonstrates using SmtpUTF8Mailbox as = an >> otherName in GeneralName to encode the email address >> "u+8001u+5E2B@example.com ". >>=20 >> The hexadecimal DER encoding of the email address is: >> A022060A 2B060105 05070012 0809A014 0C12E880 81E5B8AB 40657861 >> 6D706C65 2E636F6D >>=20 >> The text decoding is: >> 0 34: [0] { >> 2 10: OBJECT IDENTIFIER '1 3 6 1 5 5 7 0 18 8 9' >> 14 20: [0] { >> 16 18: UTF8String '...@example.com ' >> : } >> : } >>=20 >> Figure 2 >>=20 >> The example was encoded on the OSS Nokalva ASN.1 Playground and = the >> above text decoding is an output of Peter Gutmann's "dumpasn1" >> program. >>=20 >>=20 >> Corrected Text >> -------------- >> This non-normative example demonstrates using SmtpUTF8Mailbox as = an >> otherName in GeneralName to encode the email address >> "u+533Bu+751F@u+5927u+5B66.example.com = ". >>=20 >> The hexadecimal DER encoding of the block is: >> a0330608 2b060105 05070809 a0270c25 c3a5c28c c2bbc3a7 c294c29f=20 >> 40c3a5c2 a4c2a7c3 a5c2adc2 a62e6578 616d706c 652e636f 6d >>=20 >>=20 >> The text decoding is: >> 2 51: [0] { >> 4 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 8 9' >> 14 39: [0] { >> 16 37: UTF8String '..@...example.com ' >> : } >> : } >>=20 >> Figure 2 >>=20 >> The example was encoded on the OSS Nokalva ASN.1 Playground and = the >> above text decoding is an output of Peter Gutmann's "dumpasn1" >> program. >>=20 >> Notes >> ----- >> The OID used in Appendix B does not match the OID for = id-on-SmtpUTF8Mailbox defined in "Appendix A. ASN.1 Module" and is not = mentioned anywhere in the RFC. >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party =20 >> can log in to change the status and edit the report, if necessary.=20 >>=20 >> -------------------------------------- >> RFC8398 (draft-ietf-lamps-eai-addresses-18) >> -------------------------------------- >> Title : Internationalized Email Addresses in X.509 = Certificates >> Publication Date : May 2018 >> Author(s) : A. Melnikov, Ed., W. Chuang, Ed. >> Category : PROPOSED STANDARD >> Source : Limited Additional Mechanisms for PKIX and = SMIME >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> 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=_1ACC0297-00B4-482C-A2EE-176E744F1D47 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Wei:

No, = but the WG is providing input to the errata reviewer, who is the Area = Director.

Russ


On Jul = 19, 2018, at 1:14 PM, Wei Chuang <weihaw@google.com> wrote:

Apologies as I'm new to the errata process.  Do I get = nominated to be a errata verifier? as there appears to be a login page = before I can review which it sounds like the WG sets up.

The documentation here = says "The verifying party (or stream-specific party) is determined by = the stream that produced the RFC: IETF, IAB, IRTF, or Independent = Submission" which I assume is the WG.

-Wei

On = Thu, Jul 19, 2018 at 5:51 AM Russ Housley <housley@vigilsec.com> wrote:
It = looks like you should approve this errata.  Do you need anything = else from the WG?

Russ


From: Wei Chuang <weihaw=3D40google.com@dmarc.ietf.org>
Subject: Re: [lamps] = [Technical Errata Reported] RFC8398 (5418)
Date: July 11, 2018 at 5:49:16 PM EDT
To: rfc-editor@rfc-editor.org
Cc: ekr@rtfm.com, Russ Housley <housley@vigilsec.com>, SPASM <spasm@ietf.org>, kaduk@mit.edu, Alexey Melnikov <alexey.melnikov@isode.com>, Dmitry Belyavsky <beldmit@gmail.com>, tim.hollebeek@digicert.com

Hi all,

I agree = with the errata report.  Background is that I've already been = discussing with Dmitry the bug, and suggested he file the errata so we = can make the change.  The bug is in the SmtpUTF8Mailbox OID in the example found in the Appendix.  I also agree with = him that we can update the email address to be consistent with the = earlier example on page 6 in case the original is confusing.

-Wei

On = Wed, Jul 11, 2018 at 12:46 PM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata = report has been submitted for RFC8398,
"Internationalized Email Addresses in X.509 Certificates".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5418

--------------------------------------
Type: Technical
Reported by: Belyavskiy Dmitry <beldmit@gmail.com>

Section: Appendix B

Original Text
-------------
   This non-normative example demonstrates using = SmtpUTF8Mailbox as an
   otherName in GeneralName to encode the email address
   "u+8001u+5E2B@example.com".
=
      The hexadecimal DER encoding of the email address = is:
      A022060A 2B060105 05070012 0809A014 0C12E880 = 81E5B8AB 40657861
      6D706C65 2E636F6D

      The text decoding is:
        0  34: [0] {
        2  10:   OBJECT IDENTIFIER '1 = 3 6 1 5 5 7 0 18 8 9'
       14  20:   [0] {
       16  18:     UTF8String = '...@example.com'
             :    =  }
             :   }

                    =              Figure 2

   The example was encoded on the OSS Nokalva ASN.1 Playground = and the
   above text decoding is an output of Peter Gutmann's = "dumpasn1"
   program.


Corrected Text
--------------
   This non-normative example demonstrates using = SmtpUTF8Mailbox as an
   otherName in GeneralName to encode the email address
   "u+533Bu+751F@u+5927u+5B66.example.com".

   The hexadecimal DER encoding of the block is:
   a0330608 2b060105 05070809 a0270c25 c3a5c28c c2bbc3a7 = c294c29f
   40c3a5c2 a4c2a7c3 a5c2adc2 a62e6578 616d706c 652e636f 6d


   The text decoding is:
     2  51: [0] {
     4   8:   OBJECT IDENTIFIER '1 3 = 6 1 5 5 7 8 9'
    14  39:   [0] {
    16  37:     UTF8String '..@...example.com'
          :     }
          :   }

                    =              Figure 2

   The example was encoded on the OSS Nokalva ASN.1 Playground = and the
   above text decoding is an output of Peter Gutmann's = "dumpasn1"
   program.

Notes
-----
The OID used in Appendix B does not match the OID for = id-on-SmtpUTF8Mailbox defined in "Appendix A.  ASN.1 Module" and is = not mentioned anywhere in the RFC.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
= rejected. When a decision is reached, the verifying party 
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8398 (draft-ietf-lamps-eai-addresses-18)
--------------------------------------
Title               : = Internationalized Email Addresses in X.509 Certificates
Publication Date    : May 2018
Author(s)           : A. Melnikov, Ed., W. = Chuang, Ed.
Category            : PROPOSED STANDARD
Source              : Limited = Additional Mechanisms for PKIX and SMIME
Area                : = Security
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
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=_1ACC0297-00B4-482C-A2EE-176E744F1D47-- From nobody Thu Jul 19 12:18: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 D630A130E04 for ; Thu, 19 Jul 2018 12:18:03 -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] 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 VYVmrGYRFFK8 for ; Thu, 19 Jul 2018 12:18:01 -0700 (PDT) Received: from smtp-out-2.mxes.net (smtp-out-2.mxes.net [67.222.241.118]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA8B130DBE for ; Thu, 19 Jul 2018 12:18:01 -0700 (PDT) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CC26327517; Thu, 19 Jul 2018 15:17:59 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Leonard In-Reply-To: Date: Thu, 19 Jul 2018 15:17:48 -0400 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <98E04A7B-DFA0-4765-B153-C707F09A31B3@seantek.com> References: To: Tim Hollebeek X-Mailer: Apple Mail (2.3445.6.18) X-Sent-To: Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-cms-mts-hash-sig X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 19 Jul 2018 19:18:04 -0000 Substantively: good start and therefore I support adoption of this = draft. Typo: s/sine/since Sean > On Jul 14, 2018, at 12:03 PM, Tim Hollebeek = wrote: >=20 > The recently approved LAMPS WG Charter adds this work item: >=20 > =20 >=20 > 5. Specify the use of hash-based signatures with the Cryptographic = Message Syntax (CMS). Hash-based signature use small private and public = keys, and they have 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; however, sine hash-based = signature algorithms are secure even if a large-scale quantum computer = is invented. The low computational cost for signature verification = makes hash-based signatures attractive in the Internet of Things = environments, and the quantum resistance makes them attractive for the = distribution of software updates. >=20 > =20 >=20 > It has been suggested that the WG adopt draft-housley-cms-mts-hash-sig = as the starting point for this work. Since Russ Housley is the author = of this draft, Tim Hollebeek will judge consensus for this discussion. = Please voice your support or concerns on the list. >=20 > =20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Jul 19 12:43:25 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 A306F130DC9 for ; Thu, 19 Jul 2018 12:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fu-kxnBEO5yB for ; Thu, 19 Jul 2018 12:43:21 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80633130DC6 for ; Thu, 19 Jul 2018 12:43:21 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id v26-v6so8061040iog.5 for ; Thu, 19 Jul 2018 12:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=maivdBIvHVCpcz6+a56a3X2bNlq6OTpqFcu0ZA6Frwc=; b=IyfX+uVhiab+XonlVAj1qvayIJjdDklidN57k7N8V+owQiBTJ4/H4eDKhCn4NYwWGC 8xqkDi3MKSwRyvb8XeLcnfhCUhiz/D0544Un3nsLn70SMTihkWkcCGsVAXrRazm9ZSbK vL9Ct+LDQZxLzcavz7uGwewyv/Lgr+Z8FfK5E= 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=maivdBIvHVCpcz6+a56a3X2bNlq6OTpqFcu0ZA6Frwc=; b=RJv/u3a6HUFouOBKYwgq85uRlKSuVJ45oOLvPaTaV4WTZpG7q6+RflZpXyhMoDtCn/ jJcEPzYQPiZszTq34bf+fy//NN0fhytaboWGb4KvEP9V9borcmu8EcAzBZaRGIsuD+U1 2FtjVyIDc/QTu8URIk05OuaRL0gMQBnGBqrK+zDo9tu6fL5duBi/Iez/Cf3uIN0pw96p se8x7vLjjN8ZxUaR4kT0b7fAMkTbvfy9Yl6wXVg2FFsn8eyxO+SgXhFVlVHMwl6rWDvY sMlhxZwbWvkm+Gkwpv6FIhKH9+09eV3R1deBsmH+h1L0FXR4U517neNABmv6mEdDuyHB 7N0A== X-Gm-Message-State: AOUpUlE+jv5gQf4oJI/KpHWSlXi5FhO6RVjaCNFudzti/OinvLOhMJfm 6dwZm+oNuyn10Uv63owbnExm/0oNh5NWrw== X-Google-Smtp-Source: AA+uWPx90cGBoGu955/NlKtuOl3sCiCkfuY/IF1x1ypEUUN5zdrKJbWth8JM2Qb+IOyABWBdP632vg== X-Received: by 2002:a6b:1d4b:: with SMTP id d72-v6mr8823215iod.190.1532029400821; Thu, 19 Jul 2018 12:43:20 -0700 (PDT) Received: from ?IPv6:2001:67c:370:1998:6d97:3e16:3ace:6170? ([2001:67c:370:1998:6d97:3e16:3ace:6170]) by smtp.gmail.com with ESMTPSA id e19-v6sm1534846ioc.46.2018.07.19.12.43.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jul 2018 12:43:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sean Turner In-Reply-To: Date: Thu, 19 Jul 2018 15:43:18 -0400 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <6B6ABEA5-34CE-4464-BE66-9A25124F9266@sn3rd.com> References: To: Tim Hollebeek X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-cms-mts-hash-sig X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 19 Jul 2018 19:43:24 -0000 > On Jul 14, 2018, at 12:03, Tim Hollebeek = wrote: >=20 > The recently approved LAMPS WG Charter adds this work item: > =20 > 5. Specify the use of hash-based signatures with the Cryptographic = Message Syntax (CMS). Hash-based signature use small private and public = keys, and they have 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; however, sine hash-based = signature algorithms are secure even if a large-scale quantum computer = is invented. The low computational cost for signature verification = makes hash-based signatures attractive in the Internet of Things = environments, and the quantum resistance makes them attractive for the = distribution of software updates. > =20 > It has been suggested that the WG adopt draft-housley-cms-mts-hash-sig = as the starting point for this work. Since Russ Housley is the author = of this draft, Tim Hollebeek will judge consensus for this discussion. = Please voice your support or concerns on the list. >=20 Support adoption will review. spt From nobody Thu Jul 19 12:44:32 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 1E81513104E for ; Thu, 19 Jul 2018 12:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NX7IMUDNbPT7 for ; Thu, 19 Jul 2018 12:44:21 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 4A737131071 for ; Thu, 19 Jul 2018 12:44:21 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id p17-v6so11553040itc.2 for ; Thu, 19 Jul 2018 12:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ejA8ao0nAbcrUKpbJMocjKJrhIurUZq1Vg1F0+3FstA=; b=L6g58wOjpZrSuIYPYAeCXxwBf+CVnyNF8OU3o1Kq0U7TSw65GSVTJcO42iziPJAEDP oyYB4aN6X+5fMGgdnoHmgHRNFhPsnnCnMX+a2NeWQ6twvatF2XRTfn/duvcgsTrExUJi titNlh06UgBitZmK0rq1l0+qZyUpOzdVkwhXk= 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=ejA8ao0nAbcrUKpbJMocjKJrhIurUZq1Vg1F0+3FstA=; b=PcUalK3yP8aHnRF4ejX70ogrP4jDnN7gQQuh5aEAVx9S9AwXKgwuobA0w5UFlCD2hh CmDIxUez+CjVhqPwy1AO54YHuDAgQBqdcEGtKff4SMfxEOHISwk44OKvNhHwmW55enBZ LKIWj+63ZI5oYEM4yH8UoVg/AnCpu/JxqhHOUipzEl1AnLZrI1V0yuaJA5DNYJPWP/o0 p9yggmVUpCse1EYQlKHaVRYq6uGaIshFz/6Dl9ap9niFclp7z4Up5xKgw4QpX7l32BJ0 8PvGU0AeU4X9T2p0LOSqY2+kPKKR5t67ObDdrB6Pdfd85cVwOjnrcALLiHaUOCUgWTCY hvaA== X-Gm-Message-State: AOUpUlGEi0Xd+V6SZPlIL9hPTd8QzFQaqsmzimLcveL5b+xJImxYyJuy GiEw2bg/f9Oyav5tDjfqiJkihuhaOzyPGg== X-Google-Smtp-Source: AAOMgpf2BzBWyT2a4RlyriFU+NqS96vmaGbqDe1nRpMd+cfp3dSCU2SJ+9llRt7DHAItRRLujVCcjg== X-Received: by 2002:a24:307:: with SMTP id e7-v6mr6436817ite.27.1532029460631; Thu, 19 Jul 2018 12:44:20 -0700 (PDT) Received: from ?IPv6:2001:67c:370:1998:6d97:3e16:3ace:6170? ([2001:67c:370:1998:6d97:3e16:3ace:6170]) by smtp.gmail.com with ESMTPSA id e19-v6sm1534846ioc.46.2018.07.19.12.44.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jul 2018 12:44:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sean Turner In-Reply-To: Date: Thu, 19 Jul 2018 15:44:19 -0400 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tim Hollebeek X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-cms-mix-with-psk X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 19 Jul 2018 19:44:31 -0000 > On Jul 14, 2018, at 12:02, Tim Hollebeek = wrote: >=20 > =20 > The recently approved LAMPS WG Charter adds this work item: > =20 > 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. The invention of a = large-scale quantum computer poses a serious challenge for the key = management algorithms that are widely deployed today, especially the key = transport and key agreement algorithms used today with the CMS to = protect S/MIME messages. > =20 > It has been suggested that the WG adopt draft-housley-cms-mix-with-psk = as the starting point for this work. Since Russ Housley is the author = of this draft, Tim Hollebeek will judge consensus for this discussion. = Please voice your support or concerns on the list. I support adoption and will review. spt From nobody Thu Jul 19 12:46:06 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 1BB8F130DC9 for ; Thu, 19 Jul 2018 12:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UShHckhwn_DT for ; Thu, 19 Jul 2018 12:46:03 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 D0AC9130DC6 for ; Thu, 19 Jul 2018 12:46:02 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id 16-v6so11498219itl.5 for ; Thu, 19 Jul 2018 12:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/12ZB3YxAfCjOprj9bM3BkbM/TZ/vcFFxA/20Qq4o2M=; b=H/JIuv4VCLOFuBvqg16CgQeXvbQgM4cnF+sGOD+UPhHmxvhxjsOQpDMyjImWQXKs5l lIfkO09Ha4kBk1hUp6dfDDyMuJBQz05CUz67wsKhFRgWoFw8H5zpU5cSPBNtS7xcMoPx HcnLocmgt2x1JYjVBtytp4e3ZZXNUx3NwO5Kw= 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=/12ZB3YxAfCjOprj9bM3BkbM/TZ/vcFFxA/20Qq4o2M=; b=dD4bqujNRWAXO+Cqzi8e7Uvm8UXBXWoK0QEwvOHgJ5cisSkicTxlwZ0HWVhL8QpKOx /wqPtTcRszATFwxxVxho4nHNUlZWVLiPz5VKcmCk8qWZVviVTbF7DaZUA1+CvctbTvy/ KXz8zgMvUCeqmCn/I0ZHhMoVMV0aZES14tsZNSfb7ksZ13CFGWt6cKCMU1YfC5PRcnJT rZWVm2ogqUlve91qHgPZfm7UdnMyYjMTrz5qTAUdDTTeyEThc66+2hIQegJ1pEw54Vum ho92LOlq9NzU8BDVe+VkfdX6svl317B/15CIO0oB2NcksrRdNMC39A0H4/iE52rLcPyX EP3A== X-Gm-Message-State: AOUpUlGrd0+HoAtmg34prwaLGhb4VDIpHTj8lehYt48nn4Nbna4s6IVP p+Gc7Mq8kLGJbavh/zx0hyse1A== X-Google-Smtp-Source: AAOMgpfojJTLpBMdMp6YwnztSwFJ5wJxTX/5kxiQM/QI1DhlPaqlz/Ai6/ocLgfMhSyp2i2jgqOMLw== X-Received: by 2002:a24:1c0a:: with SMTP id c10-v6mr6830876itc.101.1532029562196; Thu, 19 Jul 2018 12:46:02 -0700 (PDT) Received: from ?IPv6:2001:67c:370:1998:6d97:3e16:3ace:6170? ([2001:67c:370:1998:6d97:3e16:3ace:6170]) by smtp.gmail.com with ESMTPSA id z2-v6sm156442iti.3.2018.07.19.12.46.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jul 2018 12:46:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sean Turner In-Reply-To: Date: Thu, 19 Jul 2018 15:46:00 -0400 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tim Hollebeek X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-hash-of-root-key-cert-extn X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 19 Jul 2018 19:46:05 -0000 > On Jul 14, 2018, at 12:18, Salz, Rich = wrote: >=20 > >It has been suggested that the WG adopt = draft-housley-hash-of-root-key-cert-extn as the starting point for this = work. > =20 > SET did this for their root a long time ago. Maybe re-use the OID? > =20 > At any rate, I support this. Yep me too: support.. spt From nobody Thu Jul 19 13:09: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 721C8130E2A; Thu, 19 Jul 2018 13:09:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-lamps-rfc5751-bis@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153203096045.10528.16820438729526230915.idtracker@ietfa.amsl.com> Date: Thu, 19 Jul 2018 13:09:20 -0700 Archived-At: Subject: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-rfc5751-bis-11: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 19 Jul 2018 20:09:21 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lamps-rfc5751-bis-11: 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing the discuss point; original ballot comments retained below. I suspect it's too late for changing this to be a good idea, but using "authenticated enveloped" and in the same breath talking about how it does not provide proof of origination ("wait, isn't that authentication?), but it does provide "a level of authentication", is kind of confusing for the reader. Could "integrity protection" be used to distinguish the AEAD property from proof-of-origin authentication? Similarly, it might be helpful to use the term "AEAD" before the security considerations section. Should the Abstract/Introduction mention that AEAD encryption provides non-malleability? Section-by-Section comments follow. Section 1 nit: Does FAX need to be all-caps? Section 1.1 In order to create S/MIME messages, an S/MIME agent MUST follow the specifications in this document, as well as the specifications listed in the Cryptographic Message Syntax document [CMS], [RFC3370], [RFC4056], [RFC3560], and [RFC5754]. nit: is that "[CMS] documents" plural? I have been observing growing unease with Postel's Principle over time; it's less clear that blindly repeating it is the best position to take. Section 1.2 BER does not appear to be used in the body text? Section 1.5 I recognize this is historical text, but to modern readers, there is not a single "the AES symmetric encryption algorithm" -- there are CBC modes and GCM modes, and v4.0 distinguishes between them. Should this text get clarified about the difference? Section 2.5.2 The OIDs that correspond to algorithms SHOULD use the same OID as the actual algorithm, except in the case where the algorithm usage is ambiguous from the OID. For instance, in an earlier specification, rsaEncryption was ambiguous because it could refer to either a signature algorithm or a key encipherment algorithm. In the event that an OID is ambiguous, it needs to be arbitrated by the maintainer of the registered SMIMECapabilities list as to which type of algorithm will use the OID, and a new OID MUST be allocated under the smimeCapabilities OID to satisfy the other use of the OID. (nit?) "the other use" implies there will only ever be one other (two total), which is perhaps needlessly limiting. Section 2.7.2 With "Algorithms such as RC2"; "Algorithms such as TripleDES", I'm not sure what to make of "such as" in these statements -- what are the attributes that would qualify for sufficient similarity to match the "such as", other than equality? Section 3.1 In order to protect outer, non-content-related message header fields (for instance, the "Subject", "To", "From", and "Cc" fields), the sending client MAY wrap a full MIME message in a message/rfc822 wrapper in order to apply S/MIME security services to these header fields. It is up to the receiving client to decide how to present this "inner" header along with the unprotected "outer" header. It is RECOMMENDED that a distinction be made between the location of the header. nit: I'm not sure this last sentence is grammatical. Do we want "between the locations", or "a visible distinction be made for the different possible locations of the header", or something else? Section 3.1.2 In the case where S/MIME implementations can determine that all intended recipients are capable of handling inner (all but the outermost) binary MIME objects SHOULD use binary encoding as opposed to a 7-bit-safe transfer encoding for the inner entities. nit: I think that some words got dropped in here; the sentence doesn't really parse. I guess there's a missing "implementations" in "implementations SHOULD use"? Section 3.3 but not signed messages does not provide for data integrity. The Enveloped-Only structure does not support authenticated symmetric algorithms, use the .Authenticated Enveloped structure for these algorithms. [...] nit: Is the '.' in ".Authenticated" correct? (Also, that sentence looks like a comma splice.) Section 3.5.3.2 I agree with Adam that there should be some notation in the table or adjacent to it that some algorithms are present only for historical compatibility and should be considered deprecated/insecure/risky/whatever. Section 6 Some cryptographic algorithms such as RC2 offer little actual security over sending plaintext. Other algorithms such as TripleDES, provide security but are no longer considered to be state of the art. S/MIME requires the use of current state of the art algorithms such as AES and provides the ability to announce starter cryptographic capabilities to parties with whom you communicate. [...] I can't figure out what "starter" means, here. Modification of the ciphertext in EnvelopedData can go undetected if authentication is not also used, which is the case when sending EnvelopedData without wrapping it in SignedData or enclosing SignedData within it. This is one of the reasons for moving from EnvelopedData to AuthEnvelopedData as the authenticated encryption algorithms provide the authentication without needing the SignedData layer. nit: I think a comma before "as the" would help the last sentence. When talking about compression oracles, do we want to explicitly say that a common way to do so is to compress attacker-controlled data in the same corpus as the attacker's target data? mail clients deal with HTML and multipart/mixed messages. Clients MUST require that a text/html content type is a complete HTML document (per [RFC1866]). Clients SHOULD treat each of the different pieces of the multipart/mixed construct as being of different origins. Clients MUST treat each encrypted or signed piece of a MIME message as being of different origins both from unprotected content and from each other. Do we need to cite RFC 6454 for the specific "web origin" concept (as opposed to just the normal English usage of the word)? Appendix B This appendix contains a number of references to documents that have been obsoleted or replaced, this is intentional as frequently the updated documents do not have the same information in them. nit: comma splice Appendix B.2 - Hash functions used to validate signatures on historic messages may longer be considered to be secure. (See below.) While there are not currently any known practical pre-image or second pre- image attacks against MD5 or SHA-1, the fact they are no longer considered to be collision resistant the security levels of the signatures are generally considered suspect. [...] nit: there seems to be (at least) a missing verb in this last sentence. [...] If a message is known to be historic, that it it has been in the possession of the client for some time, then it might still be considered to be secure. nit: maybe "and it has been" From nobody Thu Jul 19 13:09: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 AB75A130E2A for ; Thu, 19 Jul 2018 13:09: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, 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 eZM2VVUELoQ5 for ; Thu, 19 Jul 2018 13:09:20 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A82130DC9 for ; Thu, 19 Jul 2018 13:09:20 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id h20-v6so7559922wmb.4 for ; Thu, 19 Jul 2018 13:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=5WqHCc2rzmiQaqixOc5T1e/aWKN9qgNH9nfLHPgZIjI=; b=G8gPkA6ZtzhcYEDkUv7Rx5aW+VF84LVtSBT667ppfMQKBVsGrUZgfq/oEHpmrRY8v2 xQe7qIoYq/K8bJO1SXMJg8DmATA6oLcZHL4LDTMH9uRcb1R4qBae27MeagiVKnTA6qD2 rj5pg/IHI9FmQRnXReuJ+gub7YOgJd8DQDDEtm767AwLbXGCMCWi4+MdN9oXWSK/M0o7 t43CY+TFfHESArAfZl5iD43HfwilbvJvgIQBWKrgOhRVqgft/1q10RQrW5JXVSycaeFN gOIz5+hUFlqMIODhC2iw1al9x39UyP7k8RTEOTxVUAIW/aGWthKCoAtFA8nGk/u8FFdI Fo9Q== 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=5WqHCc2rzmiQaqixOc5T1e/aWKN9qgNH9nfLHPgZIjI=; b=ne9emUSS9oOm34zZf7w9Di5NlLU8Gq+7HqHQdYVNzVUDtdXPdrP3kzrx1l8FcsmN33 0FqXKf4OneI6tB0zuWUPOid9sIvVIFLe7pRaCn+Zlmp4VU4OF90YqK/iZzsEudBk2/rD ddCMYyaqJomxVS0H6AumC15jOSivBXlzu9JTKth9RSKRkegb9WQPceupXVMbIxshHn2K nShBHfUmlIlfeDYK0MJpldkLOhFI6cRKAuD5E8FAgt40G6boOuytS7DfzBHt5GTqbI1Z ce0U1wFrtweiugHEeLhNVM1rJA04iETAj24m/tgoU1WBpLzBlNA+Hg3tuHhFo4zmwfRc wEqQ== X-Gm-Message-State: AOUpUlExbRAdF9Z26ngoXe5ltlRMkyAwFMcFU7fR4JnudCSD11smhEFi DN6HzgfpHoQ51u4fbz63CHnTktph5QRgeq6p/4YgVQPn X-Google-Smtp-Source: AAOMgpdAEtncPSGvXD5ylTo1hWrMcBnL90P+iGjTjMz5DiiYj36Hw0FemW60IMkGfUluMaGvh+XAZ2CbECZMA+RS0NM= X-Received: by 2002:a1c:6d9a:: with SMTP id b26-v6mr4774188wmi.74.1532030958562; Thu, 19 Jul 2018 13:09:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:a414:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 13:09:18 -0700 (PDT) In-Reply-To: References: From: Tim Wicinski Date: Thu, 19 Jul 2018 16:09:18 -0400 Message-ID: To: SPASM Content-Type: multipart/alternative; boundary="00000000000011f83405715fc132" Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-hash-of-root-key-cert-extn X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 19 Jul 2018 20:09:24 -0000 --00000000000011f83405715fc132 Content-Type: text/plain; charset="UTF-8" I've read andI support this one for adoption. . Tim On Thu, Jul 19, 2018 at 3:46 PM, Sean Turner wrote: > > > > On Jul 14, 2018, at 12:18, Salz, Rich > wrote: > > > > >It has been suggested that the WG adopt draft-housley-hash-of-root-key-cert-extn > as the starting point for this work. > > > > SET did this for their root a long time ago. Maybe re-use the OID? > > > > At any rate, I support this. > > Yep me too: support.. > > spt > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --00000000000011f83405715fc132 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


I've read =C2=A0andI support t= his one for adoption. .=C2=A0

Tim

On Thu, Jul 19, 2018 a= t 3:46 PM, Sean Turner <sean@sn3rd.com> wrote:


> On Jul 14, 2018, at 12:18, Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org> wrote:<= br> >
> >It has been suggested that the WG adopt draft-housley-hash-of-root= -key-cert-extn as the starting point for this work.
>=C2=A0
> SET did this for their root a long time ago.=C2=A0 Maybe re-use the OI= D?
>=C2=A0
> At any rate, I support this.

Yep me too: support..

spt

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

--00000000000011f83405715fc132-- From nobody Thu Jul 19 15:13: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 B278A130E13 for ; Thu, 19 Jul 2018 15:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 0JS4mb5HhG06 for ; Thu, 19 Jul 2018 15:13:10 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7330130DEB for ; Thu, 19 Jul 2018 15:13:09 -0700 (PDT) Received: from fifthhorseman.net (dhcp-97d4.meeting.ietf.org [31.133.151.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 076B5F99A for ; Thu, 19 Jul 2018 18:13:09 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 9E2B320338; Thu, 19 Jul 2018 18:00:33 -0400 (EDT) From: Daniel Kahn Gillmor To: spasm@ietf.org Date: Thu, 19 Jul 2018 18:00:33 -0400 Message-ID: <87wotqx4vy.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Archived-At: Subject: [lamps] cryptographic envelope/cryptographic payload in e-mail X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 19 Jul 2018 22:13:16 -0000 --=-=-= Content-Type: text/plain Russ asked me to send a pointer to my description of the distinction between a "cryptographic envelope" and "cryptographic payload". You can find it online here: https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html It also includes discussion of user agent UI/UX concerns, which are not typical IETF fare. And i'm attaching the source markdown so that it's all on IETF infrastructure for discussion as well, but feel free to respond only to the parts that you think are relevant to the IETF. --dkg --=-=-= Content-Type: text/markdown; charset=utf-8 Content-Disposition: inline; filename=crypto-email.md Content-Transfer-Encoding: 8bit Title: E-mail Cryptography Date: 2018-05-11 12:04 Authors: Daniel Kahn Gillmor Tags: e-mail, crypto Summary: Analysis of usability and mechanics of cryptographic protection in e-mail I've been working on cryptographic e-mail software for many years now, and i want to set down some of my observations of what i think some of the challenges are. I'm involved in [Autocrypt](https://autocrypt.org), which is making great strides in sensible key management (see the last section below, which is short not because i think it's easy, but because i think Autocrypt has covered this area quite well), but there are additional nuances to the mechanics and user experience of e-mail encryption that i need to get off my chest. Feedback welcome! [TOC] Cryptography and E-mail Messages ================================ Cryptographic protection (i.e., digital signatures, encryption) of e-mail messages has a complex history. There are several different ways that various parts of an e-mail message can be protected (or not), and those mechanisms can be combined in a huge number of ways. In contrast to the technical complexity, users of e-mail tend to expect a fairly straightforward experience. They also have little to no expectation of explicit cryptographic protections for their messages, whether for authenticity, for confidentiality, or for integrity. If we want to change this -- if we want users to be able to rely on cryptographic protections for some e-mail messages in their existing e-mail accounts -- we need to be able to explain those protections without getting in the user's way. Why expose cryptographic protections to the user at all? -------------------------------------------------------- For a new messaging service, the service itself can simply enumerate the set of properties that all messages exchanged through the service must have, design the system to bundle those properties with message deliverability, and then users don't need to see any of the details for any given message. The presence of the message in that messaging service is enough to communicate its security properties to the extent that the users care about those properties. However, e-mail is a widely deployed, heterogenous, legacy system, and even the most sophisticated users will always interact with some messages that lack cryptographic protections. So if we think those protections are meaningful, and we want users to be able to respond to a protected message at all differently from how they respond to an unprotected message (or if they want to know whether the message they're sending will be protected, so they can decide how much to reveal in it), we're faced with the challenge of explaining those protections to users at some level. Simplicity ---------- The best level to display cryptographic protects for a typical e-mail user is on a per-message basis. Wider than per-message (e.g., describing protections on a per-correspondent or a per-thread basis) is likely to stumble on mixed statuses, particularly when other users switch e-mail clients that don't provide the same cryptographic protections, or when people are added to or removed from a thread. Narrower than per-message (e.g., describing protections on a per-MIME-part basis, or even within a MIME part) is too confusing: most users do not understand the structure of an e-mail message at a technical level, and are unlikely to be able to (or want to) spend any time learning about it. And a message with some cryptographic protection and other tamperable user-facing parts is a tempting vector for attack. So at most, an e-mail should have one cryptographic state that covers the entire message. At most, the user probably wants to know: * Is the content of this message known only to me and the sender (and the other people in Cc)? (Confidentiality) * Did this message come from the person I think it came from, as they wrote it? (Integrity and Authenticity) Any more detail than this is potentially confusing or distracting. Combinations ------------ Is it possible to combine the two aspects described above into something even simpler? That would be nice, because it would allow us to categorize a message as either "protected" or "not protected". But there are four possible combinations: * unsigned cleartext messages: these are clearly "not protected" * signed encrypted messages: these are clearly "protected" (though see further sections below for more troubling caveats) * signed cleartext messages: these are useful in cases where confidentiality is irrelevant -- posts to a publicly-archived mailing list, for example, or announcement e-mails about a new version of some piece of software. It's hard to see how we can get away with ignoring this category. * unsigned encrypted messages: There are people who send encrypted messages who don't want to sign those messages, for a number of reasons (e.g., concern over the reuse/misuse of their signing key, and wanting to be able to send anonymous messages). Whether you think those reasons are valid or not, some signed messages cannot be validated. For example: * the signature was made improperly, * the signature was made with an unknown key, * the signature was made using an algorithm the message recipient doesn't know how to interpret * the signature was made with a key that the recipient believes is broken/bad We have to handle receipt of signed+encrypted messages with any of these signature failures, so we should probably deal with unsigned encrypted messages in the same way. My conclusion is that we need to be able to represent these states separately to the user (or at least to the MUA, so it can plan sensible actions), even though i would prefer a simpler representation. Note that some other message encryption schemes (such as those based on shared symmetric keying material, where message signatures are not used for authenticity) may not actually need these distinctions, and can therefore get away with the simpler "protected/not protected" message state. I am unaware of any such scheme being used for e-mail today. Partial protections ------------------ Sadly, the current encrypted e-mail mechanisms are likely to make even these proposed two indicators blurry if we try to represent them in detail. To avoid adding to user confusion, we need to draw some bright lines. * For integrity and authenticity, either the entire message is signed and integrity-checked, or it isn't. We must not report messages as being signed when only a part of the message is signed, or when the signature comes from someone not in the From: field. We should probably also not present "broken signature" status any differently that we present unsigned mail. See [discussion on the enigmail mailing list](https://admin.hostpoint.ch/pipermail/enigmail-users_enigmail.net/2017-November/004683.html) about some of these tradeoffs. * For confidentiality, the user likely cares that the entire message was confidential. But there are some circumstances (e.g., when replying to an e-mail, and deciding whether to encrypt or not) when they likely care if *any part* of the message was confidential (e.g. if an encrypted part is placed next to a cleartext part). It's interesting (and frustrating!) to note that these are scoped slightly differently -- that we might care about partial confidentiality but not about partial integrity and authenticity. Note that while we might care about partial confidentiality, actually representing *which parts* of a message were confidential represents a signficant UI challenge in most MUAs. To the extent that a MUA decides it wants to display details of a partially-protected message, i recommend that MUA strip/remove *all* non-protected parts of the message, and just show the user the (remaining) protected parts. In the event that a message has partial protections like this, the MUA may need to offer the user a choice of seeing the entire partially-protected message, or the stripped down message that has complete protections. To the extent that we expect to see partially-protected messages in the real world, further UI/UX exploration would be welcome. It would be great to imagine a world where those messages simply don't exist though :) Cryptographic Mechanism ======================= There are three major categories of cryptographic protection for e-mail in use today: Inline PGP, PGP/MIME, and S/MIME. Inline PGP ---------- I've argued elsewhere (and it remains true) that [Inline PGP signatures are terrible](https://debian-administration.org/users/dkg/weblog/108). Inline PGP encryption is also terrible, but in different ways: * it doesn't protect the structure of the message (e.g., the number and size of attachments is visible) * it has no way of protecting confidential message headers (see the Protected Headers section below) * it is very difficult to safely represent to the user what has been encrypted and what has not, particularly if the message body extends beyond the encrypted block. No MUA should ever emit messages using inline PGP, either for signatures or for encryption. And no MUA should ever display an inline-PGP-signed block as though it was signed. Don't even bother to validate such a signature. However, some e-mails will arrive using inline PGP encryption, and responsible MUAs probably need to figure out what to show to the user in that case, because the user wants to know what's there. :/ PGP/MIME and S/MIME ------------------- PGP/MIME and S/MIME are roughly equivalent to one another, with the largest difference being their certificate format. PGP/MIME messages are signed/encrypted with certificates that follow the OpenPGP specification, while S/MIME messages rely on certificates that follow the X.509 specification. The cryptographic protections of both PGP/MIME and S/MIME work at the MIME layer, providing particular forms of cryptographic protection around a subtree of other MIME parts. Both standards have very similar existing flaws that must be remedied or worked around in order to have sensible user experience for encrypted mail. This document has no preference of one message format over the other, but acknowledges that it's likely that both will continue to exist for quite some time. To the extent possible, a sensible MUA that wants to provide the largest coverage will be able to support both message formats and both certificate formats, hopefully with the same fixes to the underlying problems. Cryptographic Envelope ---------------------- Given that the plausible standards (PGP/MIME and S/MIME) both work at the MIME layer, it's worth thinking about the MIME structure of a cryptographically-protected e-mail messages. I introduce here two terms related to an e-mail message: the "Cryptographic Envelope" and the "Cryptographic Payload". Consider the MIME structure of a simple cleartext PGP/MIME signed message: 0A └┬╴multipart/signed 0B ├─╴text/plain 0C └─╴application/pgp-signature Consider also the simplest PGP/MIME encrypted message: 1A └┬╴multipart/encrypted 1B ├─╴application/pgp-encrypted 1C └─╴application/octet-stream 1D ╤ <> 1E └─╴text/plain Or, an S/MIME encrypted message: 2A └─╴application/pkcs7-mime; smime-type=enveloped-data 2B ╤ <> 2C └─╴text/plain Note that the PGP/MIME decryption step (denoted "1D" above) may also include a cryptographic signature that can be verified, as a part of that decryption. This is not the case with S/MIME, where the signing layer is always separated from the encryption layer. Also note that any of these layers of protection may be nested, like so: 3A └┬╴multipart/encrypted 3B ├─╴application/pgp-encrypted 3C └─╴application/octet-stream 3D ╤ <> 3E └┬╴multipart/signed 3F ├─╴text/plain 3G └─╴application/pgp-signature For an e-mail message that has some set of these layers, we define the "Cryptographic Envelope" as the layers of cryptographic protection that start at the root of the message and extend until the first non-cryptographic MIME part is encountered. Cryptographic Payload --------------------- We can call the first non-cryptographic MIME part we encounter (via depth-first search) the "Cryptographic Payload". In the examples above, the Cryptographic Payload parts are labeled 0B, 1E, 2C, and 3F. Note that the Cryptographic Payload itself could be a multipart MIME object, like 4E below: 4A └┬╴multipart/encrypted 4B ├─╴application/pgp-encrypted 4C └─╴application/octet-stream 4D ╤ <> 4E └┬╴multipart/alternative 4F ├─╴text/plain 4G └─╴text/html In this case, the full subtree rooted at 4E is the "Cryptographic Payload". The cryptographic properties of the message should be derived from the layers in the Cryptographic Envelope, and nothing else, in particular: * the cryptographic signature associated with the message, and * whether the message is "fully" encrypted or not. Note that if some subpart of the message is protected, but the cryptographic protections don't start at the root of the MIME structure, there is *no* message-wide cryptographic envelope, and therefore there either is no Cryptographic Payload, or (equivalently) the whole message (5A here) is the Cryptographic Payload, but with a null Cryptographic Envelope: 5A └┬╴multipart/mixed 5B ├┬╴multipart/signed 5C │├─╴text/plain 5D │└─╴application/pgp-signature 5E └─╴text/plain Note also that if there are any nested encrypted parts, they do not count toward the Cryptographic Envelope, but may mean that the message is "partially encrypted", albeit with a null Cryptographic Envelope: 6A └┬╴multipart/mixed 6B ├┬╴multipart/encrypted 6C │├─╴application/pgp-encrypted 6D │└─╴application/octet-stream 6E │ ╤ <> 6F │ └─╴text/plain 6G └─╴text/plain Layering within the Envelope ---------------------------- The order and number of the layers in the Cryptographic Envelope might make a difference in how the message's cryptographic properties should be considered. ### signed+encrypted vs encrypted+signed One difference is whether the signature is made over the encrypted data, or whether the encryption is done over the signature. Encryption around a signature means that the signature was hidden from an adversary. And a signature around the encryption indicates that sender may not know the actual contents of what was signed. The common expectation is that the signature will be inside the encryption. This means that the signer likely had access to the cleartext, and it is likely that the existence of the signature is hidden from an adversary, both of which are sensible properties to want. ### Multiple layers of signatures or encryption Some specifications define [triple-layering](https://tools.ietf.org/html/rfc2634#section-1.1): signatures around encryption around signatures. It's not clear that this is in wide use, or how any particular MUA should present such a message to the user. In the event that there are multiple layers of protection of a given kind in the Cryptographic Envelope, the message should be marked based on the properties of the inner-most layer of encryption, and the inner-most layer of signing. The main reason for this is simplicity -- it is unclear how to indicate arbitrary (and potentially-interleaved) layers of signatures and encryption. (FIXME: what should be done if the inner-most layer of signing can't be validated for some reason, but one of the outer layers of signing *does* validate? ugh MIME is too complex…) Signed messages should indicate the intended recipient ------------------------------------------------------ Ideally, all signed messages would indicate their intended recipient as a way of defending against some forms of replay attack. For example, Alice signs a signed message to Bob that says "please perform task X"; Bob reformats and forwards the message to Charlie as though it was directly from Alice. Charlie might now believes that Alice is asking him to do task X, instead of Bob. Of course, this concern also includes encrypted messages that are also signed. However, there is no clear standard for how to include this information in either an encrypted message or a signed message. An e-mail specific mechanism is to ensure that the To: and Cc: headers are signed appropriately (see the "Protected Headers") below. See also Vincent Breitmoser's [proposal of Intended Recipient Fingerprint](https://mailarchive.ietf.org/arch/msg/openpgp/urog4K_2FG6_mcvoqQmjO6pZvKY) for OpenPGP as a possible OpenPGP-specific implementation. However: what should the MUA do if a message is encrypted but no intended recipients are listed? Or what if a signature clearly indicates the intended recipients, but does not include the current reader? Should the MUA render the message differently somehow? Protected Headers ----------------- Sadly, e-mail cryptographic protections have traditionally only covered the body of the e-mail, and not the headers. Most users do not (and should not have to) understand the difference. There are two not-quite-standards for protecting the headers: * [message wrapping](https://tools.ietf.org/html/draft-melnikov-smime-header-signing), which puts an entire e-mail message (`message/rfc822` MIME part) "inside" the cryptographic protections. This is also discussed in [RFC 5751 §3.1](https://tools.ietf.org/html/rfc5751#section-3.1). I don't know of any MUAs that implement this. * [memory hole](https://github.com/autocrypt/memoryhole), which puts headers on the top-level MIME part directly. This is implemented in Enigmail and K-9 mail. These two different mechanisms are roughly equivalent, with slight differences in how they behave for clients who can handle cryptographic mail but have not implemented them. If a MUA is capable of interpreting one form successfully, it probably is also capable of interpreting the other. Note that in particular, the cryptographic headers for a given message ought to be derived directly from the headers present (in one of the above two ways) in the root element of the Cryptographic Payload MIME subtree itself. If headers are stored anywhere else (e.g. in one of the leaf nodes of a complex Payload), they should not propagate to the outside of the message. If the headers the user sees are not protected, that lack of protection may need to be clearly explained and visible to the user. This is unfortunate because it is potentially extremely complex for the UI. The types of cryptographic protections can differ per header. For example, it's relatively straightforward to pack all of the headers inside the Cryptographic Payload. For a signed message, this would mean that all headers are signed. This is the recommended approach when generating an encrypted message. In this case, the "outside" headers simply match the protected headers. And in the case that the outsider headers differ, they can simply be replaced with their protected versions when displayed to the user. This defeats the replay attack described above. But for an encrypted message, some of those protected headers will be stripped from the outside of the message, and others will be placed in the outer header in cleartext for the sake of deliverability. In particular, From: and To: and Date: are placed in the clear on the outside of the message. So, consider a MUA that receives an encrypted, signed message, with all headers present in the Cryptographic Payload (so all headers are signed), but From: and To: and Date: in the clear on the outside. Assume that the external Subject: reads simply "Encrypted Message", but the internal (protected) Subject: is actually "Thursday's Meeting". When displaying this message, how should the MUA distinguish between the Subject: and the From: and To: and Date: headers? All headers are signed, but only Subject: has been hidden. Should the MUA assume that the user understands that e-mail metadata like this leaks to the MTA? This is unfortuately true today, but not something we want in the long term. ### Message-ID and threading headers Messages that are part of an e-mail thread should ensure that Message-Id: and References: and In-Reply-To: are signed, because those markers provide contextual considerations for the signed content. (e.g., a signed message saying "I like this plan!" means something different depending on which plan is under discussion). That said, given the state of the e-mail system, it's not clear what a MUA should do if it receives a cryptographically-signed e-mail message where these threading headers are *not* signed. That is the default today, and we do not want to incur warning fatigue for the user. Furthermore, unlike Date: and Subject: and From: and To: and Cc:, the threading headers are not usually shown directly to the user, but instead affect the location and display of messages. Perhaps there is room here for some indicator at the thread level, that all messages in a given thread are contextually well-bound? Ugh, more UI complexity. ### Protecting Headers during e-mail generation When generating a cryptographically-protected e-mail (either signed or encrypted or both), the sending MUA should copy all of the headers it knows about into the Cryptographic Payload using one of the two techniques referenced above. For signed-only messages, that is all that needs doing. The challenging question is for encrypted messages: what headers on the outside of the message (outside the Cryptographic Envelope) can be to be stripped (removed completely) or stubbed (replaced with a generic or randomized value)? Subject: should obviously be stubbed -- for most users, the subject is directly associated with the body of the message (it is not thought of as metadata), and the Subject is not needed for deliverability. Since some MTAs might treat a message without a Subject: poorly, and arbitrary Subject lines are a nuisance, it is recommended to use the exact string below for all external Subjects: Subject: Encrypted Message However, stripping or stubbing other headers is more complex. The date header can likely be stripped from the outside of an encrypted message, or can have it its temporal resolution made much more coarse. However, this doesn't protect much information from the MTAs that touch the message, since they are likely to see the message when it is in transit. It may protect the message from some metadata analysis as it sits on disk, though. The To: and Cc: headers could be stripped entirely in some cases, though that may make the e-mail more prone to being flagged as spam. However, some e-mail messages sent to Bcc groups are still deliverable, with a header of To: undisclosed-recipients:; Note that the Cryptographic Envelope itself may leak metadata about the recipient (or recipients), so stripping this information from the external header may not be useful unless the Cryptographic Envelope is also stripped of metadata appropriately. The From: header could also be stripped or stubbed. It's not clear whether such a message would be deliverable, particularly given DKIM and DMARC rules for incoming domains. Note that the MTA will still see the SMTP MAIL FROM: verb before the message body is sent, and will use the address there to route bounces or DSNs. However, once the message is delivered, a stripped From: header is an improvement in the metadata available on-disk. Perhaps this is something that a friendly/cooperative MTA could do for the user? Even worse is the Message-Id: header and the associated In-Reply-To: and References: headers. Some MUAs (like [notmuch](https://notmuchmail.org)) rely heavily on the Message-Id:. A message with a stubbed-out Message-Id would effectively change its Message-Id: when it is decrypted. This may not be a straightforward or safe process for MUAs that are Message-ID-centric. That said, a randomized external Message-ID: header could help to avoid leaking the fact that the same message was sent to multiple people, so long as the message encryption to each person was also made distinct. Stripped In-Reply-To: and References: headers are also a clear metadata win -- the MTA can no longer tell which messages are associated with each other. However, this means that an incoming message cannot be associated with a relevant thread without decrypting it, something that some MUAs may not be in a position to do. Recommendation for encrypted message generation in 2018: copy all headers during message generation; stub out only the Subject for now. Bold MUAs may choose to experiment with stripping or stubbing other fields beyond Subject:, possibly in response to some sort of signal from the recipient that they believe that stripping or stubbing some headers is acceptable. Where should such a signal live? Perhaps a notation in the recipient's certificate would be useful. Key management ============== Key management bedevils every cryptographic scheme, e-mail or otherwise. The simplest solution for users is to automate key management as much as possible, making reasonable decisions for them. The [Autocrypt project](https://autocrypt.org/) outlines a sensible approach here, so i'll leave most of this section short and hope that it's covered by Autocrypt. While fully-automated key management is likely to be susceptible either to MITM attacks or trusted third parties (depending on the design), as a community we need to experiment with ways to provide straightforward (possibly gamified?) user experience that enables and encourages people to do key verification in a fun and simple way. This should probably be done without ever mentioning the word "key", if possible. Serious UI/UX work is needed. I'm hoping future versions of Autocrypt will cover that territory. But however key management is done, the result for the e-mail user experience is that that the MUA will have some sense of the "validity" of a key being used for any particular correspondent. If it is expressed at all, it should be done as simply as possible by default. In particular, MUAs should avoid confusing the user with distinct (nearly orthogonal) notions of "trust" and "validity" while reading messages, and should not necessarily associate the validity of a correspondent's key with the validity of a message cryptographically associated with that correspondent's key. Identity not the same thing as message integrity, and trustworthiness is not the same thing as identity either. Key changes over time --------------------- Key management is hard enough in the moment. With a store-and-forward system like e-mail, evaluating the validity of a signed message a year after it was received is tough. Your concept of the correspondent's correct key may have changed, for example. I think our understanding of what to do in this context is not currently clear. --=-=-=-- From nobody Mon Jul 23 12:46:32 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 DD044130F0A; Mon, 23 Jul 2018 12:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3] 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 FH5QrItoOSJT; Mon, 23 Jul 2018 12:46:27 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754E3130EE2; Mon, 23 Jul 2018 12:46:27 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 46C0D58C4AF; Mon, 23 Jul 2018 21:46:23 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 33F6E4402CB; Mon, 23 Jul 2018 21:46:23 +0200 (CEST) Date: Mon, 23 Jul 2018 21:46:23 +0200 From: Toerless Eckert To: Sean Turner , spasm@ietf.org Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org Message-ID: <20180723194623.7niwhsz4tnigwern@faui48f.informatik.uni-erlangen.de> References: <20180719212936.mroidiansyiurjra@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [lamps] Renewing (short lived) certs with EST (RFC7030) [was: Re: Sean: Permissibility of expired cert renewal] X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 23 Jul 2018 19:46:30 -0000 Thanks, Sean Let me add the LAMPS working group mailing list so we have more eyes on this. [Bcc anima WG mailing list so WG members interested in this disus can subscribe to LAMPS WG mailing list (spasm@ietf.org) ] Inline replies/Q's to your analysis at the end of this mail. To repeat and expand the goal of this discussion from what i was saying that the LAMPS mike in IETF102: - In ANIMA draft-ietf-anima-autonomic-control-plane (ACP), we use EST (RFC7030) to renew certificates. We would like to make installations with short-lived certificates work reliable, but devices may be disconnected longer than the short-lived time, so renewal may only happen after the cert is expired. - In the ANIMA WG, we seem to not be clear on the rules for renewing expired certs. RFC7030 section 3.3.2 sounds as if it mandatory for the EST server to validate the client certificate according to RFC5280, so we where concluding that an expired client certificate might not be something that the client could use if he wanted to comply to all IETF PKIX regulations. [ technically it would of course be fine to us the expired client certificate, and it might be necessary to use it because for renewals, the certificate to be renewed must be carried in the TLS authentication (if i understand it correctly, it would not be re-signaled inside the EST connection because the EST server wants to have prof of posession of the cert by the client, and thats done by TLS and does not need to be duplicate). ] - Yaron reminded me that in draft-ietf-acme-star certificates renewed certificates are not handled as an entity that requires authentication of the recipient but instead something that can be pre-created and cached in various places to overcome problems with nomadic connectivity. This to me looks like quite different from the approach by EST. - My thinking is somewhat in the middle between what i think EST says and what draft-ietf-acme-star says: - In EST, you do want identification with the pre-existing (expired) certificate. - The proof of posession of the expired certificate can help the registrar to determine aliveness of the client and reset any policy that could exist to determine whether the client is dead (after a long enough period of time) and stop reneweing certificates. - The proof of posession is also necessary IMHO when rekeying is required. - Which brings us back to Seans analysis of existing PKIX texts: (inline) On Mon, Jul 23, 2018 at 08:08:10AM -0400, Sean Turner wrote: > Toreless, > > I do not believe there is any prohibition against the use of expired or even revoked certificates for renew/rekey in the PKIX suite of RFCs. That wold be great. > The path validation algorithm in 5280 does consider whether the certificate is revoked/expired, but does hard fail on that status. But that would contradict your above statement, would it not ? With RFC7030 3.3.2 requiring RFC5280, it would have to fail for expired certificates. No ? > There???s nothing in the management protocols 2986 (PKCS#10), 5272 (CMC), and 4210 (CMP) about it either. Ok, so we can ignore those docs ;-) > But, the real reason it might be allowed is based on the CP (Certificate Policy) and that follows 3647; this RFC does have sections on "Identification and authentication for re-key after revocation???; I say ???might??? here because it is a policy decision (some CPs I???ve written allow it some do not). Ok, so RFC3647 does seem to not describe the case of a purely expired certificate, but just the re-keying of a certificate that was revoked, and even in that case it would be permitted based on a policy, so it would be ok. Seems to leave 5280 as the existing doc standing in the way ? If so, how to most easily fix this ? Cheers Toerless > spt > > > On Jul 19, 2018, at 17:29, Toerless Eckert wrote: > > > > Sean, > > > > wrt to the reply you gave me in Lamps wrt to: > > "Do existing authoritative IETF PKIX documents permit to use expired > > certificates as authentication for certificate renewal" > > > > Could you please point us to the reference that you mentioned whether > > or not this is allowed by current PKI standards ? > > > > Note that specifically in the case of BRSKI, we are talking about > > using an expired client cert in a TLS connection to an RA, so that > > TLS connection would only be used for renewal. > > > > Aka: I am not even sure if the expired cert would need to be "permitted" > > for this operartion by a PKIX document and/or by TLS. > > > > To me this is key missing piece to make ANIMA enrollment/renewal > > rock-solid in the face of non-contiguous full reachability of RA/CA. > > > > If we know and can point to how this is permissible it should > > be simple for us to have short informative text explaining this > > crucial option. > > > > Thanks! > > Toerless From nobody Fri Jul 27 10:44: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 016EA131025 for ; Fri, 27 Jul 2018 10:44:44 -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 b7IVf4wm_TtV for ; Fri, 27 Jul 2018 10:44:39 -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 F2632130E6B for ; Fri, 27 Jul 2018 10:44:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B06C4300A3E for ; Fri, 27 Jul 2018 13:44:36 -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 5o6SA-ZIKGCd for ; Fri, 27 Jul 2018 13:44:35 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id CD9B1300541 for ; Fri, 27 Jul 2018 13:44:35 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Fri, 27 Jul 2018 13:44:36 -0400 To: IETF LAMPS WG X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [lamps] Minutes for LAMPS Session at IETF 102 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 27 Jul 2018 17:44:44 -0000 The DRAFT minutes have been posted here: https://datatracker.ietf.org/meeting/102/materials/minutes-102-lamps-00 Please send comments and corrections. Russ From nobody Fri Jul 27 10:48: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 F211D131006 for ; Fri, 27 Jul 2018 10:48:55 -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 4FVEvD5Ji0t6 for ; Fri, 27 Jul 2018 10:48:54 -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 F36E3130E0C for ; Fri, 27 Jul 2018 10:48:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D9E79300A3E for ; Fri, 27 Jul 2018 13:48:51 -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 pYRZUcNIBnah for ; Fri, 27 Jul 2018 13:48:50 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 67419300541; Fri, 27 Jul 2018 13:48:50 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_90F8B857-83E4-49AA-B575-44DE5F3A8DFE"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 27 Jul 2018 13:48:50 -0400 In-Reply-To: Cc: SPASM To: Tim Hollebeek References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] Call for adoption of draft-nir-saag-star X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 27 Jul 2018 17:48:56 -0000 --Apple-Mail=_90F8B857-83E4-49AA-B575-44DE5F3A8DFE Content-Type: multipart/alternative; boundary="Apple-Mail=_AA6BFCFA-B8D1-40FA-BED4-E4A546E91533" --Apple-Mail=_AA6BFCFA-B8D1-40FA-BED4-E4A546E91533 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This document was discussed at IETF 102 in Montreal. the DRAFT minutes = say: '""" A WG call for adoption is underway. This document is about Short-Term Auto-Renewed (STAR) certificates. There is no revocation information for these certificates, and the short validity period of makes this acceptable. The automatic issuance of replacement certificates overcomes the operational challenges of short-term certificates. Two use cases are driving this work: IPsec VPNs and software-defined storage. These certificate might not be suitable for the Web PKI. Many people in the room felt that an extension for that tells the relying party that no revocation information is available is needed. The authors feel that such an extension should be defined in another document; this document should remain a BCP. Some people felt that these certificates should point to an empty CRL and a similar OCSP responder so that anyone looking for revocation information would not get a failure. Some people felt that the WG should not adopt this document until it addresses thes two topics. """ My conclusion from this discussion is that an update to the = Internet-Draft is needed for the LAMPS WG to consider adoption. Please = speak now id you come to a different conclusion. Russ > On Jul 14, 2018, at 12:01 PM, Tim Hollebeek = wrote: >=20 > =20 > The recently approved LAMPS WG Charter adds this work item: > =20 > 3. Specify the use of short-lived X.509 certificates for which no = revocation information is made available by the Certification Authority. > =20 > Short-lived certificates have a lifespan that is shorter than the time = needed to detect, report, and distribute revocation information. As a = result, revoking short-lived certificates is unnecessary and pointless. > =20 > It has been suggested that the WG adopt draft-nir-saag-star as the = starting point for this work. Please voice your support or concerns on = the list. >=20 --Apple-Mail=_AA6BFCFA-B8D1-40FA-BED4-E4A546E91533 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = document was discussed at IETF 102 in Montreal.  the DRAFT minutes = say:

'"""
A WG call for adoption is underway. =  This document is about Short-Term
Auto-Renewed = (STAR) certificates.  There is no revocation information
for these certificates, and the short validity period of = makes this
acceptable.  The automatic issuance = of replacement certificates
overcomes the = operational challenges of short-term certificates.
Two use cases are driving this work: IPsec VPNs and = software-defined
storage.  These certificate = might not be suitable for the Web PKI.

Many people in the room felt that an = extension for that tells the
relying party that no = revocation information is available is needed.
The = authors feel that such an extension should be defined in = another
document; this document should remain a = BCP.

Some = people felt that these certificates should point to an empty = CRL
and a similar OCSP responder so that anyone = looking for revocation
information would not get a = failure.

Some = people felt that the WG should not adopt this document until
it addresses thes two topics.
"""

My conclusion from this discussion is that an update to the = Internet-Draft is needed for the LAMPS WG to consider adoption. =  Please speak now id you come to a different conclusion.

Russ




On Jul = 14, 2018, at 12:01 PM, Tim Hollebeek <tim.hollebeek@digicert.com> wrote:

 
The = recently approved LAMPS WG Charter adds this work item:
 
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 short-lived certificates is = unnecessary and pointless.
 
It has been suggested that the WG adopt = draft-nir-saag-star as the starting point for this work.  Please = voice your support or concerns on the list.

= --Apple-Mail=_AA6BFCFA-B8D1-40FA-BED4-E4A546E91533-- --Apple-Mail=_90F8B857-83E4-49AA-B575-44DE5F3A8DFE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILITCCBTMw ggQboAMCAQICEFcbb6PmnhYLV+jqUdyIV+0wDQYJKoZIhvcNAQELBQAwgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE4MDYyNTAwMDAwMFoXDTE5MDYyNTIzNTk1OVow JTEjMCEGCSqGSIb3DQEJARYUaG91c2xleUB2aWdpbHNlYy5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCnEvCLwPYmBVNn5g2+eLGRfG1tJMoocKbQzJeWmo3n2rJsc1eSbbCUDObn 4BfU1w+TsMsaWvP7jwHyOysmN2ekekp4XAd9yhgiLAkmb6F29U7acvrydb+iWJTKx176SdTXJZsz x8PyLddbPcOlS9TwbcgbPlzGHUzM5P/yaSClaZ+n9bFohGVOticKjj1JqQ67HuH7x0fNptRS6Sv4 tq3JWNqQRLb2DDvej57F67uVxOZKF+vgmyCr63giTBZm0gdBG1ugCMBj3UUx0PACXrvuF/2Bwnzp 6HupfUpnq7Mx/h+OzHDdXzVZiVDxP1BKHTp9pMqdK0jA+7rG+TzYGnoVAgMBAAGjggHqMIIB5jAf BgNVHSMEGDAWgBSCr2yM+MX+lmF86B89K3FIXsSLwDAdBgNVHQ4EFgQUXRm7se08nq8s9iX0jfft j3xBicUwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQG CysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEB ATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBaBgNVHR8EUzBR ME+gTaBLhklodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNh dGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGLBggrBgEFBQcBAQR/MH0wVQYIKwYBBQUHMAKGSWh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNV HREEGDAWgRRob3VzbGV5QHZpZ2lsc2VjLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAf1YQTsTrXOFr bAbmYGHOh7+BEPKSkL+5sxDsKgJ5WGfKy0TXxlBIdOQ6UmxA7BJGz/+SEG/D8/X3GAKRYv6RBbAk 3wkF0/RwNqZoSPiSpy9DOrSAYmgPGyvZK6xmTN0omfamQ8vYOOa6vHcER9a/Wg37Pbuft0X6+/vh LOgEdv3ZKGhlv7nZdrOaoWMIkNdHVSMmFqJB6vGi74lGS7TgTWeO1NH8Jsu0VJyCrvruzmkacsDQ TlANxUatYuRXNdApXj2AVcPNdrkKEb2/8o66WweokfQrBwSwDe1pVvdANvwI2bcxugTbjGlmY1Ic d3xiq4wPhrDujT5vOOW767Xz7jCCBeYwggPOoAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZI hvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01P RE8gUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIz NTk1OVowgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEu p/Y0dtmEatrQPTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypV pVSRsivlJTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5 NOpG9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoS WY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IB PDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6W YXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQK MAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01P RE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYIKwYBBQUH MAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEo NE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT 0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5 Ns77zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRgl p9fyadqGOncjZjaaSOGTTFB+E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332n XttNtjv7VFNYG+I31gnMrwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI0 6vzgkejL580ul+9hz9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8 ydehzuZutLbZdRJ5PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2H sOgkL3VYnwtx7cJUmpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQ zVxZx5/bRaTKTlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIDtzCC A7MCAQEwgawwgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01P RE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBXG2+j5p4W C1fo6lHciFftMAkGBSsOAwIaBQCgggHfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTE4MDcyNzE3NDg1MVowIwYJKoZIhvcNAQkEMRYEFEx46zhV/AhZznzZqVbs4wPz Zc0wMIG9BgkrBgEEAYI3EAQxga8wgawwgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhBXG2+j5p4WC1fo6lHciFftMIG/BgsqhkiG9w0BCRACCzGBr6CBrDCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEFcbb6PmnhYLV+jqUdyIV+0wDQYJKoZIhvcN AQEBBQAEggEAMSlYBnYlKe+tYrsdDNLzk3vV//Hto02UCo+PiJAnc+4j+7MWByhborCkUXnejS8H abOTcf8TjKzKhCgRZ7JpNhYdPZU5znpBwIExKhHpPEP45d/hbBl17NheHCxOy1tVxVswGF01ImSH fMJPICzhkwwjl8GwGSxlXLFac3tBjWzDPuYiyuHJhm+uO4IhBMkUbXULu4jRDMYkjkKgoem+K0E8 ODS8husH+z18fke/N5fNQxg3L91Z7KG3KokAeWsHLG0oN+QHnca+06kTX5bZFjWXxj25tH1TDzJJ eOk5/EM87FyftBJ/gz98uNfLwmXAvbFDyHVABvseLb32BsonyQAAAAAAAA== --Apple-Mail=_90F8B857-83E4-49AA-B575-44DE5F3A8DFE-- From nobody Sun Jul 29 17:19: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 D4A3A130DEA for ; Sun, 29 Jul 2018 17:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, 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 DG4gj7oxEZ8o for ; Sun, 29 Jul 2018 17:19:36 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A405B130E19 for ; Sun, 29 Jul 2018 17:19:36 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7801258C4C2; Mon, 30 Jul 2018 02:19:32 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5F4F74402CB; Mon, 30 Jul 2018 02:19:32 +0200 (CEST) Date: Mon, 30 Jul 2018 02:19:32 +0200 From: Toerless Eckert To: Russ Housley Cc: Tim Hollebeek , SPASM Message-ID: <20180730001932.hrz5ehijcbvcjccr@faui48f.informatik.uni-erlangen.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [lamps] discuss: empty OSCP (as: Re: Call for adoption of draft-nir-saag-star) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 30 Jul 2018 00:19:39 -0000 On Fri, Jul 27, 2018 at 01:48:50PM -0400, Russ Housley wrote: > A WG call for adoption is underway. This document is about Short-Term > Auto-Renewed (STAR) certificates. There is no revocation information > for these certificates, and the short validity period of makes this > acceptable. The automatic issuance of replacement certificates > overcomes the operational challenges of short-term certificates. > Two use cases are driving this work: IPsec VPNs and software-defined > storage. These certificate might not be suitable for the Web PKI. > > Many people in the room felt that an extension for that tells the > relying party that no revocation information is available is needed. > The authors feel that such an extension should be defined in another > document; this document should remain a BCP. Separating normative from informational text is always a WGs style option. Guidance from the WG chairs would be useful. Personally (not speaking for the co-authors), i am a fan of indicating in a certificate how/where to renew it. After all, certificates allow to include CRL, which helps a lot for discovery, so why not have the same for renewal URL. And figuring out how to indicate that the semantic is STAR. For example, you may have a STAR certificate, sign an offline data item, and when it arrives, the STAR certificate has expired - but the recipient may still go to the renewal URL and query if there is a current certificate (for the same identity) and leverage that as additional information if the originator is "still" to be trusted. > Some people felt that these certificates should point to an empty CRL > and a similar OCSP responder so that anyone looking for revocation > information would not get a failure. I don't quite remember who raised this point and expicitly for what reason, the minutes don't say. Maybe whoever raised the point could chime in. If you already have useable CRL/OCSP, this option seems like a useful simplification, but it does not address the most lightweight instance of STAR where you do NOT want to set up (unnecessarily) any CRL/OCSP infra. Maybe whoever raised the issue would be fine if the solution space would be framed this way ? Cheers Toerless > Some people felt that the WG should not adopt this document until > it addresses thes two topics. > """ > > My conclusion from this discussion is that an update to the Internet-Draft is needed for the LAMPS WG to consider adoption. Please speak now id you come to a different conclusion. > > Russ > > > > > > On Jul 14, 2018, at 12:01 PM, Tim Hollebeek wrote: > > > > > > The recently approved LAMPS WG Charter adds this work item: > > > > 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 short-lived certificates is unnecessary and pointless. > > > > It has been suggested that the WG adopt draft-nir-saag-star as the starting point for this work. Please voice your support or concerns on the list. > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Jul 30 10:43: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 78C99130E97 for ; Mon, 30 Jul 2018 10:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.343 X-Spam-Level: X-Spam-Status: No, score=-0.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqXixp-kpvuo for ; Mon, 30 Jul 2018 10:43:49 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id DBB0B130E96 for ; Mon, 30 Jul 2018 10:43:48 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id B138B3740FBE for ; Mon, 30 Jul 2018 17:43:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2ccI9y7NhDZp for ; Mon, 30 Jul 2018 13:43:47 -0400 (EDT) Received: from Maxs-MBP.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 40FC037404D6 for ; Mon, 30 Jul 2018 13:43:47 -0400 (EDT) To: spasm@ietf.org References: From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <3815b431-fd3a-0b5c-0370-d270edf4303d@openca.org> Date: Mon, 30 Jul 2018 11:43:46 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020109000400030204050304" Archived-At: Subject: Re: [lamps] Call for adoption of draft-nir-saag-star X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.27 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, 30 Jul 2018 17:43:51 -0000 This is a cryptographically signed message in MIME format. --------------ms020109000400030204050304 Content-Type: multipart/alternative; boundary="------------E81A350AE045D79B1AD9B487" Content-Language: en-US This is a multi-part message in MIME format. --------------E81A350AE045D79B1AD9B487 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Russ, all, On 7/27/18 11:48 AM, Russ Housley wrote: > This document was discussed at IETF 102 in Montreal. =A0the DRAFT > minutes say: > > [...] > > My conclusion from this discussion is that an update to the > Internet-Draft is needed for the LAMPS WG to consider adoption. > =A0Please speak now id you come to a different conclusion. > > Russ > > I share the same view - I think that your conclusion correctly captures the room's sentiment - I think that was clear from the humming about that and the overall comments / discussion. Cheers, Max --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------E81A350AE045D79B1AD9B487 Content-Type: multipart/related; boundary="------------42723792DF4A053C0548781A" --------------42723792DF4A053C0548781A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi Russ, all,

On 7/27/18 11:48 AM, Russ Housley wrote:
This document was discussed at IETF 102 in Montreal. =A0the DRAFT minutes say:

[...]

My conclusion from this discussion is that an updat= e to the Internet-Draft is needed for the LAMPS WG to consider adoption. =A0Please speak now id you come to a different conclusion.

Russ


I share the same view - I think that your conclusion correctly captures the room's sentiment - I think that was clear from the humming about that and the overall comments / discussion.

Cheers,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--------------42723792DF4A053C0548781A Content-Type: image/png; name="kidpglebebmepkpi.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="kidpglebebmepkpi.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------42723792DF4A053C0548781A-- --------------E81A350AE045D79B1AD9B487-- --------------ms020109000400030204050304 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CyAwggUyMIIEGqADAgECAhEAu2YCW4tRQdGHMc0S/FQsNDANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTcxMjAxMDAw MDAwWhcNMTgxMjAxMjM1OTU5WjAkMSIwIAYJKoZIhvcNAQkBFhNkaXJlY3RvckBvcGVuY2Eu b3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyEDKYfy+DFhtDn8bIXyP25Xe DjUIkMQDm90A1JPoQ4tuTk6kXwulPvAmvtLGuRAzEqFpV/fqz4sAlx8FgxvRZ5PunZ1H1/lJ CNEdir53Xv8TEf+R/n+Ca5RNUR+GhS72zhp9xx8uDRZds2DeXvW9uhYp9nsbX6rWIFT5YfWF 1SukFXwXSnHuXc9nDT6p0Kp6UNzusn/lMhXhIwgpNA26/mHAdScYyMoB4yaZeMpdZN75XGWO slhXcXdeGJo93E48kffdu0yo4WTbpLwhs/IrkG4OXB1N3Bf+9oHZwVun1hlCZEfuSit0mvrx x8wzPCPiggXu6j6VqPoJqecV6xKCHwIDAQABo4IB6TCCAeUwHwYDVR0jBBgwFoAUgq9sjPjF /pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFEPV9allspkmYqkQRx2BlAdbOrjhMA4GA1UdDwEB /wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggr BgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2g S4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3BlbmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEA g+REupW946f7esdYmE1QxsYlkubErxz8JLovVDSKTHwxR1/VxF/B7rGeiSPBHTmKQYwlWCrp eHZNfzaDDkDamwLXm7v4+brNfQKRpOLnYPQQffp7xim72INakLgts8d5I7bic785dj4M5JP4 XA2qUD9wduwNwquua6v7zM3chpoRjapumzLNDDr47GccOKAZYaaqFwbpwJPQYuiC07WWnn7g FzdNKYN6VM6Re6wVEHP6fEvNrleV0pf1iFjLKugnriGKL9wj6xX25JsMmGmqZcfdpnkTE4Zf eQBEZVnn8s7HBX+MA/K+YnHxRwA2c5XwNbEhZ2rvh2uFIMXBDlt+tDCCBeYwggPOoAMCAQIC EGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQ PTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivl JTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG 9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoS WY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQAB o4IBPDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKv bIz4xf6WYXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEA MBEGA1UdIAQKMAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9k b2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcB AQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFk ZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJ KoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo 7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaB Q+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKS TvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+E2pvOUtY +hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnMrwfHM5td hYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9hz9D0S0U4 jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5PDEJ M/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJU mpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTK TlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIEODCCBDQCAQEw ga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01P RE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAu2YC W4tRQdGHMc0S/FQsNDANBglghkgBZQMEAgEFAKCCAlswGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwNzMwMTc0MzQ2WjAvBgkqhkiG9w0BCQQxIgQgga7M vuGlE2A1T3BecyMgEAnEAwfwHvSRrteHaJ1IY1MwbAYJKoZIhvcNAQkPMV8wXTALBglghkgB ZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGwMIGtMIGX MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJT QSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRALtmAluLUUHR hzHNEvxULDQwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRALtmAluLUUHRhzHNEvxULDQwDQYJKoZIhvcNAQEB BQAEggEAe/38b+EEpEsadbJCCndbjhXcgUaOKwCZRPQa04mQLw5gZTnQH6wb+EzAzrrtFD7I cgPb2Vq+alBgxDk/3QVNRMfWunysnvBufXZvO0yIJw4bAmVJM/oZCMa4IFrShxBLEr29AOUL b8BC3c7Gl3zXGdzuaIjprjsUMCmjXDwoI9CKTQUN2aiaDnP9CN9qvNRgAt2VUPFTko87DsJv RVb6M63gSS+guXZFm5LK3svLg5sG70NfoqMtZ/+ek1JF/0N3w7Y9XVCrHLwNI0nChP8Ro7RG xXJUTvoz5PwpAvlpFx2TpT2Cidnwz5aUMBxebCvF659yFQc9erbewOSi2Pt51wAAAAAAAA== --------------ms020109000400030204050304--