From nobody Thu Jul 2 12:46:27 2020 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 F3D3C3A07B9; Thu, 2 Jul 2020 12:46:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tim Hollebeek via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Cc: tim.hollebeek@digicert.com, lamps-chairs@ietf.org, spasm@ietf.org, Tim Hollebeek , iesg-secretary@ietf.org Message-ID: <159371918498.31474.4721354293555958582@ietfa.amsl.com> Date: Thu, 02 Jul 2020 12:46:24 -0700 Archived-At: Subject: [lamps] Publication has been requested for draft-ietf-lamps-cms-update-alg-id-protect-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 02 Jul 2020 19:46:25 -0000 Tim Hollebeek has requested publication of draft-ietf-lamps-cms-update-alg-id-protect-02 as Proposed Standard on behalf of the LAMPS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protect/ From nobody Thu Jul 2 17:21:41 2020 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 06EF83A094D; Thu, 2 Jul 2020 17:20:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: rdd@cert.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159373563200.30173.8019413283120312827@ietfa.amsl.com> Date: Thu, 02 Jul 2020 17:20:32 -0700 Archived-At: Subject: [lamps] lamps - Requested session has been scheduled for IETF 108 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 03 Jul 2020 00:20:40 -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 (1:40 requested) Tuesday, 28 July 2020, Session I 1100-1240 Room Name: Room 7 size: 7 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/108/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): 100 Minutes Number of Attendees: 45 Conflicts to Avoid: Chair Conflict: ipwave suit stir Technology Overlap: acme cfrg ace Key Participant Conflict: oauth secdispatch saag sipbrandy tls mls teep emu People who must be present: Russ Housley Rich Salz Sean Turner Alexey Melnikov Michael Richardson Roman Danyliw Bernie Hoeneisen Jim Schaad Tim Hollebeek Hendrik Brockhaus Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Jul 5 14:19:17 2020 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 53FAD3A0B2C; Sun, 5 Jul 2020 14:19:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Jaeggli via Datatracker To: Cc: draft-ietf-lamps-rfc7030est-clarify.all@ietf.org, last-call@ietf.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159398394629.24086.11782687822229389320@ietfa.amsl.com> Reply-To: Joel Jaeggli Date: Sun, 05 Jul 2020 14:19:06 -0700 Archived-At: Subject: [lamps] Opsdir last call review of draft-ietf-lamps-rfc7030est-clarify-07 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 05 Jul 2020 21:19:07 -0000 Reviewer: Joel Jaeggli Review result: Ready Greetings, I have reviewed draft-ietf-lamps-rfc7030est-clarify for the purposes of clarity. As the document is intended as a series of clarifications, signficant changes, and some small changes to RFC 7030 this is a mostly straight foward exercise excepting that in order to be useful a through reading of RFC 7030 is required. It appears to be a that major variance to rfc 7030 is: Any updates to [RFC7030] to bring it inline with HTTP processing risk changing the on-wire protocol in a way that is not backwards compatible. However, reports from implementers suggest that many implementations do not send the Content-Transfer-Encoding, and many of them ignore it. The consequence is that simply deprecating the header would remain compatible with current implementations. This update reflect implementation experience and brings 7030 inline with present implementation. I think that this document is ready to go. Thanks joel From nobody Mon Jul 6 07:24:18 2020 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 BBA453A1573; Mon, 6 Jul 2020 07:24:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Catherine Meadows via Datatracker To: Cc: draft-ietf-lamps-rfc7030est-clarify.all@ietf.org, spasm@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159404545672.27089.13777709421479611964@ietfa.amsl.com> Reply-To: Catherine Meadows Date: Mon, 06 Jul 2020 07:24:16 -0700 Archived-At: Subject: [lamps] Secdir last call review of draft-ietf-lamps-rfc7030est-clarify-07 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 06 Jul 2020 14:24:17 -0000 Reviewer: Catherine Meadows Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other comments. This draft sets forth changes to the syntax of Enrollment over Secure Transport (EST) (RFC7030) to fix some errors and ambiguities that resulted in interoperability issues. RFC7030 also includes a form of header that has been deprecated in other RFC’s. This document thus deprecates that header as well. Since the only changes to the draft makes to the syntax are either to clarify ambiguities in the descriptions and to deprecate syntax that has already deprecated by other RFC’s, it presents no new security or privacy concerns. However, I found a few typos, etc. that I am listing below. They are all of the sort that would be missed by a spell checker. I don’t know if I got all of them, so I’d suggest another round or proofreading. I consider this document Ready with Nits. Abstract some errata that was reported should be some errata that were reported This document fixes some syntactical errors in ASN.1 that was presented assuming that the word “was” refers to the errors, that should be This document fixes some syntactical errors in ASN.1 that were presented In the Privacy Considerations Section This document does not disclose any additional identifies should be This document does not disclose any additional identities From nobody Mon Jul 6 11:58:02 2020 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 76E1B3A09BB; Mon, 6 Jul 2020 11:57:56 -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, SPF_HELO_NONE=0.001, 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 F32UIAhzUTmo; Mon, 6 Jul 2020 11:57:54 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4B63A0971; Mon, 6 Jul 2020 11:57:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CB289389A5; Mon, 6 Jul 2020 14:54:56 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id e1W8B_o_NW1e; Mon, 6 Jul 2020 14:54:55 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 444AA389A9; Mon, 6 Jul 2020 14:54:53 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7E3F8781; Mon, 6 Jul 2020 14:57:45 -0400 (EDT) From: Michael Richardson To: Catherine Meadows cc: secdir@ietf.org, spasm@ietf.org, last-call@ietf.org, draft-ietf-lamps-rfc7030est-clarify.all@ietf.org In-Reply-To: <159404545672.27089.13777709421479611964@ietfa.amsl.com> References: <159404545672.27089.13777709421479611964@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] Secdir last call review of draft-ietf-lamps-rfc7030est-clarify-07 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 06 Jul 2020 18:57:57 -0000 --=-=-= Content-Type: text/plain Catherine Meadows via Datatracker wrote: > I consider this document Ready with Nits. I have submitted -08 with the three corrections you noted. Thank you. > This document does not disclose any additional identifies This is amusing, given that identities often identify. Thank you for noticing. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8DdCkACgkQgItw+93Q 3WV9BAf/ZJDtZZJ63+OroAfMiKCUKUBlHz2S/d2t0kIfVKt6/stt4zg0g803xqNx hkg5cFKNUl6v+SYofvudlivSuG0ngrdWuhxY/HdNiQs50VK7IoPJVGCb7T1HY9DS Yeov63xaJbbRpYjNKuX+28dXqfxpjaBmKfaq+TyRFk7str9EiVQS7pSWwtt9BOGz 8DYLManfcAuH94Bl9dQkJz3HsK3CIO1dBo7DQZBJ/qG3bIqz0FKwlpTZ7SalWdzG fSoZumgATBdulIV/G+O1D7yKwyG7Ojp62XBBbvA8NSjVGqAHX7F/WUBSlnH13vhL Gbw4ry0m+Hgxq+aicjBZrbZnHZK8Gw== =iM8W -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 6 12:00:30 2020 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 A593B3A0A8B; Mon, 6 Jul 2020 12:00:22 -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: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <159406202263.10696.16926363067899176037@ietfa.amsl.com> Date: Mon, 06 Jul 2020 12:00:22 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc7030est-clarify-08.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 06 Jul 2020 19:00:29 -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 : Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1 Authors : Michael Richardson Thomas Werner Wei Pan Filename : draft-ietf-lamps-rfc7030est-clarify-08.txt Pages : 14 Date : 2020-07-06 Abstract: This document updates RFC7030: Enrollment over Secure Transport (EST) to resolve some errata that were reported, and which has proven to cause interoperability issues when RFC7030 was extended. This document deprecates the specification of "Content-Transfer- Encoding" headers for EST endpoints. This document fixes some syntactical errors in ASN.1 that were presented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7030est-clarify/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc7030est-clarify-08 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc7030est-clarify-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc7030est-clarify-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 22:40:07 2020 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 05EA33A087D; Mon, 6 Jul 2020 22:39:46 -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: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <159410038595.542.17340030074992860494@ietfa.amsl.com> Date: Mon, 06 Jul 2020 22:39:46 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cmp-updates-02.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 07 Jul 2020 05:39:46 -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 : CMP Updates Author : Hendrik Brockhaus Filename : draft-ietf-lamps-cmp-updates-02.txt Pages : 16 Date : 2020-07-06 Abstract: This document contains a set of updates to the base syntax of Certificate Management Protocol (CMP) version 2. This document updates RFC 4210. Specifically, the CMP services updated in this document comprise the enabling of using EnvelopedData instead of EncryptedValue and the definition of extended key usages to identify certificates of CMP endpoints on certification and registration authorities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cmp-updates/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cmp-updates-02 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-updates-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cmp-updates-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 8 12:16:27 2020 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 A545F3A00E3; Wed, 8 Jul 2020 12:16:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ines Robles via Datatracker To: Cc: draft-ietf-lamps-rfc7030est-clarify.all@ietf.org, last-call@ietf.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159423577963.26106.8547442088755899406@ietfa.amsl.com> Reply-To: Ines Robles Date: Wed, 08 Jul 2020 12:16:19 -0700 Archived-At: Subject: [lamps] Genart last call review of draft-ietf-lamps-rfc7030est-clarify-08 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 08 Jul 2020 19:16:20 -0000 Reviewer: Ines Robles Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-lamps-rfc7030est-clarify-08 Reviewer: Ines Robles Review Date: 2020-07-08 IETF LC End Date: 2020-07-09 IESG Telechat date: Not scheduled for a telechat Summary: This document updates RFC7030 to address errata. This document deprecates the specification of "Content-Transfer-Encoding" headers for EST endpoints. This document fixes some syntactical errors in ASN.1 that were presented. The document is clear and well written. I have some minor nits/questions Major issues: None Minor issues: None Nits/editorial comments/questions: 1- It would be nice to add in Terminology section that the document uses the terminology of RFC7030 and RFC5272 2- Introduction: "reports from implementers suggest..." It would be nice to add reference/s here 3- Security Considerations: It would be nice to add smth like "security considerations from RFC7030 applies also for the clarifications described in this document." 5- IANA Considerations: It would be nice to add the specific registry that IANA should update. For example, instead of "IANA is requested to update the "Reference" column for the Asymmetric Decryption Key Identifier attribute to also include a reference to this document." you could add smth like (if applicable): " IANA is requested to update the registry SMI Security for S/MIME Attributes (1.2.840.113549.1.9.16.2) " with the reference of this document as follows: Decimal - Description -Reference 54 id-aa-asymmDecryptKeyID [RFC7030] [ThisDocument] 4- Appendix A: In id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= {...} 4.1- pkcs9(9) should be pkcs-9(9) ? 4.2- aa(2) should be id-aa(2) ? Thank you for this document, Ines. From nobody Wed Jul 8 12:37:11 2020 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 81D163A03EA for ; Wed, 8 Jul 2020 12:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 kI8QEzzJWe1u for ; Wed, 8 Jul 2020 12:37:07 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCFD13A02BE for ; Wed, 8 Jul 2020 12:37:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 508A9300B7C for ; Wed, 8 Jul 2020 15:37:05 -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 Luxft0MPTiT8 for ; Wed, 8 Jul 2020 15:37:03 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id E42D4300A4B; Wed, 8 Jul 2020 15:37:02 -0400 (EDT) From: Russ Housley Message-Id: <3D6604F1-E541-473F-9D18-22D2A41A489C@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D82DAD50-7B90-4FD7-B8AD-0C71A4C59C41" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Wed, 8 Jul 2020 15:37:04 -0400 In-Reply-To: <159423577963.26106.8547442088755899406@ietfa.amsl.com> Cc: IETF Gen-ART , draft-ietf-lamps-rfc7030est-clarify.all@ietf.org, last-call@ietf.org, SPASM To: Ines Robles References: <159423577963.26106.8547442088755899406@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-rfc7030est-clarify-08 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 08 Jul 2020 19:37:10 -0000 --Apple-Mail=_D82DAD50-7B90-4FD7-B8AD-0C71A4C59C41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ines: Thanks for the very carful review. I'll tackle the ones about the = ASN.1... > 4- Appendix A: In id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::=3D = {...} >=20 > 4.1- pkcs9(9) should be pkcs-9(9) ? Both are used in different modules. They have become synonyms. That = said, we should pick one, and the use it in the two places where this is = used. The hyphen is used in RFC 6268, where we import some things, so I = suggest we use the hyphen here too. >=20 > 4.2- aa(2) should be id-aa(2) ? No. This one is correct. Russ --Apple-Mail=_D82DAD50-7B90-4FD7-B8AD-0C71A4C59C41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Ines:

Thanks for the very carful review.  I'll tackle the ones = about the ASN.1...

4- Appendix A: In id-aa-asymmDecryptKeyID OBJECT IDENTIFIER = ::=3D {...}

4.1- =   pkcs9(9) should be pkcs-9(9) ?

Both are used in different modules.  They have = become synonyms.  That said, we should pick one, and the use it in = the two places where this is used.

The= hyphen is used in RFC 6268, where we import some things, so I = suggest we use the hyphen here too.


4.2-   aa(2) should be id-aa(2) = ?

No. =  This one is correct.

Russ


= --Apple-Mail=_D82DAD50-7B90-4FD7-B8AD-0C71A4C59C41-- From nobody Wed Jul 8 12:55:54 2020 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 12EEA3A0772 for ; Wed, 8 Jul 2020 12:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com header.b=XuiKK3qs; dkim=pass (1024-bit key) header.d=digicert.com header.b=AqsEUQMX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkK_AoEas2-p for ; Wed, 8 Jul 2020 12:55:49 -0700 (PDT) Received: from us-smtp-delivery-173.mimecast.com (us-smtp-delivery-173.mimecast.com [216.205.24.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89E583A02C1 for ; Wed, 8 Jul 2020 12:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1594238148; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8NtFUoxvWEK54vJwfBhxJZ5MCGhip2AiDvVOH2EEt5I=; b=XuiKK3qsOaSMBH6FAqL08tixR3XaJifly0aReFPF6FzYTsOG1rBiY/Q+EvmzuuT5+6eq2X eGlEp42851DhZ2Wa3OU3fe2YUXcHdsO7nWIUa+l+sdKEpfNPei2E9fK7M5QYxPpHd/3t2n DxvTVljFLjkq3+2806/3iDBbgDitqck= Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2104.outbound.protection.outlook.com [104.47.70.104]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-439-Y-XhPs7DMzOZrz7zmiKZOw-1; Wed, 08 Jul 2020 15:55:45 -0400 X-MC-Unique: Y-XhPs7DMzOZrz7zmiKZOw-1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OxcgLcLzUheYt7xmoNd2NhxtWb/BWgqz7DNByFqCokPiPjjCmaB5j6kioBGheqhjWFVv10x+XH/wMiCysyenuoNZibBVdVmQopjOObdJNnUV8E+2olNkUE9rEFjSxKhRljeMlgQvSRMP23Qg2bM9jGH3dgcwTgO/vGaTCLAPyMk0FjC8rm46BblQF5CQqiTWkOG/fr8dj5zLVmzDLOFpQ+cSdIHDgGwNHweKnN87Pa68ru/mbPNZfKaapFjyOsD7DOl6FPtGXXC1ExBoFWEsneaOQy1JAvBNv2S9FEhZiURbZ702LoXSHH4uh5u03mwkMokIyFIWCKDgn+z0ZtWDkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8NtFUoxvWEK54vJwfBhxJZ5MCGhip2AiDvVOH2EEt5I=; b=ENMOrs6Is7Hao8syOWNaDfQZfcv8R4IYVrD1CnVdCqHM3jpSTnpX7RrFHQR5piiyvL2n5FMZsTAdJiSlnm/HyXKb0Xf7sAZFbydrpQtdYScOJeJrkqjUURmoQWYrgxHGv3gmWd+a89ZwKMae5PxiBnpcF5Sr8+mWLJ8yvZhjDd7C0s56nKUkO2lp/XtOBKzP4ieAOfPDhK9VfOkZU8mqqy8LjH/wojVJnnCJQsy8ym+OR/J2NxTk9IikDgWlLDhJ8L/aKHVlKZXSglogQwkgy/baQvAvsDrJEvOQ3j+K5QqPKrgL/EaQQITRoSjF/gGrCXcSex3SZDyoOffQuxTBxg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=digicert.com; dmarc=pass action=none header.from=digicert.com; dkim=pass header.d=digicert.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8NtFUoxvWEK54vJwfBhxJZ5MCGhip2AiDvVOH2EEt5I=; b=AqsEUQMXhbPlvVWGd8/de6JcUcAwQ3edTcuw2liXpKoT9KeSeOmAhb9KYxAaASzO6+hoGUlYojJi1mM/2okzHXZtMzvCxkbl782YI4vOV4AjdswkKozG3nlhnkD6CoAKhuXegfw/UX2EZAedpgLeFLFEmySxLn3Gjpgrkn2RLAM= Received: from MN2PR14MB3167.namprd14.prod.outlook.com (2603:10b6:208:12e::28) by MN2PR14MB3197.namprd14.prod.outlook.com (2603:10b6:208:c5::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21; Wed, 8 Jul 2020 19:55:43 +0000 Received: from MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::419f:18ba:1450:6cb]) by MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::419f:18ba:1450:6cb%7]) with mapi id 15.20.3153.030; Wed, 8 Jul 2020 19:55:43 +0000 From: Tim Hollebeek To: Erik Andersen , 'Carsten Bormann' CC: LAMPS Thread-Topic: [lamps] [Anima] on certification authorities. Thread-Index: AQHWTR+I7qUjklDOG06HiRtszeHuCqj+KH2g Date: Wed, 8 Jul 2020 19:55:43 +0000 Message-ID: References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> In-Reply-To: <000701d64d1f$7a7cea20$6f76be60$@x500.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: x500.eu; dkim=none (message not signed) header.d=none;x500.eu; dmarc=none action=none header.from=digicert.com; x-originating-ip: [74.98.249.186] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f6693b2c-4e19-428f-7dbd-08d82378e63d x-ms-traffictypediagnostic: MN2PR14MB3197: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: O5OrJZIA0ZdIhxOkjCNoCVm2BXUynfFz4OFJu8WlrtuJBUu6N4Rnf1JTcIPXvGBQYKnzXAfP2DSZJbt3HUFv2DE+2B3BYiMH7j98u+T2QfDa62hDGFGOb1mZw0mR1nVQ/lfTqi3kIzpWES18AKhfaJOvQvJJ4+QERES0Nl3csqVPXLVVCITl0cYmPV5DaN3TGKKlM8tNzbndSynR+Uk0OYIA/tnD4uRCPbH12cXTQeJVDMGylj8zilTx/f0DkgjrpLRv/AfOSV/cNUT3o/CB3SSAoKGyxcwjRUqAlXMHtZLTBmPUOlyrg+MtVP826207X28skom+ykNWFez/mE+iGEhxePWgHbo2jTrLcwzCr8Jp5LF4zsePCMqUDylE5mejHGiP8tJU2GuyyD6NNvlYJZfpTG/DpvetRn0yv+I7yIhmSqcrw56cjNpgW4UBi6Vq39mPEPNbqE/OCOxwaSf6mg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR14MB3167.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(39850400004)(136003)(376002)(346002)(366004)(396003)(99936003)(33656002)(44832011)(966005)(76116006)(86362001)(110136005)(7696005)(66946007)(53546011)(316002)(6506007)(83380400001)(4326008)(186003)(26005)(71200400001)(64756008)(66446008)(55016002)(9686003)(478600001)(52536014)(66556008)(66476007)(66616009)(5660300002)(2906002)(8936002)(8676002)(228954003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: UxCMSTci7WkTBRenCP+INfpyYgnIigfFaOU7YVxvF0VjJjJh6wewNxeNVdK+agu4wCXWGZVzTQhUw/jW4eNdT7YhfChWRMqGZbdL6xKpRnE7A1mbJl86w/noiOwiyPAZ/3AECqZWHh32QsjTRfOyRbuiTSYElQCcvf9NUXxLpiGCJXb9+Dr+fFRS8VFwV0zDeoPrh5GfG+4QDR21LInXfflxVOr1U8OW+ASdJE7VK/LzxA/eevN/RDnQPeEefs2/VRvQ72pgCpTSN/4ayUOy3MDDSi3vPEgFlfQ1rxo84yRVrVbDajTwUxUxmiOpKTtlR7VktHo8Erlv6+aPbJ8pqVRrY9kO11lPRuv20LeKCSjzzwAXPcI7uX8ypwgGpf9Mflh/r4RtPdoRZkOZdLtlWcGQGu47BKsc7+jU0r4L9wJTFyvmANcggkVMuuls+eqewOsvv8sF3HK7y121a862rAqohvLmINrH2gqdi4p2iqJffjRz2zRGg2d4+9z7EFW8 x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_024C_01D65540.05DCE980" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR14MB3167.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f6693b2c-4e19-428f-7dbd-08d82378e63d X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2020 19:55:43.7293 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: SStIhdREb2WseUnsveQmOI5shQZ57Gr1GZBOkQOlMtk4tgv6b3y3FQVV9I6Vuy3AzqM6R5K3LJXo70ZKbvsl8VKmi0C2mC+QbunhabyYYRk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB3197 Archived-At: Subject: Re: [lamps] [Anima] on certification authorities. X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 08 Jul 2020 19:55:52 -0000 ------=_NextPart_000_024C_01D65540.05DCE980 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I check the CABF Bylaws, Baseline Requirements, and EV Guidelines, and = was surprised to find that they mostly get this right. -Tim > -----Original Message----- > From: Spasm On Behalf Of Erik Andersen > Sent: Sunday, June 28, 2020 3:41 AM > To: 'Carsten Bormann' > Cc: LAMPS > Subject: Re: [lamps] [Anima] on certification authorities. >=20 > 32 years ago X.509 (1988) defined certification authority. There has = been > plenty of time to get acquainted with the term. >=20 > Erik >=20 > -----Original Message----- > From: Carsten Bormann > Sent: 27 June 2020 22:19 > To: Erik Andersen > Cc: anima@ietf.org > Subject: Re: [Anima] [lamps] on certification authorities. >=20 > On 2020-06-27, at 09:57, Erik Andersen wrote: > > > > certificate authority >=20 > 4 matches in 1id-abstracts.txt. > 7292 files on my laptop happen to match. >=20 > Enjoy how RFC 4523 dances right into the fire here: >=20 > ( 2.5.6.16 NAME 'certificationAuthority' > DESC 'X.509 certificate authority' > SUP top AUXILIARY > MUST ( authorityRevocationList $ > certificateRevocationList $ cACertificate ) > MAY crossCertificatePair ) >=20 > RFCs with =E2=80=9Ccertificate authority=E2=80=9D released before RFC = 5280: >=20 > rfc1305.txt rfc2246.txt rfc2408.txt rfc2633.txt rfc2634.txt = rfc2752.txt > rfc2828.txt rfc2847.txt rfc2904.txt rfc3108.txt rfc3182.txt = rfc3193.txt > rfc3520.txt rfc3552.txt rfc3588.txt rfc3720.txt rfc3723.txt = rfc3760.txt > rfc3851.txt rfc3854.txt rfc3911.txt rfc3920.txt rfc3923.txt = rfc4171.txt > rfc4230.txt rfc4255.txt rfc4261.txt rfc4346.txt rfc4474.txt = rfc4523.txt > rfc4534.txt rfc4582.txt rfc4795.txt rfc4870.txt rfc4949.txt = rfc4953.txt > rfc5040.txt rfc5197.txt rfc5246.txt >=20 > RFCs with =E2=80=9Ccertificate authority=E2=80=9D released after RFC = 5280: >=20 > rfc5479.txt rfc5763.txt rfc5765.txt rfc5981.txt rfc6101.txt = rfc6187.txt > rfc6189.txt rfc6376.txt rfc6406.txt rfc6810.txt rfc6818.txt = rfc6837.txt > rfc6940.txt rfc6950.txt rfc6962.txt rfc7143.txt rfc7146.txt = rfc7211.txt > rfc7340.txt rfc7378.txt rfc7427.txt rfc7533.txt rfc7576.txt = rfc7671.txt > rfc7826.txt rfc7858.txt rfc7859.txt rfc7958.txt rfc8023.txt = rfc8071.txt > rfc8446.txt rfc8572.txt rfc8705.txt >=20 > (Not all of these are about X.509 certificates, of course. > And I=E2=80=99m probably missing a few because line breaking obscures = the > combination.) >=20 > Yes, you saw TLS 1.0, 1.1, 1.2, and 1.3 there. >=20 > Now starting to write the errata reports :-) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm ------=_NextPart_000_024C_01D65540.05DCE980 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 CQUxDxcNMjAwNzA4MTk1NDExWjAvBgkqhkiG9w0BCQQxIgQg870+U2Mzpc0ApulNmJU+G2152LRz m86UwxmVbFLyzscwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAHtJNEHIgFUBrXFW7K4rKfPhY2iHconqMxCdpQp4/ueqT1CLccGsxkGfB1bzBVcAJVrmZ6Td x6T+LfJqbUrWf5AFL9nbHzNb2H/BIh2cHtd1XTdOsVcx3fvZbXIauMeezcCVTXF3vrHh4p/5T1Zs gnafF5Caw4+MiAkynT5Y8rqM3Y+s7Hr6/4KUX79VftKnDa/TxsRiKHJxlFCI3/kLK1vkEJRzE3md yFLDRwhJYd0XDbjKmEhjiUU0R6i6OGwhy4VOr75KbpqQDcpUlTNAOKlPOzq7aOrJf6b5qDlOj60E ilI73lAb0+3UWWmKPjkn1g0aq38uwc3Eme0sSQaJHLwAAAAAAAA= ------=_NextPart_000_024C_01D65540.05DCE980-- From nobody Wed Jul 8 13:19:25 2020 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 BC03C3A07B1 for ; Wed, 8 Jul 2020 13:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 3U10EP28x8EG for ; Wed, 8 Jul 2020 13:19:21 -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 C4A4B3A07B0 for ; Wed, 8 Jul 2020 13:19:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 53051300B04 for ; Wed, 8 Jul 2020 16:19:19 -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 u02eQb3qrZ2a for ; Wed, 8 Jul 2020 16:19:18 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 10F6A300464 for ; Wed, 8 Jul 2020 16:19:18 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Message-Id: <1D43C9EF-6F43-4E1A-9D4D-03B6BB733F28@vigilsec.com> Date: Wed, 8 Jul 2020 16:19:19 -0400 To: SPASM X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: [lamps] DRAFT LAMPS Agenda for IETF 108 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 08 Jul 2020 20:19:24 -0000 Please review and comment. Russ = = = = = = = LAMPS WG Agenda at Virtual IETF 108 0) Minute Taker, Jabber Scribe, Bluesheets 1) Agenda Bash 2) Documents with the RFC Editor and IESG a) draft-ietf-lamps-5480-ku-clarifications (Sean) b) draft-ietf-lamps-ocsp-nonce (Mohit) c) draft-ietf-lamps-rfc7030est-clarify (Michael, Thomas, Wei) d) draft-ietf-lamps-cms-update-alg-id-protect (Russ) 3) Active Working Group Documents a) draft-ietf-lamps-header-protection-requirements (Alexey, Bernie) b) draft-ietf-lamps-cmp-updates (Henk) c) draft-ietf-lamps-lightweight-cmp-profile (Henk, Steffen, David) 4) Wrap Up = = = = = = = = = Etherpad: https://codimd.ietf.org/notes-ietf-108-lamps# Slides: https://datatracker.ietf.org/meeting/108/session/lamps Jabber: xmpp:lamps@jabber.ietf.org From nobody Thu Jul 9 02:21:19 2020 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 8B8893A0999; Thu, 9 Jul 2020 02:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deIAT_MaXrN3; Thu, 9 Jul 2020 02:21:13 -0700 (PDT) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 1F4AE3A0995; Thu, 9 Jul 2020 02:21:13 -0700 (PDT) Received: by mail-ua1-x92a.google.com with SMTP id k7so490829uan.13; Thu, 09 Jul 2020 02:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0+MLvmp5hqqU8S4irNLIflzCOWbaXZXKlBRHbGJqm7M=; b=t9nKKWKwWGkr484eOJ3pHrOh/1tCUT2dDra2xFULVEIn/ThDJ35vkTxg5rYGxp3OO9 M2ZXHsqKsIpSTedZdE9tdYDX3FmskJD6MyASqWyZnlabzglJB3/BpOMkcwjz35f3uOuA olT9igKvii7fMI0T6CPYSYS56HzNsY+W2pQzmkvs5UaL/0XJwL14Zs5LMxXs/hZRQ123 0SBKhqzZjR12hp29033bJmftYwBv02otDKo1mrimEEN8Blg4z7oP7+IQFqrzZhzKQJxa Styeb7hQop2VmM4/zTK5gaYZR4gVOemSzpttADFHVvMaselSSigVX0NZnYBDZbJ/1+aA FjpA== 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=0+MLvmp5hqqU8S4irNLIflzCOWbaXZXKlBRHbGJqm7M=; b=iBNuM2vwbpmBz59i/umEAYAcQQoEy8U7bVn4gGx5/qeqR85rkoG04ZEf/rYFxGjIqY ZgM/27xyxnaVkX3fNRFoTcWPDUPkChr1ddyVXKdT4ZbklI0z7SGMYkjpqmA8bxp7fuUu k2exJd43Xw5Cith88/nX+4b3s4S3A0Fucwg9L1lZ1cGFmvv5LluAhBab1fUUtK6NPvZc UkKzJbmOYW4C3eHqHnAP6VtOKfO0bYkA8sSULihhnjI+FUjHgAdcj7Bo+e8/6wWv7Yo5 h1ecZysJX7kU8s9X6yaNbQL1XN750xHmnlZibxyZgHWSkPZlYftXihBaxCndxSLZFpZu 7I6A== X-Gm-Message-State: AOAM531qdBjn+NjEHQNjOUWoljgriqWNEHTutGAf+M+I2GCgUU8GT+lD 80cc5IT0Apj/F6+ZoeAPspr3ZsfMBZRTPxiPgvQzV6Cs X-Google-Smtp-Source: ABdhPJz046/ssWc5DwdVAaNJqvdjRY7Savh6y9S8nTN+Xh+nC3dY7MDJx9CIvGjwHr1gM3Jwpfn8H5nRSks1vwIpY6k= X-Received: by 2002:ab0:217:: with SMTP id 23mr46117116uas.51.1594286471963; Thu, 09 Jul 2020 02:21:11 -0700 (PDT) MIME-Version: 1.0 References: <159423577963.26106.8547442088755899406@ietfa.amsl.com> <3D6604F1-E541-473F-9D18-22D2A41A489C@vigilsec.com> In-Reply-To: <3D6604F1-E541-473F-9D18-22D2A41A489C@vigilsec.com> From: Ines Robles Date: Thu, 9 Jul 2020 12:20:41 +0300 Message-ID: To: Russ Housley Cc: IETF Gen-ART , draft-ietf-lamps-rfc7030est-clarify.all@ietf.org, last-call@ietf.org, SPASM Content-Type: multipart/alternative; boundary="000000000000d4ea0905a9febe04" Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-rfc7030est-clarify-08 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 09 Jul 2020 09:21:15 -0000 --000000000000d4ea0905a9febe04 Content-Type: text/plain; charset="UTF-8" Hi Russ, Thank you very much for your reply, Best, Ines On Wed, Jul 8, 2020 at 10:37 PM Russ Housley wrote: > Ines: > > Thanks for the very carful review. I'll tackle the ones about the ASN.1... > > 4- Appendix A: In id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= {...} > > 4.1- pkcs9(9) should be pkcs-9(9) ? > > > Both are used in different modules. They have become synonyms. That > said, we should pick one, and the use it in the two places where this is > used. > > The hyphen is used in RFC 6268, where we import some things, so I suggest > we use the hyphen here too. > > > 4.2- aa(2) should be id-aa(2) ? > > > No. This one is correct. > > Russ > > > --000000000000d4ea0905a9febe04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Russ,

Thank you very much for your r= eply,

Best,

Ines

On = Wed, Jul 8, 2020 at 10:37 PM Russ Housley <housley@vigilsec.com> wrote:
= Ines:

Thanks for the very carful review.=C2=A0 I'll = tackle the ones about the ASN.1...

4- Appendix A: In= id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::=3D {...}

4= .1- =C2=A0=C2=A0pkcs9(9) should be pkcs-9(9) ?

Both are used in different modules.=C2=A0 T= hey have become synonyms.=C2=A0 That said, we should pick one, and the use = it in the two places where this is used.

The hyphe= n is used in RFC=C2=A06268, where we import some things, so I suggest we us= e the hyphen here too.


4.2- =C2=A0=C2= =A0aa(2) should be id-aa(2) ?

No.=C2=A0 This one is correct.

Russ

--000000000000d4ea0905a9febe04-- From nobody Thu Jul 9 02:44:11 2020 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 DEE2B3A09EB for ; Thu, 9 Jul 2020 02:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4isrtaMgJg2 for ; Thu, 9 Jul 2020 02:44:07 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 00C8E3A09E9 for ; Thu, 9 Jul 2020 02:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1594287845; d=isode.com; s=june2016; i=@isode.com; bh=pfYgv60DMLT4clTi8jh3OcyN64ZZ3vNwqvZ75EU8b50=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=SHvx9MR/6NxgRHzoWO4PwZEUgI97M8lsHnowdRMyZ952GnfBmcAGnJkixeEWU6ChdKePj8 0tADTQO9ecglw3j2/vjIT8IPrl1CG42oNPMhOO65uQyZV+rTGtyHTlupqvo1wKuBdFhgb6 QKciuo6dIVOhxOIEEVCMdf97sI0rmWs=; Received: from [192.168.1.222] (host81-151-37-172.range81-151.btcentralplus.com [81.151.37.172]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 9 Jul 2020 10:44:05 +0100 To: Bernie Hoeneisen , Daniel Kahn Gillmor Cc: IETF LAMPS WG References: <87ftj3pczs.fsf@fifthhorseman.net> From: Alexey Melnikov Message-ID: <63b2a258-b471-084a-37dc-695f6de2fb75@isode.com> Date: Thu, 9 Jul 2020 10:43:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------8CA5C91DAB121BB1F459F4EF" Content-Language: en-GB Archived-At: Subject: Re: [lamps] Common Protected Header practice documented (was "Memory Hole") X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 09 Jul 2020 09:44:10 -0000 --------------8CA5C91DAB121BB1F459F4EF Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Bernie, Just to close the loop on this: On 14/06/2020 15:10, Bernie Hoeneisen wrote: > Hi Daniel > > Thanks for this great document! I was finally able to read and assess=20 > it. I believe it is quite useful to assist in finding a solution for=20 > our chartered work item on Header Protection. > > I have some questions related to the S/MIME examples: > > 1) The examples you provide for S/MIME have a simple structure, i.e.=20 > the body consist of a single MIME entity. How would an example look=20 > with the solution your are proposing, if it was a tree of MIME=20 > entities (e.g. text and html as multipart/alternative)? > > 2) In the examples (e.g. 9.2.) you are using "Content-Type:=20 > text/plain", however the content appears to be a full "message/rfc822"=20 > email. To me this looks like a mismatch between Media-Type and=20 > Content. To my understanding, whatever is in "Content-Type:=20 > text/plain" is unformated and is not guaranteed to be parsable.=20 > However your proposal suggests to parse this to replace the outer=20 > header fields. Have I misunderstood anything? So the protected body part in that example is: =C2=A0Content-Type: text/plain; charset=3D"us-ascii"; protected-headers= =3D"v1" From: Alice Lovelace To: Bob Babbage Date: Tue, 26 Nov 2019 20:03:00 -0400 Subject: The FooCorp contract Message-ID: Bob, we need to cancel this contract. Please start the necessary processes to make that happen today. (this is the 'smime-multipart-signed' message) Thanks, Alice -- Alice Lovelace President Example Corp This is a correct body part (using RFC 2045 terminology) of media type=20 "text/plain". Presence of "From" or "Subject" doesn't change its media=20 type. BNF for body part header is described in Section 3 of RFC 2045: =C2=A0=C2=A0=C2=A0=C2=A0 MIME-part-headers :=3D entity-headers =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 = [ fields ] =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 = ; Any field not beginning with =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 = ; "content-" can have no defined =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 = ; meaning and may be ignored. =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 = ; The ordering of the header =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 = ; fields implied by this BNF =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 = ; definition should be ignored. Best Regards, Alexey > Looking forward to your answer! > > cheers, > =C2=A0Bernie > > --=20 > > http://ucom.ch/ > Modern Telephony Solutions and Tech Consulting for Internet Technology > > > On Mon, 4 Nov 2019, Daniel Kahn Gillmor wrote: > >> Hey LAMPS folks-- >> >> At (and shortly after) the OpenPGP e-mail summit [0], a group of MUA >> developers went ahead and documented the way that several of us have >> been handling header protection in a backward-compatible way. >> >> This bundle of techniques used to be known as "Memory Hole" a while back >> but for a couple years now we've been calling it just "Protected >> Headers", since "Memory Hole" was confusing and weird for some people. >> >> Hopefully this document can serve as input for appendix A.1.1 of >> draft-ietf-lamps-header-protection-requirements-01 [1]. >> >> The new draft is at: >> >> https://datatracker.ietf.org/doc/draft-autocrypt-lamps-protected-headers/ >> >> (it's "draft-autocrypt-=E2=80=A6" because it's not a single-person draft,= and >> because most of the experience we have in this comes from >> implementations actively engaged in the Autocrypt project [2]. But it is >> not a formal part of the Autocrypt specifications at this time, and it >> is not intended to ever be limited to Autocrypt implementations.) >> >> To whet your appetite, the summary: >> >> ------- >> =C2=A0 The Protected Headers scheme relies on three backward-compatible >> =C2=A0 changes to a cryptographically-protected e-mail message: >> >> =C2=A0 *=C2=A0 Headers known to the composing MUA at message composition = time are >> =C2=A0=C2=A0=C2=A0=C2=A0 (in addition to their typical placement as Expos= ed Headers on the >> =C2=A0=C2=A0=C2=A0=C2=A0 outside of the message) also present in the MIME= header of the >> =C2=A0=C2=A0=C2=A0=C2=A0 root of the Cryptographic Payload.=C2=A0 These P= rotected Headers share >> =C2=A0=C2=A0=C2=A0=C2=A0 cryptographic properties with the rest of the Cr= yptographic >> =C2=A0=C2=A0=C2=A0=C2=A0 Payload. >> >> =C2=A0 *=C2=A0 When the Cryptographic Envelope includes encryption, any E= xposed >> =C2=A0=C2=A0=C2=A0=C2=A0 Header MAY be _obscured_ by a transformation (in= cluding deletion). >> >> =C2=A0 *=C2=A0 If the composing MUA intends to obscure any user-facing he= aders, >> =C2=A0=C2=A0=C2=A0=C2=A0 it MAY add a decorative "Legacy Display" MIME pa= rt to the >> =C2=A0=C2=A0=C2=A0=C2=A0 Cryptographic Payload which additionally duplica= tes the original >> =C2=A0=C2=A0=C2=A0=C2=A0 values of the obscured user-facing headers. >> >> =C2=A0 When a composing MUA encrypts a message, it SHOULD obscure the >> =C2=A0 "Subject:" header, by using the literal string "..." (three U+002E >> =C2=A0 FULL STOP characters) as the value of the exposed "Subject:" heade= r. >> >> =C2=A0 When a receiving MUA encounters a message with a Cryptographic >> =C2=A0 Envelope, it treats the headers of the Cryptographic Payload as >> =C2=A0 belonging to the message itself, not just the subpart.=C2=A0 In >> =C2=A0 particular, when rendering a header for any such message, the >> =C2=A0 renderer SHOULD prefer the header's Protected value over its Expos= ed >> =C2=A0 value. >> >> =C2=A0 A receiving MUA that understands Protected Headers and discovers a >> =C2=A0 Legacy Display part SHOULD hide the Legacy Display part when >> =C2=A0 rendering the message. >> ------- >> >> Please don't be put off by the draft length -- nearly half of the >> document consists of test vectors that implementers can use to verify >> their ability to consume well-formed, protected-header messages. >> >> I'd be happy to present this work in Singapore if there's space on the >> agenda. >> >> Feedback, critiques, comments, etc, are all welcome. >> >> Regards, >> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --dkg >> >> [0] https://wiki.gnupg.org/OpenPGPEmailSummit201910 >> [1]=20 >> https://tools.ietf.org/html/draft-ietf-lamps-header-protection-requiremen= ts-01#appendix-A.1.1 >> [2] https://autocrypt.org/ >> > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --------------8CA5C91DAB121BB1F459F4EF Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi Bernie,

Just to close the loop on this:

On 14/06/2020 15:10, Bernie Hoeneisen wrote:
Hi Daniel

Thanks for this great document! I was finally able to read and assess it. I believe it is quite useful to assist in finding a solution for our chartered work item on Header Protection.

I have some questions related to the S/MIME examples:

1) The examples you provide for S/MIME have a simple structure, i.e. the body consist of a single MIME entity. How would an example look with the solution your are proposing, if it was a tree of MIME entities (e.g. text and html as multipart/alternative)?

2) In the examples (e.g. 9.2.) you are using "Content-Type: text/plain", however the content appears to be a full "message/rfc822" email. To me this looks like a mismatch between Media-Type and Content. To my understanding, whatever is in "Content-Type: text/plain" is unformated and is not guaranteed to be parsable. However your proposal suggests to parse this to replace the outer header fields. Have I misunderstood anything? 
S=
o the protected body part in that example is:

  =C2=A0Content-Type: text/plain; charset=3D"us-ascii"; protected-headers=3D=
"v1"
   From: Alice Lovelace <alice@smime.example>
   To: Bob Babbage <bob@smime.example>
   Date: Tue, 26 Nov 2019 20:03:00 -0400
   Subject: The FooCorp contract
   Message-ID: <smime-multipart-signed@protected-=
headers.example>

   Bob, we need to cancel this contract.

   Please start the necessary processes to make that happen today.

   (this is the 'smime-multipart-signed' message)

   Thanks, Alice
   --
   Alice Lovelace
   President
   Example Corp

This is a correct body part (using RFC 2045 terminology) of media type "text/plain". Presence of "From" or "Subject" doesn't change its media type. BNF for body part header is described in Section 3 of RFC 2045:

=C2=A0=C2=A0=C2=A0=C2=A0 MIME-part-headers :=3D entity-headers
=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 [ fields ]
=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 ; Any field not beginning with
=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 ; "content-" can have no defined
=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 ; meaning and may be ignored.
=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 ; The ordering of the header
=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 ; fields implied by this BNF
=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 ; definition should be ignored.

Best Regards,

Alexey

Looking forward to your answer!

cheers,
=C2=A0Bernie

--

http://uco= m.ch/
Modern Telephony Solutions and Tech Consulting for Internet Technology


On Mon, 4 Nov 2019, Daniel Kahn Gillmor wrote:

Hey LAMPS folks--

At (and shortly after) the OpenPGP e-mail summit [0], a group of MUA
developers went ahead and documented the way that several of us have
been handling header protection in a backward-compatible way.

This bundle of techniques used to be known as "Memory Hole" a while back
but for a couple years now we've been calling it just "Protected
Headers", since "Memory Hole" was confusing and weird for some people.

Hopefully this document can serve as input for appendix A.1.1 of
draft-ietf-lamps-header-protection-requirements-01 [1].

The new draft is at:

=C2=A0=C2=A0 https://datatracker.ietf.org/doc/d= raft-autocrypt-lamps-protected-headers/

(it's "draft-autocrypt-=E2=80=A6" because it's not a single-person draft, and
because most of the experience we have in this comes from
implementations actively engaged in the Autocrypt project [2]. But it is
not a formal part of the Autocrypt specifications at this time, and it
is not intended to ever be limited to Autocrypt implementations.)

To whet your appetite, the summary:

-------
=C2=A0 The Protected Headers scheme relies on three backward-compatible
=C2=A0 changes to a cryptographically-protected e-mail message:

=C2=A0 *=C2=A0 Headers known to the composing MUA at message composi= tion time are
=C2=A0=C2=A0=C2=A0=C2=A0 (in addition to their typical placement as = Exposed Headers on the
=C2=A0=C2=A0=C2=A0=C2=A0 outside of the message) also present in the= MIME header of the
=C2=A0=C2=A0=C2=A0=C2=A0 root of the Cryptographic Payload.=C2=A0 Th= ese Protected Headers share
=C2=A0=C2=A0=C2=A0=C2=A0 cryptographic properties with the rest of t= he Cryptographic
=C2=A0=C2=A0=C2=A0=C2=A0 Payload.

=C2=A0 *=C2=A0 When the Cryptographic Envelope includes encryption, = any Exposed
=C2=A0=C2=A0=C2=A0=C2=A0 Header MAY be _obscured_ by a transformatio= n (including deletion).

=C2=A0 *=C2=A0 If the composing MUA intends to obscure any user-faci= ng headers,
=C2=A0=C2=A0=C2=A0=C2=A0 it MAY add a decorative "Legacy Display" MI= ME part to the
=C2=A0=C2=A0=C2=A0=C2=A0 Cryptographic Payload which additionally du= plicates the original
=C2=A0=C2=A0=C2=A0=C2=A0 values of the obscured user-facing headers.

=C2=A0 When a composing MUA encrypts a message, it SHOULD obscure th= e
=C2=A0 "Subject:" header, by using the literal string "..." (three U+002E
=C2=A0 FULL STOP characters) as the value of the exposed "Subject:" header.

=C2=A0 When a receiving MUA encounters a message with a Cryptographi= c
=C2=A0 Envelope, it treats the headers of the Cryptographic Payload as
=C2=A0 belonging to the message itself, not just the subpart.=C2=A0 = In
=20 =C2=A0 particular, when rendering a header for any such message, t= he
=C2=A0 renderer SHOULD prefer the header's Protected value over its Exposed
=C2=A0 value.

=C2=A0 A receiving MUA that understands Protected Headers and discovers a
=C2=A0 Legacy Display part SHOULD hide the Legacy Display part when
=C2=A0 rendering the message.
-------

Please don't be put off by the draft length -- nearly half of the
document consists of test vectors that implementers can use to verify
their ability to consume well-formed, protected-header messages.

I'd be happy to present this work in Singapore if there's space on the
agenda.

Feedback, critiques, comments, etc, are all welcome.

Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --dkg

[0] https://wiki.gnupg.org/OpenPGPEmailSummit201910<= /a>
[1] https://tools.= ietf.org/html/draft-ietf-lamps-header-protection-requirements-01#appendix-A.= 1.1
[2] https://autocrypt.org/ 


_______________________________=
________________
Spasm mailing list
Spasm@i=
etf.org
https://www.ietf.org/mailman/listinfo/spasm
--------------8CA5C91DAB121BB1F459F4EF-- From nobody Thu Jul 9 03:50:27 2020 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 5542F3A086D for ; Thu, 9 Jul 2020 03:50:25 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJ_hjwntB4pw for ; Thu, 9 Jul 2020 03:50:23 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [IPv6:2a01:4f8:c0c:15fc::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 56DC13A086C for ; Thu, 9 Jul 2020 03:50:22 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jtU8B-000E6R-UH; Thu, 09 Jul 2020 12:50:19 +0200 Date: Thu, 9 Jul 2020 12:50:19 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Alexey Melnikov cc: Daniel Kahn Gillmor , IETF LAMPS WG In-Reply-To: <63b2a258-b471-084a-37dc-695f6de2fb75@isode.com> Message-ID: References: <87ftj3pczs.fsf@fifthhorseman.net> <63b2a258-b471-084a-37dc-695f6de2fb75@isode.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1968544834-1594291819=:29104" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Archived-At: Subject: Re: [lamps] Common Protected Header practice documented (was "Memory Hole") X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 09 Jul 2020 10:50:25 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1968544834-1594291819=:29104 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Hi Alexey / Daniel Thanks for your explanations on the 2nd item. The 2nd item has been resolved in the meantime, as it was indeed a misconception on MIME (as mentioned in my question). Rg. the 1st item: To better determine, what advantages and drawbacks the different options have, I (still) believe more examples would be helpful, e.g.: a) A more complicated example for S/MIME (as suggested in my last mail). I guess, this would look like this: └─╴application/pkcs7-mime smime-type="enveloped-data" ↧ (decrypts to) └─╴application/pkcs7-mime smime-type="signed-data" ⇩ (unwraps to) └┬╴multipart/mixed ← Cryptographic Payload ├┬╴multipart/alternative │├─╴text/plain │└─╴text/html └─╴text/x-diff ← attachment b) More examples that use media type "message/rfc822" as per RFC 8551 (and the first option in our upcoming I-D). Something along the lines of: └─╴application/pkcs7-mime smime-type="enveloped-data" ↧ (decrypts to) └─╴application/pkcs7-mime smime-type="signed-data" ⇩ (unwraps to) └┬╴message/rfc822 ← Cryptographic Payload └┬╴multipart/mixed ├┬╴multipart/alternative │├─╴text/plain │└─╴text/html └─╴text/x-diff ← attachment c) More examples that use media type "message/rfc822" as per RFC 8551 and legacy display part. Something along the lines of: └─╴application/pkcs7-mime smime-type="enveloped-data" ↧ (decrypts to) └─╴application/pkcs7-mime smime-type="signed-data" ⇩ (unwraps to) └┬╴multipart/mixed ← Cryptographic Payload ├─╴text/plain ← Legacy Display Part └┬╴message/rfc822 └┬╴multipart/mixed ├┬╴multipart/alternative │├─╴text/plain │└─╴text/html └─╴text/x-diff ← attachment (Similar examples for PGP would also be helpful.) @Daniel: Would you be able to provide such examples (similarly as in your I-D) that can be tested with different MIME Parsers and MUAs? cheers Bernie PS: I hope the UTF-8 character used above display well in all your MUAs... On Thu, 9 Jul 2020, Alexey Melnikov wrote: > > Hi Bernie, > > Just to close the loop on this: > > On 14/06/2020 15:10, Bernie Hoeneisen wrote: > Hi Daniel > > Thanks for this great document! I was finally able to read and assess it. I believe it is quite useful to assist in finding a solution for our chartered work item on Header Protection. > > I have some questions related to the S/MIME examples: > > 1) The examples you provide for S/MIME have a simple structure, i.e. the body consist of a single MIME entity. How would an example look with the solution your are proposing, if it was a tree of MIME entities (e.g. > text and html as multipart/alternative)? > > 2) In the examples (e.g. 9.2.) you are using "Content-Type: text/plain", however the content appears to be a full "message/rfc822" email. To me this looks like a mismatch between Media-Type and Content. To my > understanding, whatever is in "Content-Type: text/plain" is unformated and is not guaranteed to be parsable. However your proposal suggests to parse this to replace the outer header fields. Have I misunderstood > anything? > > So the protected body part in that example is: > >  Content-Type: text/plain; charset="us-ascii"; protected-headers="v1" > From: Alice Lovelace > To: Bob Babbage > Date: Tue, 26 Nov 2019 20:03:00 -0400 > Subject: The FooCorp contract > Message-ID: > > Bob, we need to cancel this contract. > > Please start the necessary processes to make that happen today. > > (this is the 'smime-multipart-signed' message) > > Thanks, Alice > -- > Alice Lovelace > President > Example Corp > > This is a correct body part (using RFC 2045 terminology) of media type "text/plain". Presence of "From" or "Subject" doesn't change its media type. BNF for body part header is described in Section 3 of RFC 2045: > >      MIME-part-headers := entity-headers >                           [ fields ] >                           ; Any field not beginning with >                           ; "content-" can have no defined >                           ; meaning and may be ignored. >                           ; The ordering of the header >                           ; fields implied by this BNF >                           ; definition should be ignored. > > Best Regards, > > Alexey --8323329-1968544834-1594291819=:29104-- From nobody Sat Jul 11 01:02:25 2020 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 822993A07F3; Sat, 11 Jul 2020 01:02:14 -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: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <159445453446.20966.14795842561841514204@ietfa.amsl.com> Date: Sat, 11 Jul 2020 01:02:14 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-lightweight-cmp-profile-02.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 11 Jul 2020 08:02:15 -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 : Lightweight CMP Profile Authors : Hendrik Brockhaus Steffen Fries David von Oheimb Filename : draft-ietf-lamps-lightweight-cmp-profile-02.txt Pages : 77 Date : 2020-07-11 Abstract: The goal of this document is to facilitate interoperability and automation by profiling the Certificate Management Protocol (CMP) version 2, the related Certificate Request Message Format (CRMF) version 2, and the HTTP Transfer for the Certificate Management Protocol. It specifies a subset of CMP and CRMF focusing on typical uses cases relevant for managing certificates of devices in many industrial and IoT scenarios. To limit the overhead of certificate management for more constrained devices only the most crucial types of operations are specified as mandatory. To foster interoperability in more complex scenarios, other types of operations are specified as recommended or optional. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-lightweight-cmp-profile/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-lightweight-cmp-profile-02 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-lightweight-cmp-profile-02 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 Sat Jul 11 01:07:39 2020 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 A933B3A080C for ; Sat, 11 Jul 2020 01:07: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.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 93SMmduN1L8c for ; Sat, 11 Jul 2020 01:07:34 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60066.outbound.protection.outlook.com [40.107.6.66]) (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 4AED43A080A for ; Sat, 11 Jul 2020 01:07:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ab1BOFVgWqQiJseseUyqn2LoFP5LIiYjalKVXGfksyKqoMiUty8us6NEowmLOw2EWIOb2bECLUummjHmiA3nQabwv7wMGxdX+u475jVMD6YQKeIZZ8hAKkgUAxRqBBBBG+AV9xxC0EB9W8sbTtsadwRhlIBP7mK+Zrmu0SDn47+AEgI70NLaubdoXjNviRWnAWuzP8lcrwyghOlPTBqyxWE9Du5qHTljOLeEKxNWIMjXy5m5W9o3ZStSBPuWKYvaSA1ERnVGR3/GoX1OSMzbQD0ofrouXcdxyCInrWnWwnmx9vjNmEV6qVep9We/Sruu+dkOO6CmHdu32u8/YRPztw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I84m80dajKvQMTjt8VXMViOeEfUOE2iu2Q9ItoWudBE=; b=Yvd3RY2ghWLlhdp8n4N/j/ZJzrMdMDWGPNXuurkNjhT7shj8MtFmU5Ogg4uufwzxg+kzFnF/C3ozuwo/Zz3/FVCPXW+33cgT+H2GeAUA5eZiUgnXptKf5gbluSz7QmLs9gzA7JWuOmNBLmaaPGjYjnIgJMSwtbMopE5RSYvFAThhAI2/Zo9MLMZ6o1kTr3dP7qB3gM4HvGtZlSyD64NSJwlxgmRIpkCfbTo64/SDdfzszKFi5QmjW5kLTO1WgEdvQRuupqNbVyJZuhKhBci1Pf9bsw55tEVk40qjC+IvsafuzMaVunztGdzbQDec/X9KA304ayJg3IsXS+AUNZopLA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I84m80dajKvQMTjt8VXMViOeEfUOE2iu2Q9ItoWudBE=; b=IOMWhCgebdOfHri8gK0L0ykE7OZw9tIdQmb8Gugx8jwk6rz6JLyc0dNAu4St+f/ZSAv+0pFcP1XWyi62idGUxsLep3YRp7R2r3WVXns6hlyn83hW0pfCyuF/qSo+WoowfBggOwqGoR+dHdntFsISBpBknojTQ8wpRdn+x6iSYHQ= Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:184::10) by AM0PR10MB3473.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:151::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.20; Sat, 11 Jul 2020 08:07:30 +0000 Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::c5d3:8347:4ebd:93da]) by AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::c5d3:8347:4ebd:93da%3]) with mapi id 15.20.3174.024; Sat, 11 Jul 2020 08:07:30 +0000 From: "Brockhaus, Hendrik" To: "spasm@ietf.org" Thread-Topic: [lamps] I-D Action: draft-ietf-lamps-lightweight-cmp-profile-02.txt Thread-Index: AQHWV1m79YpYKHplg02OOPQVwFM2mqkCBNkw Date: Sat, 11 Jul 2020 08:07:30 +0000 Message-ID: References: <159445453446.20966.14795842561841514204@ietfa.amsl.com> In-Reply-To: <159445453446.20966.14795842561841514204@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.170] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: dd6f3c67-7ef1-43f5-a300-08d8257175af x-ms-traffictypediagnostic: AM0PR10MB3473: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gRfAu1v8DgcFdJCTA3NDYcvyLBJ2gr7PjbQv+54rdvxra0bmgG9EZlcr5aBcRh35DVBaYeEG4WMr1d7jwppRGmTP41bD1waXrTLxml90QV4J7hadkmMMxZ2Jp6Fi+Y3EmFVMfamI8XKSBdBmRAQrxn2ZjYYE6qB2pFphFNbg3vPP0GmC6OhbrhxW5MBqlwOASh5iE4s9fNbiSMQzGdVTo9eQzyYKYwCfuVYJDyD7Rem50z1J9S7OhYT6tkcOgk4mkaPXdwgMnV8esMmhmjlb5Lxi2xYIHAqvKkqIn75AgDvYCOnIYVem60Rv208/ATsc0FDKoiN5hWqkDmd/L4rDlXkzQnAQzHlUIMc7LhluxP5i/yKdGbBGFxERxmNlkZVBrD1ojRxdZgDO1kCIj0mqHQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(346002)(136003)(39860400002)(376002)(9686003)(186003)(33656002)(71200400001)(8676002)(66946007)(66476007)(76116006)(64756008)(66446008)(66556008)(45080400002)(86362001)(5660300002)(478600001)(52536014)(8936002)(316002)(2906002)(7696005)(83380400001)(26005)(83080400001)(966005)(55236004)(55016002)(66574015)(6916009)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: EdVoyYUas41y2iM4PjAohcA9NyfnmH/eZI2QWPu0dXG3dsRxSkxGj9O+NlbAFpz8ZbIoycy+E5Y41xnKkRy5X4dP1DVifdUunuMHFo+ARnknZkd3v1HdZvHZGiHbaK9D2QLQXlnfWDUi8JK8XrQ2OefbWHVcXCZnwjVv3J0nOLrrVMJ2CQNS8Dho1NmdKR7bEJ+SidX2FPSQPc/BSToqNMmhZ1M6jEUtP9bp86fgBj2H7jB5ohMkjjmKn+/WQ5YAU1Mzot2NIkvq0KbpwC1ZJEpzG3pjF2iOcIrrZA64Sjify5KsTG7j6ZY4xHCnShp0Ox+nhRk+BrR2pbzGX+GiE3zAmQAhIcxdYCp7n06PkirA7OW359ROE0tKQ6ORx9uQAMgunCTnJubD0rMEzU0DT4Rzksai5dSozo+JQSmqfNimAeibZkM+HUZ9axU4Ro0PBU7CZ5FjzFKPhg9nRKvsZ7TT0iIClKfj6Rl98H1LiP7bMDtuiNEYodLo9294YsBL x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: dd6f3c67-7ef1-43f5-a300-08d8257175af X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2020 08:07:30.7856 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: p58tFEBElfqHjpiA61OkUJuRte+ZUlYbFj78MTbknz5Ni4MPMWGRkwGkWvXMvVUjr2t2LQLsdLeY8zrhl6rOEp3Ec8ZzGZLL3nV6f6PSs8w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB3473 Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-lightweight-cmp-profile-02.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 11 Jul 2020 08:07:37 -0000 I just submitted an update to the Lightweight CMP Profile draft with the=20 following changes. The changes mainly address the action items I took=20 from IETF 107 and the following discussion on the mailing list. - Hendrik Changes from version 01 -> 02 of the document: o Extend Section 1.4 with regard to conflicts with UNISIG Subset- 137. o Minor clarifications on extraCerts in Section 3.3 and Section 4.1.1. o Complete specification of requesting a certificate from a trusted PKI with signature protection in Section 4.1.2. o Changed from symmetric key-encryption to password-based key management technique in section Section 4.1.6.3 as discussed on the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- profile-01, section 5.1.6.1") o Changed delayed enrollment described in Section 4.1.7 from recommended to optional as decided at IETF 107 o Introduced the new RootCAKeyUpdate structure for root CA certificate update in Section 4.4.3 as decided at IETF 107 (also see email thread "draft-ietf-lamps-lightweight-cmp-profile-01, section 5.4.3") o Extend the description of the CertReqTemplate PKI management operation, including an example added in the Appendix. Keep rsaKeyLen as a single integer value in Section 4.4.4 as discussed on the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- profile-01, section 5.4.4") o Deleted Sections "Get certificate management configuration" and "Get enrollment voucher" as decided at IETF 107 o Complete specification of adding an additional protection by an PKI management entity in Section 5.1.3. o Added Section 6.1 and extended Section 6.2 on definition and discovery of supported HTTP URIs and content types, add a path for nested messages as specified in Section 5.1.3 and delete the paths for /getCertMgtConfig and /getVoucher o Changed Section 6.5 to address offline transport and added more detailed specification file-based transport of CMP o Added a reference to the new I-D of Mohit Sahni on "CoAP Transport for CMPV2" in Section 6.6; thanks to Mohit supporting the effort to ease utilization of CMP o Moved the change history to the Appendix o Minor changes in wording > -----Urspr=FCngliche Nachricht----- > Von: Spasm Im Auftrag von internet-drafts@ietf.o= rg > Gesendet: Samstag, 11. Juli 2020 10:02 > An: i-d-announce@ietf.org > Cc: spasm@ietf.org > Betreff: [lamps] I-D Action: draft-ietf-lamps-lightweight-cmp-profile-02.= txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Limited Additional Mechanisms for PKIX a= nd > SMIME WG of the IETF. >=20 > Title : Lightweight CMP Profile > Authors : Hendrik Brockhaus > Steffen Fries > David von Oheimb > Filename : draft-ietf-lamps-lightweight-cmp-profile-02.txt > Pages : 77 > Date : 2020-07-11 >=20 > Abstract: > The goal of this document is to facilitate interoperability and > automation by profiling the Certificate Management Protocol (CMP) > version 2, the related Certificate Request Message Format (CRMF) > version 2, and the HTTP Transfer for the Certificate Management > Protocol. It specifies a subset of CMP and CRMF focusing on typical > uses cases relevant for managing certificates of devices in many > industrial and IoT scenarios. To limit the overhead of certificate > management for more constrained devices only the most crucial types > of operations are specified as mandatory. To foster interoperability > in more complex scenarios, other types of operations are specified as > recommended or optional. >=20 >=20 > The IETF datatracker status page for this draft is: > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= rack > er.ietf.org%2Fdoc%2Fdraft-ietf-lamps-lightweight-cmp- > profile%2F&data=3D02%7C01%7Chendrik.brockhaus%40siemens.com%7Cc6 > e897875d7344a51caa08d82570dd13%7C38ae3bcd95794fd4addab42e1495d55a > %7C1%7C0%7C637300513959254187&sdata=3DZJhcpZ44SoKZkhINz4yn2i%2F > Kou9Uy4vndrHZYFogx0M%3D&reserved=3D0 >=20 > There are also htmlized versions available at: > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf. > org%2Fhtml%2Fdraft-ietf-lamps-lightweight-cmp-profile- > 02&data=3D02%7C01%7Chendrik.brockhaus%40siemens.com%7Cc6e897875 > d7344a51caa08d82570dd13%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7 > C0%7C637300513959254187&sdata=3DaOuIi8qGwIkK0fO06z9xMdzrUhLsiK4 > CkT%2FqckGcez8%3D&reserved=3D0 > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= rack > er.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lamps-lightweight-cmp-profile- > 02&data=3D02%7C01%7Chendrik.brockhaus%40siemens.com%7Cc6e897875 > d7344a51caa08d82570dd13%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7 > C0%7C637300513959254187&sdata=3DAwoS3bBV2b2pGqvf332DKmqPgdoN > %2BhluhEPl16HV%2F7w%3D&reserved=3D0 >=20 > A diff from the previous version is available at: > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf. > org%2Frfcdiff%3Furl2%3Ddraft-ietf-lamps-lightweight-cmp-profile- > 02&data=3D02%7C01%7Chendrik.brockhaus%40siemens.com%7Cc6e897875 > d7344a51caa08d82570dd13%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7 > C0%7C637300513959254187&sdata=3DZH3jLWFW4eoLNPSEuxBDPrvz0%2B > mFxXeN4WgQBA1ek7g%3D&reserved=3D0 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > https://eur01.safelinks.protection.outlook.com/?url=3Dftp%3A%2F%2Fftp.iet= f.org% > 2Finternet- > drafts%2F&data=3D02%7C01%7Chendrik.brockhaus%40siemens.com%7Cc6e > 897875d7344a51caa08d82570dd13%7C38ae3bcd95794fd4addab42e1495d55a > %7C1%7C0%7C637300513959254187&sdata=3DQbzf8f9Y09XgOImcJ1Jb0bJT > 62hCUNML4qs0zd84QXw%3D&reserved=3D0 >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf. > org%2Fmailman%2Flistinfo%2Fspasm&data=3D02%7C01%7Chendrik.brockha > us%40siemens.com%7Cc6e897875d7344a51caa08d82570dd13%7C38ae3bcd95 > 794fd4addab42e1495d55a%7C1%7C0%7C637300513959254187&sdata=3DD > dvLeU%2FzV%2BHJ2%2FFXKGO1GEQgrZyW5i5Iy%2FnmhIbUrzk%3D&reser > ved=3D0 From nobody Sun Jul 12 17:56:50 2020 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 ED2E83A00C4; Sun, 12 Jul 2020 17:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, 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 K43j2j5Obcfn; Sun, 12 Jul 2020 17:56:40 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2653A0061; Sun, 12 Jul 2020 17:56:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 65AE6389BC; Sun, 12 Jul 2020 20:53:40 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kM0xSZKyTcQa; Sun, 12 Jul 2020 20:53:39 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 95CC7389BD; Sun, 12 Jul 2020 20:53:39 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A832E795; Sun, 12 Jul 2020 20:56:37 -0400 (EDT) From: Michael Richardson To: Ines Robles cc: gen-art@ietf.org, spasm@ietf.org, last-call@ietf.org, draft-ietf-lamps-rfc7030est-clarify.all@ietf.org In-Reply-To: <159423577963.26106.8547442088755899406@ietfa.amsl.com> References: <159423577963.26106.8547442088755899406@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] [Last-Call] Genart last call review of draft-ietf-lamps-rfc7030est-clarify-08 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jul 2020 00:56:42 -0000 --=-=-= Content-Type: text/plain Ines Robles via Datatracker wrote: > 2- Introduction: "reports from implementers suggest..." It would be nice to add > reference/s here Well, I'm not sure how I can add a reference to private emails. I can ask the implementers to write a public email if that is intended. Please advise. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8LsUUACgkQgItw+93Q 3WWvYwf/etLvaMer+ewB4UrnAkWp4V8opEdcwbrt7d/JXUEpzg4+F1ty8TaG1cd8 QsG7pKQ4EUSUhBamPCMtw5PgUFR8N6wZMygcpxQ61zoSeC8YYdn8AZwRn/AyWW3G UU8ITACO+jmreeoGxEtCmI8WG24BkajMhE0vkjgBU4YzNNae1b5Zh3gxBWHJiF90 hA6z7Mp5fT0MnnFLJcsdH1rHEsFAQi01OGAwWHuoHum4YHbts7BLS9N14icRJvV1 JCIwZMluwEVVPuNdNV/V+GbJAzh48qlLUutLM/HFsR+OxjI7G0AugI8CkGLSFlRW ru6qad7hCw5t2bmycIph4DFEEJevdA== =Of+L -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 12 18:00:55 2020 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 3216F3A00C0; Sun, 12 Jul 2020 18:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, 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 bcdvoPe_G7Me; Sun, 12 Jul 2020 18:00:52 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBBDE3A00B0; Sun, 12 Jul 2020 18:00:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 485AA389BD; Sun, 12 Jul 2020 20:57:52 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SySVqSRKXtnT; Sun, 12 Jul 2020 20:57:50 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E4D2A389BC; Sun, 12 Jul 2020 20:57:49 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 04B6C795; Sun, 12 Jul 2020 21:00:48 -0400 (EDT) From: Michael Richardson To: Ines Robles cc: gen-art@ietf.org, spasm@ietf.org, last-call@ietf.org, draft-ietf-lamps-rfc7030est-clarify.all@ietf.org In-Reply-To: <159423577963.26106.8547442088755899406@ietfa.amsl.com> References: <159423577963.26106.8547442088755899406@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] [Last-Call] Genart last call review of draft-ietf-lamps-rfc7030est-clarify-08 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jul 2020 01:00:54 -0000 --=-=-= Content-Type: text/plain Ines Robles via Datatracker wrote: > 1- It would be nice to add in Terminology section that the document uses the > terminology of RFC7030 and RFC5272 > 2- Introduction: "reports from implementers suggest..." It would be nice to add > reference/s here > 3- Security Considerations: > It would be nice to add smth like "security considerations from RFC7030 applies > also for the clarifications described in this document." done. > 5- IANA Considerations: > It would be nice to add the specific registry that IANA should update. > For example, instead of "IANA is requested to update the "Reference" column for > the Asymmetric Decryption Key Identifier attribute to also include a reference > to > this document." you could add smth like (if applicable): " IANA is requested > to update the registry SMI Security for S/MIME Attributes > (1.2.840.113549.1.9.16.2) " > with the reference of this document as follows: > Decimal - Description -Reference > 54 id-aa-asymmDecryptKeyID [RFC7030] [ThisDocument] > 4- Appendix A: In id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= {...} > 4.1- pkcs9(9) should be pkcs-9(9) ? I have done this as per Russ Housley's suggestion. > 4.2- aa(2) should be id-aa(2) ? I have not done this. This is in version -09. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8Lsj8ACgkQgItw+93Q 3WV/4gf/TS87bigZezN4NdM+JK9SiuejJ66C/o7qBxj104/42fZUhuamycILGc6T NsCe1/kbhOdom/7r/lZBa6Wz6IyIKksZHgJX39tMAAQTBuzT7o6LnQe8umXW/Lse khH7Blygb8Lp/hKYCIgI/gZ7aTTIpoBu71NYIKbLsw6oFbNIefKWLzYCUPFCrhcO mLIbfV1R/MTLtzzJecSamaByTYa/ych/+RpxUN+LkxZr/WuOUHc95UhGVL5tKRdk EoVkddBRJsaD/01V87wjSrtzYCriK2QmIVgtk41K5uXP3RX0lD80A0ElgvXjqy5s YsjYox1yLvoqv/jKcpZkIs1VpxXWTA== =AF5P -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 12 18:06:47 2020 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 086F33A00E4; Sun, 12 Jul 2020 18:06:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.8.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <159460240499.22227.488946692540909068@ietfa.amsl.com> Date: Sun, 12 Jul 2020 18:06:45 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc7030est-clarify-09.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jul 2020 01:06:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1 Authors : Michael Richardson Thomas Werner Wei Pan Filename : draft-ietf-lamps-rfc7030est-clarify-09.txt Pages : 14 Date : 2020-07-12 Abstract: This document updates RFC7030: Enrollment over Secure Transport (EST) to resolve some errata that were reported, and which has proven to cause interoperability issues when RFC7030 was extended. This document deprecates the specification of "Content-Transfer- Encoding" headers for EST endpoints. This document fixes some syntactical errors in ASN.1 that were presented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7030est-clarify/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc7030est-clarify-09 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc7030est-clarify-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc7030est-clarify-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 12 23:52:47 2020 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 5A9DE3A0E16; Sun, 12 Jul 2020 23:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-tjSPxBydPM; Sun, 12 Jul 2020 23:52:36 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 545463A0E12; Sun, 12 Jul 2020 23:52:36 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id q15so6037802vso.9; Sun, 12 Jul 2020 23:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hQvx0icicTV0TnQcup5D6/vB8yJFcVO+5bdCFsieZ7o=; b=ZnosMQHOGRd68jbcxzAM4Ct7k1J5ULz4kh61cFvlbZSS92x4Sx9yCHevudU95Sq/YC ktGIq/ou5PpXqFhNXN4eqAs3lKcyW5p8rhPm0XGlZakTyhvHCgLwHp+l6BdxZwDkgKX0 YW9iasKKGGJJXef7+WGQHcbZZPN839tMceGeCLrsSupG5swZg1Q1eKQspK13kzKZaQTh ISdK4eIxywnew1mCiKItQRfp+tT65jfHN2dPaLEyS31+QkP0fGPFFOEiOvEdVj+AE0sN Wp8WNLfoZkDkJURgAHJR0if0THZquTcsvcNR6Pn1KatniOV9StLMffK2rIIwAQDzHYdR msew== 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=hQvx0icicTV0TnQcup5D6/vB8yJFcVO+5bdCFsieZ7o=; b=F7cjtCDTkur4+9yT4zN9lVjmzetSfKsTihSNYe9dT+HdobLSESJRr54vG0zphNfZXN PapFB13nZPWOCLKoOoVUZGm5p1I3ckMu7WyyaDcD3sqD65TFSYisT2dGvTfvaMKZ/wTi Ca0qSEgF/yzm9LGCtJ01t66ItmpmnYNrG+9nUlDdaNI+jofsWIiTeiJsabtdFTJ1XOqQ e0PZQikRgr+azmY8IV5cEjmy7PHUCMKpUzfcXzWba+/8ze7yOCIpn+6Pq8/A4/3SGyYH fEc0fVUXwYSbu3FfLiadiGR51mohmRHf6TPFvTnrtQrjoH3/R1Ru1Ejr1fBb052MxGyZ 6jXg== X-Gm-Message-State: AOAM533q6Kewyq0WwQz0zOgcqaIDdAGdgYU0QBm3ziD3sZfVbpS7ggXQ M/U/of352Zcx0mUZ1QDvFHva2/23kk/5BT4yRrFU0eE4 X-Google-Smtp-Source: ABdhPJxLXl5nLKful96b0ezpQHT/Mfm9NRyJfhzS2w1lzF/EmIce+HeUu9jHEIPEZk2On5X4d4EWz1eLltwhMhMqG6I= X-Received: by 2002:a67:eac5:: with SMTP id s5mr516012vso.216.1594623155180; Sun, 12 Jul 2020 23:52:35 -0700 (PDT) MIME-Version: 1.0 References: <159423577963.26106.8547442088755899406@ietfa.amsl.com> <17412.1594601797@localhost> In-Reply-To: <17412.1594601797@localhost> From: Ines Robles Date: Mon, 13 Jul 2020 09:52:02 +0300 Message-ID: To: Michael Richardson Cc: IETF Gen-ART , LAMPS , last-call@ietf.org, draft-ietf-lamps-rfc7030est-clarify.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000b7228005aa4d2274" Archived-At: Subject: Re: [lamps] [Last-Call] Genart last call review of draft-ietf-lamps-rfc7030est-clarify-08 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jul 2020 06:52:39 -0000 --000000000000b7228005aa4d2274 Content-Type: text/plain; charset="UTF-8" Hi Michael, Yes, that would be great, if possible. Thank you, Ines On Mon, Jul 13, 2020 at 3:56 AM Michael Richardson wrote: > > Ines Robles via Datatracker wrote: > > 2- Introduction: "reports from implementers suggest..." It would be > nice to add > > reference/s here > > Well, I'm not sure how I can add a reference to private emails. > I can ask the implementers to write a public email if that is intended. > Please advise. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > --000000000000b7228005aa4d2274 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Michael,

Yes, that would be grea= t, if possible.

Thank you,

Ines

On Mon, Jul 13, 2020 at 3:56 AM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Ines Robles via Datatracker <noreply@ietf.org> wrote:
=C2=A0 =C2=A0 > 2- Introduction: "reports from implementers suggest= ..." It would be nice to add
=C2=A0 =C2=A0 > reference/s here

Well, I'm not sure how I can add a reference to private emails.
I can ask the implementers to write a public email if that is intended.
Please advise.


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-



--000000000000b7228005aa4d2274-- From nobody Mon Jul 13 10:28:04 2020 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 2421D3A15E5; Mon, 13 Jul 2020 10:27:58 -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: 7.8.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <159466127810.28477.11631955838258944792@ietfa.amsl.com> Date: Mon, 13 Jul 2020 10:27:58 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-header-protection-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jul 2020 17:27:59 -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 : Header Protection for S/MIME Authors : Bernie Hoeneisen Alexey Melnikov Filename : draft-ietf-lamps-header-protection-00.txt Pages : 27 Date : 2020-07-13 Abstract: Privacy and security issues with email header protection in S/MIME have been identified for some time. However, the desire to fix these issues has only recently been expressed in the IETF LAMPS Working Group. The existing S/MIME specification is to be updated regarding header protection. This document describes the problem statement, generic use cases, and the S/MIME specification for header protection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-header-protection-00 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-header-protection-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 13 15:06:44 2020 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 E2B933A0F97; Mon, 13 Jul 2020 15:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 KNs3zJ5ZISFh; Mon, 13 Jul 2020 15:06:29 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 C40183A0F28; Mon, 13 Jul 2020 15:06:15 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id i4so15177819iov.11; Mon, 13 Jul 2020 15:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Kjka8CMKATro5Q8U9NTyKFn8XrGTUrQn9GE9Y3CiFqI=; b=Wz4hwTTB9TDGCqs7q31q753YmIvPKbW0lcoswL9N58iLP89pBKI1XWZs5SomJ07pN0 giEOkIHzQ7izbNGEldg0bVXQAEekldTZn6j0kiabVg43beCvBebMsNdKbxwKAkKk+rvR APIFRGnfK41DEHz/bQ/VbytSZyCgPdYK1HaC4d81gBPtl7he5pyFj0k2padvGrfykZbt Y5HLu5BXCNG5WmjritaddRx99DNNRnrxQ2RnPbxZX6nKJAHkW7ENLA1YWphq7og9wHzq gQ7hnc+R8PynE7WMJzQcvShcXakHwlcMlrVzz4OtyQM48v52xEvOD7XgleWulN8UuFLa /keQ== 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=Kjka8CMKATro5Q8U9NTyKFn8XrGTUrQn9GE9Y3CiFqI=; b=f3mWtEijrbdEkqBXotEnEhOj5T3VxO8uaUtveSvxoWu0Gup6Im8T9lY07MtS126DR1 l7/na6JOLQd3LEVCxOio6BHQtxheg6Bs9icVkZF3v61E1EU12LG3hUeL8PM55+oou/Y1 3lQEYdLjkxjej3RySWbqOI8+XPCDpvR31vAbaIRlS8+E+f57xM1K7plXX4tjaQ8ybLws D7QCVDdcO0peZLi2K8VlF7VqYxKYhhROaK3tqb2boUdmWahAIUr//cmY9kLKwGw4fHv2 P9c3yqhUQmVu4RbdAng+FOQCdCTE7Mp6p40EPUVyUZb+CABCdE2jgV0gle6uPTa8aXio lcpg== X-Gm-Message-State: AOAM532FbjFadi4dbMRDd3Dfp5ZBOSdaTNKOIET02eAgjArOtPZ2RUoH TqtoP9tISprNcVgGnzkLi8Oz8PmR27GkHVbzBRA= X-Google-Smtp-Source: ABdhPJzi0kwmwabLDCmkkc2tWEhKsIJRKpSu0IgY1p0RtUSzriD5PZVcsNWmDWcQoTFJsz8TQTBj5OE8c7p45axYzSM= X-Received: by 2002:a02:a008:: with SMTP id a8mr2397227jah.68.1594677974010; Mon, 13 Jul 2020 15:06:14 -0700 (PDT) MIME-Version: 1.0 References: <1978e1d6-ae62-1b85-1e70-062aee0fcc89@primekey.se> <000101d63ba8$d9cd4020$8d67c060$@augustcellars.com> In-Reply-To: From: Mohit Sahni Date: Mon, 13 Jul 2020 15:06:03 -0700 Message-ID: To: Jim Schaad Cc: LAMPS WG , ace@ietf.org, "Brockhaus, Hendrik" Content-Type: multipart/alternative; boundary="0000000000002c129605aa59e666" Archived-At: Subject: Re: [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jul 2020 22:06:39 -0000 --0000000000002c129605aa59e666 Content-Type: text/plain; charset="UTF-8" Hi All I have published the first draft for the document here is the link to the draft https://datatracker.ietf.org/doc/draft-msahni-ace-cmpv2-coap-transport/ . As Jim mentioned that adopting this might need change in the ACE WG charter can we please discuss that in IETF 108 ? Thanks Mohit On Sat, Jun 6, 2020 at 10:01 AM Mohit Sahni wrote: > Hi Jim, > Thanks for the feedback. I will go over the EST document and update > sections around DTLS and proxying and address your other comments. Once > ready, I will post the draft in ACE WG. > > Regards, > Mohit > > > On Fri, Jun 5, 2020 at 7:19 PM Jim Schaad wrote: > >> I suppose that this could go into the ACE working group, but it will >> require a charter change to do so. >> >> >> >> I would suggest that you review the EST document with special attention >> to the sections on DTLS and proxying. It would also help to have some idea >> of guidance for when coap or coaps is going to be used. I am not sure that >> this strongly exists in CMP as my very vague memory was that it was assumed >> that all transactions where going to be done over TLS with server >> validation as a minimum. >> >> >> >> Jim >> >> >> >> >> >> *From:* Spasm *On Behalf Of *Mohit Sahni >> *Sent:* Thursday, June 4, 2020 10:49 PM >> *To:* Tomas Gustavsson >> *Cc:* LAMPS WG >> *Subject:* Re: [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport >> >> >> >> Hi Tomas >> >> Thanks for the feedback, I was trying to write it in a way so that it can >> work for both CMPv2 and LightWeight CMP, I have noted it your feedback and >> I will try to make it more clear. >> >> >> >> -Mohit >> >> >> >> On Thu, Jun 4, 2020 at 10:40 PM Tomas Gustavsson > > wrote: >> >> Hi, >> >> I noticed that section 4, Proxy Support (good section btw), mentions >> Announcement messages. These are excluded from the Lightweight >> specification. Since the LIghtweight specification is mentioned in the >> beginning, I'm not sure if that's worth mentioning here? >> >> Cheers, >> Tomas >> >> On 2020-06-04 20:03, Mohit Sahni wrote: >> > Hi Jim, >> > There were some discussions about using CoAP as transport for the >> > Lightweight CMP profile in the last LAMPS WG meeting. After having some >> > discussions with Hendrik, David, and Andreas I have written an >> > internet-draft for using CoAP as transport for CMPv2 / Light Weight CMP >> > Profile. If I am not mistaken, the recommendation was to present this >> > draft to ACE WG for the review instead of Lamps group, can you please >> > advice on that? >> > >> > Here is the link to the internet-draft that I wrote >> > https://www.ietf.org/id/draft-msahni-tbd-cmpv2-coap-transport-00.txt >> > >> > Thanks >> > Mohit >> > >> > _______________________________________________ >> > 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 >> >> --0000000000002c129605aa59e666 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All
I have published the first dra= ft for the document here is the link to the draft=C2=A0https://dat= atracker.ietf.org/doc/draft-msahni-ace-cmpv2-coap-transport/=C2=A0. As = Jim mentioned that adopting=C2=A0this might need change in the ACE WG chart= er can we please discuss that in IETF 108 ?

Thanks=
Mohit=C2=A0

On Sat, Jun 6, 2020 at 10:01 AM = Mohit Sahni <mohit06jan@gmail.co= m> wrote:
Hi Jim,
Thanks for the feedback. I will go over= the EST document and update sections around DTLS and proxying and address = your other comments. Once ready, I will post the draft in ACE WG.
=
Regards,
Mohit=C2=A0


On Fri, Jun 5, 2020 at 7:19 PM Jim Schaad <ietf@augustcellars.com> wrote:
<= div>

I suppose that this could go into the ACE workin= g group, but it will require a charter change to do so.=C2=A0

=C2=A0

= I would suggest that you review the EST document with special attention to = the sections on DTLS and proxying.=C2=A0 It would also help to have some id= ea of guidance for when coap or coaps is going to be used.=C2=A0 I am not s= ure that this strongly exists in CMP as my very vague memory was that it wa= s assumed that all transactions where going to be done over TLS with server= validation as a minimum.

= =C2=A0

Jim

=C2=A0

=C2=A0

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Mohit Sahni=
Sent: Thursday, June 4, 2020 10:49 PM
To: Tomas Gustav= sson <tomas@prime= key.se>
Cc: LAMPS WG <spasm@ietf.org>
Subject: Re: [lamps] CM= Pv2/LightWeiight-CMP profile over CoAP transport

=C2=A0

Hi= =C2=A0Tomas

Thanks for the fee= dback, I was trying=C2=A0to write it in a way so that it can work for both = CMPv2 and LightWeight CMP, I have noted it your=C2=A0feedback and I will tr= y to make it more clear.

=C2=A0

-Mohit=C2=A0<= /u>

=C2=A0

On Thu, Jun 4, 2020 at 10:40 PM Tomas Gustav= sson <tomas@prime= key..se> wrote:

Hi,

I noticed that section 4, Proxy Support (good s= ection btw), mentions
Announcement messages. These are excluded from the= Lightweight
specification. Since the LIghtweight specification is menti= oned in the
beginning, I'm not sure if that's worth mentioning h= ere?

Cheers,
Tomas

On 2020-06-04 20:03, Mohit Sahni wrote:=
> Hi Jim,
> There were some discussions about using CoAP as tr= ansport for the
> Lightweight CMP profile in the last LAMPS WG meetin= g. After having some
> discussions with Hendrik, David, and=C2=A0Andr= eas I have written an
> internet-draft for using CoAP as transport fo= r CMPv2 / Light Weight CMP
> Profile. If I am not=C2=A0mistaken, the= =C2=A0recommendation was to present this
> draft to ACE WG for the re= view instead of Lamps group, can you please
> advice on that?
>=
> Here is the link to the internet-draft that I wrote
> https://www.ietf.org/id/draft-msahni-tbd-cmpv2-coap-tran= sport-00.txt=C2=A0
>
> Thanks
> Mohit=C2=A0=C2=A0>
> _______________________________________________
> Spas= m mailing list
> = Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm>

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

--0000000000002c129605aa59e666-- From nobody Mon Jul 13 22:54:03 2020 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 A35F33A10E8; Mon, 13 Jul 2020 22:54:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.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 txbsi_uovHrl; Mon, 13 Jul 2020 22:53:59 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2045.outbound.protection.outlook.com [40.107.20.45]) (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 5E34A3A10E7; Mon, 13 Jul 2020 22:53:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bip6AtsySOpFZ8kqdrkydnNlXoZUJAYD4VWmDzur8cX/QMp3LPR5K6iD9LToYKBiAOdZm3ep5IqPji2StrJLF852HN0rOCfqPtneHTvPR1HTUznV5hifhe4fjlPO6R1io1u9D2Byqcs3mlku/33lBlQ8t2ZHRRLT3eC2WEObFsCZMtOgbnwpW51ZpoBc+9fu6Z19ZegvipvGXAOT3vk0ontHmlDfViPoUQe5BZcvciThbQtyQBjiAVHgq9oG2QUp0tV7VFAhHAoqogaOD7jwYegsOq6PrDKao7ZGpyw+2sFawhr2wh6JuIcJETJVyC52+qpFUVB9b1rdEPhjKVRLpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n/h1JZ+pzd94bbMFu/sw4q0kbse6IBxxSHGWsW+jKzI=; b=ZaK9pUhSbQT2e8stE7Kk/1op/fxqh1bOkU0xuW3KZHizDpk/gIcR7vz3NIuVXgvJkJKrBCE0O5RVmkRGLWZIhmVf++N1si+5lxOZA0nfZbHq0nuw1tD7PvzVdA6R/NjoIKa4p9N3epPTrev6q7nhKhPIXrHyO6CxWZ1TihdSC/SIAcZzxJKi2i0Zo2Ov/ca3Yjj7MS8bQjBvLJY+4Wm4LYLPHMpR3vrA7Qb3b48V2g/lzpu3xAmPnW+fCMczPR18IOGH46/NQ5XWzL1V9GkBqFhPPJ76pwT7JfuuW/+ngGsntaxemgYtAW9QGJSEz2xWwNFYEWBBKxJnUHalEHI7cw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n/h1JZ+pzd94bbMFu/sw4q0kbse6IBxxSHGWsW+jKzI=; b=M1RokqOLvsVXHSy5LzdwUonJJ6XTIhxpf7Z9Xi9C6mq7bi34f6S/09jONRCdsIIlEpGPDHg0dqyIPh855iejdXEcHeaP1q6cBV4OmhP670RD23VSXQxFVkTusEzmADZv9OK2kIwLiM9XAwCYZCOh59eGA3qYbUFsvu/5s1lstWM= Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:184::10) by AM0PR10MB2931.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:160::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21; Tue, 14 Jul 2020 05:53:57 +0000 Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::c5d3:8347:4ebd:93da]) by AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::c5d3:8347:4ebd:93da%3]) with mapi id 15.20.3174.026; Tue, 14 Jul 2020 05:53:57 +0000 From: "Brockhaus, Hendrik" To: Mohit Sahni , Jim Schaad CC: LAMPS WG , "ace@ietf.org" Thread-Topic: [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport Thread-Index: AQHWOpqMTaopCwilUkGOk9vnrw2MI6jJgmkAgAACSACAAVfKAIAA9m0AgDp7e4CAAIG8UA== Date: Tue, 14 Jul 2020 05:53:57 +0000 Message-ID: References: <1978e1d6-ae62-1b85-1e70-062aee0fcc89@primekey.se> <000101d63ba8$d9cd4020$8d67c060$@augustcellars.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.178] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 73310bb0-af22-4d8b-ebe7-08d827ba4c6f x-ms-traffictypediagnostic: AM0PR10MB2931: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: m5jF4NKPB3DnJfU6sdJ0B3/W2RUJ61D5SISskW2pcHOG7NQSlRe4MI7jReHUHXBrYD4k3TbuMwuf5s+mAFdxTeaP6/dO1/5JKKIHiuiXeIKrBoo52zYsbHisZLSyTqyeuvm/Grmq0NBCtnBepsxeICd4Bc5GwkbXYV8MMHXLzEH2QY0FWxRt+Ui3OQ4W4qsYNPq18lHpgWXYzoJyPqnS8wa+9vFoRhISD6suxaQE54OmgCYhYzt02D7DWtzAYyaT8gremb1UHTddEAN30WUj4RKHoontoV8Jic4exC+jcdeEkFHRmmQFXiebHZRl9ybuhx3kgeQNAjDCJFTix9QnzOs6g0jtp43vy9vGGh+2R+9UP7uaoxiOYiv6UTjAK0mho5r9tIHphLIW1mr+1tMWqA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(136003)(366004)(396003)(376002)(26005)(186003)(66946007)(66476007)(4326008)(64756008)(966005)(76116006)(19627235002)(66556008)(66446008)(7696005)(86362001)(316002)(6506007)(110136005)(53546011)(54906003)(55236004)(2906002)(83380400001)(8676002)(8936002)(9686003)(55016002)(33656002)(66574015)(45080400002)(71200400001)(478600001)(5660300002)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: PMBYUcI76eBwB5zcZmWt4b1XFNkIlX0mwJWnX2XfYqEZDJcEri3iJgFzhv8l7FReLIUXB4YeRKR67jKkpttMaHdQTjnftKHRlwDsEThDhcuNKf80p/pZSPEN2XYn1gNeQMpJ7qtdcvZTUN5FRbsOSaglVSjkPI4Sa7zSEGpMEOjHuqh5R/KbCt/SqyUcVLmbAcbOgtW3OEBDGNaA2PgYsX2c44eXnGkfJKgnZAOupm0kgYkS6KBSubF4BlMQvqAEvYWjgVTcRu6qgxnGXqJVr9EWyrOCAJXiaE0ZbZoTLVMeeiE0BUjj6s6Z2Mt58NZG+sMWqOAGudeDlxYOsBa4vfS0c9N6GQlyeU2Ul2JIn1zO/AHEAucwf3Iof1vls2dx1vphhFNNMlFAm7zuDhKv5gKrj00diwb/UpolWJVlbDZy73njtN/zyE5LFA84LPt0L+vCtxKEYkbAG+9BF562DKXZddPSfZgsf9X5Q3VlSeICLMCqpkEd0FU+DvGV6eQz x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 73310bb0-af22-4d8b-ebe7-08d827ba4c6f X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2020 05:53:57.2260 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dFT8SPeV5LiICKSEpgXoimgrN1+uaTbGGPoaphW9tC8XuIG3SM9x8fDATl00kLU3ylEB4FLyHl6CMTOKtg7znSqms++yuUbIHhzA8JSNarU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2931 Archived-At: Subject: Re: [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 14 Jul 2020 05:54:02 -0000 TW9oaXQNClRoYW5rcyBmb3IgdGhlIHVwZGF0ZS4gSSdtIGxvb2tpbmcgZm9yd2FyZCB0byB0aGUg ZGlzY3Vzc2lvbiBpbiBBQ0UuDQoNCkhlbmRyaWsNCg0KVm9uOiBNb2hpdCBTYWhuaSA8bW9oaXQw NmphbkBnbWFpbC5jb20+IA0KR2VzZW5kZXQ6IERpZW5zdGFnLCAxNC4gSnVsaSAyMDIwIDAwOjA2 DQoNCkhpIEFsbA0KSSBoYXZlIHB1Ymxpc2hlZCB0aGUgZmlyc3QgZHJhZnQgZm9yIHRoZSBkb2N1 bWVudCBoZXJlIGlzIHRoZSBsaW5rIHRvIHRoZSBkcmFmdCBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1tc2FobmktYWNlLWNtcHYyLWNvYXAtdHJhbnNwb3J0Ly4gQXMgSmlt IG1lbnRpb25lZCB0aGF0IGFkb3B0aW5nwqB0aGlzIG1pZ2h0IG5lZWQgY2hhbmdlIGluIHRoZSBB Q0UgV0cgY2hhcnRlciBjYW4gd2UgcGxlYXNlIGRpc2N1c3MgdGhhdCBpbiBJRVRGIDEwOCA/DQoN ClRoYW5rcw0KTW9oaXTCoA0KDQpPbiBTYXQsIEp1biA2LCAyMDIwIGF0IDEwOjAxIEFNIE1vaGl0 IFNhaG5pIDxtYWlsdG86bW9oaXQwNmphbkBnbWFpbC5jb20+IHdyb3RlOg0KSGkgSmltLA0KVGhh bmtzIGZvciB0aGUgZmVlZGJhY2suIEkgd2lsbCBnbyBvdmVyIHRoZSBFU1QgZG9jdW1lbnQgYW5k IHVwZGF0ZSBzZWN0aW9ucyBhcm91bmQgRFRMUyBhbmQgcHJveHlpbmcgYW5kIGFkZHJlc3MgeW91 ciBvdGhlciBjb21tZW50cy4gT25jZSByZWFkeSwgSSB3aWxsIHBvc3QgdGhlIGRyYWZ0IGluIEFD RSBXRy4NCg0KUmVnYXJkcywNCk1vaGl0wqANCg0KDQpPbiBGcmksIEp1biA1LCAyMDIwIGF0IDc6 MTkgUE0gSmltIFNjaGFhZCA8bWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20+IHdyb3RlOg0K SSBzdXBwb3NlIHRoYXQgdGhpcyBjb3VsZCBnbyBpbnRvIHRoZSBBQ0Ugd29ya2luZyBncm91cCwg YnV0IGl0IHdpbGwgcmVxdWlyZSBhIGNoYXJ0ZXIgY2hhbmdlIHRvIGRvIHNvLsKgIA0KwqANCkkg d291bGQgc3VnZ2VzdCB0aGF0IHlvdSByZXZpZXcgdGhlIEVTVCBkb2N1bWVudCB3aXRoIHNwZWNp YWwgYXR0ZW50aW9uIHRvIHRoZSBzZWN0aW9ucyBvbiBEVExTIGFuZCBwcm94eWluZy7CoCBJdCB3 b3VsZCBhbHNvIGhlbHAgdG8gaGF2ZSBzb21lIGlkZWEgb2YgZ3VpZGFuY2UgZm9yIHdoZW4gY29h cCBvciBjb2FwcyBpcyBnb2luZyB0byBiZSB1c2VkLsKgIEkgYW0gbm90IHN1cmUgdGhhdCB0aGlz IHN0cm9uZ2x5IGV4aXN0cyBpbiBDTVAgYXMgbXkgdmVyeSB2YWd1ZSBtZW1vcnkgd2FzIHRoYXQg aXQgd2FzIGFzc3VtZWQgdGhhdCBhbGwgdHJhbnNhY3Rpb25zIHdoZXJlIGdvaW5nIHRvIGJlIGRv bmUgb3ZlciBUTFMgd2l0aCBzZXJ2ZXIgdmFsaWRhdGlvbiBhcyBhIG1pbmltdW0uDQrCoA0KSmlt DQrCoA0KwqANCkZyb206IFNwYXNtIDxtYWlsdG86c3Bhc20tYm91bmNlc0BpZXRmLm9yZz4gT24g QmVoYWxmIE9mIE1vaGl0IFNhaG5pDQpTZW50OiBUaHVyc2RheSwgSnVuZSA0LCAyMDIwIDEwOjQ5 IFBNDQpUbzogVG9tYXMgR3VzdGF2c3NvbiA8bWFpbHRvOnRvbWFzQHByaW1la2V5LnNlPg0KQ2M6 IExBTVBTIFdHIDxtYWlsdG86c3Bhc21AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2xhbXBzXSBD TVB2Mi9MaWdodFdlaWlnaHQtQ01QIHByb2ZpbGUgb3ZlciBDb0FQIHRyYW5zcG9ydA0KwqANCkhp wqBUb21hcw0KVGhhbmtzIGZvciB0aGUgZmVlZGJhY2ssIEkgd2FzIHRyeWluZ8KgdG8gd3JpdGUg aXQgaW4gYSB3YXkgc28gdGhhdCBpdCBjYW4gd29yayBmb3IgYm90aCBDTVB2MiBhbmQgTGlnaHRX ZWlnaHQgQ01QLCBJIGhhdmUgbm90ZWQgaXQgeW91csKgZmVlZGJhY2sgYW5kIEkgd2lsbCB0cnkg dG8gbWFrZSBpdCBtb3JlIGNsZWFyLg0KwqANCi1Nb2hpdMKgDQrCoA0KT24gVGh1LCBKdW4gNCwg MjAyMCBhdCAxMDo0MCBQTSBUb21hcyBHdXN0YXZzc29uIDxtYWlsdG86dG9tYXNAcHJpbWVrZXku c2U+IHdyb3RlOg0KSGksDQoNCkkgbm90aWNlZCB0aGF0IHNlY3Rpb24gNCwgUHJveHkgU3VwcG9y dCAoZ29vZCBzZWN0aW9uIGJ0dyksIG1lbnRpb25zDQpBbm5vdW5jZW1lbnQgbWVzc2FnZXMuIFRo ZXNlIGFyZSBleGNsdWRlZCBmcm9tIHRoZSBMaWdodHdlaWdodA0Kc3BlY2lmaWNhdGlvbi4gU2lu Y2UgdGhlIExJZ2h0d2VpZ2h0IHNwZWNpZmljYXRpb24gaXMgbWVudGlvbmVkIGluIHRoZQ0KYmVn aW5uaW5nLCBJJ20gbm90IHN1cmUgaWYgdGhhdCdzIHdvcnRoIG1lbnRpb25pbmcgaGVyZT8NCg0K Q2hlZXJzLA0KVG9tYXMNCg0KT24gMjAyMC0wNi0wNCAyMDowMywgTW9oaXQgU2Fobmkgd3JvdGU6 DQo+IEhpIEppbSwNCj4gVGhlcmUgd2VyZSBzb21lIGRpc2N1c3Npb25zIGFib3V0IHVzaW5nIENv QVAgYXMgdHJhbnNwb3J0IGZvciB0aGUNCj4gTGlnaHR3ZWlnaHQgQ01QIHByb2ZpbGUgaW4gdGhl IGxhc3QgTEFNUFMgV0cgbWVldGluZy4gQWZ0ZXIgaGF2aW5nIHNvbWUNCj4gZGlzY3Vzc2lvbnMg d2l0aCBIZW5kcmlrLCBEYXZpZCwgYW5kwqBBbmRyZWFzIEkgaGF2ZSB3cml0dGVuIGFuDQo+IGlu dGVybmV0LWRyYWZ0IGZvciB1c2luZyBDb0FQIGFzIHRyYW5zcG9ydCBmb3IgQ01QdjIgLyBMaWdo dCBXZWlnaHQgQ01QDQo+IFByb2ZpbGUuIElmIEkgYW0gbm90wqBtaXN0YWtlbiwgdGhlwqByZWNv bW1lbmRhdGlvbiB3YXMgdG8gcHJlc2VudCB0aGlzDQo+IGRyYWZ0IHRvIEFDRSBXRyBmb3IgdGhl IHJldmlldyBpbnN0ZWFkIG9mIExhbXBzIGdyb3VwLCBjYW4geW91IHBsZWFzZQ0KPiBhZHZpY2Ug b24gdGhhdD8NCj4gDQo+IEhlcmUgaXMgdGhlIGxpbmsgdG8gdGhlIGludGVybmV0LWRyYWZ0IHRo YXQgSSB3cm90ZQ0KPiBodHRwczovL2V1cjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZpZCUyRmRyYWZ0LW1zYWhuaS10 YmQtY21wdjItY29hcC10cmFuc3BvcnQtMDAudHh0JmRhdGE9MDIlN0MwMSU3Q2hlbmRyaWsuYnJv Y2toYXVzJTQwc2llbWVucy5jb20lN0M3NTUzZDhhZjI2MDM0MzYwMzExMjA4ZDgyNzc4ZjZhMCU3 QzM4YWUzYmNkOTU3OTRmZDRhZGRhYjQyZTE0OTVkNTVhJTdDMSU3QzAlN0M2MzczMDI3NDc3Njk4 NzU1MTAmc2RhdGE9JTJCVWhUTUpqZ0g4SjNnVlZ5VmE4ZVlaZTBjTk84QUtaTks4QXhpNVJaQWdj JTNEJnJlc2VydmVkPTDCoA0KPiANCj4gVGhhbmtzDQo+IE1vaGl0wqDCoA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gU3Bhc20gbWFpbGlu ZyBsaXN0DQo+IG1haWx0bzpTcGFzbUBpZXRmLm9yZw0KPiBodHRwczovL2V1cjAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmcl MkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcGFzbSZkYXRhPTAyJTdDMDElN0NoZW5kcmlrLmJyb2Nr aGF1cyU0MHNpZW1lbnMuY29tJTdDNzU1M2Q4YWYyNjAzNDM2MDMxMTIwOGQ4Mjc3OGY2YTAlN0Mz OGFlM2JjZDk1Nzk0ZmQ0YWRkYWI0MmUxNDk1ZDU1YSU3QzElN0MwJTdDNjM3MzAyNzQ3NzY5ODg1 NDY3JnNkYXRhPVNCREphNlA3JTJGZDVPU1E0d25kOG8lMkZ1TzJQSmc1ZXNZblh0S21IbEJjVGFv JTNEJnJlc2VydmVkPTANCj4gDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpTcGFzbSBtYWlsaW5nIGxpc3QNCm1haWx0bzpTcGFzbUBpZXRmLm9yZw0K aHR0cHM6Ly9ldXIwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3Bhc20mZGF0YT0w MiU3QzAxJTdDaGVuZHJpay5icm9ja2hhdXMlNDBzaWVtZW5zLmNvbSU3Qzc1NTNkOGFmMjYwMzQz NjAzMTEyMDhkODI3NzhmNmEwJTdDMzhhZTNiY2Q5NTc5NGZkNGFkZGFiNDJlMTQ5NWQ1NWElN0Mx JTdDMCU3QzYzNzMwMjc0Nzc2OTg5MDQzNyZzZGF0YT1oNWlCdU0lMkJ4dWNqR05BRVN6b0FJUTI2 VG81NWl6ZWtsRmV1WUdVa1hZZmMlM0QmcmVzZXJ2ZWQ9MA0K From nobody Tue Jul 14 07:32:06 2020 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 6D4E33A07FB for ; Tue, 14 Jul 2020 07:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=siemens.onmicrosoft.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 fSFwVpI0mp4p for ; Tue, 14 Jul 2020 07:32:03 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10055.outbound.protection.outlook.com [40.107.1.55]) (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 B92F43A0774 for ; Tue, 14 Jul 2020 07:31:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D7S0sxm4TIK7IG6VWFWA0EnR6LvfiIk/tLEpEAD9btKDtc3TvcKoJ40QEBDHmzuZwVlNp5amcCbu3S4zpcQQVJ45urEnCxZtaIf+FJflvhbCwM8PNxWhwlf/8r8VEByd2x0VFri9COySNUKVOp8+uEwQxomz1bhNU4pExu8GgPPnQwWRcmWhuWxmYVjKbqCvvirri09+MulVWJxUzoqXd6o8oWhiPOhAd4Imm+jPL9+SeF2oE9gJD53dQ3NcnDcPfNvM5WocfVWssTxmr5NI0SH2CmGtPd04hdVPpdlh+CSy370B8aw6zbD/bh22nQyeEiGMLpU6dKMgyvw6z1tWVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VC1tQZIImEezfZUbE5ih+x5o3uAwOalelG6gqKvPja0=; b=AK/qD7QK6apevL2M16DLUCQcN2Nq0rXheu08Av365slR7Hj2jp2nyElTRJwoYZjuodH63aU9bDmZrvyKC5mThsi0xNbSAwvwJDB496FZ2BeAtrlhuieUQGLuQsDyleDlC6P/ZyEAbcL1c/pKGn8Oa82zJ1P1qp7RfSmnBNan6VVxGShFziR+H60VKWyyIeEF7jYoIBtesMx74gLX5oqqJ5Enc6IFTRhaHiF8S5/ZCcvtTdVlISWaeaprWVIWUWGSpL/zbzMEQnQeYjftqDACxenyAL94EX581HnEinOIKlk8DVXlp3MY5/E/TIFBOlCDTl+F0jRu8yLPsKbuNn3qRA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VC1tQZIImEezfZUbE5ih+x5o3uAwOalelG6gqKvPja0=; b=eltYfDmTq1Zo4VeWYbHsvOoQHU6HW8fHR+iMFF/EOjqLOCLV+R6ClLhKZVIitCVCD1omoWxuK61uu2M6ZH5468GipucmjVhXzN+L8q+zK/pnP5sWbFXTas5Mpiz2yevpJlAxjeCOJEjiz27utH9l1+eMR5D4vN5yRzjspXOG/iQ= Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:184::10) by AM0PR10MB2195.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:d6::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.24; Tue, 14 Jul 2020 14:31:55 +0000 Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::c5d3:8347:4ebd:93da]) by AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::c5d3:8347:4ebd:93da%3]) with mapi id 15.20.3174.026; Tue, 14 Jul 2020 14:31:55 +0000 From: "Brockhaus, Hendrik" To: Russ Housley CC: LAMPS WG , "david.von.oheimb@siemens.com" Thread-Topic: draft-ietf-lamps-lightweight-cmp-profile-02 and draft-ietf-lamps-updates-cmp-02 - pre-registration of OIDs Thread-Index: AdZZ6a15uH58Cx3ITzaKWzWqPh+FqQ== Date: Tue, 14 Jul 2020 14:31:55 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.178] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ad8a1cae-d310-4dd0-89f7-08d82802a85c x-ms-traffictypediagnostic: AM0PR10MB2195: x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kYHoxfHQnBheVE3CUW1gxK59hBHr9mlLXGmC/4rKd7quHzJEI851vn+nyFXUxguooFyOXEmorxgkutmMDne4hsaKHTb9omejak4Nz6klXACSH6uXCKhBjbNhbVqrCqUVLj1i/E3BP3MjLHlf9mV48RIGonlNTF9pnrZQICmhET2bZXgALaHxoFMxhtGBNPE7uXvvhGTSq3grgn3hfwBExeBVe7Z7X8ESqsvxPC9z6BbXP6VHnkPPFhjPUZXRgbPvjvA5ZUHJ1JunCJjqEtNoQQa0Wt2q1VFD+PlAh3NNjZecTTA+5iqWNlftQFMcwscm757OU/3Ja3oCygVONKWXOA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(346002)(376002)(39860400002)(366004)(136003)(8676002)(6506007)(55236004)(6916009)(8936002)(4743002)(15650500001)(186003)(2906002)(55016002)(4326008)(107886003)(83380400001)(9686003)(4744005)(71200400001)(33656002)(76116006)(86362001)(66446008)(54906003)(7696005)(64756008)(66946007)(5660300002)(316002)(66476007)(478600001)(66556008)(26005)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: CNwufWii2Ggyj/Hocayxu4y7OqJNsWWWXhWw2rYVdpt5jfPHj19KMSlTgXfan9Gt0jClDSOcspJlVQwc3GmroJ2NKDsltmNzWztKx3a/CdbcCxGCJ5zT9DH7J5qi+k6+mM2p2LOjVUKtBUXgyHky3NmA3F6v1T9JtSBaetWnk647Fi2RZXFdYzM6n/ynToqty1ixGNCPXG2nsUNnGZHU6VIFiOcRLEJNqWi2Xd0GDL/RPiS0NEKEzC22vn/7C2mNJbiC4rvd+vxpC3xOFQdCDTdcl7UCqPR/CSRSs1JmHqQc1LTw6nnHrsnLBJneqU50yox14F3bBUbCPajcOBSOsCgzb27/NVToSEw3vJLpD5bhS0klYgdOm+qen/yMU/XIOpy+KhcbK4hhS1FRY2ElNJ0ftdwfZMqHqQbqeqMwvdOxevnRj9OW/KQJN+Vcc0F5CixKuvHYGy03DRAhLCkQz4yomQ8yG4qgMn8UxOAX3MxoX9S7nB5Q0ETSWHNeovPx Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: ad8a1cae-d310-4dd0-89f7-08d82802a85c X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2020 14:31:55.2348 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vSTeuHkrXswY2Nls+XLLWf7v9TFy/xWXZ2JqbrzuaZF8RleyDgx8kS2XbLy8QSbqUretfQsVIQ2GyW8UcX2Vv+xin4tnzdJ01nU94bzag70= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2195 Archived-At: Subject: [lamps] draft-ietf-lamps-lightweight-cmp-profile-02 and draft-ietf-lamps-updates-cmp-02 - pre-registration of OIDs X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 14 Jul 2020 14:32:04 -0000 Russ As we are currently implementing the CMP profile, it would be great to get = a pre-registration of the new OIDs. draft-ietf-lamps-lightweight-cmp-profile-02 section 4.4.2 + Appendix A - id-it-caCerts OBJECT IDENTIFIER ::=3D { id-it-= ... } section 4.4.3 + Appendix A - id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::=3D = { id-it- ... } section 4.4.4 + Appendix A - id-it-certReqTemplate OBJECT IDENTIFIER ::=3D = { id-it- ... } draft-ietf-lamps-updates-cmp-02 section 2.2 + Appendix A - id-kp-cmKGA OBJECT IDENTIFIER ::=3D { id-kp- ...= } - Hendrik From nobody Tue Jul 14 11:13:56 2020 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 5A3A53A097A for ; Tue, 14 Jul 2020 11:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 VGA2OhPjhcwG for ; Tue, 14 Jul 2020 11:13: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 B11633A0974 for ; Tue, 14 Jul 2020 11:13:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0AFF9300B7F for ; Tue, 14 Jul 2020 14:13: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 mpBwggkGOJ8h for ; Tue, 14 Jul 2020 14:13:49 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 26286300A55; Tue, 14 Jul 2020 14:13:49 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: Date: Tue, 14 Jul 2020 14:13:50 -0400 Cc: LAMPS WG , "david.von.oheimb@siemens.com" , "Brockhaus, Hendrik" Content-Transfer-Encoding: quoted-printable Message-Id: <8E4BE9A8-3696-471C-BF7D-3FE0CC729C05@vigilsec.com> References: To: "Roman D. Danyliw" X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [lamps] draft-ietf-lamps-lightweight-cmp-profile-02 and draft-ietf-lamps-cmp-updates-02 - pre-registration of OIDs X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 14 Jul 2020 18:13:55 -0000 Roman: Can we get early IANA allocation of these OIDs? They will be allocated from these registries: = https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers= -1.3.6.1.5.5.7.3 = https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers= -1.3.6.1.5.5.7.4 I am the IANA Expert for both of these registries, and I thing early = assignment is fine. Russ > On Jul 14, 2020, at 10:31 AM, Brockhaus, Hendrik = wrote: >=20 > Russ >=20 > As we are currently implementing the CMP profile, it would be great to = get a pre-registration of the new OIDs. >=20 > draft-ietf-lamps-lightweight-cmp-profile-02 > section 4.4.2 + Appendix A - id-it-caCerts OBJECT IDENTIFIER ::=3D { = id-it- ... } > section 4.4.3 + Appendix A - id-it-rootCaKeyUpdate OBJECT IDENTIFIER = ::=3D { id-it- ... } > section 4.4.4 + Appendix A - id-it-certReqTemplate OBJECT IDENTIFIER = ::=3D { id-it- ... } >=20 > draft-ietf-lamps-updates-cmp-02 > section 2.2 + Appendix A - id-kp-cmKGA OBJECT IDENTIFIER ::=3D { = id-kp- ... } >=20 > - Hendrik From nobody Tue Jul 21 16:18:36 2020 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 F006B3A07C3; Tue, 21 Jul 2020 16:18:30 -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, SPF_HELO_NONE=0.001, 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 yiepH0MgHb65; Tue, 21 Jul 2020 16:18:29 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAAE33A07C2; Tue, 21 Jul 2020 16:18:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 4790438A1F; Tue, 21 Jul 2020 18:58:01 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id k0uEc6jR9jLN; Tue, 21 Jul 2020 18:58:00 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8C66B3899F; Tue, 21 Jul 2020 18:57:59 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 276EEA8; Tue, 21 Jul 2020 19:18:25 -0400 (EDT) From: Michael Richardson To: "Brockhaus\, Hendrik" , "secdispatch\@ietf.org" , "spasm\@ietf.org" , Tomas Gustavsson In-Reply-To: References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] IDevID considerations document to secdispatch X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jul 2020 23:18:31 -0000 --=-=-= Content-Type: text/plain Brockhaus, Hendrik wrote: >> In particular, the self-generated (_invivo_) key suffers because the device >> needs to do a write/read operation from the infrastructure. That involves the >> highest possible latency for interaction with the CA and therefore would slow >> the assembly line the most. > We make use of the key-pair generated on the fly on the device and do > not see major delay on the manufacturing line due to CA communication. I hear this complaint as heresay, and I have yet to hear it directly from someone who would know. They always seem two or three layers of indirection away. I would be very happy to kill this issue as a non-issue. I'm aware of a major VoIP phone supplier whose CA is on a different continent, and it's not an issue. > Finally it is a question of how you arrange your manufacturing > procedures. If you experience delay due to waiting for the certificate > delivery, you can do other meaningful things in the meantime. yes, that's certainly true, but it also take some interactions among different layers. >> The invitro and shared-secret methods allows the infrastructure to generate a >> few keys in advance (and get them signed, assigning DN-serialNumber at the >> same time), and then injecting that key via JTAG at the same time as the >> firmware. This overlaps the CA interaction with other steps. > Finally this method puts higher security burden on the manufacturing > infrastructure to securely handle the pre-generated key pairs. This is > why I do not like it, but sometimes it is needed. The -02 version of the document cites: "Factoring RSA keys from certified smart cards: Coppersmith in the wild", September 2013, . for a story of not-quite-random-enough issues! -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8Xd8AACgkQgItw+93Q 3WUMGQf+In/nhpmLhdutkBOle7Mx+ANnBxCYsWYlYRBNSsszvOpoMZpev77pLgAY pep2UHka1yRd4+9EJyN9ijp1q+NFT+/jAbvvH7jFGC7cg9W++yEO+LEo9kEqVo86 +fBxeekQ6ovkjRIKKxgApcBfUp3Uo2P96+5mD3oHTtxvbSUOfGRnafTyWO+T+hZu kFZMFY9GVKfIaq+A7k2VSVkxncLhUztnOSP3jbg3CDD49eZ5eVgQjaELx5Jd4M9L 3Or2gN5m3drgwhejlP2dRSoEsHsjVDRr2iWt8kH4i7YkUVevKOzulb98coRdZRcL dMDxTFuSBfCrWTyWlr6CtAUWzZXpbg== =o9+p -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 21 16:31:51 2020 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 BDD2F3A0805; Tue, 21 Jul 2020 16:31: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, SPF_HELO_NONE=0.001, 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 eQ4iYh3n1pnc; Tue, 21 Jul 2020 16:31:44 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A2D3A0802; Tue, 21 Jul 2020 16:31:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C691E38A26; Tue, 21 Jul 2020 19:11:16 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bD7QivpLNRCA; Tue, 21 Jul 2020 19:11:15 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5BF4F38A20; Tue, 21 Jul 2020 19:11:15 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E9F63A8; Tue, 21 Jul 2020 19:31:40 -0400 (EDT) From: Michael Richardson To: Tomas Gustavsson , secdispatch@ietf.org, spasm@ietf.org In-Reply-To: <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] IDevID considerations document to secdispatch X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jul 2020 23:31:46 -0000 --=-=-= Content-Type: text/plain Tomas Gustavsson wrote: > On 2020-06-28 22:51, Michael Richardson wrote: >> >> Thank you again for reviewing the document! >> >> I know that primekey is involved in creating Birth Certificates for >> many product lines. (Your website's term, not mine, but a good >> one) > It wasn't my (ours) terminology unfortunately :-). We found it > elsewhere. I don't remember where "birth" came from. 3GPP 33.310 have > the same concept, but calling Vendor certificate. I think birth > certificate is a little better, as it's more generic than specifying a > vendor relationship. I do like the birth concept, and I am thinking if changing the document name to include it would make sense. Perhaps someone with expertise in attachment parenting can provide some interesting words about how trust anchors are installed. >> I wonder if you can comment on which of the three methods you >> support? Do you have any suggestions on names for the three >> methods? To me, just getting three good names is 90% of the value >> of this document. > We support: > 2.1.1. On-device private key generation > Standard CSR-submitted-to-CA process I have named this: a) _device-generated_ / _mechanically-transfered_ b) _device-generated_ / _network-transfered_ I know that you are blown away by my imagination here. Perhaps someone can feed this through a mechanical translator, run it English->German->Mandarin->Swahili->English, and see what comes back. I think that it's useful for the entity that needs to examine the risk for the process to distinguish the two transfer methods. > 2.1.2. Off-device private key generation > Typically CA-generates-keystore process. Some protocols, i.e. > CMP/RFC4210 have standard support for encrypting the private key sent > back to the client I have named this: a) _factory-generated_ / _mechanically-transfered_ Like a serial console connection, or a JTAG flash writer. for b) _factory-generated_/ _network-transfered_ yes, but what key would you use? :-) The device has nothing.... So I think that it really has to always be used in the factory with a physically secure network connection. > 2.1.3. Key setup based on 256-bit secret seed > We haven't seen this. Albeit, it's not so much related to the PKI > part, so it can still be supported/used if the certificate issuance is > done using a CSR process to the CA. I have named this: device/factory-co-generated I had not seen this either. Laurence Lundblade, formerly of Qualcomm says that it's a thing. While the interface to the CA could still be via CSR, the CSR is generated by the OEM, possibly not in the factory at all. The private key can be generated, used to sign a CSR and create a certificate, and then destroyed. This can occur completely asynchronously to the manufacturing process. It can occur in advance, in which case the certificate can be loaded via a (pipelined) write operation to the device, which will generate the same private key. It can also occur after the device has been built and provisioned. The device might never actually have it's certificate internally: the onboarding infrastructure could retrieve it from the OEM when the device first shows up. Or the device could retrieve it when it first boots up as part of the QA process. But, ultimately, what's happening is that >> Thinking about "birth" concept, I am trying to think if this helps >> with terms. Invivo <- self-generated private key, with >> enrollment. Invitro <- private key generated in test-tub, deployed >> to device. > Good idea to have naming for these. I like the idea. I don't have any > immediate ideas. Are there any naming from TMP/SE vendors/standards > that can be re-used? (I'm not very familiar with those specs myself). -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8XetwACgkQgItw+93Q 3WV2nwf/T/NQp6uh9YhFHpuirbdyOLBS1xCxYbswQZ3edO+QOUXEy0WWEZT4urK0 CVLSLdpNt1HKgFtNdnWXBhAFS9V8yksHzbnDK/ozj8BQ3xvP0ATtzrSM9PmkxSty 4L5LTbIUBlXZPC4mkiBiasS/2lN8rrfKHCB16CuX2NS7NMt/ro7MT+hkEiYeYoiT M+Wt69J4KYP9yfYjcNOjmFD42bY4rAuGEhEBBJEgArdu/Zjr1jt5GFT0zPcD7WNX o2QmfHVszLd7AUnWQTwe48Lz8NEhT50Vacm++9HdAODPDW3mCaKfzN9xPrvD7neT 2Ai4ge3ne4ZjMc49Rp86lBO5k/7sFQ== =Matd -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 21 22:22:53 2020 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 B9C3A3A0DDF; Tue, 21 Jul 2020 22:22:51 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.se header.b=5PxX9SNt; dkim=pass (1024-bit key) header.d=primekey.se header.b=5PxX9SNt Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHdkXO2okdmN; Tue, 21 Jul 2020 22:22:49 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 770103A0DDD; Tue, 21 Jul 2020 22:22:47 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id 3DFB16AA061E; Wed, 22 Jul 2020 07:22:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.se; s=mail; t=1595395345; bh=4xFd0v9RTqcGwEbPDd1flPzGzwpCi8HOVlkudM9kZZo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=5PxX9SNtF9efkf4IuPu+MJbL1dQ/O1Ec6DdxQve2dIFuIgxPm3KumDiQl62XlpKhM bu04QXU/tOS2XOrmzXMVu9SS7oAqrT2koKkX7DTNnx+9T7KhmG8RnFM1u/rz1KcrwN fFPVe4yb2QsxC/x0OJAHhBXK6ENlmeuhQridbc/Q= Received: from [192.168.1.113] (unknown [85.24.187.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id 0D4936AA0618; Wed, 22 Jul 2020 07:22:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.se; s=mail; t=1595395345; bh=4xFd0v9RTqcGwEbPDd1flPzGzwpCi8HOVlkudM9kZZo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=5PxX9SNtF9efkf4IuPu+MJbL1dQ/O1Ec6DdxQve2dIFuIgxPm3KumDiQl62XlpKhM bu04QXU/tOS2XOrmzXMVu9SS7oAqrT2koKkX7DTNnx+9T7KhmG8RnFM1u/rz1KcrwN fFPVe4yb2QsxC/x0OJAHhBXK6ENlmeuhQridbc/Q= To: Michael Richardson , secdispatch@ietf.org, spasm@ietf.org References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> <22303.1595374300@localhost> From: Tomas Gustavsson Autocrypt: addr=tomas@primekey.se; prefer-encrypt=mutual; keydata= xsBNBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAHNMFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPsLA dwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5zsBNBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAHCwF8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: <08ab938b-deee-09f2-697b-657049cc4192@primekey.se> Date: Wed, 22 Jul 2020 07:22:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <22303.1595374300@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] IDevID considerations document to secdispatch X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jul 2020 05:22:52 -0000 On 2020-07-22 01:31, Michael Richardson wrote: > > Tomas Gustavsson wrote: > > On 2020-06-28 22:51, Michael Richardson wrote: > >> > >> Thank you again for reviewing the document! > >> > >> I know that primekey is involved in creating Birth Certificates for > >> many product lines. (Your website's term, not mine, but a good > >> one) > > > It wasn't my (ours) terminology unfortunately :-). We found it > > elsewhere. I don't remember where "birth" came from. 3GPP 33.310 have > > the same concept, but calling Vendor certificate. I think birth > > certificate is a little better, as it's more generic than specifying a > > vendor relationship. > > I do like the birth concept, and I am thinking if changing the document name to > include it would make sense. > Perhaps someone with expertise in attachment parenting can provide some > interesting words about how trust anchors are installed. > > >> I wonder if you can comment on which of the three methods you > >> support? Do you have any suggestions on names for the three > >> methods? To me, just getting three good names is 90% of the value > >> of this document. > > > We support: > > 2.1.1. On-device private key generation > > Standard CSR-submitted-to-CA process > > I have named this: > a) _device-generated_ / _mechanically-transfered_ > b) _device-generated_ / _network-transfered_ > > I know that you are blown away by my imagination here. > Perhaps someone can feed this through a mechanical translator, run it > English->German->Mandarin->Swahili->English, and see what comes back. > > I think that it's useful for the entity that needs to examine the risk for > the process to distinguish the two transfer methods. > > > > 2.1.2. Off-device private key generation > > Typically CA-generates-keystore process. Some protocols, i.e. > > CMP/RFC4210 have standard support for encrypting the private key sent > > back to the client > > I have named this: > a) _factory-generated_ / _mechanically-transfered_ > Like a serial console connection, or a JTAG flash writer. > > for b) _factory-generated_/ _network-transfered_ > > yes, but what key would you use? :-) > The device has nothing.... Very good question, I thought the same. In the case I see, the device don't talk directly with the PKI. There can be a secure HW device in the factory interacting with production line on one side, and the CA on the other. It can talk something device specific, direct connect, with the device on the production line, and make the CMP calls to the PKI. The private key generated (by the CA) is then encrypted with the gateways public key (where the private key is kept in an HSM/TPM/SmartCard). Yes, the "gateway" becomes a point where the private key is decrypted and vulnerable for a short time, so it's not for every scenario. The CA can be off-site, not in the factory, i.e. central organization PKI. The the term _factory_generated_ can be a bit misleading. The CA can of course be in the factory as well, I just don't want to trigger a specific architecture image in the readers mind. > So I think that it really has to always be used in the factory with a > physically secure network connection. Physically secure on the production line itself, but can be internet between the gateway on the production line and the CA. > > > 2.1.3. Key setup based on 256-bit secret seed > > We haven't seen this. Albeit, it's not so much related to the PKI > > part, so it can still be supported/used if the certificate issuance is > > done using a CSR process to the CA. > > I have named this: device/factory-co-generated > > I had not seen this either. > Laurence Lundblade, formerly of Qualcomm says that it's a thing. > While the interface to the CA could still be via CSR, the CSR is generated > by the OEM, possibly not in the factory at all. > > The private key can be generated, used to sign a CSR and create a > certificate, and then destroyed. > > This can occur completely asynchronously to the manufacturing process. > > It can occur in advance, in which case the certificate can be loaded via a > (pipelined) write operation to the device, which will generate the same > private key. > > It can also occur after the device has been built and provisioned. > The device might never actually have it's certificate internally: the > onboarding infrastructure could retrieve it from the OEM when the device > first shows up. Or the device could retrieve it when it first boots up as > part of the QA process. > > But, ultimately, what's happening is that > > >> Thinking about "birth" concept, I am trying to think if this helps > >> with terms. Invivo <- self-generated private key, with > >> enrollment. Invitro <- private key generated in test-tub, deployed > >> to device. > > > Good idea to have naming for these. I like the idea. I don't have any > > immediate ideas. Are there any naming from TMP/SE vendors/standards > > that can be re-used? (I'm not very familiar with those specs myself). > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Wed Jul 22 01:15:04 2020 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 135773A0FB0; Wed, 22 Jul 2020 01:14:30 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.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 WlxnmTB8axRK; Wed, 22 Jul 2020 01:14:24 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70070.outbound.protection.outlook.com [40.107.7.70]) (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 4DFF83A0FAF; Wed, 22 Jul 2020 01:14:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WNLwrt4Wykme5oXH1prRcNs0vYOOjhIqde5U4lU6yyyd+bqPYnww0VdDCSMhAOmKXQMXGkiP4UTS4DYUvPGcY2YJOJpAzr9Jz0lplatFgGuuny15I/1ez0Fu8xxMWxnnMYD8YRpjPhsx42bhU6b+VmkCV+uKZSsutW2lSAbvq/dIkSGT2rn75kY/9Yk/PuuTPp0V0YW+1dcNdDeNOwDwcQjlh6orYCvxrpVVIEIa+OH/bAD02YnXmAa+9M8tt1Joc32VQ7OsFHwyLWF275RgMP+DyNhL7qs5q93YnvwEc0YpHYsUhnan+BEekZoym0g3zF5Vob3DnnXHTX98skwEUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SbdlfhpJYCYGsQQcuUTjQUQT+W12VkpY+HdlNyN70AI=; b=hCvYpNtEjvedDWSr//vIB5C6mpeoZCbu7R2hlrAYMHJPIF89Keg49oI27jNCq36G1KCtJW6g5QcXoWVZNWdo0X/h/cFZyJfeDBQ2eXdPp8ttTCuYhdC+gwChF11dQu5BN0X5IJUTGgezwl9mhjP78MaJLGrl5EG0SPo0hyNtYd3S6ZtUa8qxfd//wMz0l8OQ2AB5+uU2LVRqNPmpB8ZMoHLSPnUASc6KvV8V/PewiR/X++Ygf7os98SADTP8MOrJyCUliaFX5ZCHoFa75sXfse/3vx2BkW58k+6Wby253DRMPRSAdFY7ZPLeH6b40LS8a17HwCsHfA+z1ahijQYFkA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SbdlfhpJYCYGsQQcuUTjQUQT+W12VkpY+HdlNyN70AI=; b=icXjQhb/EJXM+eGHQ+/k0MOSX6w46CAv0nViK7zKblD/8So7kxgApWdVAjt3kAPbeeq/pv5gVIASwAJOmdola7qZSquRvmDWPvJoDcgLHjLuU5IV6sqOVUvkIi7UBhCD0SsYAvommTeISEbwW+ze1OHg/4dl4S9hhljO3/QcfeM= Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:184::10) by AM0PR10MB2787.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:132::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.20; Wed, 22 Jul 2020 08:14:20 +0000 Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0]) by AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0%9]) with mapi id 15.20.3195.028; Wed, 22 Jul 2020 08:14:20 +0000 From: "Brockhaus, Hendrik" To: Michael Richardson CC: "secdispatch@ietf.org" , "spasm@ietf.org" , Tomas Gustavsson Thread-Topic: [lamps] IDevID considerations document to secdispatch Thread-Index: AQHWP8N6k88ddaiq9U6Bs/QsBzthBajTsr2AgAV/EICAFWp0gIAApgFAgCOoroCAAJIagA== Date: Wed, 22 Jul 2020 08:14:20 +0000 Message-ID: References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <19437.1595373505@localhost> In-Reply-To: <19437.1595373505@localhost> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=e01786dd-8b4d-436f-b3f0-0000287cb7ac; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-07-22T08:01:20Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; x-document-confidentiality: NotClassified authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.158] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3c8c4795-9433-4be2-b801-08d82e173c75 x-ms-traffictypediagnostic: AM0PR10MB2787: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: E2GGaBiS9A/JRbNEukF1eoHTEcAFgJDxnLW0zQYoSMvfxwmayHwrzo7ujSG/ND8kldo6kDBjFpxSjOeCrfL3qCtCn61cXjkbtK+ewsEuvtPH/d1MxyyYDpo8TwXpMag/jf7GnyyzjxaeKorRdcgGicqD/Cmd542RQpkOCokBlUjxMfc5HWO30rCmPPQ99jw6b+9qFQ4JIh9vhNu8u3kKd6de0VZkNcwqgbM+XLZD2M7IhVZkGvKxNhn/qzgxRJXSlrYpjEsTE6btouqclHN8nmOui07B7HiCY4SbH7vPDRVQHbVDjqrk6gQ78xKZyyVbVdFch7OqGcCycLVDz4CQ16DHEtZhmRDFCY5F0Wh/+v/JOVgie8bhzhgfLHc4tagGenWaAAiOcR9GCwpqwQOKrg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(346002)(376002)(366004)(396003)(39860400002)(55016002)(9686003)(8676002)(478600001)(186003)(55236004)(52536014)(66446008)(7696005)(66556008)(6506007)(66476007)(64756008)(83380400001)(76116006)(66946007)(316002)(26005)(33656002)(15974865002)(54906003)(8936002)(5660300002)(4326008)(2906002)(86362001)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: t131DU3FebnTjLyxN4EmqdCCUrZAyvlyhiOcHuwy72SKieuLDc3gBA8dyHqYCipQEcYCaGqitSV4YvpDE85RInY8yM8wnNShFixUbwgYv7VtomZtQhKexCdPENJnn7jIlI08ai5/i2Te4EONjdRWDSBGN/QYGe9F7k0GHeHOJ2ek5d3ZfDefPBSR0wnBsR7jINeE074z3L9kFEmMNLZ272nSICyWixoO6xzIt84FK8CISzID7RgFlFaoHw4Gl1jwcky23uPHhDZKu9pKpeSLEczLCntP/BA8nq1fCnIT6GKj+nefAhHnkFQ6UZ9IZfYmpDyIwWxkhJQAMnvpQm1dblIr5e5qxSFhYcelVpGiBvOAKZ6oXKToBytsitvlLmhqVUKDM6h868vbS/X5YX3G0CYeCwN8u27J/h9HUIpjw4EpfZB3Al3QTO6EE70kl0uy8zBSa2CwRfotvvBi/GtHIeWbk25MuYInQpO/JmIhVVf88CRBQIEUVmUFpdVaqKTd x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 3c8c4795-9433-4be2-b801-08d82e173c75 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2020 08:14:20.5552 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OtfCidSDhn8oHtKmwO1SAkKf8K0p/rR2r/H1DB3BvQGL6I3TXf71AGeUc9oP8rWtsWtUTb5cyDibQuLXvJQ6nXoIMeNs42Evb1KlBFauJY0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2787 Archived-At: Subject: Re: [lamps] IDevID considerations document to secdispatch X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jul 2020 08:14:30 -0000 > Von: Michael Richardson >=20 > Brockhaus, Hendrik wrote: > >> In particular, the self-generated (_invivo_) key suffers because t= he device > >> needs to do a write/read operation from the infrastructure. That = involves > the > >> highest possible latency for interaction with the CA and therefore= would > slow > >> the assembly line the most. >=20 > > We make use of the key-pair generated on the fly on the device and = do > > not see major delay on the manufacturing line due to CA communicati= on. >=20 > I hear this complaint as heresay, and I have yet to hear it directly from > someone who would know. They always seem two or three layers of > indirection away. I would be very happy to kill this issue as a non-issu= e. > I'm aware of a major VoIP phone supplier whose CA is on a different conti= nent, > and it's not an issue. We make used of a CA across continents for some years now and it works fine= . >=20 > > Finally it is a question of how you arrange your manufacturing > > procedures. If you experience delay due to waiting for the certific= ate > > delivery, you can do other meaningful things in the meantime. >=20 > yes, that's certainly true, but it also take some interactions among diff= erent > layers. >=20 > >> The invitro and shared-secret methods allows the infrastructure to > generate a > >> few keys in advance (and get them signed, assigning DN-serialNumbe= r at > the > >> same time), and then injecting that key via JTAG at the same time = as the > >> firmware. This overlaps the CA interaction with other steps. >=20 > > Finally this method puts higher security burden on the manufacturin= g > > infrastructure to securely handle the pre-generated key pairs. This= is > > why I do not like it, but sometimes it is needed. >=20 > The -02 version of the document cites: > "Factoring RSA keys from certified smart cards: > Coppersmith in the wild", September 2013, > . >=20 > for a story of not-quite-random-enough issues! For smart card production the pre-generation of keys is often used. Especia= lly if RSA keys are required. Key generation for RSA keys is much slower and duration is unpredictable, c= ompared to generating ECC keys. Actually I mainly see ECC keys on embedded devices today. Today the require= d key length for long term used RSA keys gets inacceptable, as ECC keys key= length is still acceptable. See section 4.6 in www.ecrypt.eu.org/csa/docum= ents/D5.4-FinalAlgKeySizeProt.pdf - Hendrik From nobody Wed Jul 22 01:45:32 2020 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 11F653A00E4; Wed, 22 Jul 2020 01:45:31 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.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 Al5c_f17MIN8; Wed, 22 Jul 2020 01:45:29 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80079.outbound.protection.outlook.com [40.107.8.79]) (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 9B25B3A00D4; Wed, 22 Jul 2020 01:45:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BCmMZTEP8j+4QxjWjD/csecS8VqOGjaTPB/oCW1gPaAAyXwewifJu9uUTibdu33K5lmfSpbjJPfl3hjEZ+p8SOPuzpOeOih9Sjyhz+dDAA1ACOnFpbp5kuK40/+jLbIfJ56CHQ/o4y+yL1OpNWDVkYejHrwi6hX4Vf40qciUvA62J0ZwclVFlIbuT/ZvFe5CyX0vGMlRUDYZATjPLt9EarbvFpAJqOvkSwRkOdZpaJZl/b5b9MZZh+mPGLEdvZ1ZeoiSUv8QAQt+NkdW6xkdtq3tNiu4IQzDEQLcy92PaCkg0mSPpzz6h3wUJK1tupbY9y+oTbOExRRzvVKx0Inlmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z2sBVPz4f8QRohXLpBCxqTMOKNED7lmoRF34eQXi3YA=; b=a45c3EArpgYi1KgEjVZ/k6Ix68jwi3mg630h6UJ2LZGcQG47i3HvqbVwUVKCMOOsXUL61hB7ZF9noAlj+OlSHmyhKwn/A5/1PIwmRlVXr9jkESG8YnWgVRz+DqCT3Z1Rl+VN9dOZ2H4lO2lII+rBr79RHyxrPUw7/CXxHHBrXBpeySfrUGUhl62XdWaHSfP4jAha00tlfzS8yCAC7harNJu6EW9UT56dMc79KEcyOhzZbhsn9QzYhwqSfIfxlVE0f0QEvvXmhWT8e3jsk9oO6l2N9tYWhfnJ7Hnk3C1PhRrqH3BpzuJzPxn8tPusr356oQfUIyo+eGd3UjUASQhgYA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z2sBVPz4f8QRohXLpBCxqTMOKNED7lmoRF34eQXi3YA=; b=LAMYXqDEZf0yKNKgYwgtyl6KPkvtj4APihiDhW2Y8AlNJXlGN9oKTMiHZ9NxcF85CfJ3N+iA+ISc3uHn9nSvtUkF/+Xe4MPPL8obNjaMCLwssnOrUflU3tLj4pQDl6XwbjvdAuQ7wlWOMy3nEKQWCaC3Dz8m6jybXIy9Km3goUE= Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:184::10) by AM0PR10MB3474.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:154::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.20; Wed, 22 Jul 2020 08:45:26 +0000 Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0]) by AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0%9]) with mapi id 15.20.3195.028; Wed, 22 Jul 2020 08:45:26 +0000 From: "Brockhaus, Hendrik" To: Michael Richardson CC: Tomas Gustavsson , "secdispatch@ietf.org" , "spasm@ietf.org" Thread-Topic: [lamps] IDevID considerations document to secdispatch Thread-Index: AQHWP8N6k88ddaiq9U6Bs/QsBzthBajTsr2AgAV/EICAFWp0gIAAvESAgCOWHwCAAJRy4A== Date: Wed, 22 Jul 2020 08:45:26 +0000 Message-ID: References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> <22303.1595374300@localhost> In-Reply-To: <22303.1595374300@localhost> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=6f010863-e5e4-4555-aa03-0000e8b22546; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-07-22T08:22:59Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; x-document-confidentiality: NotClassified authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.158] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 9db08c61-6f89-4b28-9ddb-08d82e1b94a3 x-ms-traffictypediagnostic: AM0PR10MB3474: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GYKzc1kzwhC4iArveau3KDtaiXiBTliitsyI8LHETrHN+eHX+Ufhuosq++DxKOvr++AzT2A1ia8Wgg2zzVN7eyJvEHt1AYz9GOFPkwGoF24sRpxqCAOzaVuKUjf328sk+cErgIwGRkKKGO4PgKQa+twTeWIHryLvAZx8Cj5XC//uTkb3nEr2ORTTFacEGivxI1CMvjMeZhcIUvzwHA0ZYBdemND9Mb0tv16HjDIjDm+6TAjMl/O8LTc8l7xczrJeBd4fjqA0/FxKtyE3zzJzWRGjAanrh5cuRVN1s8WGhTY5pYqlYpUyINkXYDh7oeeC5XI+u8grjskS0sTVFtNUrw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(366004)(346002)(136003)(39860400002)(26005)(5660300002)(55236004)(186003)(54906003)(33656002)(7696005)(8676002)(83380400001)(316002)(66446008)(66556008)(55016002)(52536014)(71200400001)(76116006)(53546011)(6506007)(4326008)(8936002)(2906002)(66476007)(66946007)(478600001)(86362001)(9686003)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: wAm0HRW3iilu7AfKcpAQ5MUSbXX9tiEtI9hVL1TAZR6e7lOEihCycN2U/itqHRDflsIUioyJTY+42N8bQIt81sd+My78ma1DdAX5baVZ9wMtyAndpb7utanPMiBLnKXmLtQplQXKMNklI4nXpDoUUCBD6lGe0kfYQ7ni4IOUpVnp5ZjrSQYNof67ESucrYAvJjxT9ozJzlN73jyqBlP7+fmqZ1fnb3kj8pM/twqLJgCwFTik2jw1K765JSC7Scu/1ca4FyJlJ0crIitee+qbkh//D0sSgPNSoYUsM/5AdmbsIUvr5yJ7OGU7gMBChv6Jd/rX6svW4Wl58zDrEuG8uMBspmhDOKt434UWIGv2sc06nRwnILwXGp682mW5PkXs+CZSQ4T4aCZ/QAYkwiB7IYrhBcQcsg3s7wGD2UbTAXNKLx42qP2INVxGwRDONtiM6XOVMG6j5JEDrWnirfmBCO4PawfnZFNxje5U2e5Z+RXtI8sjVYPXW7JUeDWxN464 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 9db08c61-6f89-4b28-9ddb-08d82e1b94a3 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2020 08:45:26.5222 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1zexfqWeMvoLGwP/A96LRj67MzQA8buFZDaC5JlTxyMbImhh43+j6nghLlz0Jd9QILhsp6KTSEOpec1ApO/FQW5WHBcC3tJfEXzx4IcGSpk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB3474 Archived-At: Subject: Re: [lamps] IDevID considerations document to secdispatch X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jul 2020 08:45:31 -0000 > Von: Spasm Im Auftrag von Michael Richardson >=20 > Tomas Gustavsson wrote: > > On 2020-06-28 22:51, Michael Richardson wrote: > >> > >> Thank you again for reviewing the document! > >> > >> I know that primekey is involved in creating Birth Certificates fo= r > >> many product lines. (Your website's term, not mine, but a good > >> one) >=20 > > It wasn't my (ours) terminology unfortunately :-). We found it > > elsewhere. I don't remember where "birth" came from. 3GPP 33.310 ha= ve > > the same concept, but calling Vendor certificate. I think birth > > certificate is a little better, as it's more generic than specifyin= g a > > vendor relationship. >=20 > I do like the birth concept, and I am thinking if changing the document n= ame to > include it would make sense. > Perhaps someone with expertise in attachment parenting can provide some > interesting words about how trust anchors are installed. >=20 I use the image of the "birth certificate" to better explain the attributes= of an IDevID certificate. - Issued at manufacturing time (in Germany the birth certificate is a simpl= e sheet stamped and signed by the local register office) - The enrollment process requires some organizational/physical security, as= there is nothing to derive trust from at that point in time (in Germany th= e father or mother have to request the birth certificate personally. They n= eed to define the name of the child in front of the register officer and ne= ed present a conformation letter from the hospital or midwife about the dat= e of birth) - It lasts as long as the device is used (in Germany a birth certificate ha= s no validity and it is difficult to get a new one, if you lost yours) - It is required for initial authentication to request an operational certi= ficate (in Germany the birth certificate is required if you request a natio= nal ID card or a passport) - It should not be used for day-to-day operational tasks (you would not use= the birth certificate to identify yourself other than to the register offi= ce. Only rarely it is requested, e.g., when becoming a governmental or publ= ic official) > >> I wonder if you can comment on which of the three methods you > >> support? Do you have any suggestions on names for the three > >> methods? To me, just getting three good names is 90% of the value > >> of this document. >=20 > > We support: > > 2.1.1. On-device private key generation > > Standard CSR-submitted-to-CA process >=20 > I have named this: > a) _device-generated_ / _mechanically-transfered_ > b) _device-generated_ / _network-transfered_ >=20 > I know that you are blown away by my imagination here. > Perhaps someone can feed this through a mechanical translator, run it > English->German->Mandarin->Swahili->English, and see what comes back. >=20 > I think that it's useful for the entity that needs to examine the risk fo= r the > process to distinguish the two transfer methods. >=20 >=20 > > 2.1.2. Off-device private key generation > > Typically CA-generates-keystore process. Some protocols, i.e. > > CMP/RFC4210 have standard support for encrypting the private key se= nt > > back to the client >=20 > I have named this: > a) _factory-generated_ / _mechanically-transfered_ > Like a serial console connection, or a JTAG flash writer. >=20 > for b) _factory-generated_/ _network-transfered_ >=20 > yes, but what key would you use? :-) > The device has nothing.... > So I think that it really has to always be used in the factory with a phy= sically > secure network connection. I personally would prefer to say '_infrastructure-generated_' than '_factor= y-generated_', because the generation on the device will most likely also t= ake place in the factory. >=20 > > 2.1.3. Key setup based on 256-bit secret seed > > We haven't seen this. Albeit, it's not so much related to the PKI > > part, so it can still be supported/used if the certificate issuance= is > > done using a CSR process to the CA. >=20 > I have named this: device/factory-co-generated Same here: 'device/infrastructure-co-generated'. - Hendrik From nobody Wed Jul 22 01:56:19 2020 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 D79843A03FF; Wed, 22 Jul 2020 01:56:17 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.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 7fAjZipvjS1w; Wed, 22 Jul 2020 01:56:16 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2061.outbound.protection.outlook.com [40.107.22.61]) (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 01B323A03F3; Wed, 22 Jul 2020 01:56:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cTG5R3uo2IpKhT8kq3psXUyrbwStwjFlUP3ZRNdn1MVzk1AFHE4IH+F3Kjx5TUKpV69nIf0yUp/a9EDB9NEhsB/7C7UN4kGrYH+pajJk3zbGAEva6nhjVigHTgj/YegjEwqyb3g30PA8c5ooHnWl59QGh/ARJiyC/6fZZb328HAI0LpnmRYjqvy2LmxTVxmovhxVo6LUnoLRED/0TKZ/OEM1RRDD+tu2z/LWXytTsydirno0pkpeZUkAZosZhkKWFF0bp3usYu9em85ONRzNZKVHx9MWeAssUdRh6oHx2kCF3b3cR4v6D8t38t4TUPnj2F7x13FusAU+YdYb198I1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iSWQZK6CT+BT6bvxdxhLk2rf9uj5DwjITaxcfOVQBrk=; b=TCkzDnfvutquuO6ce76m+94GTe2m0xPzWRCW7RX+QQ3YiUiY41xDZCAPulw5fSRH7babyybQLZzpKeX4yjBgG+sqSHMn832HQRQafvpGBYf+CX/078EIQ5mqGy1MW2q4Zmp0+tMaFu1pDsH84S74M6cuTan0SzHn3vJzCyYkd75h0xPpeM88tB5Q/de8miHdyRUNFoXblrngFVxqwQ1YAQU39UrRRYfkU1yKevhXjIKrSnZVxB4tScvws3jDjpytEbGQPUtTSHOMOeXYp+Ez4jFfHoI9o+10LyoeDYoCNA2MG7Hcdwch3qf0CUF1u1q+V0g89vO0rd/HVGkH2JfoGQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iSWQZK6CT+BT6bvxdxhLk2rf9uj5DwjITaxcfOVQBrk=; b=oUDRdZgLX93Ro2o6Q0BeAU0R0MD8Sb1aBJCNrYKXPOcIdTcFqLL5VJsUsgzVzR92RE0Hu/nM6QtNX8wlpOSgJ0sRX5mL78g4Zh6E+fw+w4F7MW4bsDMFMg6zBA2lgpYd5b3EXwKl1Z9QZdUzJc6H/grVMxyeAfG4tdUbBjvoa+U= Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:184::10) by AM0PR10MB3457.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:154::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.22; Wed, 22 Jul 2020 08:56:13 +0000 Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0]) by AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0%9]) with mapi id 15.20.3195.028; Wed, 22 Jul 2020 08:56:13 +0000 From: "Brockhaus, Hendrik" To: Tomas Gustavsson , Michael Richardson CC: "secdispatch@ietf.org" , "spasm@ietf.org" Thread-Topic: [lamps] IDevID considerations document to secdispatch Thread-Index: AQHWP8N6k88ddaiq9U6Bs/QsBzthBajTsr2AgAV/EICAFWp0gIAAvESAgCOWHwCAAGIVgIAAOgCg Date: Wed, 22 Jul 2020 08:56:13 +0000 Message-ID: References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> <22303.1595374300@localhost> <08ab938b-deee-09f2-697b-657049cc4192@primekey.se> In-Reply-To: <08ab938b-deee-09f2-697b-657049cc4192@primekey.se> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=564c554f-cedb-425c-a34c-0000f7674392; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-07-22T08:50:19Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; x-document-confidentiality: NotClassified authentication-results: primekey.se; dkim=none (message not signed) header.d=none;primekey.se; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.158] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 9614d11e-53da-4fa0-c0cb-08d82e1d1679 x-ms-traffictypediagnostic: AM0PR10MB3457: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LHgzG0IpzzKjliD8tqIzURGiolA3ozxnCjZT1fc6C8RrUFbJcCgqX2oVsyJcsxbgkg7xfJcc9EVwjP3PuuJXWhvUr5mie3Yya47eDfY/fSX7rtHrqrIN54ZCyMdNxJrfvp1JHGCsvKopR4mhfRPFtzaRDpwJ6ErojfBDPE4TpI38KvUQ4J1W4f3vN4zNK/j+Y9aP82itpmUKCUo3/onZoM+xj2ppGlwG9pYyN/mk15wLD+52JDIv2U3q2M8Vz0gN4GpobJ6cToVM9NW6xB8uXSYR9Jbr0Eg1pjUSGXuoGJ1YAA43n84b/ILjRYru/wM7uxTOTtMXC8jK1392R9yUxg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(136003)(366004)(396003)(39860400002)(376002)(52536014)(8676002)(186003)(83380400001)(6506007)(316002)(71200400001)(2906002)(26005)(8936002)(5660300002)(478600001)(66476007)(66946007)(55236004)(76116006)(66556008)(7696005)(9686003)(55016002)(53546011)(110136005)(54906003)(86362001)(4326008)(33656002)(64756008)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: gWK2EenDW8O9O1ZslEEzVPd99JKCFbcZjbp5kfiyIPw0FbsqossLaEw68x7Ymp5SPxp2WxBEQO7ZCFwkye0l3fS0vi4djCXZcLUBDaaOlpfcomwk5fmDLvKEGiFrj90SFn/ydewYk0r7DW+8VfjD6z1i5XLQyJS9XpPVc/Jg8jdd9GC4Rbru+loWGPJg0HURyCgUgcCI7YL6/DRmZKSOl5eWyOh+5VayDvsgGe6afp1ZuuomvWtaseb18sDfTgTtCnaVUfIypdzso/e3nalnyzguwYz0GizQWHYgX4l7mXIG5vYrMgtS1T5p0K1YkTZUBCs0M3yg7hnFopdIbQTQY1yA35JuzDiqBRyVeQGnQnwEpblX0FdMubnqWaZXVAtfS23UQgMxRSSUZeUyhtr7AZw21o9FxZa++ToMRm/k5Mm8OnnGqwofRNlrvx2pnuupZUPVPfewBMC0flC9E5HsUdkhAG6pHbcrPizgFjjw48RiTrTr/NB/ZnVQcucVPnIE x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 9614d11e-53da-4fa0-c0cb-08d82e1d1679 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2020 08:56:13.7737 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: V2fnxPjgE5a0ErMcsyfGxwumNwySeYteJz74bLOt3WxNkrLqWnc6BSkgewke44ZW6Sgfz18/v9bsL8I/kMnud5BAamScBMV7ZPHOH1f447Q= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB3457 Archived-At: Subject: Re: [lamps] IDevID considerations document to secdispatch X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jul 2020 08:56:18 -0000 > Von: Spasm Im Auftrag von Tomas Gustavsson >=20 > On 2020-07-22 01:31, Michael Richardson wrote: > > > > Tomas Gustavsson wrote: > > > > > On 2020-06-28 22:51, Michael Richardson wrote: > > > 2.1.2. Off-device private key generation > > > Typically CA-generates-keystore process. Some protocols, i.e. > > > CMP/RFC4210 have standard support for encrypting the private key = sent > > > back to the client > > > > I have named this: > > a) _factory-generated_ / _mechanically-transfered_ > > Like a serial console connection, or a JTAG flash writer. > > > > for b) _factory-generated_/ _network-transfered_ > > > > yes, but what key would you use? :-) > > The device has nothing.... >=20 > Very good question, I thought the same. > In the case I see, the device don't talk directly with the PKI. > There can be a secure HW device in the factory interacting with productio= n line > on one side, and the CA on the other. It can talk something device specif= ic, > direct connect, with the device on the production line, and make the CMP = calls > to the PKI. The private key generated (by the CA) is then encrypted with = the > gateways public key (where the private key is kept in an HSM/TPM/SmartCar= d). > Yes, the "gateway" becomes a point where the private key is decrypted and > vulnerable for a short time, so it's not for every scenario. I wrote down some thoughts on central key generation in tools.ietf.org/html= /draft-ietf-lamps-lightweight-cmp-profile-02#section-4.1.6. There are some cases where an EE is not able or not willing to locally generate the new key pair. Reasons for this may be the following: o Lack of sufficient initial entropy. Note: Good random numbers are not only needed for key generation, but also for session keys and nonces in any security protocol. Therefore, we believe that a decent security architecture should anyways support good random number generation on the EE side or provide enough entropy for the RNG seed during manufacturing to guarantee good initial pseudo-random number generation. o Due to lack of computational resources, e.g., in case of RSA keys. Note: As key generation can be performed in advance to the certificate enrollment communication, it is typical not time critical. Note: Besides the initial enrollment right after the very first bootup of the device, where entropy available on the device may be insufficient, we do not see any good reason for central key generation. Note: As mentioned in Section 2.1 central key generation may be required in a push model, where the certificate response message is transferred by the PKI management entity to the EE without receiving a previous request message. - Hendrik From nobody Wed Jul 22 08:39:58 2020 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 BFD6D3A0916; Wed, 22 Jul 2020 08:39:56 -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, SPF_HELO_NONE=0.001, 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 6uhuoty_7HGd; Wed, 22 Jul 2020 08:39:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A3E43A090B; Wed, 22 Jul 2020 08:39:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6F7F238A26; Wed, 22 Jul 2020 11:19:26 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2cJHfdR22g9q; Wed, 22 Jul 2020 11:19:25 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 07E2538A24; Wed, 22 Jul 2020 11:19:25 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 322FF1CC; Wed, 22 Jul 2020 11:39:51 -0400 (EDT) From: Michael Richardson To: Tomas Gustavsson cc: secdispatch@ietf.org, spasm@ietf.org In-Reply-To: <08ab938b-deee-09f2-697b-657049cc4192@primekey.se> References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> <22303.1595374300@localhost> <08ab938b-deee-09f2-697b-657049cc4192@primekey.se> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] IDevID considerations document to secdispatch X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jul 2020 15:39:57 -0000 --=-=-= Content-Type: text/plain Tomas Gustavsson wrote: >> > 2.1.2. Off-device private key generation >> > Typically CA-generates-keystore process. Some protocols, i.e. >> > CMP/RFC4210 have standard support for encrypting the private key sent >> > back to the client >> >> I have named this: >> a) _factory-generated_ / _mechanically-transfered_ >> Like a serial console connection, or a JTAG flash writer. >> >> for b) _factory-generated_/ _network-transfered_ >> >> yes, but what key would you use? :-) >> The device has nothing.... > Very good question, I thought the same. > In the case I see, the device don't talk directly with the PKI. > There can be a secure HW device in the factory interacting with > production line on one side, and the CA on the other. It can talk > something device specific, direct connect, with the device on the > production line, and make the CMP calls to the PKI. The private key > generated (by the CA) is then encrypted with the gateways public key > (where the private key is kept in an HSM/TPM/SmartCard). > Yes, the "gateway" becomes a point where the private key is decrypted > and vulnerable for a short time, so it's not for every scenario. > The CA can be off-site, not in the factory, i.e. central organization > PKI. The the term _factory_generated_ can be a bit misleading. The CA > can of course be in the factory as well, I just don't want to trigger a > specific architecture image in the readers mind. Should I say _ca-generated_ then? >> So I think that it really has to always be used in the factory with a >> physically secure network connection. > Physically secure on the production line itself, but can be internet > between the gateway on the production line and the CA. Agreed. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8YXcYACgkQgItw+93Q 3WUnLQf+MHxRB1ZLzTykok6hRqG7iWuI+LiPf5v9th8H5QfxaYtWXWczOClJn/bE yHek+G3X6Z//ahYcAPKdUYKi4dnZkn7Bjh8FGXNclY8t/TCTyais4dkCceEYSzmJ oA4rAWR2kjxUDxVI8pL2IL+TysKIUCchgM9LFHxUt56vqb9iVvbR/2RvgGfIH0wF PYfoGpLcGZyTRScvmSxarBrVMwqY4n48cC8XfL2pVuAI7aZLTbIac+inppXydq7S qeCxovzq0zlsRVRNKyQGkquGl1iEh1+xo1BVwQ6t83GRW2PntOp2VwGMrekGDTB+ ceMp43+NMoA8MSDjDkyXnw6lDRMpkw== =Dx21 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 22 22:19:25 2020 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 0F0683A0645 for ; Wed, 22 Jul 2020 22:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=SjXbesK6; dkim=pass (1024-bit key) header.d=primekey.com header.b=gTm0sprW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZ9g4BfHP-EG for ; Wed, 22 Jul 2020 22:19:21 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924063A05A0 for ; Wed, 22 Jul 2020 22:19:20 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id 19BBF6AA059F for ; Thu, 23 Jul 2020 07:19:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1595481540; bh=PNuewqXT3GFn0CZG6ujODOZmSUkmVvSIlAzq7yEzuds=; h=Subject:To:References:From:Date:In-Reply-To:From; b=SjXbesK6zysZNIjASSICor3jN/FO60jN2Es1DZUfwjaDrhp3Uj3u2NsXQJos5jaVd WTw+LFbwIQZXZpKpwT5J5climgvqSrozRXSmh8PnPl5U2HsEIEwR7y4mt3sYqe695j tft/PdEq3P3piRY7s2qCJnN/J+mRgFnRdwz+sHWw= Received: from [192.168.1.113] (unknown [85.24.187.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id E2F876AA0599 for ; Thu, 23 Jul 2020 07:18:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1595481539; bh=PNuewqXT3GFn0CZG6ujODOZmSUkmVvSIlAzq7yEzuds=; h=Subject:To:References:From:Date:In-Reply-To:From; b=gTm0sprWpVxJV66qphF8O58MMbB2w4hXtay02GPJrANUd0TJ9nE/T2kbtgiYzpKvu R1lJjq56hLAE1o/sx3o5nN0F4A+klzGuwUI7fNe2iqWsYIUXZZDTl/iE01EiL810Me ue9d3qm1qrz1XOtc6JqccHHgbdOqYKy4aCHrnDb8= To: spasm@ietf.org References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> <22303.1595374300@localhost> <08ab938b-deee-09f2-697b-657049cc4192@primekey.se> <19924.1595432391@localhost> From: Tomas Gustavsson Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= xsBNBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAHNMFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPsLA dwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5zsBNBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAHCwF8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: <995a966c-bd9e-ca25-18a2-1e90b3c530e7@primekey.com> Date: Thu, 23 Jul 2020 07:19:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <19924.1595432391@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] IDevID considerations document to secdispatch X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 23 Jul 2020 05:19:24 -0000 On 2020-07-22 17:39, Michael Richardson wrote: > > Tomas Gustavsson wrote: >>>> 2.1.2. Off-device private key generation Typically >>>> CA-generates-keystore process. Some protocols, i.e. >>>> CMP/RFC4210 have standard support for encrypting the private >>>> key sent back to the client >>> >>> I have named this: a) _factory-generated_ / >>> _mechanically-transfered_ Like a serial console connection, or >>> a JTAG flash writer. >>> >>> for b) _factory-generated_/ _network-transfered_ >>> >>> yes, but what key would you use? :-) The device has >>> nothing.... > >> Very good question, I thought the same. In the case I see, the >> device don't talk directly with the PKI. There can be a secure HW >> device in the factory interacting with production line on one >> side, and the CA on the other. It can talk something device >> specific, direct connect, with the device on the production line, >> and make the CMP calls to the PKI. The private key generated (by >> the CA) is then encrypted with the gateways public key (where the >> private key is kept in an HSM/TPM/SmartCard). Yes, the "gateway" >> becomes a point where the private key is decrypted and vulnerable >> for a short time, so it's not for every scenario. > >> The CA can be off-site, not in the factory, i.e. central >> organization PKI. The the term _factory_generated_ can be a bit >> misleading. The CA can of course be in the factory as well, I >> just don't want to trigger a specific architecture image in the >> readers mind. > > Should I say _ca-generated_ then? I kind of liked Hendriks suggestion: '_infrastructure-generated_' > >>> So I think that it really has to always be used in the factory >>> with a physically secure network connection. > >> Physically secure on the production line itself, but can be >> internet between the gateway on the production line and the CA. > > Agreed. > > -- ] Never tell me the odds! | ipv6 > mesh networks [ ] Michael Richardson, Sandelman Software Works > | IoT architect [ ] mcr@sandelman.ca > http://www.sandelman.ca/ | ruby on rails [ > > > -- Michael Richardson , Sandelman Software > Works -= IPv6 IoT consulting =- > > > > > _______________________________________________ Spasm mailing list > Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm > From nobody Thu Jul 23 05:55:20 2020 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 B9F033A0A4E for ; Thu, 23 Jul 2020 05:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.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 keREmAJXF_Xm for ; Thu, 23 Jul 2020 05:55:17 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70057.outbound.protection.outlook.com [40.107.7.57]) (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 0C30E3A0A4D for ; Thu, 23 Jul 2020 05:55:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ehv42NqhZkhxQe5n+b4odBppKlfAfNeq5Og12KVjhoc4nPQf4ygc2Qpa29mNnqRwhd0aVBF57c7ra376w5fdTET+m9fe8BZi08S1NC3JnQBK5elxKQ/xWI5sdRoQmxDlVvHq4wjCERT5UgOm+oOS8oeAZZfJC21QoMMZyGAsv1xA2Tmx+BWEvhbpepw19Q9kWqtVlv29wp+Tg3JcOGfhFBerIRVbFEDybQUEIlBocnLeiMCOFfZ6fUeIfs78zGH8UvL85vWptjl3ukdd/L0AVoFqCtYa7Ktf9h3oYw+dYW0dBawdzYyIVvsQ+KRO5uy+FkZ/428B/MW1QjqHh/rt/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GjloprhL2YcGnUIUTzuvrsBI0r0PdTW6Rj6KBl37qUw=; b=gaa1O9LmZSdynVpULFUC0YYJVbsNcJsnPJSK1C+ZyIC2j2qBKZhGre1p/7c7upVGZvMi43vQxPNPfmVPgngscShugPKJ/ZL23DcxD7rKV0Ck+uZq3BVqCwtpzDuMskkPDA16wmb7DIbn5yeOSh57ZhEJrYQoFWlV6YXjVuCn0+bWmqGI5w6rcN1H5gdatn8EHpmb2uuz1dzaXgiyqKiyOVz+dqELEcL7oPMf9TzdBmSTnDeM1V86Li8zZdwrS0sDpKtJy/qVdtNGegoG2b9giscxpfrGdlz00sh1s4AxAiMeGQh8SUW1Zf0bceGzk2fATPW1wS56a7U3Otga4umFHw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GjloprhL2YcGnUIUTzuvrsBI0r0PdTW6Rj6KBl37qUw=; b=RodzTsBeMG9PYQymGpdzpWpJ/f6WaikockwPtP/P0I4gCo2UsN55hgqVWLUR3qEubHoC/l3VCfYgqTt1HgnCrN04eU6kbZH/as4tQ5vxdhay4jZVlwRzhgIzyNSw6YkcRBpYfdPWTuSNq2eaS6dGUKulye82h/+vm+I41N/BW2s= Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:184::10) by AM4PR1001MB1282.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:200:98::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.23; Thu, 23 Jul 2020 12:55:14 +0000 Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0]) by AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0%9]) with mapi id 15.20.3216.024; Thu, 23 Jul 2020 12:55:14 +0000 From: "Brockhaus, Hendrik" To: Russ Housley , "Roman D. Danyliw" CC: LAMPS WG , "david.von.oheimb@siemens.com" Thread-Topic: [lamps] draft-ietf-lamps-lightweight-cmp-profile-02 and draft-ietf-lamps-cmp-updates-02 - pre-registration of OIDs Thread-Index: AQHWWgqPfGW4tT5yqEGbylkn9PlRWqkVLFWA Content-Class: Date: Thu, 23 Jul 2020 12:55:14 +0000 Message-ID: References: <8E4BE9A8-3696-471C-BF7D-3FE0CC729C05@vigilsec.com> In-Reply-To: <8E4BE9A8-3696-471C-BF7D-3FE0CC729C05@vigilsec.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-07-23T12:55:12Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=7cc3c81b-741b-47cc-8da7-cb535bbe363e; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.148] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 74420703-de9f-4829-036e-08d82f07a4b0 x-ms-traffictypediagnostic: AM4PR1001MB1282: x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bIpTq6ovMgJEtXKpzQ14EafxgFOL/5jr5Y3uyG/k/fTFbW0s5kY/XoRyIaqRRwbg5HgxhK6cj45OwrsLEfLC2X6fSPZSnyz1DAMkElYEQXlTswtmAXq0eAZi+AzHt8hNsScN938M4He/HK4jEqgR7p6+c1EAkQBmtRH75lTHrzFK6kI4OLNm6JkgzwNwqwwbfXP3MT9K7TiyAehAKaq+HAHx4M3OwALHvoVuVuSiYsSfgKNALZ1igk+mCnc/h5HoDfsgORSwW8UmeFicFhsK2uLsqZ9OcvDZpym83JQMIzdimvC8fuqXLFfnZ3M2T02YqHChgmqXCjt6dC8OaMplV2WVlL1Kpb9YtrO9oJj4WPyC6H534PbzY5l2xN9gyjFMjfemefLgBWq5Fzsre+erJg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(346002)(396003)(376002)(39860400002)(316002)(33656002)(110136005)(2906002)(66476007)(55236004)(66556008)(478600001)(66446008)(83080400001)(54906003)(966005)(64756008)(5660300002)(53546011)(45080400002)(52536014)(186003)(55016002)(7696005)(9686003)(71200400001)(86362001)(6506007)(76116006)(8676002)(15650500001)(4326008)(107886003)(8936002)(83380400001)(66946007)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 6dqHa1ETcAaSoYqhEfJlAsVULVYhXH9fNlxo5wikN/uCTQAYwINivceb5e4Pz5BnfPuKbw0WhuzMbzcogek8M2NEarMX7yEemYJKSoS4NjZoXoIJvr1HQWciaS4hPWtxJAFz4wrqmy4Lf/fvzPQlfEPTHsSORbyCHy2u0hKdOj3uHc5ba31RhrSJOoLZLnPeFQ7ge1ED2TwPzS2XdRsmhAI8Wfc6+uDzfgcDSoYqKKcLj0FYWKjXsy0GMfpVagBey9HQY1V0jDLpac60U4LKLXT4O6tRHSjJzN7wSF4W9+VpNG8xZkMLeYpjAidRxmuge80FNENuARcCN8rxTUpP0mNIA7o36KdbRYmSg0H8rz8oCEbaPqfYd0P95ookOTovH6GRhHvzrv1YQTi46H9vcb4lCaaui6aNaHEGUDICw3meXQ+h92LjZPx+zwiZO2jkBudkW72mnxkFYaV2ersys8rzU+wVUYmitcqJjI9OJNW+wcpP4TXUBvAkwIQJZQw6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 74420703-de9f-4829-036e-08d82f07a4b0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2020 12:55:14.5677 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5mz6G4655RSLhnBVgiShpPoSoWU996FKTWwBxrUiZ7ZVhuYp4U+9gWxIqQ9g/FFCG1woemxvagQbjjIL3MhNzBIefGx0gruEZVKkpwKcbPo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR1001MB1282 Archived-At: Subject: Re: [lamps] draft-ietf-lamps-lightweight-cmp-profile-02 and draft-ietf-lamps-cmp-updates-02 - pre-registration of OIDs X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 23 Jul 2020 12:55:19 -0000 Roman, Russ Is there anything you need for the pre-registration, please let me know. - Hendrik > Von: Spasm Im Auftrag von Russ Housley >=20 > Roman: >=20 > Can we get early IANA allocation of these OIDs? >=20 > They will be allocated from these registries: > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= ana > .org%2Fassignments%2Fsmi-numbers%2Fsmi-numbers.xhtml%23smi-numbers- > 1.3.6.1.5.5.7.3&data=3D02%7C01%7Chendrik.brockhaus%40siemens.com%7 > Cbacb7408e0684503d96e08d82821b10a%7C38ae3bcd95794fd4addab42e1495 > d55a%7C1%7C0%7C637303472452586449&sdata=3DbJ%2BadCn4qVulqHPaG > fMV3i5GGMwd5Pt4TqV4HqRm21M%3D&reserved=3D0 > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= ana > .org%2Fassignments%2Fsmi-numbers%2Fsmi-numbers.xhtml%23smi-numbers- > 1.3.6.1.5.5.7.4&data=3D02%7C01%7Chendrik.brockhaus%40siemens.com%7 > Cbacb7408e0684503d96e08d82821b10a%7C38ae3bcd95794fd4addab42e1495 > d55a%7C1%7C0%7C637303472452586449&sdata=3DZUxzurbyjzuzh0z0HibNY > VyX89u%2B5HK3DD%2BljfnGmS0%3D&reserved=3D0 >=20 > I am the IANA Expert for both of these registries, and I thing early assi= gnment is > fine. >=20 > Russ >=20 >=20 >=20 > > On Jul 14, 2020, at 10:31 AM, Brockhaus, Hendrik > wrote: > > > > Russ > > > > As we are currently implementing the CMP profile, it would be great to = get a > pre-registration of the new OIDs. > > > > draft-ietf-lamps-lightweight-cmp-profile-02 > > section 4.4.2 + Appendix A - id-it-caCerts OBJECT IDENTIFIER ::=3D { > > id-it- ... } section 4.4.3 + Appendix A - id-it-rootCaKeyUpdate OBJECT > > IDENTIFIER ::=3D { id-it- ... } section 4.4.4 + Appendix A - > > id-it-certReqTemplate OBJECT IDENTIFIER ::=3D { id-it- ... } > > > > draft-ietf-lamps-updates-cmp-02 > > section 2.2 + Appendix A - id-kp-cmKGA OBJECT IDENTIFIER ::=3D { id-kp- > > ... } > > > > - Hendrik >=20 From nobody Thu Jul 23 07:22:12 2020 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 243F73A083C for ; Thu, 23 Jul 2020 07:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.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 8qBsWdTjk1Dm for ; Thu, 23 Jul 2020 07:22:08 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 85E7F3A083B for ; Thu, 23 Jul 2020 07:22:08 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 06NEM7ZY040353; Thu, 23 Jul 2020 10:22:07 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 06NEM7ZY040353 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1595514127; bh=GlrkEzet6KVc4nh+WfCdyFCCotQRqfD58HqYi8UBsvw=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=jFyJyddDy5E3fnkQvn96RdelZJfpIUPtKQy4xjwjqNv9sQLZOxsmirE9q9rL1/pLA cIeLGrhZEW3PQrWTFkOKu728EHooSocgM9bSxYmc68k8H1kzXQyCFJ/yePsuHu8e7y txBXCgXO/kOr0ngvl2po2XPiorCnKcjRP0SaGDco= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 06NEM0EE016019; Thu, 23 Jul 2020 10:22:00 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by CASCADE.ad.sei.cmu.edu (10.64.28.248) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 23 Jul 2020 10:21:59 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Thu, 23 Jul 2020 10:21:59 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Thu, 23 Jul 2020 10:21:59 -0400 From: Roman Danyliw To: Russ Housley CC: LAMPS WG , "david.von.oheimb@siemens.com" , "Brockhaus, Hendrik" Thread-Topic: [lamps] draft-ietf-lamps-lightweight-cmp-profile-02 and draft-ietf-lamps-cmp-updates-02 - pre-registration of OIDs Thread-Index: AQHWWgqNtFVFfAgCeE6It9YO+24RlqkVRQPA Date: Thu, 23 Jul 2020 14:21:58 +0000 Message-ID: References: <8E4BE9A8-3696-471C-BF7D-3FE0CC729C05@vigilsec.com> In-Reply-To: <8E4BE9A8-3696-471C-BF7D-3FE0CC729C05@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] draft-ietf-lamps-lightweight-cmp-profile-02 and draft-ietf-lamps-cmp-updates-02 - pre-registration of OIDs X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 23 Jul 2020 14:22:10 -0000 Hi! I approve this early allocation. Regards, Roman > -----Original Message----- > From: Russ Housley > Sent: Tuesday, July 14, 2020 2:14 PM > To: Roman Danyliw > Cc: LAMPS WG ; david.von.oheimb@siemens.com; > Brockhaus, Hendrik > Subject: Re: [lamps] draft-ietf-lamps-lightweight-cmp-profile-02 and draf= t-ietf- > lamps-cmp-updates-02 - pre-registration of OIDs >=20 > Roman: >=20 > Can we get early IANA allocation of these OIDs? >=20 > They will be allocated from these registries: > https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- > numbers-1.3.6.1.5.5.7.3 > https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- > numbers-1.3.6.1.5.5.7.4 >=20 > I am the IANA Expert for both of these registries, and I thing early assi= gnment is > fine. >=20 > Russ >=20 >=20 >=20 > > On Jul 14, 2020, at 10:31 AM, Brockhaus, Hendrik > wrote: > > > > Russ > > > > As we are currently implementing the CMP profile, it would be great to = get a > pre-registration of the new OIDs. > > > > draft-ietf-lamps-lightweight-cmp-profile-02 > > section 4.4.2 + Appendix A - id-it-caCerts OBJECT IDENTIFIER ::=3D { > > id-it- ... } section 4.4.3 + Appendix A - id-it-rootCaKeyUpdate OBJECT > > IDENTIFIER ::=3D { id-it- ... } section 4.4.4 + Appendix A - > > id-it-certReqTemplate OBJECT IDENTIFIER ::=3D { id-it- ... } > > > > draft-ietf-lamps-updates-cmp-02 > > section 2.2 + Appendix A - id-kp-cmKGA OBJECT IDENTIFIER ::=3D { id-kp- > > ... } > > > > - Hendrik From nobody Thu Jul 23 08:33:14 2020 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 9D3393A0A43 for ; Thu, 23 Jul 2020 08:33:12 -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, SPF_HELO_NONE=0.001, 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 oYxS8ZmEg8sj for ; Thu, 23 Jul 2020 08:33:11 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6943A0A30 for ; Thu, 23 Jul 2020 08:33:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 18D8A38A39; Thu, 23 Jul 2020 11:12:42 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Mx7Wirali5xf; Thu, 23 Jul 2020 11:12:41 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7236B38A3E; Thu, 23 Jul 2020 11:12:41 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8C2821CB; Thu, 23 Jul 2020 11:33:08 -0400 (EDT) From: Michael Richardson To: Tomas Gustavsson cc: spasm@ietf.org In-Reply-To: <995a966c-bd9e-ca25-18a2-1e90b3c530e7@primekey.com> References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> <22303.1595374300@localhost> <08ab938b-deee-09f2-697b-657049cc4192@primekey.se> <19924.1595432391@localhost> <995a966c-bd9e-ca25-18a2-1e90b3c530e7@primekey.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] IDevID considerations document to secdispatch X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 23 Jul 2020 15:33:13 -0000 --=-=-= Content-Type: text/plain Tomas Gustavsson wrote: >> Should I say _ca-generated_ then? > I kind of liked Hendriks suggestion: '_infrastructure-generated_' I'm going with that. BTW: There is exactly the same set of considerations with initial(default) passwords. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8ZrbQACgkQgItw+93Q 3WWU2Qf/SoGLZGSt/JGeUTUFU66lLqE5ZqhBRTfouzQ6GyUSSzaVaNQIh9Yis5wb X1NQVxmr2kmDmMUGf5xyUy1nIWnA7SmqS8EirBUWz3T7ZzdL9vqFVpRdFvXWM82d l5pP2+6rNxBoF8KPTQEwnIkLUEjPvcVy9t3qKEdjFtxzXKpShJXfawExjzj441wT D9zp0bMcNV3OJipZkeYxEg7vpWjlNBNScy8uGBQDLGTLNsEDYdJUTuHeNOMi0iMh NMUJ5pYqOg4vIBMS+f2WDSA3ahRs1O5sRLFgwvYRWnjRwVuUlbkZQKefzJVC7+SC 3vftz9iqXK/zQxOg5k3U3z1bZEVlsg== =GDpS -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 23 08:39:41 2020 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 E254E3A094A for ; Thu, 23 Jul 2020 08:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 g8uI94P3owKe for ; Thu, 23 Jul 2020 08:39:38 -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 86D0A3A081D for ; Thu, 23 Jul 2020 08:39:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2D23E300B10 for ; Thu, 23 Jul 2020 11:39: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 srP76mioVWeh for ; Thu, 23 Jul 2020 11:39:34 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id D11DE300A55 for ; Thu, 23 Jul 2020 11:39:34 -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 12.4 \(3445.104.15\)) Message-Id: <91892BED-A8A5-454C-8CE8-1453C47D34C0@vigilsec.com> Date: Thu, 23 Jul 2020 11:39:36 -0400 To: LAMPS WG X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: [lamps] Problems with the Abstract and Introduction of draft-ietf-lamps-header-protection-00 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 23 Jul 2020 15:39:40 -0000 I really do not like the Abstract and Introduction of this = Internet-Draft. ABSTRACT RFC 8551 says: 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. When an S/MIME message is received, if the top-level protected MIME entity has a Content-Type of message/rfc822, it can be assumed that the intent was to provide header protection. This entity SHOULD be presented as the top-level message, taking into account header merging issues as previously discussed. We have discussed the problems with this approach, but that is not what = the Abstract says. It says: Privacy and security issues with email header protection in S/MIME have been identified for some time. However, the desire to fix these issues has only recently been expressed in the IETF LAMPS Working Group. The existing S/MIME specification is to be updated regarding header protection. I would be much happier if the Abstract listed a few problems at a very = high level with the approach in RFC 8551, and then said that this = document addresses them. INTRODUCTION I do not understand the reason for the first paragraph of the = Introduction to talk about DKIM, SPF, and DMARC. This might come up = much later in the Introduction if you want to make the point that some = parts of the message headers can be integrity protected by non-S/MIME = protocols, but it seems like a really strange way to start. I think that the Introductions should state that the high-level = objective is to provide end-to-end protection for header fields, and = then say what the shortcomings are with the RFC 8551 mechanism, and then = say how they are improved by this mechanism defined here. Section 2 has = place holders for some of this discussion, so it might be fine to point = there. Something about backward compatibility, even if it is a forward pointer, = needs to be said in the Introduction. Finally, the Introduction should point out that the mechanism is also = applicable to PGP/MIME. Russ= From nobody Thu Jul 23 08:42:24 2020 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 753053A0999 for ; Thu, 23 Jul 2020 08:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 q4VQcqbxgrSY for ; Thu, 23 Jul 2020 08:42:21 -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 0C68B3A0855 for ; Thu, 23 Jul 2020 08:42:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A2A36300B39 for ; Thu, 23 Jul 2020 11:42:18 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TxMiUmsl0ap9 for ; Thu, 23 Jul 2020 11:42:15 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id ABC2C300A55; Thu, 23 Jul 2020 11:42:15 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_8B585162-E091-4005-8726-AE332619495B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Date: Thu, 23 Jul 2020 11:42:17 -0400 References: Cc: LAMPS WG , "david.von.oheimb@siemens.com" , "Brockhaus, Hendrik" To: IANA Message-Id: X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: [lamps] Fwd: draft-ietf-lamps-lightweight-cmp-profile-02 and draft-ietf-lamps-cmp-updates-02 - pre-registration of OIDs X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 23 Jul 2020 15:42:23 -0000 --Apple-Mail=_8B585162-E091-4005-8726-AE332619495B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear IANA Functions Operator: As you can see from the attached messages, the Security AD has approved = early allocation. Please make the following early allocation = assignments. = https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers= -1.3.6.1.5.5.7.3 id-kp-cmKGA = [draft-ietf-lamps-cmp-updates] = https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers= -1.3.6.1.5.5.7.4 id-it-caCerts = [draft-ietf-lamps-lightweight-cmp-profile] id-it-rootCaKeyUpdate = [draft-ietf-lamps-lightweight-cmp-profile] id-it-certReqTemplate = [draft-ietf-lamps-lightweight-cmp-profile] Thanks, Russ > From: Roman Danyliw > Subject: Re: [lamps] draft-ietf-lamps-lightweight-cmp-profile-02 and = draft-ietf-lamps-cmp-updates-02 - pre-registration of OIDs > Date: July 23, 2020 at 10:21:58 AM EDT > To: Russ Housley > Cc: LAMPS WG , "david.von.oheimb@siemens.com" = , "Brockhaus, Hendrik" = >=20 > Hi! >=20 > I approve this early allocation. >=20 > Regards, > Roman >=20 >> -----Original Message----- >> From: Russ Housley >> Sent: Tuesday, July 14, 2020 2:14 PM >> To: Roman Danyliw >> Cc: LAMPS WG ; david.von.oheimb@siemens.com; >> Brockhaus, Hendrik >> Subject: Re: [lamps] draft-ietf-lamps-lightweight-cmp-profile-02 and = draft-ietf- >> lamps-cmp-updates-02 - pre-registration of OIDs >>=20 >> Roman: >>=20 >> Can we get early IANA allocation of these OIDs? >>=20 >> They will be allocated from these registries: >> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- >> numbers-1.3.6.1.5.5.7.3 >> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- >> numbers-1.3.6.1.5.5.7.4 >>=20 >> I am the IANA Expert for both of these registries, and I thing early = assignment is >> fine. >>=20 >> Russ >>=20 >>=20 >>=20 >>> On Jul 14, 2020, at 10:31 AM, Brockhaus, Hendrik >> wrote: >>>=20 >>> Russ >>>=20 >>> As we are currently implementing the CMP profile, it would be great = to get a >> pre-registration of the new OIDs. >>>=20 >>> draft-ietf-lamps-lightweight-cmp-profile-02 >>> section 4.4.2 + Appendix A - id-it-caCerts OBJECT IDENTIFIER ::=3D { >>> id-it- ... } section 4.4.3 + Appendix A - id-it-rootCaKeyUpdate = OBJECT >>> IDENTIFIER ::=3D { id-it- ... } section 4.4.4 + Appendix A - >>> id-it-certReqTemplate OBJECT IDENTIFIER ::=3D { id-it- ... } >>>=20 >>> draft-ietf-lamps-updates-cmp-02 >>> section 2.2 + Appendix A - id-kp-cmKGA OBJECT IDENTIFIER ::=3D { = id-kp- >>> ... } >>>=20 >>> - Hendrik >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --Apple-Mail=_8B585162-E091-4005-8726-AE332619495B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear IANA Functions Operator:

As you can see from the attached = messages, the Security AD has approved early allocation.  Please = make the following early allocation assignments.

https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#= smi-numbers-1.3.6.1.5.5.7.3

id-kp-cmKGA = [draft-ietf-lamps-cmp-updates]


https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#= smi-numbers-1.3.6.1.5.5.7.4

= id-it-caCerts = [draft-ietf-lamps-lightweight-cmp-profile]
= id-it-rootCaKeyUpdate = [draft-ietf-lamps-lightweight-cmp-profile]
= id-it-certReqTemplate = [draft-ietf-lamps-lightweight-cmp-profile]

Thanks,
  Russ


From: Roman Danyliw <rdd@cert.org>
Subject: Re: [lamps] draft-ietf-lamps-lightweight-cmp-profile-02 and = draft-ietf-lamps-cmp-updates-02 - pre-registration of OIDs
Date: = July 23, 2020 at 10:21:58 AM = EDT
To: = Russ Housley <housley@vigilsec.com>
Cc: LAMPS WG <spasm@ietf.org>, "david.von.oheimb@siemens.com" <david.von.oheimb@siemens.com>, "Brockhaus, Hendrik" = <hendrik.brockhaus@siemens.com>

Hi!

I approve this early = allocation.

Regards,
Roman

-----Original Message-----
From: Russ Housley = <housley@vigilsec.com>
Sent: Tuesday, = July 14, 2020 2:14 PM
To: Roman Danyliw <rdd@cert.org>
Cc: LAMPS WG <spasm@ietf.org>; david.von.oheimb@siemens.com;
Brockhaus, = Hendrik <hendrik.brockhaus@siemens.com>
Subject: = Re: [lamps] draft-ietf-lamps-lightweight-cmp-profile-02 and = draft-ietf-
lamps-cmp-updates-02 - pre-registration of = OIDs

Roman:

Can = we get early IANA allocation of these OIDs?

They will be allocated from these registries:
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#= smi-
numbers-1.3.6.1.5.5.7.3
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#= smi-
numbers-1.3.6.1.5.5.7.4

I = am the IANA Expert for both of these registries, and I thing early = assignment is
fine.

Russ



On Jul 14, 2020, at 10:31 AM, Brockhaus, = Hendrik
<hendrik.brockhaus@siemens.com> = wrote:

Russ

As we are currently = implementing the CMP profile, it would be great to get a
pre-registration of the new OIDs.

draft-ietf-lamps-lightweight-cmp-profile-02
section 4.4.2 + Appendix A - id-it-caCerts OBJECT IDENTIFIER = ::=3D {
id-it- ... } section 4.4.3 + Appendix A - = id-it-rootCaKeyUpdate OBJECT
IDENTIFIER ::=3D { id-it- ... = } section 4.4.4 + Appendix A -
id-it-certReqTemplate = OBJECT IDENTIFIER ::=3D { id-it- ... }

draft-ietf-lamps-updates-cmp-02
section 2.2 + = Appendix A - id-kp-cmKGA OBJECT IDENTIFIER ::=3D { id-kp-
... }

- Hendrik

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

= --Apple-Mail=_8B585162-E091-4005-8726-AE332619495B-- From nobody Thu Jul 23 08:54:05 2020 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 B7A4C3A0AAC for ; Thu, 23 Jul 2020 08:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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 J2JySAsaJzRS for ; Thu, 23 Jul 2020 08:54:03 -0700 (PDT) Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) (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 3A1923A0AAA for ; Thu, 23 Jul 2020 08:54:03 -0700 (PDT) Received: by mail-ot1-f54.google.com with SMTP id 95so4680957otw.10 for ; Thu, 23 Jul 2020 08:54:03 -0700 (PDT) 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=qfM//iPd0VTfDGtnuB0O1ZC6QDgJ2sbKYn2PW+Lmfn0=; b=BbPdG9Em9rpiJ22MyBb4JyHRhpIycTabKabA4GwrtTRh+S+TdUGDlkCA4j8IRTcQ6K Pnnmap2FDyd+vrnpAQvamaLUK+AdaQNNnxZdc78VwnjTAeEWT/unS+Tt5ZiFDXurYbt6 /vjZGXTUOCQQTW092e5lRe8I63R4IvVBqZVOcxGJBPLw1mrIW5xO9w3sCx+Gbm6R3SAR +hosuR3a2VhDM0eWs1vacT/TVw1LPwTvxxVAWVovY9c4WC2zdBMUoXzSigxq4XizfKnp WFqt+6XZjQuoIdhAAGZEmkDR9swa1mdfxOK81ggiQMKgxE/VYJD+mz83wdERYzjs+8Qb WWag== X-Gm-Message-State: AOAM532zDScyt768iFejVeiyHJnM+2sOE1co4ea7WOhEu5zgmzV48efT fWjFOq9Z3oMHUEkgnw/Aj/BE3r/F9LRFZdG8NWLa/c6caAA= X-Google-Smtp-Source: ABdhPJwKcRSOlQde6EtnS1TO/7m8BAEIfiPNvJ2hxoPLhzTOxjqPnsjfsW9wq4dV4x6pvoQMBaGtPU/5dJ38azpxrcE= X-Received: by 2002:a9d:6a12:: with SMTP id g18mr5117676otn.155.1595519642458; Thu, 23 Jul 2020 08:54:02 -0700 (PDT) MIME-Version: 1.0 References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> <22303.1595374300@localhost> <08ab938b-deee-09f2-697b-657049cc4192@primekey.se> <19924.1595432391@localhost> <995a966c-bd9e-ca25-18a2-1e90b3c530e7@primekey.com> <19403.1595518388@localhost> In-Reply-To: <19403.1595518388@localhost> From: Phillip Hallam-Baker Date: Thu, 23 Jul 2020 11:53:51 -0400 Message-ID: To: Michael Richardson Cc: Tomas Gustavsson , SPASM Content-Type: multipart/alternative; boundary="0000000000008561c305ab1dddba" Archived-At: Subject: Re: [lamps] IDevID considerations document to secdispatch X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 23 Jul 2020 15:54:05 -0000 --0000000000008561c305ab1dddba Content-Type: text/plain; charset="UTF-8" Just thought I would weigh in with some points. There are some device vendors who made use of XKMS to provision private keys to devices. As far as I am aware, that is the only standards based effort that got anywhere in that space. The rest is not just proprietary, it is a mess. The bane of enterprise software and services is that everyone who is paying seven figures for a project can and does demand special treatment. There are no good choices for creating key pairs. All have drawbacks. * Any key generated by the manufacturer can leak at multiple points in the supply chain. But it can be welded to the device in such a way that it cannot be extracted without extreme persuasion. * Any key that is generated by the device can also be compromised through an intentional side channel or by weak key generation. And once generated can usually be extracted. * Any key that is installed from an external source during onboarding can be compromised during that process. So none of the solutions are good. What should we do? The best answer is to do all of them and combine the keys using threshold techniques. That allows us to get a key that combines all the properties we want and is only vulnerable if there are multiple failures. The math is explained in this draft: https://tools.ietf.org/id/draft-hallambaker-threshold-02.html There are some caveats. While the private key is as strong as the strongest of the input keys, the public key is only as good as the weakest public key. Which means that the validation process has to be carefully designed. There are approaches I took out of the drafts that are secure but only when implemented exactly right so I have described a conservative approach. --0000000000008561c305ab1dddba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just thought I would weigh in with some points.

There are some device vendors who made= use of XKMS to provision private keys to devices. As far as I am aware, th= at is the only standards based effort that got anywhere in that space. The = rest is not just proprietary, it is a mess. The bane of enterprise software= and services is that everyone who is paying seven figures for a project ca= n and does demand special treatment.

There are no good choices for creating key pairs. All have draw= backs.=C2=A0
* Any key ge= nerated by the manufacturer can leak at multiple points in the supply chain= . But it can be welded to the device in such a way that it cannot be extrac= ted without extreme persuasion.

* Any key that is generated by the device can also be compromised th= rough an intentional side channel or by weak key generation. And once gener= ated can usually be extracted.

* Any key that is installed from an external source during onboarding= can be compromised during that process.

So none of the solutions are good. What should we do? The b= est answer is to do all of them and combine the keys using threshold techni= ques. That allows us to get a key that combines all the properties we want = and is only vulnerable if there are multiple failures.

The math is explained in this draft:
https://tools.ietf.org/i= d/draft-hallambaker-threshold-02.html

There are some caveats. While the private key is as st= rong as the strongest of the input keys, the public key is only as good as = the weakest public key. Which means that the validation process has to be c= arefully designed. There are approaches I took out of the drafts that are s= ecure but only when implemented exactly right so I have described a conserv= ative approach.
--0000000000008561c305ab1dddba-- From nobody Thu Jul 23 10:33:29 2020 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 79EC93A0C63; Thu, 23 Jul 2020 10:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 ocA71TTpg8CT; Thu, 23 Jul 2020 10:33:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB9A3A0C64; Thu, 23 Jul 2020 10:33:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 231F838A30; Thu, 23 Jul 2020 13:12:51 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dY7-hBsZd7gp; Thu, 23 Jul 2020 13:12:50 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 40B1E389AA; Thu, 23 Jul 2020 13:12:50 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 640939A; Thu, 23 Jul 2020 13:33:17 -0400 (EDT) From: Michael Richardson To: "Brockhaus\, Hendrik" cc: "spasm\@ietf.org" , "secdispatch\@ietf.org" , Tomas Gustavsson In-Reply-To: References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> <22303.1595374300@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] IDevID considerations document to secdispatch X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 23 Jul 2020 17:33:25 -0000 --=-=-= Content-Type: text/plain Brockhaus, Hendrik wrote: > I use the image of the "birth certificate" to better explain the attributes of an IDevID certificate. > - Issued at manufacturing time (in Germany the birth certificate is a > simple sheet stamped and signed by the local register office) > - The enrollment process requires some organizational/physical > security, as there is nothing to derive trust from at that point in > time (in Germany the father or mother have to request the birth > certificate personally. They need to define the name of the child in > front of the register officer and need present a conformation letter > from the hospital or midwife about the date of birth) In Canada, I think the birth certificate is signed by doctor or midwife. > - It lasts as long as the device is used (in Germany a birth > certificate has no validity and it is difficult to get a new one, if > you lost yours) Thus IDevID never expire. > - It is required for initial authentication to request an operational > certificate (in Germany the birth certificate is required if you > request a national ID card or a passport) > - It should not be used for day-to-day operational tasks (you would not > use the birth certificate to identify yourself other than to the > register office. Only rarely it is requested, e.g., when becoming a > governmental or public official) But, you don't use your IDevID for day-to-day activities. One needs an onboarding protocol to talk to an organizational CA to get the LDevID. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8Zyd0ACgkQgItw+93Q 3WVggQf/b9SvHfuMXB3LsWAatnEA6kb4w2mvbg2zi07/0n5TEI3vWKVWEJW5svYQ YfSYlB2dMbjH5+lfJyPHsznJ8FJqYcx5+iLDhIUITZUsF1uwKFR5UF0jnvsSsE0r m30A5GE8+W08Oes4vFq/2p6E/l3nKZGi8XFB/FG75SdbOKGV9qLEbGd5LH1lwDY+ cXW6EKQa5mz1f4+iTuOD0pp1N8FpU8Zfu/AMHSvK+At4ai8PGgrBOd1I6rLxMD8M 4T/q/iI+mGp4SAtD17ka8GWECuuTV9EnyNbxf/XcDa7qgwBzJwMFMBT9VyEUo3dV /ZIiK60GjLHC6yXQgEwlwKj45gbW/Q== =OlPZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 23 12:35:02 2020 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 059F43A0CF3; Thu, 23 Jul 2020 12:35:01 -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, SPF_HELO_NONE=0.001, 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 CUXcAJ7CMsSS; Thu, 23 Jul 2020 12:34:58 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96CB03A0C4D; Thu, 23 Jul 2020 12:34:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id DD94438A32; Thu, 23 Jul 2020 15:14:29 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TsC2yniYBvz5; Thu, 23 Jul 2020 15:14:29 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D397638A06; Thu, 23 Jul 2020 15:14:28 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1D8851CB; Thu, 23 Jul 2020 15:34:56 -0400 (EDT) From: Michael Richardson To: Phillip Hallam-Baker , SPASM , secdispatch@ietf.org In-Reply-To: References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> <22303.1595374300@localhost> <08ab938b-deee-09f2-697b-657049cc4192@primekey.se> <19924.1595432391@localhost> <995a966c-bd9e-ca25-18a2-1e90b3c530e7@primekey.com> <19403.1595518388@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] IDevID considerations document to secdispatch X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 23 Jul 2020 19:35:01 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Phillip Hallam-Baker wrote: > Just thought I would weigh in with some points. Thank you. I don't quite understand how XKMS can be used to provision private keys, but I do agree that I do agree that the rest is a mess. My goal is to just collect and describe the methods. I originally started with the idea of being prescriptive about the shape of of the PKI that is used to provision the certificates. I am pulling back from the prescriptive part, and instead I intend to just describe the different considerations, giving them names. > There are no good choices for creating key pairs. All have drawbacks. > * Any key generated by the manufacturer can leak at multiple points i= n the > supply chain. But it can be welded to the device in such a way that it > cannot be extracted without extreme persuasion. > * Any key that is generated by the device can also be compromised thr= ough > an intentional side channel or by weak key generation. And once gener= ated > can usually be extracted. I am interested in why you say that the key can be welded into place by the factory, but a key generated internally can't be welded in place in the same way. I think both strong and weak ways are possible in each case. > * Any key that is installed from an external source during onboarding= can > be compromised during that process. Agreed. > So none of the solutions are good. What should we do? The best answer= is to > do all of them and combine the keys using threshold techniques. That = allows > us to get a key that combines all the properties we want and is only > vulnerable if there are multiple failures. > The math is explained in this draft: > https://tools.ietf.org/id/draft-hallambaker-threshold-02.html I would like to include this in my list, but we have a chicken and egg situation on it. > There are some caveats. While the private key is as strong as the str= ongest > of the input keys, the public key is only as good as the weakest publ= ic > key. Which means that the validation process has to be carefully desi= gned. > There are approaches I took out of the drafts that are secure but onl= y when > implemented exactly right so I have described a conservative approach. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8Z5l8ACgkQgItw+93Q 3WVMoggAs1LtngZYGQKV16PwX6++J5WeWlLMeQbOG1AM80zUL1LkgCZGmvYri8Ha 07SKo4NTjS0ZFGv2/9nPbx7Zfkub7Bzj68HgkKFsGaCWO6Ss+1Qduh/qDOAOQg8O 90W555c+dcdgQDNKPtabd8ApjrgV+cbzoYLqKViVFWzotkMQ33C4+isDNALw54Os uTDTRznp6pIIyOA7dWl6IJDA2eCigXcR8VOk7YjoGC27P44NAVbSxQ/CY27IF8X/ mcS+STW4EteWVqEtBQIZMsJBPtvt4/ksO+L1jsz+ktVFfCFIsYnyfbM/SNIsv6ok zgGyCTCg7EB5d7jZ8Ah8YpgNTkvv4Q== =uyML -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 23 13:44:22 2020 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 E955A3A0D8C for ; Thu, 23 Jul 2020 13:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 C6HWdG1Sp1uV for ; Thu, 23 Jul 2020 13:44:18 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [IPv6:2a01:4f8:c0c:15fc::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 6FC933A0D88 for ; Thu, 23 Jul 2020 13:44:17 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jyi4d-000za1-I0; Thu, 23 Jul 2020 22:44:15 +0200 Date: Thu, 23 Jul 2020 22:44:13 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Russ Housley cc: LAMPS WG In-Reply-To: <91892BED-A8A5-454C-8CE8-1453C47D34C0@vigilsec.com> Message-ID: References: <91892BED-A8A5-454C-8CE8-1453C47D34C0@vigilsec.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Archived-At: Subject: Re: [lamps] Problems with the Abstract and Introduction of draft-ietf-lamps-header-protection-00 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 23 Jul 2020 20:44:21 -0000 Hi Russ Thanks for your feedback. I agree with you that the Abstract and Introduction Sections have lots of room for improvement. In fact, I focussed my limited time to the Specification and Use Case Sections, leaving other sections to be improved/fixed at some later stage. Any text with suggestions to replace and/or improve the Abstract and Introduction Sections is welcome. cheers, Bernie -- http://ucom.ch/ Modern Telephony Solutions and Tech Consulting for Internet Technology On Thu, 23 Jul 2020, Russ Housley wrote: > I really do not like the Abstract and Introduction of this Internet-Draft. > > ABSTRACT > > RFC 8551 says: > > 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. > > When an S/MIME message is received, if the top-level protected MIME > entity has a Content-Type of message/rfc822, it can be assumed that > the intent was to provide header protection. This entity SHOULD be > presented as the top-level message, taking into account header > merging issues as previously discussed. > > We have discussed the problems with this approach, but that is not what the Abstract says. It says: > > Privacy and security issues with email header protection in S/MIME > have been identified for some time. However, the desire to fix these > issues has only recently been expressed in the IETF LAMPS Working > Group. The existing S/MIME specification is to be updated regarding > header protection. > > I would be much happier if the Abstract listed a few problems at a very high level with the approach in RFC 8551, and then said that this document addresses them. > > INTRODUCTION > > I do not understand the reason for the first paragraph of the Introduction to talk about DKIM, SPF, and DMARC. This might come up much later in the Introduction if you want to make the point that some parts of the message headers can be integrity protected by non-S/MIME protocols, but it seems like a really strange way to start. > > I think that the Introductions should state that the high-level objective is to provide end-to-end protection for header fields, and then say what the shortcomings are with the RFC 8551 mechanism, and then say how they are improved by this mechanism defined here. Section 2 has place holders for some of this discussion, so it might be fine to point there. > > Something about backward compatibility, even if it is a forward pointer, needs to be said in the Introduction. > > Finally, the Introduction should point out that the mechanism is also applicable to PGP/MIME. > > Russ > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Sat Jul 25 13:24:08 2020 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 9C42F3A0AA3 for ; Sat, 25 Jul 2020 13:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 HYyugs7ykvQs for ; Sat, 25 Jul 2020 13:24:05 -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 347CE3A0AA6 for ; Sat, 25 Jul 2020 13:24:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D60B1300B6C for ; Sat, 25 Jul 2020 16:24:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DqtV-UxLqoUV for ; Sat, 25 Jul 2020 16:24:01 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id ADCF6300A55 for ; Sat, 25 Jul 2020 16:24:01 -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 12.4 \(3445.104.15\)) Message-Id: <12D02997-1D75-4694-AC30-CA349AEC31F1@vigilsec.com> References: To: LAMPS WG Date: Sat, 25 Jul 2020 16:24:03 -0400 X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: [lamps] Visit NomCom during office hours X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 25 Jul 2020 20:24:07 -0000 If anyone is interested in finding out more about NomCom or about = standing for a leadership position, please visit with NomCom during = office hours next week. Russ > I wanted to let everyone know that NomCom will be holding some office = hours next week. If you want to stop by and talk with us (just to say = Hi, ask about NomCom, ask about being a nominee for the various I* = positions, etc.), we'd love to see and hear from you. >=20 > The date and times (which are also posted on the IETF 108 Agenda) are: >=20 > Monday, July 27, 16:00-17:00 UTC WebEx: = https://ietf.webex.com/ietf/j.php?MTID=3Dm13c41ae118e538b6d25efb25d41307ee= > Tuesday, July 28, 09:30-10:30 UTC WebEx: = https://ietf.webex.com/ietf/j.php?MTID=3Dm6132b48c3eac5469a41043ce55dada20= > Thursday, July 30, 20:00-21:00 UTC WebEx: = https://ietf.webex.com/ietf/j..php?MTID=3Dmf7ce451931e35818fd7b3bf44abd102= 6 >=20 > In addition to being available by WebEx, those of us who can will = simultaneously be on Gather.Town (possibly in a special NomCom corner). = To find us, the easiest way is to go to the Participants list (at right = of the Gather screen), find "Barbara Stark", left click on my name and = select "Locate". >=20 > See you next week! > Barbara=20 >=20 From nobody Sun Jul 26 12:33:46 2020 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 04E083A13E4 for ; Sun, 26 Jul 2020 12:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 0IvtqCs2IXzO for ; Sun, 26 Jul 2020 12:33: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 58F1B3A13E8 for ; Sun, 26 Jul 2020 12:33:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id AC0BE300B71 for ; Sun, 26 Jul 2020 15:33: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 3rGsaH4QSAkG for ; Sun, 26 Jul 2020 15:33:38 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 5377B3005C6; Sun, 26 Jul 2020 15:33:38 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: Date: Sun, 26 Jul 2020 15:33:39 -0400 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <97AAAE51-45E0-4363-ACAD-99144085E710@vigilsec.com> References: To: "Brockhaus, Hendrik" X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: [lamps] draft-ietf-lamps-cmp-updates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jul 2020 19:33:45 -0000 IANA has made the assignment for id-kp-cmKGA. I was looking at Appendix A in the draft, and it is not completely clear = to me what the revised ASN.1 module looks like: First, the source of some imports is updated. No big deal. Second, in CertifiedKeyPair and CertOrEncCert, the EncryptedValue os = replaced with EncryptedKey. Third, id-it-revPassphrase (which is in a comment) is associated with = EncryptedKey instead of EncryptedValue. Fourth, id-kp-cmKGA is added to the list of EKU values, but these do not = appear in the previous module anywhere. Where do they belong? Russ= From nobody Sun Jul 26 19:00:01 2020 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 A3AD93A07BB for ; Sun, 26 Jul 2020 18:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.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 MfZWroImqRmZ for ; Sun, 26 Jul 2020 18:59:58 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 580B83A07C5 for ; Sun, 26 Jul 2020 18:59:57 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 06R1xuDi005809 for ; Sun, 26 Jul 2020 21:59:57 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 06R1xuDi005809 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1595815197; bh=oP8PTA1SAdfMF98qHy/Zm8k1qtZd3QmrwKtSBoJCiQQ=; h=From:To:Subject:Date:From; b=Llc89eiAtyNCfGHDAdMJbUAqbOWZHTo8NMl914XHx2sFTIDBx3pjNNcApY0bDYCz9 NJey16LBNwQm++1PiI6PWOxtbhITMz7vJXQBcCa6nkH3plyxzcVjTi6dr2yPxxBItY P22KkHUT7tcZcrSnCN6tIXAOeovP4GfI299sseCc= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 06R1xqcS019516 for ; Sun, 26 Jul 2020 21:59:53 -0400 Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASCADE.ad.sei.cmu.edu (10.64.28.248) with Microsoft SMTP Server (TLS) id 14.3.487.0; Sun, 26 Jul 2020 21:59:52 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Sun, 26 Jul 2020 21:59:52 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Sun, 26 Jul 2020 21:59:52 -0400 From: Roman Danyliw To: LAMPS WG Thread-Topic: AD Review of draft-ietf-lamps-ocsp-nonce-02 Thread-Index: AdZjuO9aZUqo3FPnSZiEUxxNW+T6mg== Date: Mon, 27 Jul 2020 01:59:50 +0000 Message-ID: <79447b68da0d4cd09757e531caee14d9@cert.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [lamps] AD Review of draft-ietf-lamps-ocsp-nonce-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 27 Jul 2020 02:00:00 -0000 Hi! I conducted an AD review of draft-ietf-lamps-ocsp-nonce-02. Thanks for the= work on this document to harden the nonce extension of RFC 6960. Below is= my feedback: ** Section 2. Editorial. s/Following is the list/The following is a list/ ** Section 2.1. This section appears to be a complete rewrite of the text = in 4.4.1 of RFC6960 with the exception of the definitions of id-pkix-ocsp a= nd id-pkix-ocsp-nonce. To eliminate confusion, I would recommend you add t= hese definitions here (id-pkix-ocsp and id-pkix-ocsp-nonce) and state that = this new text replaces the entirety of Section 4.4.1. ** Section 2.1. Per "The minimum nonce length of 1 octet is defined to pro= vide the backward compatibility with clients following [RFC6960]. However = the newer OCSP clients MUST use length of at least 16 octets for Nonce ..."= , how would this guidance work in practice from the perspective of the serv= er? =20 -- Is this saying that servers shouldn't reject 1 octet nonces for backward= compatibility? -- How do I judge if I have a "newer OCSP client" if I have a server? ** Section 3.1. s/a man in the middle (MiTM) entity/an on-path attacker/ ** Section 3.1. Per "This can be mitigated by the server using a closer ne= xtUpdate value ...", as the units of nextUpdate are time what does "closer"= mean? ** When is cryptographically strong PRNG needed? -- Section 2.1 seems to be restricting the "cryptographically strong pseudo= random number generator" to only new clients ("However the newer OCSP clien= ts MUST use length of at least 16 octets for Nonce extension and the value = of the nonce MUST be generated using a cryptographically strong pseudorand= om number generator") -- Section 3.2 seems to be saying something stronger that all client need s= trong randomness ("Therefore the client MUST use a nonce value that contain= s cryptographically strong randomness"). =20 ** Section 3.2. Per "A client SHOULD use 32 octets for nonce length", it w= as odd to me to specify a minimum length in Section 2.1, but the recommende= d length here. Why not put the guidance in one place? Regards, Roman From nobody Mon Jul 27 04:55:43 2020 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 2FB143A18FA for ; Mon, 27 Jul 2020 04:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 xIl84IhR63ZU for ; Mon, 27 Jul 2020 04:55: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 9F0593A18F8 for ; Mon, 27 Jul 2020 04:55:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F0138300AAF for ; Mon, 27 Jul 2020 07:55: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 hUR9jucSRZns for ; Mon, 27 Jul 2020 07:55:36 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 191EF300AAB for ; Mon, 27 Jul 2020 07:55:36 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Message-Id: <3B552FF1-5809-49E6-953D-3162BB311F71@vigilsec.com> Date: Mon, 27 Jul 2020 07:55:37 -0400 To: LAMPS WG X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: [lamps] IETF 108 LAMPS session X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 27 Jul 2020 11:55:42 -0000 If you=E2=80=99re interested in volunteering to take minutes or be = jabber scribe, please let the chairs know (chairs-lamps@ietf.org). Presenters, please send slides today. During a practice session, I = learned some ways to make it go more smooth, and i need time to do the = preparation. Russ From nobody Mon Jul 27 09:23:02 2020 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 7B2573A1AF7 for ; Mon, 27 Jul 2020 09:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.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 GdRRLOtan0Ie for ; Mon, 27 Jul 2020 09:22:51 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2056.outbound.protection.outlook.com [40.107.21.56]) (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 4473F3A1AEB for ; Mon, 27 Jul 2020 09:22:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oNgAk7LZvCG+WXD2QrbVn5BzRr2S+fGNAG+JeoNlUKI7ayL0cmeREMhiijwtCmodeeeSNZViMbINEWwf9dod3UtZIGTfqXaBYAecUYMFjTmlGMEzj7/wo4+a1oRnCjLTolYn53TBHHSO3/498HIF/GxNfEIGv3JHle5xkkog9up7t7JzTV208OsCLJUV+wcFmbT+TULQhJ6wN83ArxtvxCwBXM/g65rjr7L1RqGVAYrgEa5kpQ4nppZv+OUIJk2zZZoljLJ8tutmUg8FqG+Zvo3FJtw/tJub/ueK/Za6fD3Lui8s3b4/kMzQJUcrirNd14LJMUDinidXCrBcNI8UaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZlA9u1rNlOxEmjxS5S7Eqz4HjauRAoCt5CaLcmncFUQ=; b=oJe0UpjV+mwEupeyK4v2KPGr92qYzV2xZ3WBBtc9N5LCYIaNwB8UcRsdfJEPCOhisNQAiZXzWGFmCy2UTRuz//1IY+A8XfT67GC6jwjD5g4Wn6tlTfdQ8SW+6roJ6ZNHX5gVi8Kgi6r/BT2hCa1lfWJpXyo9mJCWjr+iox7YjpL/nDmIgEXnjkh5m4Ej2CfMUpsxn1sKUV7DxjgZqKc9oWEY25/ZqPFXKVDEZIF3eiT8EXZbcASDhvPe+fBdo/yzjVZ+KKK0xfna6ks+Vrfq+gNsxaW63bfaZvjT6c3ETs+jXb4iuxuKMGEl1KRwNk3LU1msY6WwfUj3mkNbzm3cbQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZlA9u1rNlOxEmjxS5S7Eqz4HjauRAoCt5CaLcmncFUQ=; b=ZKzllfkDV1WrZ+dYRwqVM/g3ULgcTxzi63JRoQp51CCHjHr+ezxjYZJA/y4EnL9sI4x3uZUPT6uMzsGDP6d36TbWYmyGan70ZxRIboynO7Z/7tbk0ZR/PNg6u5nAtBuvlrd6/479PqTWmOeDXkDo93J9LtMF5Rc9QwGk+umMkUc= Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:184::10) by AM0PR10MB1858.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:3f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Mon, 27 Jul 2020 16:22:49 +0000 Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0]) by AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0%9]) with mapi id 15.20.3216.033; Mon, 27 Jul 2020 16:22:48 +0000 From: "Brockhaus, Hendrik" To: Russ Housley CC: LAMPS WG Thread-Topic: draft-ietf-lamps-cmp-updates Thread-Index: AQHWY4Otd7XI25AWCU2d90xbJWNT86kbmGwg Content-Class: Date: Mon, 27 Jul 2020 16:22:48 +0000 Message-ID: References: <97AAAE51-45E0-4363-ACAD-99144085E710@vigilsec.com> In-Reply-To: <97AAAE51-45E0-4363-ACAD-99144085E710@vigilsec.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-07-27T16:22:47Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=047ff5d2-bc12-4bcf-99bd-98940004c52a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.183] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ea54b0a1-d41a-4dd2-1052-08d832494da2 x-ms-traffictypediagnostic: AM0PR10MB1858: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SjTGkmxgo4PNJlFUrDAE08xPB+LVXrvmHWz0vkkS21BapDkOqR9x3+bfMOnvU07MsBvAobBxrlr5QC3bm+dFdL6HR3TfPv+M/X2/uHruYphi6joqBQBO52UbbIBfXQAHHOHmF2yIp9ZUKP1xi6zhVm2KamGsHiUrbIrLGhWraxfkuljMrRbtT/Cr0NwCN5fJiEzV6cuDmocCsXcAg6geYfRIDM/vqdPIzDcrU2EHlN8AlZ2JItkPCd8cTNiRIr4QAOaXrJ6ursKZjitGmN6dqMLdojrLZb72fLMQ6GhbSf+cLHxT5U4gYLpjn+S3YD2OQe/6BuVnDbp37Rkx8Su0NA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(366004)(136003)(346002)(396003)(39860400002)(52536014)(66446008)(83380400001)(66946007)(2906002)(8936002)(64756008)(66556008)(66476007)(76116006)(9686003)(8676002)(478600001)(186003)(7696005)(55016002)(26005)(55236004)(33656002)(86362001)(316002)(6506007)(71200400001)(4326008)(5660300002)(6916009)(15650500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: uy+NkDyk3J6uMYOQ4uiLmokGIAeuRPI08uI9yr/wQHo1LO1A+/wRjcGY52d6Vuxt1Bio2bhgqDOydXilKVeXDwXO6exsZI0LnO0cMTvVkI8mekooWQHHRC+3O5ufgPpzwEMUJMPyXP5XHIfXv5GNScPPhui1axWba7riGt0Co0r0x/YW7bBzSS6vXITldlcgobBo6dklicOH1h5TSdS6zocq9ht7fG398Dwst0r0PNtr550PW6KEMLjtvnPAMiDuCOqF0vauDWQM9E3ASpbOGl4Jqo5A3asPT5FXoCxCS/Z7BeQkKURsEjegvWQV/G+sAPey9//oZtwevlcWoVv58o44ZUlkbHb+zNDriWOG51a/P5MlxdcFp8/AzzK2Y0vC24gkLXL9YP3u0aprLSDJ+xCLf+7Ek5VFwyn1hjvSKY5NT1gUsShifzORndg3iBdzPG2ROMe0vAMo+9xhY2Nz6mQRGVZJykDa/Of7f9Jn5F3KREyIser1o+niMdicJuDW x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: ea54b0a1-d41a-4dd2-1052-08d832494da2 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2020 16:22:48.8009 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /FtbmmCLeY9OfjMKukh7NM0zF7sUuVWLpjw2azTlj7d543MQZA6peuk4jTPSoOrq+AQP7+04oY61h+CeBw/Q0VH+3IGWWFzUxnZhDeLZZ9s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB1858 Archived-At: Subject: Re: [lamps] draft-ietf-lamps-cmp-updates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 27 Jul 2020 16:23:00 -0000 Russ Thanks for having a coser look at the ASN.1 module. Actually I am a little uncertain how to properly specify things. :-( > Von: Russ Housley >=20 > IANA has made the assignment for id-kp-cmKGA. That is great. I will add the OID in the next release of the draft. >=20 > I was looking at Appendix A in the draft, and it is not completely clear = to me > what the revised ASN.1 module looks like: >=20 > First, the source of some imports is updated. No big deal. >=20 > Second, in CertifiedKeyPair and CertOrEncCert, the EncryptedValue os repl= aced > with EncryptedKey. >=20 > Third, id-it-revPassphrase (which is in a comment) is associated with > EncryptedKey instead of EncryptedValue. Finally, I do not fully understand this specification, too.=20 My goal is to update OID {id-it 12} as specified in section 5.3.19.9 and t= he only lines in the ASN.1 module on this OID is in comments? >=20 > Fourth, id-kp-cmKGA is added to the list of EKU values, but these do not = appear > in the previous module anywhere. Where do they belong? You are right. The EKUs id-kp-cmcCA and id-kp-cmcRA must be imported from R= FC6402 and can be deleted from this draft. But the id-kp-cmKGA must be spec= ified here, right?=20 Hendrik From nobody Mon Jul 27 09:26:31 2020 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 883B63A1B33 for ; Mon, 27 Jul 2020 09:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 HIl6mCC8kjlz for ; Mon, 27 Jul 2020 09:26:28 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 015043A1B1E for ; Mon, 27 Jul 2020 09:26:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 87C69300B5A for ; Mon, 27 Jul 2020 12:26:25 -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 wAjEF5il37eU for ; Mon, 27 Jul 2020 12:26:24 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 43C0D30009A; Mon, 27 Jul 2020 12:26:24 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: Date: Mon, 27 Jul 2020 12:26:25 -0400 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <6637BD5E-96EF-4982-8F4B-289209D1EBD2@vigilsec.com> References: <97AAAE51-45E0-4363-ACAD-99144085E710@vigilsec.com> To: "Brockhaus, Hendrik" X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [lamps] draft-ietf-lamps-cmp-updates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 27 Jul 2020 16:26:30 -0000 > On Jul 27, 2020, at 12:22 PM, Brockhaus, Hendrik = wrote: >=20 > Russ >=20 > Thanks for having a coser look at the ASN.1 module. > Actually I am a little uncertain how to properly specify things. :-( >=20 >> Von: Russ Housley >>=20 >> IANA has made the assignment for id-kp-cmKGA. >=20 > That is great. I will add the OID in the next release of the draft. >=20 >>=20 >> I was looking at Appendix A in the draft, and it is not completely = clear to me >> what the revised ASN.1 module looks like: >>=20 >> First, the source of some imports is updated. No big deal. >>=20 >> Second, in CertifiedKeyPair and CertOrEncCert, the EncryptedValue os = replaced >> with EncryptedKey. >>=20 >> Third, id-it-revPassphrase (which is in a comment) is associated with >> EncryptedKey instead of EncryptedValue. >=20 > Finally, I do not fully understand this specification, too.=20 > My goal is to update OID {id-it 12} as specified in section 5.3.19.9 = and the only lines in the ASN.1 module on this OID is in comments? Right, so it is just and updated comment; however, the place were this = is defined needs to be updated too, right? >=20 >>=20 >> Fourth, id-kp-cmKGA is added to the list of EKU values, but these do = not appear >> in the previous module anywhere. Where do they belong? >=20 > You are right. The EKUs id-kp-cmcCA and id-kp-cmcRA must be imported = from RFC6402 and can be deleted from this draft. But the id-kp-cmKGA = must be specified here, right?=20 Yes, that is correct. Russ From nobody Mon Jul 27 10:25:50 2020 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 417263A1AF3 for ; Mon, 27 Jul 2020 10:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyGs0D-kU7ay for ; Mon, 27 Jul 2020 10:25:44 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 429AB3A1B42 for ; Mon, 27 Jul 2020 10:25:36 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id q75so9651149iod.1 for ; Mon, 27 Jul 2020 10:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=stGxl87b2ubJpd3ftrF95Lp2ZRLeYPWJchJ92Lk+b/s=; b=K9QnSkloXmpMT8khuD803v0w01sAZrTrQI/fKtmTuhYjsN5n6TxEi1JK3qlEtOQ0Ms iL3OkwCgGpeAclPU5UWyTY7UQ6v3WhoZK4sCnu8g/UC6rvDkga83+bIzCkJiCgRmrqoT lBMF8r9gOnag8dK5MYw8KnEHutlTWl7RFLV+ubv/JV2XAMbx3/bRwfk7iE7k3qPOb3tE jjhfp8QkGHyFCruvMS0r4M1y9Oe+NDZaW4KyflSZ/2+tX7y298ORbhhsGdpkeAnDX/m6 qE0iMrvFilHa5hBcJ/6ixf4i2RHSU5pq7bb5VoBg3fBF+C4U7M0EV47BHxuaPaBfRz5v 2nOw== 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=stGxl87b2ubJpd3ftrF95Lp2ZRLeYPWJchJ92Lk+b/s=; b=ig6wiHFqm841BDCw+yZNi0GcnOsMaFb0/itGB+LcB8mRj5jbADHB6qe4CCvIk9Tgpm 0QcoVZ/Xw6PqXsX5RCqFzVIpHxmslZLh70xYqro3l3mWicRUkXQvb5rOMbr5zYpw+hO9 uzR1fAJ1VDvINC7tgV6udNKgs7uBQHcpaJoWXPSLpJDPr8aQZC1iCIEXsC2ppQVTzitY GeqRJ55Oxl0D7zUy0yId0CBg8UGbLz4EG62QroOHB/5RAHfqyEwAKnZYwXgOdIVfktbc E/ufKbXbGaMo5NyAgcn5u72zOxSY2S09kduAKGXNyEbklGc6MZ+NyGDuQ7RTVA1+hF0J zq4w== X-Gm-Message-State: AOAM5332yuN0ePQiCY20YxG7Dn8TgeKvw3Qpyrm2jkZDBV1QmscMxSiC hVIFbWWHHaDCSl6aSHehF+6qy4DxbnNRIvWxrLDFjw== X-Google-Smtp-Source: ABdhPJySrzsgqCmvuDZ7jAPALjS+GsnhlzkxKFn66zYbwEy/ewUc3OaxS9GEjahLnubqDZ0a3fmStF1NLVsIWiU/Qdk= X-Received: by 2002:a05:6602:1610:: with SMTP id x16mr18298283iow.68.1595870735441; Mon, 27 Jul 2020 10:25:35 -0700 (PDT) MIME-Version: 1.0 References: <79447b68da0d4cd09757e531caee14d9@cert.org> In-Reply-To: <79447b68da0d4cd09757e531caee14d9@cert.org> From: Mohit Sahni Date: Mon, 27 Jul 2020 10:25:24 -0700 Message-ID: To: Roman Danyliw Cc: LAMPS WG Content-Type: multipart/alternative; boundary="0000000000004b227205ab6f9ce3" Archived-At: Subject: Re: [lamps] AD Review of draft-ietf-lamps-ocsp-nonce-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 27 Jul 2020 17:25:48 -0000 --0000000000004b227205ab6f9ce3 Content-Type: text/plain; charset="UTF-8" Hi Roman, Thanks for your feedback, I will make these changes and upload the new version of the draft. Mohit On Sun, Jul 26, 2020 at 7:00 PM Roman Danyliw wrote: > Hi! > > I conducted an AD review of draft-ietf-lamps-ocsp-nonce-02. Thanks for > the work on this document to harden the nonce extension of RFC 6960. Below > is my feedback: > > ** Section 2. Editorial. s/Following is the list/The following is a list/ > > ** Section 2.1. This section appears to be a complete rewrite of the text > in 4.4.1 of RFC6960 with the exception of the definitions of id-pkix-ocsp > and id-pkix-ocsp-nonce. To eliminate confusion, I would recommend you add > these definitions here (id-pkix-ocsp and id-pkix-ocsp-nonce) and state that > this new text replaces the entirety of Section 4.4.1. > > ** Section 2.1. Per "The minimum nonce length of 1 octet is defined to > provide the backward compatibility with clients following [RFC6960]. > However the newer OCSP clients MUST use length of at least 16 octets for > Nonce ...", how would this guidance work in practice from the perspective > of the server? > > -- Is this saying that servers shouldn't reject 1 octet nonces for > backward compatibility? > > -- How do I judge if I have a "newer OCSP client" if I have a server? > > ** Section 3.1. s/a man in the middle (MiTM) entity/an on-path attacker/ > > ** Section 3.1. Per "This can be mitigated by the server using a closer > nextUpdate value ...", as the units of nextUpdate are time what does > "closer" mean? > > ** When is cryptographically strong PRNG needed? > > -- Section 2.1 seems to be restricting the "cryptographically strong > pseudorandom number generator" to only new clients ("However the newer OCSP > clients MUST use length of at least 16 octets for Nonce extension and the > value of the nonce MUST be generated using a cryptographically strong > pseudorandom number generator") > > -- Section 3.2 seems to be saying something stronger that all client need > strong randomness ("Therefore the client MUST use a nonce value that > contains cryptographically strong randomness"). > > ** Section 3.2. Per "A client SHOULD use 32 octets for nonce length", it > was odd to me to specify a minimum length in Section 2.1, but the > recommended length here. Why not put the guidance in one place? > > Regards, > Roman > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --0000000000004b227205ab6f9ce3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Roman,
Thanks for your feedback, I will make these = changes and upload the new version of the draft.=C2=A0

=
Mohit=C2=A0=C2=A0

On Sun, Jul 26, 2020 at 7:00 PM Roman Danyliw= <rdd@cert.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Hi!

I conducted an AD review of draft-ietf-lamps-ocsp-nonce-02.=C2=A0 Thanks fo= r the work on this document to harden the nonce extension of RFC 6960.=C2= =A0 Below is my feedback:

** Section 2.=C2=A0 Editorial.=C2=A0 s/Following is the list/The following = is a list/

** Section 2.1.=C2=A0 This section appears to be a complete rewrite of the = text in 4.4.1 of RFC6960 with the exception of the definitions of id-pkix-o= csp and id-pkix-ocsp-nonce.=C2=A0 To eliminate confusion, I would recommend= you add these definitions here (id-pkix-ocsp and id-pkix-ocsp-nonce) and s= tate that this new text replaces the entirety of Section 4.4.1.

** Section 2.1.=C2=A0 Per "The minimum nonce length of 1 octet is defi= ned to provide the backward compatibility with clients following [RFC6960].= =C2=A0 However the newer OCSP clients MUST use length of at least 16 octets= for Nonce ...", how would this guidance work in practice from the per= spective of the server?=C2=A0

-- Is this saying that servers shouldn't reject 1 octet nonces for back= ward compatibility?

-- How do I judge if I have a "newer OCSP client" if I have a ser= ver?

** Section 3.1.=C2=A0 s/a man in the middle (MiTM) entity/an on-path attack= er/

** Section 3.1.=C2=A0 Per "This can be mitigated by the server using a= closer nextUpdate value ...", as the units of nextUpdate are time wha= t does "closer" mean?

** When is cryptographically strong PRNG needed?

-- Section 2.1 seems to be restricting the "cryptographically strong p= seudorandom number generator" to only new clients ("However the n= ewer OCSP clients MUST use length of at least 16 octets for Nonce extension= and the value of the nonce MUST be generated using a=C2=A0 cryptographical= ly strong pseudorandom number generator")

-- Section 3.2 seems to be saying something stronger that all client need s= trong randomness ("Therefore the client MUST use a nonce value that co= ntains cryptographically strong randomness").=C2=A0

** Section 3.2.=C2=A0 Per "A client SHOULD use 32 octets for nonce len= gth", it was odd to me to specify a minimum length in Section 2.1, but= the recommended length here.=C2=A0 Why not put the guidance in one place?<= br>
Regards,
Roman

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--0000000000004b227205ab6f9ce3-- From nobody Mon Jul 27 12:03:40 2020 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 47B253A0044 for ; Mon, 27 Jul 2020 12:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.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 7T0Bab0CSDnF for ; Mon, 27 Jul 2020 12:03:23 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 CECE53A087D for ; Mon, 27 Jul 2020 12:03:22 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 06RJ3LAt003315 for ; Mon, 27 Jul 2020 15:03:22 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 06RJ3LAt003315 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1595876602; bh=919lE83umq/5KkwZoI8hfZJZTa9VLO/HnoBKEp6j9rA=; h=From:To:Subject:Date:From; b=SOmBxwQuDxulXlDT3Ccdu4t/AbfnddtinL30h/Jc8LDRJQE7ZbvEuCCGWWxDSetZ0 dV+zKHiha3N4M3xdLOod0ZBT9QJ7GQgf8V3gux+iRBLo968hX1MLFz2vt/R9Tf58ev EtVITIyaC5gMrMSbzT+8+RWklCiz7RfULw0vkLcM= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 06RJ3Iio020689 for ; Mon, 27 Jul 2020 15:03:18 -0400 Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASCADE.ad.sei.cmu.edu (10.64.28.248) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 27 Jul 2020 15:03:18 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 27 Jul 2020 15:03:17 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Mon, 27 Jul 2020 15:03:17 -0400 From: Roman Danyliw To: LAMPS WG Thread-Topic: AD Review of draft-ietf-lamps-cms-update-alg-id-protect-02 Thread-Index: AdZkSFWD+IydvLxlRLucfc76q2usIA== Date: Mon, 27 Jul 2020 19:03:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.201.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [lamps] AD Review of draft-ietf-lamps-cms-update-alg-id-protect-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 27 Jul 2020 19:03:36 -0000 Hi! I conducted an AD review of draft-ietf-lamps-cms-update-alg-id-protect-02. = Thanks for the work on this document to harden CMS. Below is my feedback.= As it is editorial in nature, it can be handled with any other IETF LC fe= edback. ** Section 3. Section title. Editorial. s/Require use the same hash algori= thm/Required use of the same hash algorithm/ ** Section 3. Editorial. Recommend consistent use of either signedAttrs o= r signedAttributes (i.e., choose either the data structure name or the vari= able name) -- Section 3.1 says "If signedAttrs are present in SignerInfo ..." -- Section 3.2 says "When the signedAttrs field is present ..." -- Section 3.3.says "If the SignedData signerInfo includes signedAttributes= ..." and "... included in the signedAttributes of the SignedData signerInf= o" ** Section 3.1. Editorial. Simplify the guidance. OLD If signedAttrs are present in the SignerInfo, then the same digest algorithm MUST be used to compute the digest of the SignedData encapContentInfo eContent, which is carried in the message-digest attribute, and to compute the digest of the DER-encoded SET OF signed attributes, which is passed to the signature algorithm. NEW If signedAttrs are present in the SignerInfo, then the same digest algorith= m MUST be used to compute both the digest of the SignedData encapContentInf= o eContent, which is carried in the message-digest attribute, and the diges= t of the DER-encoded SET OF signed attributes, which is passed to the signa= ture algorithm. ** Section 3.2. Typo. s/the the/the/ ** Section 3.3. Typo. s/the the/the/ ** Section 3.4. Significant editorial. s/might lead to compatibility/migh= t lead to incompatibility/ ** Section 6. Per "There is not currently protection mechanism ..." and "L= ikewise there is not currently a protection mechanism ...", it's true that = these are a gap, but would that age well? Perhaps just say: OLD There is not currently protection mechanism for the algorithm identifiers used in the enveloped-data, digested-data, or encrypted-data content types. Likewise there is not currently a protection mechanism for the algorithm identifiers used in the authenticated-enveloped-data content type defined in [RFC5083]. NEW It provides no protection mechanism for the algorithm identifiers used in t= he enveloped-data, digested-data, or encrypted-data content types. Likewis= e, The CMSAlgorithmProtection attribute provides no protection for the algo= rithm identifiers used in the authenticated-enveloped-data content type def= ined in [RFC5083]. Regards, Roman From nobody Mon Jul 27 12:30:36 2020 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 2F82D3A0B32; Mon, 27 Jul 2020 12:30:30 -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: 7.10.1 Auto-Submitted: auto-generated Precedence: bulk CC: lamps-chairs@ietf.org, tim.hollebeek@digicert.com, draft-ietf-lamps-cms-update-alg-id-protect@ietf.org, Tim Hollebeek , spasm@ietf.org, rdd@cert.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <159587822960.14385.16987449382336395882@ietfa.amsl.com> Date: Mon, 27 Jul 2020 12:30:30 -0700 Archived-At: Subject: [lamps] Last Call: (Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 27 Jul 2020 19:30:31 -0000 The IESG has received a request from the Limited Additional Mechanisms for PKIX and SMIME WG (lamps) to consider the following document: - 'Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-08-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates the Cryptographic Message Syntax (CMS) specified in RFC 5652 to ensure that algorithm identifiers in signed- data and authenticated-data content types are adequately protected. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protect/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Jul 27 13:18:41 2020 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 7B06E3A0BE7 for ; Mon, 27 Jul 2020 13:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 pYPO_DyvfE7t for ; Mon, 27 Jul 2020 13:18:32 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F17123A0BA1 for ; Mon, 27 Jul 2020 13:18:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 92268300B59 for ; Mon, 27 Jul 2020 16:18:29 -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 e8n0HeTSctHd for ; Mon, 27 Jul 2020 16:18:27 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 8CB8E30009A; Mon, 27 Jul 2020 16:18:27 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: Date: Mon, 27 Jul 2020 16:18:28 -0400 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Roman D. Danyliw" X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [lamps] AD Review of draft-ietf-lamps-cms-update-alg-id-protect-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 27 Jul 2020 20:18:40 -0000 Roman: Thanks for the careful review and editorial suggestions. I have taken = acre of all of these in my edit buffer. In your final comment (below), I came up with a slightly different = wording. > On Jul 27, 2020, at 3:03 PM, Roman Danyliw wrote: >=20 > Hi! >=20 > I conducted an AD review of = draft-ietf-lamps-cms-update-alg-id-protect-02. Thanks for the work on = this document to harden CMS. Below is my feedback. As it is editorial = in nature, it can be handled with any other IETF LC feedback. >=20 > ** Section 3. Section title. Editorial. s/Require use the same hash = algorithm/Required use of the same hash algorithm/ >=20 > ** Section 3. Editorial. Recommend consistent use of either = signedAttrs or signedAttributes (i.e., choose either the data structure = name or the variable name) > -- Section 3.1 says "If signedAttrs are present in SignerInfo ..." >=20 > -- Section 3.2 says "When the signedAttrs field is present ..." >=20 > -- Section 3.3.says "If the SignedData signerInfo includes = signedAttributes ..." and "... included in the signedAttributes of the = SignedData signerInfo" >=20 > ** Section 3.1. Editorial. Simplify the guidance. >=20 > OLD > If signedAttrs are present in the SignerInfo, then the same digest > algorithm MUST be used to compute the digest of the SignedData > encapContentInfo eContent, which is carried in the message-digest > attribute, and to compute the digest of the DER-encoded SET OF > signed attributes, which is passed to the signature algorithm. > NEW > If signedAttrs are present in the SignerInfo, then the same digest = algorithm MUST be used to compute both the digest of the SignedData = encapContentInfo eContent, which is carried in the message-digest = attribute, and the digest of the DER-encoded SET OF signed attributes, = which is passed to the signature algorithm. >=20 > ** Section 3.2. Typo. s/the the/the/ >=20 > ** Section 3.3. Typo. s/the the/the/ >=20 > ** Section 3.4. Significant editorial. s/might lead to = compatibility/might lead to incompatibility/ >=20 > ** Section 6. Per "There is not currently protection mechanism ..." = and "Likewise there is not currently a protection mechanism ...", it's = true that these are a gap, but would that age well? Perhaps just say: >=20 > OLD > There is not currently protection mechanism for > the algorithm identifiers used in the enveloped-data, digested-data, > or encrypted-data content types. Likewise there is not currently a > protection mechanism for the algorithm identifiers used in the > authenticated-enveloped-data content type defined in [RFC5083]. >=20 > NEW >=20 > It provides no protection mechanism for the algorithm identifiers used = in the enveloped-data, digested-data, or encrypted-data content types. = Likewise, The CMSAlgorithmProtection attribute provides no protection = for the algorithm identifiers used in the authenticated-enveloped-data = content type defined in [RFC5083]. The paragraph now reads: The CMSAlgorithmProtection attribute [RFC6211] offers protection for the algorithm identifiers used in the signed-data and authenticated- data content types. However, no protection is provided for the algorithm identifiers in the enveloped-data, digested-data, or encrypted-data content types. Likewise, The CMSAlgorithmProtection attribute provides no protection for the algorithm identifiers used in the authenticated-enveloped-data content type defined in [RFC5083]. Russ From nobody Mon Jul 27 22:57:27 2020 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 25B713A0CB4 for ; Mon, 27 Jul 2020 22:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.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 kM0BSALs14Z6 for ; Mon, 27 Jul 2020 22:57:21 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2056.outbound.protection.outlook.com [40.107.20.56]) (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 517213A0CB3 for ; Mon, 27 Jul 2020 22:57:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BeHdr05tmGdXqpDcKRJYYb9LARG/3VzJrGiUV7tYtHH6Z9aJzrWytzFTr62f35fQkqGI+0DuY2FyajDp8wqDEpvJjSx/qeRVfvIckfLnI920jZYzFK1/mHLweGK/WRCc4fbSBRfzllB8vOfYRPLXFt/Jlp8zA/OiEXorZDt/DR4hVIOa+1KaYqQ1qSYl2AKgxWEOsMBcgjK8CGiV6qm+qpzPZxryrECCJqa0d6UF7Z50O5WMgMsHcnS2l79O+bo1GA8/22mJI93JL67GuYD5fgOqn59nvMUR8OfO9wBfQ5cs47EQdmPbMCjgt9pZ1/TG4iZnB1/gVteCHAInWMMB1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qq75TJsv6O+PJ+9nkYhBQ6DPFnf1VmFWgD0kHCoYNes=; b=EMg1I82wj3OLBffO1pK4Rx+tcbzNfTYr2lx1yC9kZoQRk0PZp5qL6SJz7Qcx0zTF6rOH5ifzzhO4KE+a7V/+wb/T9BhRVDJbkgGfZ77fa3+IxXMVnQxjvCvNs/ob+zppUfc8Jv5SwWetYaKIuf+QukGW1DoUuMKuKQfL5kCf3e3l54g3RQC12ANHbkm8xNbLWeLFlBRXW+riFafDOEIu6KuHG7BTgdCGA5BS4Lim9QtvNmcY2GJBiKlyCbDL3jPLxBtmHrotZuhVLRvc4DsT+R7PwxEXyBy82VYbHbL+Sm7Q92zUFYw/Q52+HsYc9VTBDTEFcuB6X73LklcFZOQZIA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qq75TJsv6O+PJ+9nkYhBQ6DPFnf1VmFWgD0kHCoYNes=; b=Rlazw9bbwBDTaFDlb1jZt8T7NOPxz4o99gjNZTaQSa2h5MPwjeXjppkJqGQJDUbJo/RL8dWAiztNL0nsSBsGktmqOXXjlIoGZpDpuqkVhj02+MRzYe7HL1Kr4l8e1ZM+rqA9BLs5zRK5hv0OcE1BugqSeIoJpKc3A7Uhg2tHs74= Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:184::10) by AM4PR1001MB1426.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:200:96::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.23; Tue, 28 Jul 2020 05:57:19 +0000 Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0]) by AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0%9]) with mapi id 15.20.3216.034; Tue, 28 Jul 2020 05:57:19 +0000 From: "Brockhaus, Hendrik" To: Russ Housley CC: LAMPS WG Thread-Topic: draft-ietf-lamps-cmp-updates Thread-Index: AQHWY4Otd7XI25AWCU2d90xbJWNT86kbmGwggAAF5ICAAN4GQA== Content-Class: Date: Tue, 28 Jul 2020 05:57:19 +0000 Message-ID: References: <97AAAE51-45E0-4363-ACAD-99144085E710@vigilsec.com> <6637BD5E-96EF-4982-8F4B-289209D1EBD2@vigilsec.com> In-Reply-To: <6637BD5E-96EF-4982-8F4B-289209D1EBD2@vigilsec.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-07-28T05:57:17Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=1baeb6dd-d96a-489d-b6a6-43bfc685c2d8; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.157] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e32d7738-d0a5-4c29-4504-08d832bb16a2 x-ms-traffictypediagnostic: AM4PR1001MB1426: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: g9a6bQOkP4OJa7IXVUIbc51jM7I9JCdEctmtXgP58o50Jy3KRRSIahJ8xv4LIb8gq/7gSG1jUdjyQ5qMRPfBEomBNnpGvP/ULd/scX5xKMwUh/1KZreq21hu4V91FKYWYVg121DYDQdONZDKuAC2zeOXQUj1G8eu+cnAzkR3dyQHngJt8frONcayeCEEG7Q5IqGsUuDotiS0lxLFU7X9kaa0N+1uLAQgksV0PDmbx/2u+qaIlc23fZzE9NL64cB4sdmqXNh/IH74qBxVzW7Bv0U6DnRmGX4W1NVJZTg/TWEpKEawR2mq7+/7V7WVtdkHOEbAI1ZKucHEV65C/cbqkg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(366004)(346002)(396003)(136003)(39860400002)(478600001)(52536014)(5660300002)(76116006)(4326008)(66476007)(66556008)(64756008)(9686003)(66446008)(66946007)(55016002)(71200400001)(15650500001)(316002)(6916009)(2906002)(55236004)(26005)(4744005)(186003)(7696005)(53546011)(6506007)(83380400001)(8936002)(33656002)(86362001)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: A9xEDrfRoHtN2TaF+LsN7obGkC9p5v83QCG2edjzukI2cALu9G7rTDCTQoYex33oVxY/98WnnRuJ7z6FBVCu1le1wZp/pShtCwcP+RLrpi0FWdOTXyAEBXDUs6KsCjUEdghXkcPArlSnv5Nsobkzge2ttSqDx1v3csyDcJOXdFOzdEMqB39ub96j3jJUw4x9n7Jl6ayszOGZf6Vu55zW8re/wmp9Vu4cj/jp/uG2dKuNTFeMv6wGLUpb6nUHK0LtxAkO6VTBSCRZwjYfF8ohQzfa+O56HZXWkJoq/gXqd0kIESlLjoghUuL7OQiUyrKPmWzX0wssIQlfEgRiAZSK1wcD+x3C8zHw+07lr6RrpxxM1XpnhSNIkXHpgT7DF+3lmvx7jgqXiKbibQ8LSBUjS3EoNPv0SjlLq6fRL8vAe5GuSslQh9YHreNp53G4P4ObF5GOl/AE9QYyWv6n53CB1dqYuwbbP4YD6xzBJpKQV+c4gm/5xGFFLMKL3xcN0FHs x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: e32d7738-d0a5-4c29-4504-08d832bb16a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 05:57:19.1428 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iQP9i9xzP09mnWlQrQP/Q/xssWeRnRM8WDyI3i3MGx1xGnE8kQQPV0rM6D0GPlcgfqeaNZmJEEocyCQktkCMpAaTIQ5SYtYktvrVfACAmkg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR1001MB1426 Archived-At: Subject: Re: [lamps] draft-ietf-lamps-cmp-updates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jul 2020 05:57:27 -0000 > Von: Russ Housley >=20 > > On Jul 27, 2020, at 12:22 PM, Brockhaus, Hendrik > wrote: > > > >> Third, id-it-revPassphrase (which is in a comment) is associated with > >> EncryptedKey instead of EncryptedValue. > > > > Finally, I do not fully understand this specification, too. > > My goal is to update OID {id-it 12} as specified in section 5.3.19.9 a= nd the > only lines in the ASN.1 module on this OID is in comments? >=20 > Right, so it is just and updated comment; however, the place were this is > defined needs to be updated too, right? Yes. But the only place I am aware of where this OID is defined is in secti= on 5.3.19.9 of RFC4210. I update this section in section 2.6 of the draft. Are there any other place I should update? Hendrik From nobody Tue Jul 28 01:32:32 2020 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 2AF763A0870 for ; Tue, 28 Jul 2020 01:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=LWsJu0ue; dkim=pass (1024-bit key) header.d=primekey.com header.b=LWsJu0ue Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5Q_263Gv077 for ; Tue, 28 Jul 2020 01:32:27 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0934A3A087B for ; Tue, 28 Jul 2020 01:32:26 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id 2408F6AA05A9 for ; Tue, 28 Jul 2020 10:32:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1595925125; bh=Tn+fhj6Bg78kB+viEHz85EQqiOHen5aJ4OnXAB6DWhk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=LWsJu0uenoKVeuYZKjIgNJx5Vx0vm6kNhuWk9Xc1EvPmjtSV21LeNZAmGV9vZ3rVK yueG7fw6hO/r07/6/Fmcfd5Nr/EkiTbqqv7Lo88dMXo7P5TL3fp9kNuURDfNhuGzuD bskqESHLqkKPNiCVxEmqPoCbSI8SitStQ2rTEl+s= Received: from [10.11.0.15] (gatekeeper.primekey.se [84.55.121.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id EC97C6AA05A7 for ; Tue, 28 Jul 2020 10:32:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1595925125; bh=Tn+fhj6Bg78kB+viEHz85EQqiOHen5aJ4OnXAB6DWhk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=LWsJu0uenoKVeuYZKjIgNJx5Vx0vm6kNhuWk9Xc1EvPmjtSV21LeNZAmGV9vZ3rVK yueG7fw6hO/r07/6/Fmcfd5Nr/EkiTbqqv7Lo88dMXo7P5TL3fp9kNuURDfNhuGzuD bskqESHLqkKPNiCVxEmqPoCbSI8SitStQ2rTEl+s= To: spasm@ietf.org References: <8E4BE9A8-3696-471C-BF7D-3FE0CC729C05@vigilsec.com> From: Tomas Gustavsson Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= xsBNBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAHNMFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPsLA dwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5zsBNBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAHCwF8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: <0c36bf62-605e-b010-8e1a-602c051c1a51@primekey.com> Date: Tue, 28 Jul 2020 10:32:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <8E4BE9A8-3696-471C-BF7D-3FE0CC729C05@vigilsec.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [lamps] draft-ietf-lamps-lightweight-cmp-profile-02 SHA-256 and URLs X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jul 2020 08:32:30 -0000 Hi, I aim to participate in the WG meeting at IETF-108 today to discuss this, but send this ahead to the list. Also good for archive. I have two comments: draft-ietf-lamps-lightweight-cmp-profile-02: 1. Section 3.1: "The hash algorithm used SHOULD be SHA-256" Would it be beneficial for crypto agility to specify algorithms in a separate section? Now we will eventually end up with the same state as RFC4210 that specifies SHA-1. We also start to get some requests for EdDSA for IoT, so I could see that EdDSA may come up as a requirement here. SHA-256 is specified in a couple of places, and we may want to think crypto agility from start. 2. Section 6.1. RFC6712 only mentions one "cmp/" url, and I think most implementations today uses only one url endpoint for all CMP messages. I think this is an extension to the RFC 6712, and think that this fact should be stated explicitly. Regards, Tomas From nobody Tue Jul 28 04:22:05 2020 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 0A1393A0B18 for ; Tue, 28 Jul 2020 04:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KWa_7PIb_wF for ; Tue, 28 Jul 2020 04:22:00 -0700 (PDT) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2114.outbound.protection.outlook.com [40.107.89.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 270833A0AFF for ; Tue, 28 Jul 2020 04:21:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EMG6BBZt0rqTJVWIh/JDXGE7YDqmOHU9WEiPObzCg0c01T980gnvN1fzPw7JWuXIVM4aAB3kE9vqN0f9+naWz+OBrawM5UYTWt82nsFfEwE2vopD55su1fpCWnQJWLHKLoOBvH5Uyke4TpjsF5u9439AJEDopXUXtt9s5FE55g2hAA0ShrTbOyOUViqvyB4A+v4kbGHRzVnNK7BkYwJvhlDwOkSiq6G5H4d3AnEj81bkIP7lMFnqgTNj1PpPRwrcLP2Rt+nFA7CjvWoDK6Hb5uBpKFeqssGvts8dW+9skYQetcSlIjYxYZZvN5qtXKrEvK1tudZlQplr/bMzhMhA2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t2qEid6wOFRe7gYN0r+U0aMuzI2rFWboi+CgIOaLYVI=; b=G2e8u69R8FtIHfKVBGYDs45UBD6IGTlcuuVn97dJh8iq3FQOJvo1k9Fo8twllp3Fx/oxHr8UMfKa2/g8gO7dKhz/9xFJ5W6rNqLenfgRnH1+B+b4SoPBbdsyVdteaWhkSPOi7tl8NPWhCOwMswfh7Q0fA16vJMSH0qEwxtNCCUUfXJUZuINdDRxjpcGhMZ4nviF8cX8Sfap2Pdj9gT2Kq+1yE1S+N6sdTBmZySVHYEPmNrzwrsx7dUNRnpF2UnlqZjoq680DnHUlkO1n4Pd6qqmQEydPiKHxsdWSEScBC1BJdearwFH+aSo5+yIVkQkeK3s0kpixh9yMWRdDUPrPug== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t2qEid6wOFRe7gYN0r+U0aMuzI2rFWboi+CgIOaLYVI=; b=Mw9G068CgPVCeYLekDp7vKYgIOhSoM5AUuTgnx5Q146M4lDpF76l7YN9KUw/quCTz2Lzo1nTfgBaoECROiinkH+TwQg3TMspPovAaspKEZIojKOCgicobtuYIhomz6rTFRmOXNGemYEAVsSBKS/rVGCjdlO2NKTAUIxJ8yaufR4= Received: from CH2PR09MB4553.namprd09.prod.outlook.com (2603:10b6:610:62::15) by CH2PR09MB4569.namprd09.prod.outlook.com (2603:10b6:610:64::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Tue, 28 Jul 2020 11:21:57 +0000 Received: from CH2PR09MB4553.namprd09.prod.outlook.com ([fe80::b028:d8c6:6bcb:53ca]) by CH2PR09MB4553.namprd09.prod.outlook.com ([fe80::b028:d8c6:6bcb:53ca%6]) with mapi id 15.20.3239.016; Tue, 28 Jul 2020 11:21:57 +0000 From: "Dang, Quynh H. (Fed)" To: LAMPS WG Thread-Index: AQHWZNFNWKaP2r/l4kSf43+4EJ79yQ== Date: Tue, 28 Jul 2020 11:21:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [2610:20:6005:223::8d] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 7fb00a48-81cc-4c7f-b742-08d832e8708b x-ms-traffictypediagnostic: CH2PR09MB4569: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FvylSKpCbFg6uVI8Zy7gk+OXYGK6ACG2jw3v4zVfNDv3jcAa11Y6mxpOP+6ioFUbzO2yHMPFQjrBZL08OpxUG36LBDCo8PKXYOxf5EV3hF4L6j97w8XUonWLELPZ08/IjnozLATOTSrX2yzdYZFX+rS9HgsNI+jIF4gmDvqeRxiQ/M7iJUqxPmvW+0d9ubCSjR+c/nT7Pi4T+hw+uABZrtF9dKaDjEPKCaKPQLzJAmQmmUe2GTcb8vI3r7Gm+ZSCcq4ip4YQ6ZcDJasbfzAREqq4mLYlmfLwmWpYSMKbYj3DHw1SLkWyv5GFL5W++sOkiO/COr/skuyKPPNBk6ZGkQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR09MB4553.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(55016002)(498600001)(7696005)(19627405001)(71200400001)(6916009)(4270600006)(186003)(8936002)(6506007)(9686003)(33656002)(52536014)(86362001)(5660300002)(5406001)(64756008)(66946007)(558084003)(76116006)(66446008)(2906002)(66556008)(66476007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: iLEvorxtbFOpUs0+i0QGTsZWYYuXttvwZJnOFXEQz3BWBOqeAntSI3KILZFtZ7StSb+sxz2EsCB6P5zcxCjk9dpra3n8EaaeRuskzOVEWCa699G2lEwuAa2luHkgHpGnK4KjuTTs8vaE29lKF8QRk22Wcj8Z2THL1nQDER+EP6pqgIAy3fAsipCLmzpIf4ZfO6Je1GsSrN9QtM57VAXBCiaxlOXxDROI9vsQA/duReSN2LGOa/mBratjZoQMBDb7jtN33tAVcOK2pT+Wxvd6EH94rsy8Ci+Q/jn8gQBpWTHe05JnQUbTRwn2HOe5b7JEVblcmclB0Vb+4GF8dDtNXN4tvBzkD+GwCo0XW92B6fCsJrnQVsUWWhrtLUHEEZ+TBxyjOW+YIrfUm4RMEd4mR8M8aC+gdqthKhshgqp35pdiE0Wq+uqUJMlq1Qh1x6bcHiyqUPJXOQFqkrqn1S+o4tnlleK+voC3FdGQr0FpYnvqWFFttLrd1+C8yPC0V+c2 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR09MB455396DBBB8A45C814D42931F3730CH2PR09MB4553namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR09MB4553.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7fb00a48-81cc-4c7f-b742-08d832e8708b X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 11:21:57.4274 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yUXq9huO1uaf7VjP+8zSej845VRFv/6+s0EABLk5iagc+KHsuQeANYs3s/CM9ENu X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR09MB4569 Archived-At: Subject: [lamps] (no subject) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jul 2020 11:22:02 -0000 --_000_CH2PR09MB455396DBBB8A45C814D42931F3730CH2PR09MB4553namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please let me know the link to the meeting please! --_000_CH2PR09MB455396DBBB8A45C814D42931F3730CH2PR09MB4553namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Please let me know the link to the meeting please! 
--_000_CH2PR09MB455396DBBB8A45C814D42931F3730CH2PR09MB4553namp_-- From nobody Tue Jul 28 04:23:56 2020 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 BBEE73A0B94 for ; Tue, 28 Jul 2020 04:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=Ktq7D0I1; dkim=pass (1024-bit key) header.d=primekey.com header.b=Ktq7D0I1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9ZtLIahUhxJ for ; Tue, 28 Jul 2020 04:23:45 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 692F23A0B83 for ; Tue, 28 Jul 2020 04:23:44 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id A94D16AA037F for ; Tue, 28 Jul 2020 13:23:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1595935404; bh=wcyu0foM6u3g7CNOasy++mJZYL28AqdN7Vj+ryK09Mk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Ktq7D0I1r5II/t3lwGWgnB3MuwdOQOdHDKQomYLa91/CSvOdebyqpG+1CfTw1smDm CqvbMQGA5NvhPneVN4TOf6twJzkqjBnTjgu1BIZhdSsiu5oxxEzQBDxcm88Uq3UrD4 /oDu+fBAaVvQnRl+4w9WBC2sCPnUX8v5nwb2VJso= Received: from [10.0.0.9] (h217-72-53-54.cust.a3fiber.se [217.72.53.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id 8A0E16AA033F for ; Tue, 28 Jul 2020 13:23:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1595935404; bh=wcyu0foM6u3g7CNOasy++mJZYL28AqdN7Vj+ryK09Mk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Ktq7D0I1r5II/t3lwGWgnB3MuwdOQOdHDKQomYLa91/CSvOdebyqpG+1CfTw1smDm CqvbMQGA5NvhPneVN4TOf6twJzkqjBnTjgu1BIZhdSsiu5oxxEzQBDxcm88Uq3UrD4 /oDu+fBAaVvQnRl+4w9WBC2sCPnUX8v5nwb2VJso= To: spasm@ietf.org References: From: Tomas Gustavsson Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= xsBNBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAHNMFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPsLA dwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5zsBNBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAHCwF8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: <9c79a988-b1a7-3f2d-9bb0-8f743e50796f@primekey.com> Date: Tue, 28 Jul 2020 13:23:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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] (no subject) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jul 2020 11:23:53 -0000 https://gce.conf.meetecho.com/conference/?group=lamps&short=&item=1 On 2020-07-28 13:21, Dang, Quynh H. (Fed) wrote: > Please let me know the link to the meeting please! > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Tue Jul 28 05:20:22 2020 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 D02D93A0BF2 for ; Tue, 28 Jul 2020 05:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=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 HxxtLR4a0ZDe for ; Tue, 28 Jul 2020 05:19:54 -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 7E1823A0C81 for ; Tue, 28 Jul 2020 05:19:45 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 06SCE8uB019133; Tue, 28 Jul 2020 13:19:41 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=jAA2kr/uH2buXyTv+g8ShJAAGiMSya7oNmMGD7mDgVo=; b=hIXFnyemR8l0OXwY1L4HsPOGyDUTItTbclEf43H61myZKGfivFzchfhDdR6OB0I/JLc7 xXQoOjSqKOrI7iE4lFiH8+LUOLXXGNiwOAHzJ8Jcv8Us/icGGg5Z2KraGdZTRl5jdP++ XmpDMDDHFpNvwJYbIzwEfr7jESRsbceY6livbNc01h0HwbvgPAEi6j7/NJKcdyHbPHoK TL3KPXi3Tf7jOpkhcLLb3dk2mLbzroMz+uvbCcdnkmEVzno8OwayPsgIoG/AsFYFzPnW hlOhkTLRjlh0qerltr89qkh1fTQCtaXgSXXmO8WCDW21yP5UxsnOui0xolxu5Y536A9u 9w== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 32gc0vyn1n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Jul 2020 13:19:41 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 06SCH9Sh021198; Tue, 28 Jul 2020 08:19:39 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 32gg2y3ucj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 28 Jul 2020 08:19:39 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 28 Jul 2020 08:19:38 -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.1497.006; Tue, 28 Jul 2020 08:19:38 -0400 From: "Salz, Rich" To: Wang Guilin , "spasm@ietf.org" Thread-Topic: [Cfrg] How to issue CRLs after the private key of old root certificate has been destroyed? Thread-Index: AQHWZNjaO2G2MAfO80KxQHMPQXJnGKkc6QcA Date: Tue, 28 Jul 2020 12:19:38 +0000 Message-ID: References: <123C83B5-DFCB-4409-80A7-7DFA45056B7F@akamai.com> In-Reply-To: <123C83B5-DFCB-4409-80A7-7DFA45056B7F@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.35] Content-Type: text/plain; charset="utf-8" Content-ID: <7AC7EE12B3316E43B6A0D5881DBFF185@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-28_07:2020-07-28, 2020-07-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 spamscore=0 mlxlogscore=999 suspectscore=0 malwarescore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007280092 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-28_07:2020-07-28, 2020-07-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011 malwarescore=0 bulkscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=999 priorityscore=1501 suspectscore=0 adultscore=0 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007280094 Archived-At: Subject: Re: [lamps] [Cfrg] How to issue CRLs after the private key of old root certificate has been destroyed? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jul 2020 12:20:06 -0000 TWFpbCBhbGlhcyBpc3N1ZXMuICBNZWEgY3VscGENCg0K77u/T24gNy8yOC8yMCwgODoxNiBBTSwg IlNhbHosIFJpY2giIDxyc2FsekBha2FtYWkuY29tPiB3cm90ZToNCg0KICAgIE1vdmluZyBDRlJH IHRvIEJDQzsgdGhlIExBTVBTIHdvcmtpbmcgZ3JvdXAgaXMgYSBiZXR0ZXIgcGxhY2UgKGl0IGhh bmRsZXMgNTI4MCB1cGRhdGVzKSB0byBkaXNjdXNzIHRoaXMuDQoNCiAgICBPbiA3LzI4LzIwLCA2 OjIyIEFNLCAiV2FuZyBHdWlsaW4iIDxXYW5nLkd1aWxpbkBodWF3ZWkuY29tPiB3cm90ZToNCg0K ICAgICAgICBEZWFyIGFsbCwgDQoNCiAgICAgICAgSSBhbSBoZXJlIHRvIGVucXVpcmUgb25lIHF1 ZXN0aW9uIGFib3V0IHJldm9raW5nIFBLSSBjZXJ0aWZpY2F0ZXMuIA0KDQogICAgICAgIEluIHBy YWN0aWNlLCB0byBndWFyYW50ZWUgaGlnaCBzZWN1cml0eSwgdGhlIHZhbGlkaXR5IChzYXkgMTAg eWVhcnMpIG9mIGEgcm9vdCBjZXJ0aWZpY2F0ZSBwcml2YXRlIGtleSBtYXkgYmUgZXNzZW50aWFs bHkgc2hvcnRlciB0aGF0IHRoZSB2YWxpZGl0eSAoc2F5IDMwIHllYXJzKSBvZiB0aGUgY29ycmVz cG9uZGluZyBwdWJsaWMga2V5LiBBZnRlciB0aGUgZmlyc3QgMTAgeWVhcnMsIGEgbmV3IHJvb3Qg Y2VydGlmaWNhdGUgd2l0aCBhIG5ldyBrZXkgcGFpciB3aWxsIGJlIGdlbmVyYXRlZCwgYW5kIHRo ZSBvbGQgcm9vdCBwcml2YXRlIG1heSBiZSBldmVuIGRlc3Ryb3llZC4gQWZ0ZXIgdGhhdCwgaG93 ZXZlciwgaG93IGNhbiB3ZSB1c2UgdGhlIG5ldyByb290IHByaXZhdGUga2V5IHRvIGlzc3VlIENS THMgdG8gcmV2b2tlIGNlcnRpZmljYXRlcyBwcmV2aW91c2x5IHNpZ25lZCBieSB0aGUgb2xkIHJv b3QgcHJpdmF0ZSBrZXk/IA0KDQogICAgICAgIEF0IGZpcnN0LCBJIHRob3VnaHQgdGhpcyBpcyB0 aGUgY2FzZSBvZiB1c2luZyBpbmRpcmVjdCByZXZvY2F0aW9uIG1lY2hhbmlzbSBkaXNjdXNzZWQg aW4gUkZDIDUyODAsIHdoaWNoIG1heSBpbnZvbHZlIHRoZSBsaW5rIGNlcnRpZmljYXRlIE5ld1dp dGhPbGQsIHdoaWNoIGlzIGEgY2VydGlmaWNhdGUgZm9yIHRoZSBuZXcgcm9vdCBwdWJsaWMga2V5 IHNpZ25lZCBieSB0aGUgb2xkICByb290IHByaXZhdGUga2V5LiBIb3dldmVyLCBpdCBzZWVtcyB0 aGF0IGluZGlyZWN0IHJldm9jYXRpb24gb25seSB3b3JrcyBmb3IgZGlmZmVyZW50IGVudGl0aWVz LiBOYW1lbHksIGJ5IHVzaW5nIGluZGlyZWN0IHJldm9jYXRpb24sIHRoZSBjZXJ0aWZpY2F0ZXMg aXNzdWVkIGJ5IEEgY2FuIGJlIHJldm9rZWQgYnkgYSBkaWZmZXJlbnQgZW50aXR5IEIuIEhvd2V2 ZXIsIGluIHRoZSBhYm92ZSBjYXNlLCB0aGUgb2xkIGFuZCBuZXcgcm9vdCBjZXJ0aWZpY2F0ZXMg YXJlIGZvciB0aGUgc2FtZSBlbnRpdHkgKG9yIG93bmVyKS4gU28sIG15IHJlYWwgcXVlc3Rpb25z IGlzOiBDYW4gaW5kaXJlY3QgcmV2b2NhdGlvbiBiZSB1c2VkIGluIHN1Y2ggYSBzY2VuYXJpbz8g SWYgbm90LCBpcyB0aGVyZSBhbnkgZ29vZCB3YXkgdG8gZG8gdGhpcywgZXNwZWNpYWxseSBpZiBp bnRlcm9wZXJhYmlsaXR5IHdpdGggVExTLCBTU0wsIElQU2VjIGV0YyBpcyByZXF1aXJlZD8gDQoN CiAgICAgICAgVGhhbmtzIGEgbG90IGluIGFkdmFuY2UsIA0KDQogICAgICAgIEd1aWxpbg0KDQog ICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQog ICAgICAgIENmcmcgbWFpbGluZyBsaXN0DQogICAgICAgIENmcmdAaXJ0Zi5vcmcNCiAgICAgICAg aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu aXJ0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19jZnJnJmQ9RHdJQ0FnJmM9OTZaYlpaY2FNRjR3MEY0 anBONkxaZyZyPTRMTTBHYlIwaDlGdng4NkZ0c0tJLXcmbT1iOFB1dDVfb0ZnT1htbzZaZ2Zna1BM QmdmWjh2dFRCby1lUlY5QURFNlJRJnM9V0ZWc1NnTEhPUWs1Wl91QTVVRnlQUzE4U0NEYkwyNy1V d1lvcE5pOWdENCZlPSANCg0KDQo= From nobody Tue Jul 28 06:14:24 2020 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 8991A3A0C64 for ; Tue, 28 Jul 2020 06:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 8UJgjNvVu18D for ; Tue, 28 Jul 2020 06:14:16 -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 14CA03A0C6F for ; Tue, 28 Jul 2020 06:14:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7AF6C300AEC for ; Tue, 28 Jul 2020 09:14:04 -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 sTfe-xUp_yxY for ; Tue, 28 Jul 2020 09:14:03 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 7E0F2300A55 for ; Tue, 28 Jul 2020 09:14:03 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Message-Id: Date: Tue, 28 Jul 2020 09:14:05 -0400 To: LAMPS WG X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: [lamps] Summary of LAMPS at IETF 108 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jul 2020 13:14:23 -0000 Summary of the LAMPS WG Agenda at Virtual IETF 108: 1) draft-ietf-lamps-5480-ku-clarifications: in the RFC Editor queue. 2) draft-ietf-lamps-rfc7030est-clarify: on the IESG Telechat agenda for 2020-08-13. 3) draft-ietf-lamps-cms-update-alg-id-protect: in IETF Last Call. 4) draft-ietf-lamps-ocsp-nonce: just completed AD Review. Once those issues are resolved, it will go into IETF Last Call. 5) draft-ietf-lamps-cmp-updates: needs an updated ASN.1 module, then it will be ready for WG Last Call. 6) draft-ietf-lamps-lightweight-cmp-profile: nearly complete, but depends upon draft-ietf-lamps-cmp-updates, so it will go to WG Last Call after that document. 7) draft-ietf-lamps-header-protection: active discussion. From nobody Tue Jul 28 06:50:46 2020 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 E2F2A3A0C47 for ; Tue, 28 Jul 2020 06:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 qrpTm-4XRVe8 for ; Tue, 28 Jul 2020 06:50:43 -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 EB98C3A0E56 for ; Tue, 28 Jul 2020 06:50:16 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06SDhOXW004640 for ; Tue, 28 Jul 2020 14:50:15 +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=GiABv6BfNxoDc3j300P0yxZqAGNXoOPU4O9f2obNvcI=; b=QK95zuI+oAMTt64FDPSgb8W46yzxgSKZp1dYrT+/7JIAqb0jynEGBTOE9RIllvIhWjUM qNXF9OKXPJyQMxBSkD/6RsVX0SPRzPZ7RDcoDyQMmcw1EBsTyH0wmmeQN5JXLnmWCWEm 3AZ8OcipI7u/gL89vUsO15O9Dvw0ERgBIb42Hym5XJSLq9lUIZf1EjED5W3a50Z+F+VG 4hEIi/cDuBvqcZJp9eyvwZGhrJDMS0QcQ1wdwz5bssrHqeNwoEFiPtyj3fgB0f0JKGps FO5jdexLLqZRGxGf1z8xvhkjYSPM7qhVe1bKqGeA0fOU4X9Dmg2g3IEsTCBNcykc3cto tA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 32gcd27t7a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 28 Jul 2020 14:50:15 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 06SDlCVS026295 for ; Tue, 28 Jul 2020 09:50:13 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint2.akamai.com with ESMTP id 32gg2y4de9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 28 Jul 2020 09:50:13 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb2.msg.corp.akamai.com (172.27.123.59) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 28 Jul 2020 09:50:13 -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.1497.2; Tue, 28 Jul 2020 09:50:13 -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.1497.006; Tue, 28 Jul 2020 09:50:12 -0400 From: "Salz, Rich" To: "spasm@ietf.org" Thread-Topic: draft minutes for July 28 IETF 108 meeting Thread-Index: AQHWZOYDL7BlsTvd90WKSTbn7QMOXA== Date: Tue, 28 Jul 2020 13:50:12 +0000 Message-ID: <01DB80AF-1E13-45D3-AB64-D258D282F238@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.52] Content-Type: multipart/mixed; boundary="_004_01DB80AF1E1345D3AB64D258D282F238akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-28_11:2020-07-28, 2020-07-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 spamscore=0 mlxlogscore=901 suspectscore=0 malwarescore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007280103 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-28_11:2020-07-28, 2020-07-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 adultscore=0 mlxlogscore=914 priorityscore=1501 phishscore=0 malwarescore=0 lowpriorityscore=0 suspectscore=0 mlxscore=0 bulkscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007280105 Archived-At: Subject: [lamps] draft minutes for July 28 IETF 108 meeting X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jul 2020 13:50:45 -0000 --_004_01DB80AF1E1345D3AB64D258D282F238akamaicom_ Content-Type: multipart/alternative; boundary="_000_01DB80AF1E1345D3AB64D258D282F238akamaicom_" --_000_01DB80AF1E1345D3AB64D258D282F238akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXJlIGF0IGh0dHBzOi8vY29kaW1kLmlldGYub3JnL25vdGVzLWlldGYtMTA4LWxhbXBzIyBhbmQg YSBtYXJrZG93biBleHBvcnQgaXMgYWxzbyBhdHRhY2hlZC4NCg0K --_000_01DB80AF1E1345D3AB64D258D282F238akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <009FD146D99D8B4FA977391473A3FE3A@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0i Izk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFyZSBhdCA8YSBocmVmPSJodHRwczov L2NvZGltZC5pZXRmLm9yZy9ub3Rlcy1pZXRmLTEwOC1sYW1wcyMiPg0KaHR0cHM6Ly9jb2RpbWQu aWV0Zi5vcmcvbm90ZXMtaWV0Zi0xMDgtbGFtcHMjPC9hPiBhbmQgYSBtYXJrZG93biBleHBvcnQg aXMgYWxzbyBhdHRhY2hlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_01DB80AF1E1345D3AB64D258D282F238akamaicom_-- --_004_01DB80AF1E1345D3AB64D258D282F238akamaicom_ Content-Type: text/markdown; name="LAMPS WG at Virtual IETF 108.md" Content-Description: LAMPS WG at Virtual IETF 108.md Content-Disposition: attachment; filename="LAMPS WG at Virtual IETF 108.md"; size=2096; creation-date="Tue, 28 Jul 2020 13:50:12 GMT"; modification-date="Tue, 28 Jul 2020 13:50:12 GMT" Content-ID: Content-Transfer-Encoding: base64 TEFNUFMgV0cgYXQgVmlydHVhbCBJRVRGIDEwOAo9PT0KCkFnZW5kYQo9PT0KCjApICBNaW51dGUg VGFrZXIsIEphYmJlciBTY3JpYmUsIEJsdWVzaGVldHMKICAgICAgICBNaW51dGVzIC0gUmljaCBT YWx6CgoxKSAgQWdlbmRhIEJhc2gKICAgICAgICBObyBjaGFuZ2VzCgoyKSAgRG9jdW1lbnRzIHdp dGggdGhlIFJGQyBFZGl0b3IgYW5kIElFU0cKICAgIGEpICBkcmFmdC1pZXRmLWxhbXBzLTU0ODAt a3UtY2xhcmlmaWNhdGlvbnMgKFNlYW4pCiAgICAgICAgICAgIEluIFJGQyBlZGl0b3IgcXVldWU7 IGJlbGlldmVkIHdhaXRpbmcgZm9yIGNsdXN0ZXIgMjM4LCBhdCBsZWFzdAogICAgYikgIGRyYWZ0 LWlldGYtbGFtcHMtb2NzcC1ub25jZSAoTW9oaXQpCiAgICAgICAgICAgIFdpbGwgYWRkcmVzcyBB RCBjb21tZW50cyBhbmQgcG9zdCBuZXcgdmVyc2lvbiBzb29uCiAJYykgIGRyYWZ0LWlldGYtbGFt cHMtcmZjNzAzMGVzdC1jbGFyaWZ5IChNaWNoYWVsLCBUaG9tYXMsIFdlaSkKICAgICAgICAgICAg SW4gSUVURiBsYXN0IGNhbGw7IG9uIElFU0cgdGVsZWNoYXQgZm9yIEF1Z3VzdCAxMwogICAgZCkg IGRyYWZ0LWlldGYtbGFtcHMtY21zLXVwZGF0ZS1hbGctaWQtcHJvdGVjdCAoUnVzcykKICAgICAg ICAgICAgQUQgcmV2aWV3IGRvbmUsIGFsbCBlZGl0b3JpYWwsIElFVEYgTEMgc3RhcnRlZCB5ZXN0 ZXJkYXkKCjMpICBBY3RpdmUgV29ya2luZyBHcm91cCBEb2N1bWVudHMKICAgIGEpICBkcmFmdC1p ZXRmLWxhbXBzLWNtcC11cGRhdGVzIChIZW5kcmlrKQogICAgICAgICAgICBDaGFuZ2VzIHByZXNl bnRlZC4gRWRpdG9yaWFsIHVwZGF0ZXMgc3RpbGwgbmVlZGVkLgogICAgICAgICAgICBQcml2YXRl IGtleSBpcyBjdXJyZW50bHkgaWQtRGF0YSAob2N0ZXQgc3RyaW5nKTsKICAgICAgICAgICAgbGlr ZWx5IGRvIHNvbWV0aGluZyB3aXRoIG1vcmUgc3RydWN0dXJlIChSRkMgNTk1OCBrZXkgcGFja2Fn ZSkuCiAgICBiKSAgZHJhZnQtaWV0Zi1sYW1wcy1saWdodHdlaWdodC1jbXAtcHJvZmlsZSAoSGVu ZHJpaywgU3RlZmZlbiwgRGF2aWQpCiAgICAgICAgICAgIENoYW5nZXMgcHJlc2VudGVkLiBIZW5k cmlrIGhhdmluZyBuZXR3b3JrIGlzc3VlcywgU3RlZmZlbiBzdGVwcGVkIGluIHRlbXBvcmFyaWx5 LgogICAgICAgICAgICBUb0RvOiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucywgZGlzY3Vzc2lvbiBv ZiBjZW50cmFsaXplZCBrZXkgZ2VuZXJhdGlvbiwgZWRpdG9yaWFsIHN0dWZmLgogICAgICAgICAg ICBTaG93ZWQgZGV0YWlscyBvZiBjb252ZXJ0aW5nIFNpZ25lZERhdGEgY29udGVudCBmcm9tIG9j dGV0IHRvIGlkLWN0LUtQLWFLZXlQYWNrYWdlCiAgICAgICAgICAgIE5lZWQgV0cgcmV2aWV3LCBp biBwYXJ0aWN1bGFyIEFTTjEsIElBTkEgY29uc2lkZXJhdGlvbnMsIGdlbmVyYWwgRW5nbGlzaC4K ICAgICAgICAgICAgRGlzY3Vzc2lvbiBvZiBob3cgdG8gaWRlbnRpZnkgYWxnb3JpdGhtcy4KICAg ICAgICAgICAgV2lsbCBzcGxpdCBvdXQgZXhpc3RpbmcgYWxnb3JpdGhtIHNwZWNzIGFuZCBzdWJt aXQgYSBuZXcgV0cgZG9jdW1lbnQuCiAgICAgICAgICAgIERpc2N1c3Npb24gb2YgbmFtaW5nIHdo YXQgcGFydHMgb2YgNjcxMiBhcmUgdXBkYXRlZC4KICAgIGMpICBkcmFmdC1pZXRmLWxhbXBzLWhl YWRlci1wcm90ZWN0aW9uIChBbGV4ZXksIEJlcm5pZSkKICAgICAgICAgICAgQmVybmllIHByZXNl bnRpbmcuICBEaXNjdXNzaW9uIG9mIHVzZSBjYXNlcywgcGFydGljdWxhcmx5IE1JTUUvbm9uLU1J TUUuCiAgICAgICAgICAgIE1lc3NhZ2UgcHJvdGVjdGlvbiAoc2lnbmluZywgZW5jcnlwdGlvbiku IERpc2N1c3Npb24uCiAgICAgICAgICAgIHtvZmZsaW5lfQogICAgICAgICAgICBEaXNjdXNzaW9u IG9mIE1JTUUgY29tcGxpYW5jZSwgRm9ybWF0IGlzc3VlcyBhbmQgcmVuZGVyaW5nLCBub24tTUlN RSwKICAgICAgICAgICAgbmVzdGVkIG1lc3NhZ2VzLCBnYXRld2F5cywgZXRjLgogICAgICAgICAg ICBSZXF1ZXN0IGZyb20gY2hhaXIgdG8ga2VlcCB0aGUgbW9tZW50dW0gZ29pbmcgKGhhZCBhIHNp eC1tb250aCBzaWxlbnQgcGVyaW9kL2hpYXR1cykKCjQpICBXcmFwIFVwCgo= --_004_01DB80AF1E1345D3AB64D258D282F238akamaicom_-- From nobody Tue Jul 28 07:48:39 2020 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 381423A0DAB for ; Tue, 28 Jul 2020 07:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 Lp3LwKiJaZi2 for ; Tue, 28 Jul 2020 07:48:33 -0700 (PDT) Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) (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 10BE83A0D93 for ; Tue, 28 Jul 2020 07:48:32 -0700 (PDT) Received: by mail-pl1-f180.google.com with SMTP id q17so9987185pls.9 for ; Tue, 28 Jul 2020 07:48:32 -0700 (PDT) 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=FZdCSwFuKdT5AjC2SalGnrXRdscHgNxowRJIB08eyAY=; b=j8e6uzJIoWCwoqwHss+SQJXd5nh2WtapTeu00DOXr/QOoX0Jce6k+snbtd5h3mScow Kq4Jsc1j5QNo+mIbJXhlqwr7ZHaJe9NFsyvjqC3MGJ/4X112LiLYQCjqjqm533frg+yr 3ViTP8rVFK9kt05KfxhDQBSvBA47dr58rYH54U1hlnHB8LtpqdSFaERGL8q55IHQHANf 0t1NnD7XVQT/gRskd9kliqNUU4oerork4yxIDwULY3YNrb6qWesEVvz87/5Nv+r20NQw E+GWNVka/t9qjYRsv6xOmhYzPUgQy3V+AVmk30YXvMPgQRvu+ButrgM4P7dOULPDHF5B BxuQ== X-Gm-Message-State: AOAM532TuA+cL6dpg/6Oi4wesGuGMtDRIL0ZoXYWyMd3LXEob5xDquNN HL2Sthe4FTJAykwOwUQREquWscAb X-Google-Smtp-Source: ABdhPJxzBRB7eb9u7CO4g9JGSi4VQndMUiYGEVrdl+Z0uD4ea3wkRNOuSvnPspLo8WVXZrQ2aF1chg== X-Received: by 2002:a17:90b:94f:: with SMTP id dw15mr5036117pjb.209.1595947711293; Tue, 28 Jul 2020 07:48:31 -0700 (PDT) Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com. [209.85.216.46]) by smtp.gmail.com with ESMTPSA id a17sm18255437pgw.60.2020.07.28.07.48.30 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jul 2020 07:48:31 -0700 (PDT) Received: by mail-pj1-f46.google.com with SMTP id k1so11704382pjt.5 for ; Tue, 28 Jul 2020 07:48:30 -0700 (PDT) X-Received: by 2002:a17:90a:e2c7:: with SMTP id fr7mr4883080pjb.103.1595947710635; Tue, 28 Jul 2020 07:48:30 -0700 (PDT) MIME-Version: 1.0 References: <123C83B5-DFCB-4409-80A7-7DFA45056B7F@akamai.com> In-Reply-To: From: Ryan Sleevi Date: Tue, 28 Jul 2020 10:48:19 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Salz, Rich" Cc: Wang Guilin , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005f638905ab818885" Archived-At: Subject: Re: [lamps] [Cfrg] How to issue CRLs after the private key of old root certificate has been destroyed? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jul 2020 14:48:38 -0000 --0000000000005f638905ab818885 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is something the CA would address as part of the RFC 3647 framework for discussing CA or RA termination: https://tools.ietf.org/html/rfc3647#section-4.5.8 I don't understand the remark about signing CRLs after the expiration of the (old) root. After that expiration, there is presumably no temporally valid certificate chain for those existing certificates, and they are thus not time valid, as called out in https://tools.ietf.org/html/rfc5280#section-4.1.2.5 and https://tools.ietf.org/html/rfc5280#section-6.1.3 I suspect I must be misunderstanding something about the question, because I'm having trouble understanding the scenario where the revocation data would be relevant after the expiration of all issuer certificate(s)? Is it describing a scenario in which the new root issues a cross-certificate for the old root, after the old root's private key has been destroyed, which extends the lifetime of the old root beyond the 10 years specified? On Tue, Jul 28, 2020 at 8:20 AM Salz, Rich wrote: > Mail alias issues. Mea culpa > > =EF=BB=BFOn 7/28/20, 8:16 AM, "Salz, Rich" wrote: > > Moving CFRG to BCC; the LAMPS working group is a better place (it > handles 5280 updates) to discuss this. > > On 7/28/20, 6:22 AM, "Wang Guilin" wrote: > > Dear all, > > I am here to enquire one question about revoking PKI certificates= . > > In practice, to guarantee high security, the validity (say 10 > years) of a root certificate private key may be essentially shorter that > the validity (say 30 years) of the corresponding public key. After the > first 10 years, a new root certificate with a new key pair will be > generated, and the old root private may be even destroyed. After that, > however, how can we use the new root private key to issue CRLs to revoke > certificates previously signed by the old root private key? > > At first, I thought this is the case of using indirect revocation > mechanism discussed in RFC 5280, which may involve the link certificate > NewWithOld, which is a certificate for the new root public key signed by > the old root private key. However, it seems that indirect revocation onl= y > works for different entities. Namely, by using indirect revocation, the > certificates issued by A can be revoked by a different entity B. However, > in the above case, the old and new root certificates are for the same > entity (or owner). So, my real questions is: Can indirect revocation be > used in such a scenario? If not, is there any good way to do this, > especially if interoperability with TLS, SSL, IPSec etc is required? > > Thanks a lot in advance, > > Guilin > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.irtf.org_mailm= an_listinfo_cfrg&d=3DDwICAg&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3D4LM0GbR0h9Fvx86F= tsKI-w&m=3Db8Put5_oFgOXmo6ZgfgkPLBgfZ8vtTBo-eRV9ADE6RQ&s=3DWFVsSgLHOQk5Z_uA= 5UFyPS18SCDbL27-UwYopNi9gD4&e=3D > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --0000000000005f638905ab818885 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is something the CA would address as part of the RFC = 3647 framework for discussing CA or RA termination:=C2=A0https://tools.ietf.org/html/rfc= 3647#section-4.5.8

I don't understand the remark= about signing CRLs after the expiration of the (old) root. After that expi= ration, there is presumably no temporally valid certificate chain for those= existing certificates, and they are thus not time valid, as called out in= =C2=A0https= ://tools.ietf.org/html/rfc5280#section-4.1.2.5=C2=A0and=C2=A0https://tools.ietf.org/= html/rfc5280#section-6.1.3

I suspect I must be= misunderstanding something about the question, because I'm having trou= ble understanding the scenario where the revocation data would be relevant = after the expiration of all issuer certificate(s)? Is it describing a scena= rio in which the new root issues a cross-certificate for the old root, afte= r the old root's private key has been destroyed, which extends the life= time of the old root beyond the 10 years specified?

On Tue, Jul 28, 20= 20 at 8:20 AM Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org> wrote:
Mail alias issues.=C2=A0 Mea culpa

=EF=BB=BFOn 7/28/20, 8:16 AM, "Salz, Rich" <rsalz@akamai.com> wrote:

=C2=A0 =C2=A0 Moving CFRG to BCC; the LAMPS working group is a better place= (it handles 5280 updates) to discuss this.

=C2=A0 =C2=A0 On 7/28/20, 6:22 AM, "Wang Guilin" <Wang.Guilin@huawei.com&= gt; wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Dear all,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I am here to enquire one question about revokin= g PKI certificates.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 In practice, to guarantee high security, the va= lidity (say 10 years) of a root certificate private key may be essentially = shorter that the validity (say 30 years) of the corresponding public key. A= fter the first 10 years, a new root certificate with a new key pair will be= generated, and the old root private may be even destroyed. After that, how= ever, how can we use the new root private key to issue CRLs to revoke certi= ficates previously signed by the old root private key?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 At first, I thought this is the case of using i= ndirect revocation mechanism discussed in RFC 5280, which may involve the l= ink certificate NewWithOld, which is a certificate for the new root public = key signed by the old=C2=A0 root private key. However, it seems that indire= ct revocation only works for different entities. Namely, by using indirect = revocation, the certificates issued by A can be revoked by a different enti= ty B. However, in the above case, the old and new root certificates are for= the same entity (or owner). So, my real questions is: Can indirect revocat= ion be used in such a scenario? If not, is there any good way to do this, e= specially if interoperability with TLS, SSL, IPSec etc is required?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks a lot in advance,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Guilin

=C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cfrg mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cfrg@irtf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://urldefens= e.proofpoint.com/v2/url?u=3Dhttps-3A__www.irtf.org_mailman_listinfo_cfrg&am= p;d=3DDwICAg&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3D4LM0GbR0h9Fvx86FtsKI-w&= amp;m=3Db8Put5_oFgOXmo6ZgfgkPLBgfZ8vtTBo-eRV9ADE6RQ&s=3DWFVsSgLHOQk5Z_u= A5UFyPS18SCDbL27-UwYopNi9gD4&e=3D


_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--0000000000005f638905ab818885-- From nobody Tue Jul 28 07:54:35 2020 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 38DEC3A0D48 for ; Tue, 28 Jul 2020 07:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 vjlzwRNDf0G2 for ; Tue, 28 Jul 2020 07:54:31 -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 40DCA3A0CD9 for ; Tue, 28 Jul 2020 07:54:27 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 06SErthc026669; Tue, 28 Jul 2020 15:54:11 +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=OEtVx8mJ8KiBfYi5wW8Oyjf6k855LDMyXZDQWxi3/KA=; b=J9b+qcRV3DQWHn6xoGYHbpgFyhldfjancLUhuUCoAYqN2e64x/DtEH2ef0rNjL/dj0HD Yl+QDNcPxoNkhyDQDK6O57V5N2CJEnFjJxoLHR7luoYVfindG2R1dXOjIqixkRIXR4K7 rhFSp5aKubqBVaugAXv9jka+dcihOWaEQN7JyQrnM6rOgp7h6AfEzNM3zBvPNTVFoMC7 v5YlItKx1FwqwELZg5/pOHcw4Ci/19CF2oWyZbDpEwwTP6fCCKapLn6GEpLeXBtWFpr3 sRDkJCJWU0Qzs2/7FNNabRvLjIC8ER9jrgw7wsnjEap37bnVPk0e11ybd9AK4NDvI89h jw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 32gc0w5t9q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Jul 2020 15:54:11 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 06SElEqK000632; Tue, 28 Jul 2020 10:54:10 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint2.akamai.com with ESMTP id 32gg2y4wrg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 28 Jul 2020 10:54:10 -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.1497.2; Tue, 28 Jul 2020 10:54:09 -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.1497.006; Tue, 28 Jul 2020 10:54:09 -0400 From: "Salz, Rich" To: Ryan Sleevi CC: Wang Guilin , "spasm@ietf.org" Thread-Topic: [lamps] [Cfrg] How to issue CRLs after the private key of old root certificate has been destroyed? Thread-Index: AQHWZNjaO2G2MAfO80KxQHMPQXJnGKkc6QcAgABsmYD//76SAA== Date: Tue, 28 Jul 2020 14:54:08 +0000 Message-ID: <2001BA94-5044-42C8-9CE9-0F8BF0DA5C65@akamai.com> References: <123C83B5-DFCB-4409-80A7-7DFA45056B7F@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.52] Content-Type: multipart/alternative; boundary="_000_2001BA94504442C89CE90F8BF0DA5C65akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-28_11:2020-07-28, 2020-07-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 spamscore=0 mlxlogscore=905 suspectscore=0 malwarescore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007280112 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-28_13:2020-07-28, 2020-07-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 malwarescore=0 bulkscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=863 priorityscore=1501 suspectscore=0 adultscore=0 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007280115 Archived-At: Subject: Re: [lamps] [Cfrg] How to issue CRLs after the private key of old root certificate has been destroyed? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jul 2020 14:54:34 -0000 --_000_2001BA94504442C89CE90F8BF0DA5C65akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGF0IGlzIHRoZSBrZXkgcG9pbnQuICBBIENBIGNhbm5vdCBzaWduIGFueXRoaW5n IHRoYXQgZ29lcyBiZXlvbmQgaXRzIG93biBub3RBZnRlciBmaWVsZC4NCg0K --_000_2001BA94504442C89CE90F8BF0DA5C65akamaicom_ 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 IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoYXQgaXMgdGhlIGtleSBw b2ludC4mbmJzcDsgQSBDQSBjYW5ub3Qgc2lnbiBhbnl0aGluZyB0aGF0IGdvZXMgYmV5b25kIGl0 cyBvd24gbm90QWZ0ZXIgZmllbGQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2001BA94504442C89CE90F8BF0DA5C65akamaicom_-- From nobody Tue Jul 28 07:54:59 2020 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 71C833A0D5A for ; Tue, 28 Jul 2020 07:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=entrustdatacardcorp.onmicrosoft.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 ka1I_WFkQygz for ; Tue, 28 Jul 2020 07:54:53 -0700 (PDT) Received: from mx2.entrustdatacard.com (mx2.entrustdatacard.com [204.124.80.222]) (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 30A663A0D4A for ; Tue, 28 Jul 2020 07:54:53 -0700 (PDT) IronPort-SDR: FrcGduNTE7nbGP9/SGRuwk4lXKSlTx+/I7oRZXSAG1ju+vMJYfPA3db7cJflGWGJvJTjD5lgJ6 FYXuIH41888w== X-IronPort-AV: E=Sophos; i="5.75,406,1589259600"; d="scan'208,217"; a="17690907" Received: from pmspex01.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.29]) by pmspesa04inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 28 Jul 2020 09:54:24 -0500 Received: from pmspex01.corporate.datacard.com (192.168.211.29) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 28 Jul 2020 09:54:24 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (172.28.1.8) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 28 Jul 2020 09:54:24 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U5M9adgzfd/9nRnKfiR2Sv1PQwo4YDPc4QplxCGvR1LlhlryZHs09BdrLd9kY2whhvIduwa71m1RrgNP5q1DmMY3e6rU0KQvbweN0vKXZvXS9CSQZIDWwCMuVmQyJWMM70p5MBs6utNzMASXa/CrpdZidQ+f1O1AI92+3GlPsFCBsoVEtidT/cVQAAE+l2drQV6w6r6/UHAw9jQKXYBZ+XawrTYh5b6ShAR1HN5hu+MFl+SHb3IcpXEOVANzwNCWVpk04oFjVFULaXKwpO7T0N4gJvcOHniw3vPePCgde31TS4gG4h3R/9PGjtz5E8Ehp5wkCGYlqkjwmVSuiMTEVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jv/HIxwv5r22VjgjHKw/y5NNkA277z1J94guzBReSGA=; b=Lwleagb/oD3/DME861P4rfpVPA/+Px6TAYtwl5wN+A3vXGLR6RecCvrF1uxqc7KgA3H5HPkXWv7yLgL3RITGWRtaA1IRwVYYmDroopVfa3TatP0azvMGOv5g/EMrNp7oXuKtv/IUyyN+Xv9JR5zXDWZ1vIpqlqh5MobpZNALt9f4tN4YZ1+C4zgJ7UEdF94DIMZBGH5PHLvbxNN3ayr7YEzysdgHSF9mBXIBCAPKiJ4SJZT36GVbnXWV2y2hufpvzN4MCff51IeEbVmKoaKG1Ct1Z6mLi8EOfXaFRTFyda8wBrcwv13Tky9XRjv7IA8+sEplaXoNFVfRBPuhfzLusg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrustdatacard.com; dmarc=pass action=none header.from=entrustdatacard.com; dkim=pass header.d=entrustdatacard.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrustdatacardcorp.onmicrosoft.com; s=selector1-entrustdatacardcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jv/HIxwv5r22VjgjHKw/y5NNkA277z1J94guzBReSGA=; b=JkRoUd3NOjGB0QRfuabWu5TtpOuS6XawxOeb0sYd8JlACPLBH4PA0Xf67/kfpzmnWPi77xoOsVaxLDfk2kgZvTjvoC6q7qxAOGNyxtmcgvGgHh+ADf2X3WCydp2nkrIT5rz2k0khuzavMMqrVU8SRGI16AH91tGEIjXWBOTn3gU= Received: from DM6PR11MB3915.namprd11.prod.outlook.com (2603:10b6:5:19c::11) by DM6PR11MB4627.namprd11.prod.outlook.com (2603:10b6:5:2a2::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.23; Tue, 28 Jul 2020 14:54:22 +0000 Received: from DM6PR11MB3915.namprd11.prod.outlook.com ([fe80::e411:a475:5fca:f0dd]) by DM6PR11MB3915.namprd11.prod.outlook.com ([fe80::e411:a475:5fca:f0dd%4]) with mapi id 15.20.3216.034; Tue, 28 Jul 2020 14:54:22 +0000 From: Mike Ounsworth To: Ryan Sleevi , "Salz, Rich" CC: "spasm@ietf.org" , Wang Guilin Thread-Topic: [EXTERNAL]Re: [lamps] [Cfrg] How to issue CRLs after the private key of old root certificate has been destroyed? Thread-Index: AQHWZNjaO2G2MAfO80KxQHMPQXJnGKkc6QcAgAApi4CAAACf8A== Date: Tue, 28 Jul 2020 14:54:22 +0000 Message-ID: References: <123C83B5-DFCB-4409-80A7-7DFA45056B7F@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sleevi.com; dkim=none (message not signed) header.d=none;sleevi.com; dmarc=none action=none header.from=entrustdatacard.com; x-originating-ip: [70.76.144.81] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c1abc21a-cf9c-4d0e-5ec1-08d833061d3a x-ms-traffictypediagnostic: DM6PR11MB4627: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3044; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RGnOusXxxbzu2fqg0luI5mPQEmmwvRi7F+eYByu6KtTCWS6t88HtjvGAFGHkhrCi1yFBMaCsonDWb29JUSGi9OMe+AXzKMD5uumhSl0nHrXGPIZj4MZYWOdJYu1sMZ1UloNs+7rj5OE3tFGlVUvFgmSOuHNYwC2ZjzkICTCaMiKkGDhd8uerchdJkKvlqktjhHF1rpNqiHELpZd/4nQjquHEePi4svnZffA2oxSkX/NCMckhWaG0mzZgPF3FFd1y8ySd5wmlrL4/w72MXDErfWU+b8jz6waUqjGf/7WAq8/4qcoBIBnk7DLpKSzsJ28xXWS25UQDVuCCrYsP2aNHFdAk6VxjGLmT0adIj1KJsGV9VaMuFoUXUBssszZpD45qdWv7ltacJV/8ifh5F2zzig== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3915.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(136003)(376002)(346002)(39850400004)(366004)(396003)(966005)(26005)(186003)(478600001)(52536014)(5660300002)(110136005)(4326008)(316002)(54906003)(7696005)(71200400001)(6506007)(53546011)(83380400001)(8676002)(55016002)(66946007)(9686003)(2906002)(8936002)(86362001)(166002)(66556008)(66476007)(76116006)(66446008)(64756008)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: XHa+5Nyb4U92Nm6rIgrIlniR8b6Tk5n+jZypwxpyEZ/MgpSgwpuLu3KM98q66s+QmkQNSAQsgO3BOWDzvNRnhB07ypjavCDoPEPcb6uI9n+mMmUpHjlmerzz7SqwH+kuZWd7puqmBW33dJ2wCMP7Bn5Yz7KmeLSLsMMOi4Hh+b7lofdMLSYHbwWwcgDjrjeRge8YnJ72mUsZk55zZKocPcPsnSvlwveSlrPd1FW8KyAgKmSrOhP9WMHWwtetDp63T7Jn9LTQZN2ewug+ZxfO2xU4zTFxKAgBB89OepgQJqJjfv1yUWWt3sRb304RlDMxWCbqjhoAiDMLAV4YKA3gajayBrQlTUnbLpJkIxU9XTyOJ4Dqf19VMVkknkvGE+uXq2p9TPSIaQWPyPRWa+QFltHR4zI4GFWMxLPOWFrM/FKjqOTLLrguWoohlijYhSAnCTVLZZmWBZQOt+YCJa9ER0lfcUEwz2n6hsYD2uvFXtI= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB391533860F13BBD51DB53E699B730DM6PR11MB3915namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3915.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c1abc21a-cf9c-4d0e-5ec1-08d833061d3a X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 14:54:22.4471 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Bq2/px+gZ7VLtpA1jqHX5em7CfMDam2jTeD4dX4LVRgzuoK8+HDg1NsBosmYeChP0ryN9q4h4C01I09gRL8v76esRr94B1zQ3xj6AdVqNPMAT9UA2P5/xbavV9N+PqDk X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4627 X-OriginatorOrg: entrustdatacard.com Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: [Cfrg] How to issue CRLs after the private key of old root certificate has been destroyed? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jul 2020 14:54:58 -0000 --_000_DM6PR11MB391533860F13BBD51DB53E699B730DM6PR11MB3915namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UnlhbiwNCg0KSeKAmW0gaW50ZXJwcmV0aW5nIHRoZSBzY2VuYXJpbyB0byBiZSBhIDMwLXllYXIg cm9vdCBjZXJ0LCBpc3N1aW5nIDMwIHllYXIgZW5kIGVudGl0aWVzLiBBdCB0aGUgMTAgeWVhciBt YXJrIHRoZXkgZGVzdHJveWVkIHRoZSByb2904oCZcyBwcml2IGtleS4gVGhleSBhcmUgbm93IHJl YWxpemluZyB0aGF0IHRoZXkgaGF2ZSBlbmQgZW50aXRpZXMgdmFsaWQgZm9yIGFub3RoZXIgMjAg eWVhcnMgYnV0IG5vIHdheSB0byBpc3N1ZSBmcmVzaCBDUkxzIGZvciB0aGVtLiBJIG1heSBiZSBt aXMtcmVhZGluZyB0aG91Z2guDQoNCi0tLQ0KTWlrZSBPdW5zd29ydGgNClNvZnR3YXJlIFNlY3Vy aXR5IEFyY2hpdGVjdCwgRW50cnVzdCBEYXRhY2FyZA0KDQpGcm9tOiBTcGFzbSA8c3Bhc20tYm91 bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFJ5YW4gU2xlZXZpDQpTZW50OiBKdWx5IDI4LCAy MDIwIDk6NDggQU0NClRvOiBTYWx6LCBSaWNoIDxyc2Fsej00MGFrYW1haS5jb21AZG1hcmMuaWV0 Zi5vcmc+DQpDYzogc3Bhc21AaWV0Zi5vcmc7IFdhbmcgR3VpbGluIDxXYW5nLkd1aWxpbkBodWF3 ZWkuY29tPg0KU3ViamVjdDogW0VYVEVSTkFMXVJlOiBbbGFtcHNdIFtDZnJnXSBIb3cgdG8gaXNz dWUgQ1JMcyBhZnRlciB0aGUgcHJpdmF0ZSBrZXkgb2Ygb2xkIHJvb3QgY2VydGlmaWNhdGUgaGFz IGJlZW4gZGVzdHJveWVkPw0KDQpXQVJOSU5HOiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgb3V0c2lk ZSBvZiBFbnRydXN0IERhdGFjYXJkLg0KRE8gTk9UIENMSUNLIGxpbmtzIG9yIGF0dGFjaG1lbnRz IHVubGVzcyB5b3UgdHJ1c3QgdGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZl Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRoaXMgaXMgc29tZXRoaW5nIHRo ZSBDQSB3b3VsZCBhZGRyZXNzIGFzIHBhcnQgb2YgdGhlIFJGQyAzNjQ3IGZyYW1ld29yayBmb3Ig ZGlzY3Vzc2luZyBDQSBvciBSQSB0ZXJtaW5hdGlvbjogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzM2NDcjc2VjdGlvbi00LjUuOA0KDQpJIGRvbid0IHVuZGVyc3RhbmQgdGhlIHJlbWFy ayBhYm91dCBzaWduaW5nIENSTHMgYWZ0ZXIgdGhlIGV4cGlyYXRpb24gb2YgdGhlIChvbGQpIHJv b3QuIEFmdGVyIHRoYXQgZXhwaXJhdGlvbiwgdGhlcmUgaXMgcHJlc3VtYWJseSBubyB0ZW1wb3Jh bGx5IHZhbGlkIGNlcnRpZmljYXRlIGNoYWluIGZvciB0aG9zZSBleGlzdGluZyBjZXJ0aWZpY2F0 ZXMsIGFuZCB0aGV5IGFyZSB0aHVzIG5vdCB0aW1lIHZhbGlkLCBhcyBjYWxsZWQgb3V0IGluIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjgwI3NlY3Rpb24tNC4xLjIuNSBhbmQgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUyODAjc2VjdGlvbi02LjEuMw0KDQpJIHN1c3Bl Y3QgSSBtdXN0IGJlIG1pc3VuZGVyc3RhbmRpbmcgc29tZXRoaW5nIGFib3V0IHRoZSBxdWVzdGlv biwgYmVjYXVzZSBJJ20gaGF2aW5nIHRyb3VibGUgdW5kZXJzdGFuZGluZyB0aGUgc2NlbmFyaW8g d2hlcmUgdGhlIHJldm9jYXRpb24gZGF0YSB3b3VsZCBiZSByZWxldmFudCBhZnRlciB0aGUgZXhw aXJhdGlvbiBvZiBhbGwgaXNzdWVyIGNlcnRpZmljYXRlKHMpPyBJcyBpdCBkZXNjcmliaW5nIGEg c2NlbmFyaW8gaW4gd2hpY2ggdGhlIG5ldyByb290IGlzc3VlcyBhIGNyb3NzLWNlcnRpZmljYXRl IGZvciB0aGUgb2xkIHJvb3QsIGFmdGVyIHRoZSBvbGQgcm9vdCdzIHByaXZhdGUga2V5IGhhcyBi ZWVuIGRlc3Ryb3llZCwgd2hpY2ggZXh0ZW5kcyB0aGUgbGlmZXRpbWUgb2YgdGhlIG9sZCByb290 IGJleW9uZCB0aGUgMTAgeWVhcnMgc3BlY2lmaWVkPw0KDQpPbiBUdWUsIEp1bCAyOCwgMjAyMCBh dCA4OjIwIEFNIFNhbHosIFJpY2ggPHJzYWx6PTQwYWthbWFpLmNvbUBkbWFyYy5pZXRmLm9yZzxt YWlsdG86NDBha2FtYWkuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpNYWlsIGFsaWFzIGlz c3Vlcy4gIE1lYSBjdWxwYQ0KDQrvu79PbiA3LzI4LzIwLCA4OjE2IEFNLCAiU2FseiwgUmljaCIg PHJzYWx6QGFrYW1haS5jb208bWFpbHRvOnJzYWx6QGFrYW1haS5jb20+PiB3cm90ZToNCg0KICAg IE1vdmluZyBDRlJHIHRvIEJDQzsgdGhlIExBTVBTIHdvcmtpbmcgZ3JvdXAgaXMgYSBiZXR0ZXIg cGxhY2UgKGl0IGhhbmRsZXMgNTI4MCB1cGRhdGVzKSB0byBkaXNjdXNzIHRoaXMuDQoNCiAgICBP biA3LzI4LzIwLCA2OjIyIEFNLCAiV2FuZyBHdWlsaW4iIDxXYW5nLkd1aWxpbkBodWF3ZWkuY29t PG1haWx0bzpXYW5nLkd1aWxpbkBodWF3ZWkuY29tPj4gd3JvdGU6DQoNCiAgICAgICAgRGVhciBh bGwsDQoNCiAgICAgICAgSSBhbSBoZXJlIHRvIGVucXVpcmUgb25lIHF1ZXN0aW9uIGFib3V0IHJl dm9raW5nIFBLSSBjZXJ0aWZpY2F0ZXMuDQoNCiAgICAgICAgSW4gcHJhY3RpY2UsIHRvIGd1YXJh bnRlZSBoaWdoIHNlY3VyaXR5LCB0aGUgdmFsaWRpdHkgKHNheSAxMCB5ZWFycykgb2YgYSByb290 IGNlcnRpZmljYXRlIHByaXZhdGUga2V5IG1heSBiZSBlc3NlbnRpYWxseSBzaG9ydGVyIHRoYXQg dGhlIHZhbGlkaXR5IChzYXkgMzAgeWVhcnMpIG9mIHRoZSBjb3JyZXNwb25kaW5nIHB1YmxpYyBr ZXkuIEFmdGVyIHRoZSBmaXJzdCAxMCB5ZWFycywgYSBuZXcgcm9vdCBjZXJ0aWZpY2F0ZSB3aXRo IGEgbmV3IGtleSBwYWlyIHdpbGwgYmUgZ2VuZXJhdGVkLCBhbmQgdGhlIG9sZCByb290IHByaXZh dGUgbWF5IGJlIGV2ZW4gZGVzdHJveWVkLiBBZnRlciB0aGF0LCBob3dldmVyLCBob3cgY2FuIHdl IHVzZSB0aGUgbmV3IHJvb3QgcHJpdmF0ZSBrZXkgdG8gaXNzdWUgQ1JMcyB0byByZXZva2UgY2Vy dGlmaWNhdGVzIHByZXZpb3VzbHkgc2lnbmVkIGJ5IHRoZSBvbGQgcm9vdCBwcml2YXRlIGtleT8N Cg0KICAgICAgICBBdCBmaXJzdCwgSSB0aG91Z2h0IHRoaXMgaXMgdGhlIGNhc2Ugb2YgdXNpbmcg aW5kaXJlY3QgcmV2b2NhdGlvbiBtZWNoYW5pc20gZGlzY3Vzc2VkIGluIFJGQyA1MjgwLCB3aGlj aCBtYXkgaW52b2x2ZSB0aGUgbGluayBjZXJ0aWZpY2F0ZSBOZXdXaXRoT2xkLCB3aGljaCBpcyBh IGNlcnRpZmljYXRlIGZvciB0aGUgbmV3IHJvb3QgcHVibGljIGtleSBzaWduZWQgYnkgdGhlIG9s ZCAgcm9vdCBwcml2YXRlIGtleS4gSG93ZXZlciwgaXQgc2VlbXMgdGhhdCBpbmRpcmVjdCByZXZv Y2F0aW9uIG9ubHkgd29ya3MgZm9yIGRpZmZlcmVudCBlbnRpdGllcy4gTmFtZWx5LCBieSB1c2lu ZyBpbmRpcmVjdCByZXZvY2F0aW9uLCB0aGUgY2VydGlmaWNhdGVzIGlzc3VlZCBieSBBIGNhbiBi ZSByZXZva2VkIGJ5IGEgZGlmZmVyZW50IGVudGl0eSBCLiBIb3dldmVyLCBpbiB0aGUgYWJvdmUg Y2FzZSwgdGhlIG9sZCBhbmQgbmV3IHJvb3QgY2VydGlmaWNhdGVzIGFyZSBmb3IgdGhlIHNhbWUg ZW50aXR5IChvciBvd25lcikuIFNvLCBteSByZWFsIHF1ZXN0aW9ucyBpczogQ2FuIGluZGlyZWN0 IHJldm9jYXRpb24gYmUgdXNlZCBpbiBzdWNoIGEgc2NlbmFyaW8/IElmIG5vdCwgaXMgdGhlcmUg YW55IGdvb2Qgd2F5IHRvIGRvIHRoaXMsIGVzcGVjaWFsbHkgaWYgaW50ZXJvcGVyYWJpbGl0eSB3 aXRoIFRMUywgU1NMLCBJUFNlYyBldGMgaXMgcmVxdWlyZWQ/DQoNCiAgICAgICAgVGhhbmtzIGEg bG90IGluIGFkdmFuY2UsDQoNCiAgICAgICAgR3VpbGluDQoNCiAgICAgICAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgQ2ZyZyBtYWlsaW5n IGxpc3QNCiAgICAgICAgQ2ZyZ0BpcnRmLm9yZzxtYWlsdG86Q2ZyZ0BpcnRmLm9yZz4NCiAgICAg ICAgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193 d3cuaXJ0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19jZnJnJmQ9RHdJQ0FnJmM9OTZaYlpaY2FNRjR3 MEY0anBONkxaZyZyPTRMTTBHYlIwaDlGdng4NkZ0c0tJLXcmbT1iOFB1dDVfb0ZnT1htbzZaZ2Zn a1BMQmdmWjh2dFRCby1lUlY5QURFNlJRJnM9V0ZWc1NnTEhPUWs1Wl91QTVVRnlQUzE4U0NEYkwy Ny1Vd1lvcE5pOWdENCZlPQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpTcGFzbSBtYWlsaW5nIGxpc3QNClNwYXNtQGlldGYub3JnPG1haWx0bzpT cGFzbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Bh c20NCg== --_000_DM6PR11MB391533860F13BBD51DB53E699B730DM6PR11MB3915namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsNCglwYW5vc2UtMToy IDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOiM3MDMwQTA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiM3MDMwQTAiPlJ5YW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojNzAzMEEwIj5J4oCZbSBpbnRlcnByZXRpbmcgdGhlIHNjZW5hcmlvIHRvIGJlIGEgMzAteWVh ciByb290IGNlcnQsIGlzc3VpbmcgMzAgeWVhciBlbmQgZW50aXRpZXMuIEF0IHRoZSAxMCB5ZWFy IG1hcmsgdGhleSBkZXN0cm95ZWQgdGhlIHJvb3TigJlzIHByaXYga2V5LiBUaGV5IGFyZSBub3cg cmVhbGl6aW5nIHRoYXQgdGhleSBoYXZlIGVuZCBlbnRpdGllcyB2YWxpZCBmb3IgYW5vdGhlcg0K IDIwIHllYXJzIGJ1dCBubyB3YXkgdG8gaXNzdWUgZnJlc2ggQ1JMcyBmb3IgdGhlbS4gSSBtYXkg YmUgbWlzLXJlYWRpbmcgdGhvdWdoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzcwMzBB MCI+LS0tPGJyPg0KTWlrZSBPdW5zd29ydGg8YnI+DQpTb2Z0d2FyZSBTZWN1cml0eSBBcmNoaXRl Y3QsIEVudHJ1c3QgRGF0YWNhcmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFNwYXNtICZsdDtzcGFz bS1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KUnlhbiBTbGVldmk8 YnI+DQo8Yj5TZW50OjwvYj4gSnVseSAyOCwgMjAyMCA5OjQ4IEFNPGJyPg0KPGI+VG86PC9iPiBT YWx6LCBSaWNoICZsdDtyc2Fsej00MGFrYW1haS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBzcGFzbUBpZXRmLm9yZzsgV2FuZyBHdWlsaW4gJmx0O1dhbmcuR3VpbGluQGh1 YXdlaS5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFWFRFUk5BTF1SZTogW2xhbXBzXSBb Q2ZyZ10gSG93IHRvIGlzc3VlIENSTHMgYWZ0ZXIgdGhlIHByaXZhdGUga2V5IG9mIG9sZCByb290 IGNlcnRpZmljYXRlIGhhcyBiZWVuIGRlc3Ryb3llZD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOnJlZCI+V0FSTklORzo8L3NwYW4+PC9zdHJvbmc+IFRoaXMgZW1haWwgb3Jp Z2luYXRlZCBvdXRzaWRlIG9mIEVudHJ1c3QgRGF0YWNhcmQuPGJyPg0KPHN0cm9uZz48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnJl ZCI+RE8gTk9UIENMSUNLPC9zcGFuPjwvc3Ryb25nPiBsaW5rcyBvciBhdHRhY2htZW50cyB1bmxl c3MgeW91IHRydXN0IHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS48bzpw PjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9 InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNl bnRlciI+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIHNvbWV0 aGluZyB0aGUgQ0Egd291bGQgYWRkcmVzcyBhcyBwYXJ0IG9mIHRoZSBSRkMgMzY0NyBmcmFtZXdv cmsgZm9yIGRpc2N1c3NpbmcgQ0Egb3IgUkEgdGVybWluYXRpb246Jm5ic3A7PGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM2NDcjc2VjdGlvbi00LjUuOCI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzM2NDcjc2VjdGlvbi00LjUuODwvYT48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUg cmVtYXJrIGFib3V0IHNpZ25pbmcgQ1JMcyBhZnRlciB0aGUgZXhwaXJhdGlvbiBvZiB0aGUgKG9s ZCkgcm9vdC4gQWZ0ZXIgdGhhdCBleHBpcmF0aW9uLCB0aGVyZSBpcyBwcmVzdW1hYmx5IG5vIHRl bXBvcmFsbHkgdmFsaWQgY2VydGlmaWNhdGUgY2hhaW4gZm9yIHRob3NlIGV4aXN0aW5nIGNlcnRp ZmljYXRlcywgYW5kIHRoZXkgYXJlIHRodXMgbm90IHRpbWUgdmFsaWQsDQogYXMgY2FsbGVkIG91 dCBpbiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjgwI3Nl Y3Rpb24tNC4xLjIuNSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUyODAjc2VjdGlv bi00LjEuMi41PC9hPiZuYnNwO2FuZCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM1MjgwI3NlY3Rpb24tNi4xLjMiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM1MjgwI3NlY3Rpb24tNi4xLjM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc3VzcGVjdCBJIG11c3QgYmUgbWlzdW5kZXJzdGFu ZGluZyBzb21ldGhpbmcgYWJvdXQgdGhlIHF1ZXN0aW9uLCBiZWNhdXNlIEknbSBoYXZpbmcgdHJv dWJsZSB1bmRlcnN0YW5kaW5nIHRoZSBzY2VuYXJpbyB3aGVyZSB0aGUgcmV2b2NhdGlvbiBkYXRh IHdvdWxkIGJlIHJlbGV2YW50IGFmdGVyIHRoZSBleHBpcmF0aW9uIG9mIGFsbCBpc3N1ZXIgY2Vy dGlmaWNhdGUocyk/IElzIGl0IGRlc2NyaWJpbmcgYSBzY2VuYXJpbw0KIGluIHdoaWNoIHRoZSBu ZXcgcm9vdCBpc3N1ZXMgYSBjcm9zcy1jZXJ0aWZpY2F0ZSBmb3IgdGhlIG9sZCByb290LCBhZnRl ciB0aGUgb2xkIHJvb3QncyBwcml2YXRlIGtleSBoYXMgYmVlbiBkZXN0cm95ZWQsIHdoaWNoIGV4 dGVuZHMgdGhlIGxpZmV0aW1lIG9mIHRoZSBvbGQgcm9vdCBiZXlvbmQgdGhlIDEwIHllYXJzIHNw ZWNpZmllZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gVHVlLCBKdWwgMjgsIDIwMjAgYXQgODoyMCBBTSBTYWx6LCBSaWNoICZsdDtyc2Fs ej08YSBocmVmPSJtYWlsdG86NDBha2FtYWkuY29tQGRtYXJjLmlldGYub3JnIj40MGFrYW1haS5j b21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1haWwgYWxpYXMgaXNzdWVzLiZuYnNw OyBNZWEgY3VscGE8YnI+DQo8YnI+DQrvu79PbiA3LzI4LzIwLCA4OjE2IEFNLCAmcXVvdDtTYWx6 LCBSaWNoJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cnNhbHpAYWthbWFpLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnJzYWx6QGFrYW1haS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7IE1vdmluZyBDRlJHIHRvIEJDQzsgdGhlIExBTVBTIHdvcmtpbmcgZ3JvdXAgaXMg YSBiZXR0ZXIgcGxhY2UgKGl0IGhhbmRsZXMgNTI4MCB1cGRhdGVzKSB0byBkaXNjdXNzIHRoaXMu PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBPbiA3LzI4LzIwLCA2OjIyIEFNLCAmcXVvdDtXYW5n IEd1aWxpbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOldhbmcuR3VpbGluQGh1YXdlaS5jb20i IHRhcmdldD0iX2JsYW5rIj5XYW5nLkd1aWxpbkBodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IERlYXIgYWxsLCA8YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSSBhbSBoZXJlIHRvIGVucXVpcmUgb25lIHF1 ZXN0aW9uIGFib3V0IHJldm9raW5nIFBLSSBjZXJ0aWZpY2F0ZXMuIDxicj4NCjxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbiBwcmFjdGljZSwgdG8gZ3VhcmFudGVlIGhpZ2ggc2Vj dXJpdHksIHRoZSB2YWxpZGl0eSAoc2F5IDEwIHllYXJzKSBvZiBhIHJvb3QgY2VydGlmaWNhdGUg cHJpdmF0ZSBrZXkgbWF5IGJlIGVzc2VudGlhbGx5IHNob3J0ZXIgdGhhdCB0aGUgdmFsaWRpdHkg KHNheSAzMCB5ZWFycykgb2YgdGhlIGNvcnJlc3BvbmRpbmcgcHVibGljIGtleS4gQWZ0ZXIgdGhl IGZpcnN0IDEwIHllYXJzLCBhIG5ldyByb290IGNlcnRpZmljYXRlIHdpdGgNCiBhIG5ldyBrZXkg cGFpciB3aWxsIGJlIGdlbmVyYXRlZCwgYW5kIHRoZSBvbGQgcm9vdCBwcml2YXRlIG1heSBiZSBl dmVuIGRlc3Ryb3llZC4gQWZ0ZXIgdGhhdCwgaG93ZXZlciwgaG93IGNhbiB3ZSB1c2UgdGhlIG5l dyByb290IHByaXZhdGUga2V5IHRvIGlzc3VlIENSTHMgdG8gcmV2b2tlIGNlcnRpZmljYXRlcyBw cmV2aW91c2x5IHNpZ25lZCBieSB0aGUgb2xkIHJvb3QgcHJpdmF0ZSBrZXk/DQo8YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQXQgZmlyc3QsIEkgdGhvdWdodCB0aGlzIGlz IHRoZSBjYXNlIG9mIHVzaW5nIGluZGlyZWN0IHJldm9jYXRpb24gbWVjaGFuaXNtIGRpc2N1c3Nl ZCBpbiBSRkMgNTI4MCwgd2hpY2ggbWF5IGludm9sdmUgdGhlIGxpbmsgY2VydGlmaWNhdGUgTmV3 V2l0aE9sZCwgd2hpY2ggaXMgYSBjZXJ0aWZpY2F0ZSBmb3IgdGhlIG5ldyByb290IHB1YmxpYyBr ZXkgc2lnbmVkIGJ5IHRoZSBvbGQmbmJzcDsgcm9vdCBwcml2YXRlIGtleS4gSG93ZXZlciwgaXQN CiBzZWVtcyB0aGF0IGluZGlyZWN0IHJldm9jYXRpb24gb25seSB3b3JrcyBmb3IgZGlmZmVyZW50 IGVudGl0aWVzLiBOYW1lbHksIGJ5IHVzaW5nIGluZGlyZWN0IHJldm9jYXRpb24sIHRoZSBjZXJ0 aWZpY2F0ZXMgaXNzdWVkIGJ5IEEgY2FuIGJlIHJldm9rZWQgYnkgYSBkaWZmZXJlbnQgZW50aXR5 IEIuIEhvd2V2ZXIsIGluIHRoZSBhYm92ZSBjYXNlLCB0aGUgb2xkIGFuZCBuZXcgcm9vdCBjZXJ0 aWZpY2F0ZXMgYXJlIGZvciB0aGUgc2FtZSBlbnRpdHkNCiAob3Igb3duZXIpLiBTbywgbXkgcmVh bCBxdWVzdGlvbnMgaXM6IENhbiBpbmRpcmVjdCByZXZvY2F0aW9uIGJlIHVzZWQgaW4gc3VjaCBh IHNjZW5hcmlvPyBJZiBub3QsIGlzIHRoZXJlIGFueSBnb29kIHdheSB0byBkbyB0aGlzLCBlc3Bl Y2lhbGx5IGlmIGludGVyb3BlcmFiaWxpdHkgd2l0aCBUTFMsIFNTTCwgSVBTZWMgZXRjIGlzIHJl cXVpcmVkPw0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoYW5rcyBh IGxvdCBpbiBhZHZhbmNlLCA8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg R3VpbGluPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IENmcmcgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IDxhIGhyZWY9Im1haWx0bzpDZnJnQGlydGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Q2Zy Z0BpcnRmLm9yZzwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0i aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu aXJ0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19jZnJnJmFtcDtkPUR3SUNBZyZhbXA7Yz05NlpiWlpj YU1GNHcwRjRqcE42TFpnJmFtcDtyPTRMTTBHYlIwaDlGdng4NkZ0c0tJLXcmYW1wO209YjhQdXQ1 X29GZ09YbW82WmdmZ2tQTEJnZlo4dnRUQm8tZVJWOUFERTZSUSZhbXA7cz1XRlZzU2dMSE9RazVa X3VBNVVGeVBTMThTQ0RiTDI3LVV3WW9wTmk5Z0Q0JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0K aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu aXJ0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19jZnJnJmFtcDtkPUR3SUNBZyZhbXA7Yz05NlpiWlpj YU1GNHcwRjRqcE42TFpnJmFtcDtyPTRMTTBHYlIwaDlGdng4NkZ0c0tJLXcmYW1wO209YjhQdXQ1 X29GZ09YbW82WmdmZ2tQTEJnZlo4dnRUQm8tZVJWOUFERTZSUSZhbXA7cz1XRlZzU2dMSE9RazVa X3VBNVVGeVBTMThTQ0RiTDI3LVV3WW9wTmk5Z0Q0JmFtcDtlPTwvYT4NCjxicj4NCjxicj4NCjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K U3Bhc20gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlNwYXNtQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+U3Bhc21AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcGFzbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Bhc208L2E+PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM6PR11MB391533860F13BBD51DB53E699B730DM6PR11MB3915namp_-- From nobody Tue Jul 28 07:57:03 2020 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 EC1653A0D78 for ; Tue, 28 Jul 2020 07:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 aiErztryxR08 for ; Tue, 28 Jul 2020 07:56:59 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by ietfa.amsl.com (Postfix) with ESMTP id D534E3A0D72 for ; Tue, 28 Jul 2020 07:56:41 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06SEu0i0028714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Jul 2020 10:56:02 -0400 Date: Tue, 28 Jul 2020 07:55:59 -0700 From: Benjamin Kaduk To: "Salz, Rich" Cc: Ryan Sleevi , "spasm@ietf.org" , Wang Guilin Message-ID: <20200728145559.GO41010@kduck.mit.edu> References: <123C83B5-DFCB-4409-80A7-7DFA45056B7F@akamai.com> <2001BA94-5044-42C8-9CE9-0F8BF0DA5C65@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2001BA94-5044-42C8-9CE9-0F8BF0DA5C65@akamai.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [lamps] [Cfrg] How to issue CRLs after the private key of old root certificate has been destroyed? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jul 2020 14:57:01 -0000 On Tue, Jul 28, 2020 at 02:54:08PM +0000, Salz, Rich wrote: > I think that is the key point. A CA cannot sign anything that goes beyond its own notAfter field. You could perhaps decide that you don't want to carry the operational risk of securing the private key for the whole validity period, though, and destroy all copies of the private key before the notAfter time. -Ben From nobody Tue Jul 28 08:04:31 2020 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 386F33A0D66 for ; Tue, 28 Jul 2020 08:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id if_9QqPZhm5P for ; Tue, 28 Jul 2020 08:04:27 -0700 (PDT) Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) (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 CDD0F3A0D5E for ; Tue, 28 Jul 2020 08:04:27 -0700 (PDT) Received: by mail-pj1-f41.google.com with SMTP id t15so11777451pjq.5 for ; Tue, 28 Jul 2020 08:04:27 -0700 (PDT) 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=RQP6czcQYqIeGIg0UHtXjDveo2yZAlB02kiOk97V6hY=; b=gc2U0ikKbgZQHlBdRnlqPet2jAy8/RqJOi3US4tVDvyan3QzVunmeVXzKJp8UkPA30 nIm1OAoaIYh+ncibMDCUg7XlVDidbO5FkucL2yDzF2kkjSPBqCATCefRYrlee5FDeXSX 3mNQ8eGNOwTirNR5qQpilJeRz0PQbjGgpqOsdpaTQqObxIkxQMu26A8+p3BQ3ATNisUV B6XzaC3bYKp3BtCP/Ns8Ql/GtgZG2mjeSz0Ho3E4IHbkKkX75KF+txIZA9pCcZ2ljyC/ swWXpsp+cQzkiOJe3XOBjrPcjYPFB0OhN6pgcznlXSiVa3SYOseoLlDVKoprB851g8S7 USYQ== X-Gm-Message-State: AOAM530huOjrRowj4yvzLGmOhUKtj01LhfW6mrevZurcjR8JanK2KqG5 /l7dOygx9G4pwuv4E2DlrN/ilnnH X-Google-Smtp-Source: ABdhPJwKtyYm+lSFH0/C5/kDSD1LCqil5eIuT15hdpmQyOJa2wD4Y2b4ScCSg1fbc06B2gCw6LR7zA== X-Received: by 2002:a17:90a:bf04:: with SMTP id c4mr4616700pjs.149.1595948666788; Tue, 28 Jul 2020 08:04:26 -0700 (PDT) Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com. [209.85.216.45]) by smtp.gmail.com with ESMTPSA id c125sm18266489pfa.119.2020.07.28.08.04.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jul 2020 08:04:26 -0700 (PDT) Received: by mail-pj1-f45.google.com with SMTP id t15so11777419pjq.5 for ; Tue, 28 Jul 2020 08:04:26 -0700 (PDT) X-Received: by 2002:a17:90a:e2c7:: with SMTP id fr7mr4946763pjb.103.1595948666063; Tue, 28 Jul 2020 08:04:26 -0700 (PDT) MIME-Version: 1.0 References: <123C83B5-DFCB-4409-80A7-7DFA45056B7F@akamai.com> <2001BA94-5044-42C8-9CE9-0F8BF0DA5C65@akamai.com> <20200728145559.GO41010@kduck.mit.edu> In-Reply-To: <20200728145559.GO41010@kduck.mit.edu> From: Ryan Sleevi Date: Tue, 28 Jul 2020 11:04:15 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Benjamin Kaduk Cc: "Salz, Rich" , Ryan Sleevi , "spasm@ietf.org" , Wang Guilin Content-Type: multipart/alternative; boundary="00000000000052119905ab81c111" Archived-At: Subject: Re: [lamps] [Cfrg] How to issue CRLs after the private key of old root certificate has been destroyed? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jul 2020 15:04:29 -0000 --00000000000052119905ab81c111 Content-Type: text/plain; charset="UTF-8" Right, but in that scenario, it's to be treated like a CA termination event. I don't know if you're necessarily reducing risk, but rather, shifting risk. Prior to destroying that key material, operationally you'd be expected to do something such as "sign final CRLs" - e.g. revoking all certificates that have been issued. That's the interoperable answer: destroying the key is a termination event. Or, if you're looking at a business continuity termination, you have arrangements for some other service provider to continue to provide revocation services, using a copy of the key that they have and maintain. But there's not really a good interoperable way post key-destruction to continue the provision of revocation information in an interoperable fashion. On Tue, Jul 28, 2020 at 10:56 AM Benjamin Kaduk wrote: > On Tue, Jul 28, 2020 at 02:54:08PM +0000, Salz, Rich wrote: > > I think that is the key point. A CA cannot sign anything that goes > beyond its own notAfter field. > > You could perhaps decide that you don't want to carry the operational risk > of securing the private key for the whole validity period, though, and > destroy all copies of the private key before the notAfter time. > > -Ben > --00000000000052119905ab81c111 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Right, but in that scenario, it's to be treated like a= CA termination event. I don't know if you're necessarily reducing = risk, but rather, shifting risk.

Prior to destroying tha= t key material, operationally you'd be expected to do something such as= "sign final CRLs" - e.g. revoking all certificates that have bee= n issued. That's the interoperable answer: destroying the key is a term= ination event. Or, if you're looking at a business continuity=C2=A0term= ination, you have arrangements for some other service provider to continue = to provide revocation services, using a copy of the key that they have and = maintain. But there's not really a good interoperable way post key-dest= ruction to continue the provision of revocation information in an interoper= able fashion.

On Tue, Jul 28, 2020 at 10:56 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
On Tue, Jul 28, 2020 at 02:54:08P= M +0000, Salz, Rich wrote:
> I think that is the key point.=C2=A0 A CA cannot sign anything that go= es beyond its own notAfter field.

You could perhaps decide that you don't want to carry the operational r= isk
of securing the private key for the whole validity period, though, and
destroy all copies of the private key before the notAfter time.

-Ben
--00000000000052119905ab81c111-- From nobody Tue Jul 28 08:34:54 2020 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 9F9793A0DB4 for ; Tue, 28 Jul 2020 08:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_HTML_ATTACH=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 GZOw7jxOocKk for ; Tue, 28 Jul 2020 08:34:47 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E953A0D5A for ; Tue, 28 Jul 2020 08:34:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B7B96300AB1 for ; Tue, 28 Jul 2020 11:34:44 -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 LdhvJkBZS2JH for ; Tue, 28 Jul 2020 11:34:43 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 1E52C30009A for ; Tue, 28 Jul 2020 11:34:43 -0400 (EDT) From: Russ Housley Content-Type: multipart/mixed; boundary="Apple-Mail=_AAD062ED-DD10-4589-B9EC-06384ADE0113" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Message-Id: <55D70550-B6FE-4037-9306-3E5BD687D8E9@vigilsec.com> Date: Tue, 28 Jul 2020 11:34:44 -0400 To: LAMPS WG X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: [lamps] DRAFT Minutes for LAMPS WG at IETF 108 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jul 2020 15:34:52 -0000 --Apple-Mail=_AAD062ED-DD10-4589-B9EC-06384ADE0113 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please review and comment on list: = https://www.ietf.org/proceedings/108/minutes/minutes-108-lamps-00 In addition, I have attached the .html file that one converter generates = from the posted .md file. Russ --Apple-Mail=_AAD062ED-DD10-4589-B9EC-06384ADE0113 Content-Disposition: attachment; filename=minutes-108-lamps.html Content-Type: text/html; x-unix-mode=0644; name="minutes-108-lamps.html" Content-Transfer-Encoding: 7bit

LAMPS WG at Virtual IETF 108

0) Minute Taker, Jabber Scribe, Bluesheets

Rich Salz agreed to take notes.

1) Agenda Bash

No changes.

2) Documents with the RFC Editor and IESG

a) draft-ietf-lamps-5480-ku-clarifications (Sean)

In RFC editor queue.

b) draft-ietf-lamps-ocsp-nonce (Mohit)

Will address AD comments and post new version soon. That version should be ready for IETF Last Call.

c) draft-ietf-lamps-rfc7030est-clarify (Michael, Thomas, Wei)

In IESG Evaluation; on IESG telechat for 13 August 2020.

d) draft-ietf-lamps-cms-update-alg-id-protect (Russ)

AD review done, which only uncovered a few editorial changes. IETF Last Call started yesterday.

3) Active Working Group Documents

a) draft-ietf-lamps-cmp-updates (Hendrik)

Changes presented. Editorial updates still needed.

Private key is currently id-data (OCTET STRING); the Lightweight CMP Profile will use an Asymmetric Key Package (RFC 5958).

The ASN.1 module needs to be added, and then the document will be ready for WG Last Call.

b) draft-ietf-lamps-lightweight-cmp-profile (Hendrik, Steffen, David)

Changes presented. Still need more work on the security considerations, discussion of centralized key generation, and editorial clean up.

In addition, changes are needed to be clear what parts of RFC 6712 are being updated.

Showed details of converting SignedData content from id-data (OCTET STRING) to id-ct-KP-aKeyPackage (RFC 5958).

There was discussion of where to identify algorithms, and it was agreed that they will be put in a companion document so that it is easy to update MUST and SHOULD statements about particular algorithms without opening the protocol document.

Since this document depends upon draft-ietf-lamps-cmp-updates, so it will go to WG Last Call after that document.

c) draft-ietf-lamps-header-protection (Alexey, Bernie)

There was discussion of the extent that the selected mechanism need to accomodate MIME-compliant user agents and non-MIME-compliant user agents. This has an impact on what the recipient is likely to see rendered by their user agent. There was general agreement that the document ought to present the processing steps for a sender and separately present the processing steps for a recipient.

There was discussion of message protection profiles to be included in the document. Nested messages, gateway handling, and many other things impact the headers that are actually rendered by the recipient user agent. There was general agreement that the document ought to address two right now: (1) signed only, and (2) signed and encrypted. Once these two, which are the most common ones, are sorted out, then the WG can decide whether to include others, including triple-wrap (sign-encrypt-sign).

There was general agreement that the document ought to state what the user agent needs to be presented to the human user, but not say anything about how it is presented.

There was a request from the WG chair to keep the momentum going. Work on this document had stalled for a while. He asked the document authors to update the Internet-Draft based on today's discussion, and then start a thread on the mail list for any open issues.

--Apple-Mail=_AAD062ED-DD10-4589-B9EC-06384ADE0113-- From nobody Tue Jul 28 08:53:40 2020 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 F17803A0E0E for ; Tue, 28 Jul 2020 08:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 b49Z0yjlYcNF for ; Tue, 28 Jul 2020 08:53:34 -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 15A803A0E4C for ; Tue, 28 Jul 2020 08:53:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A3CD7300B71 for ; Tue, 28 Jul 2020 11:53:31 -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 salrYUTleMp9 for ; Tue, 28 Jul 2020 11:53:30 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 3148130009A; Tue, 28 Jul 2020 11:53:30 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: Date: Tue, 28 Jul 2020 11:53:31 -0400 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <9E8DDD8B-1F37-40C5-B49D-A6B8D2B3F9A1@vigilsec.com> References: <97AAAE51-45E0-4363-ACAD-99144085E710@vigilsec.com> <6637BD5E-96EF-4982-8F4B-289209D1EBD2@vigilsec.com> To: "Brockhaus, Hendrik" X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [lamps] draft-ietf-lamps-cmp-updates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jul 2020 15:53:38 -0000 Hendrik: >> Von: Russ Housley >>=20 >>> On Jul 27, 2020, at 12:22 PM, Brockhaus, Hendrik >> wrote: >>>=20 >>>> Third, id-it-revPassphrase (which is in a comment) is associated = with >>>> EncryptedKey instead of EncryptedValue. >>>=20 >>> Finally, I do not fully understand this specification, too. >>> My goal is to update OID {id-it 12} as specified in section = 5.3.19.9 and the >> only lines in the ASN.1 module on this OID is in comments? >>=20 >> Right, so it is just and updated comment; however, the place were = this is >> defined needs to be updated too, right? >=20 > Yes. But the only place I am aware of where this OID is defined is in = section 5.3.19.9 of RFC4210. I update this section in section 2.6 of the = draft. > Are there any other place I should update? If that is the case, I suspect that all of the id-it- OID values need to = appear in this new module. Looking at RFC 5912, is seem that Jim and Paul defined these constructs = for this purpose: ~~~ INFO-TYPE-AND-VALUE ::=3D TYPE-IDENTIFIER InfoTypeAndValue ::=3D SEQUENCE { infoType INFO-TYPE-AND-VALUE. &id({SupportedInfoSet}), infoValue INFO-TYPE-AND-VALUE. &Type({SupportedInfoSet}{@infoType}) } ~~~ This is probably something that should be carried forward. So, for example, that would lead to this in the ASN.1 module: ~~~ it-caProtEncCert INFO-TYPE-AND-VALUE ::=3D { CMPCertificate IDENTIFIED BY id-it-caProtEncCert } ~~~ You need a statement like this for each of the id-it- OID values. Russ From nobody Tue Jul 28 08:59:24 2020 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 E20303A0E1C for ; Tue, 28 Jul 2020 08:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 Ea3qpz0HcwW2 for ; Tue, 28 Jul 2020 08:59:20 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 0A1683A0E18 for ; Tue, 28 Jul 2020 08:59:19 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id j187so19077195qke.11 for ; Tue, 28 Jul 2020 08:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=mXZUpXZTtvKpT757apKw1RR10ya1c3rtZjrnbHyhwuo=; b=0sZjzrMBSREWlNsH8q78GIO4gHX+z8Zgmervz1jj1xEhXB3/1qONMFFQdgEBIoHD/5 NwxwBWWk6WIctVOAhA0qSemeH1Q99Gm4EsZbv5mSKG930VV4HXLeu9X9wthr8EnRyd87 cW2q6pNuz1jxRYIMHgCIQC4CE+i5gDAKM1hE0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=mXZUpXZTtvKpT757apKw1RR10ya1c3rtZjrnbHyhwuo=; b=I2nj2hsrT1EanzTiGVsDW82xTK93OKtcD5F0JMWIbv7B4ym62ooZnotHZzlriJAwHV XO2oQHPcTFdCel9iAxkGMu8KCOyAnOf4bmarXs17EdJIRVsQOmGrFAIskTVZU+uEsQVO fZQvaLwCzd0RIaHRt1GKC3PefzdES9V0rClGHOJB9gOGY7d0gBSaHBzpLTZ5BtW/x9el CWecVTODGzVHNkfscdcyUS4ACwSJ4x2AjKzmHvs7KK27EdWgjRBypArsCyUol39w8zQc aBjFbKh/aHAA2d+IHz0fu4+7OvrAVV4yiVwj66D+RBR5Tf74RkaqBHwIxL3Fp1F9mCS2 tg+g== X-Gm-Message-State: AOAM530swttYCwARTsW08gQOWDIzSqNCGoYcmf3XDl6oZdGSoFhgmQnP 21uoGHLf2q8ASkX2u7poQCjiuA== X-Google-Smtp-Source: ABdhPJw21tbDPYIQcqtu3xPVe3LWCARomy6kv+ZV1F+iMT4F4uhM6RJ1MaVoTjSrisuIi8EvBG/YWQ== X-Received: by 2002:a05:620a:1256:: with SMTP id a22mr24385746qkl.95.1595951958872; Tue, 28 Jul 2020 08:59:18 -0700 (PDT) Received: from [192.168.2.16] (pool-108-18-106-102.washdc.fios.verizon.net. [108.18.106.102]) by smtp.gmail.com with ESMTPSA id d16sm22649121qkk.106.2020.07.28.08.59.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2020 08:59:17 -0700 (PDT) User-Agent: Microsoft-MacOutlook/10.10.18.200713 Date: Tue, 28 Jul 2020 11:59:16 -0400 From: Carl Wallace To: Ryan Sleevi , Benjamin Kaduk CC: "spasm@ietf.org" , "Salz, Rich" , Wang Guilin Message-ID: Thread-Topic: [lamps] [Cfrg] How to issue CRLs after the private key of old root certificate has been destroyed? References: <123C83B5-DFCB-4409-80A7-7DFA45056B7F@akamai.com> <2001BA94-5044-42C8-9CE9-0F8BF0DA5C65@akamai.com> <20200728145559.GO41010@kduck.mit.edu> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3678782357_151302470" Archived-At: Subject: Re: [lamps] [Cfrg] How to issue CRLs after the private key of old root certificate has been destroyed? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jul 2020 15:59:22 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3678782357_151302470 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Existing certs would not have CRL DPs to match the IDPs the CRLs issued by the new issuer would need contain. This would have had to have been planned to even attain poor interop. From: Spasm on behalf of Ryan Sleevi Date: Tuesday, July 28, 2020 at 11:04 AM To: Benjamin Kaduk Cc: Ryan Sleevi , "spasm@ietf.org" , "Salz, Rich" , Wang Guilin Subject: Re: [lamps] [Cfrg] How to issue CRLs after the private key of old root certificate has been destroyed? Right, but in that scenario, it's to be treated like a CA termination event. I don't know if you're necessarily reducing risk, but rather, shifting risk. Prior to destroying that key material, operationally you'd be expected to do something such as "sign final CRLs" - e.g. revoking all certificates that have been issued. That's the interoperable answer: destroying the key is a termination event. Or, if you're looking at a business continuity termination, you have arrangements for some other service provider to continue to provide revocation services, using a copy of the key that they have and maintain. But there's not really a good interoperable way post key-destruction to continue the provision of revocation information in an interoperable fashion. On Tue, Jul 28, 2020 at 10:56 AM Benjamin Kaduk wrote: On Tue, Jul 28, 2020 at 02:54:08PM +0000, Salz, Rich wrote: > I think that is the key point. A CA cannot sign anything that goes beyond its own notAfter field. You could perhaps decide that you don't want to carry the operational risk of securing the private key for the whole validity period, though, and destroy all copies of the private key before the notAfter time. -Ben _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --B_3678782357_151302470 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Existing certs would not= have CRL DPs to match the IDPs the CRLs issued by the new issuer would need= contain. This would have had to have been planned to even attain poor inter= op.

 

 

From: Spasm <spasm-bounces@ietf.org> on behalf of Ryan Sleevi <ryan-= ietf@sleevi.com>
Date: Tuesday, July 28, 2020 at 11:04 AM
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Ryan Sleevi <= ryan-ietf@sleevi.com>, "spasm@ietf.org" <spasm@ietf.org>,= "Salz, Rich" <rsalz=3D40akamai.com@dmarc.ietf.org>, Wang Guil= in <Wang.Guilin@huawei.com>
Subject: Re: [lamps] [Cfrg] How = to issue CRLs after the private key of old root certificate has been destroy= ed?

 

=

Right, but in that scenario, it's to be treate= d like a CA termination event. I don't know if you're necessarily reducing r= isk, but rather, shifting risk.

&= nbsp;

Prior to destroying that key ma= terial, operationally you'd be expected to do something such as "sign f= inal CRLs" - e.g. revoking all certificates that have been issued. That= 's the interoperable answer: destroying the key is a termination event. Or, = if you're looking at a business continuity termination, you have arrang= ements for some other service provider to continue to provide revocation ser= vices, using a copy of the key that they have and maintain. But there's not = really a good interoperable way post key-destruction to continue the provisi= on of revocation information in an interoperable fashion.

 

On Tue, Jul 28, 2020 at 10:56 AM Benjamin Kaduk <kaduk@mit.edu> wrote:

On Tue, Jul 28, 2020 at 02:= 54:08PM +0000, Salz, Rich wrote:
> I think that is the key point. = ; A CA cannot sign anything that goes beyond its own notAfter field.

= You could perhaps decide that you don't want to carry the operational riskof securing the private key for the whole validity period, though, and
= destroy all copies of the private key before the notAfter time.

-Ben<= o:p>

________________________= _______________________ Spasm mailing list Spasm@ietf.org https://www.ietf.o= rg/mailman/listinfo/spasm

--B_3678782357_151302470-- From nobody Wed Jul 29 08:22:54 2020 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 66DC33A0C50; Wed, 29 Jul 2020 08:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 Mv2W-f8giFGv; Wed, 29 Jul 2020 08:22:46 -0700 (PDT) Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653FB3A0C4A; Wed, 29 Jul 2020 08:22:45 -0700 (PDT) Received: by mail-oi1-f181.google.com with SMTP id k22so21062825oib.0; Wed, 29 Jul 2020 08:22:45 -0700 (PDT) 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=Mr40i66UCktCJo+VWijBOq4XSC+g1Ln4LvdN+u3LWx0=; b=fsJ+V4yYykTSgOc2he1dZgaDlyuWaZtCGfMzlBEVwST0fmS6CGX5FLXcFm8Uz1XwTh d2z8txa7Bz1mP4BFXt39Flvz/oGrELVeIVC1mwb2H3d6zPK0pO6XCYgkzLAM/j0Nkw9J LatqS/G/qRmRspBoLthVRnvEcR/EikDPMnDZiFUNzlWr3GhEQSHj4gw44hYJDjhfkP5b eYCXE8+WXTLsjFOy6jJDMgrqJHUwWa1XWhUWITKaoKGseS1cocc3snEDFcVmFS10wZ0g JlyUQ94aESci5rfyrTdgArRpyIp5CqizuP/XiTfRYIarSpiyfqG90hRvDGiWg1WbHHlC HCGA== X-Gm-Message-State: AOAM532GyDrEuga3upKbZmZzSPe/KZnIkAWMOzw2EhCZHCZuy5cuddOr yH+sYHxtlYEY/WpiUgPprY1ZcXEjwev8YYCqYx5WY3doN0s= X-Google-Smtp-Source: ABdhPJyMmQgQks2TF/CCCCyTCFohfrEoL+FQskarjAGm0tYjMz3Qn8oGu+/OyD2ogb0yUNZdrKzBHPXXfNef2eEstxE= X-Received: by 2002:aca:fcd2:: with SMTP id a201mr6040989oii.166.1596036164439; Wed, 29 Jul 2020 08:22:44 -0700 (PDT) MIME-Version: 1.0 References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> <22303.1595374300@localhost> <08ab938b-deee-09f2-697b-657049cc4192@primekey.se> <19924.1595432391@localhost> <995a966c-bd9e-ca25-18a2-1e90b3c530e7@primekey.com> <19403.1595518388@localhost> <15413.1595532896@localhost> In-Reply-To: <15413.1595532896@localhost> From: Phillip Hallam-Baker Date: Wed, 29 Jul 2020 11:22:33 -0400 Message-ID: To: Michael Richardson Cc: SPASM , IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000a152e705ab962038" Archived-At: Subject: Re: [lamps] IDevID considerations document to secdispatch X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 29 Jul 2020 15:22:49 -0000 --000000000000a152e705ab962038 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 23, 2020 at 3:35 PM Michael Richardson wrote: > > Phillip Hallam-Baker wrote: > > Just thought I would weigh in with some points. > > Thank you. > I don't quite understand how XKMS can be used to provision private keys, > but > I do agree that I do agree that the rest is a mess > There is a key provisioning protocol in the spec. > My goal is to just collect and describe the methods. > > I originally started with the idea of being prescriptive about the shape of > of the PKI that is used to provision the certificates. I am pulling back > from the prescriptive part, and instead I intend to just describe the > different considerations, giving them names. > > > There are no good choices for creating key pairs. All have drawbacks. > > > * Any key generated by the manufacturer can leak at multiple points > in the > > supply chain. But it can be welded to the device in such a way that > it > > cannot be extracted without extreme persuasion. > > > * Any key that is generated by the device can also be compromised > through > > an intentional side channel or by weak key generation. And once > generated > > can usually be extracted. > > I am interested in why you say that the key can be welded into place > by the factory, but a key generated internally can't be welded in place in > the same way. > I have been through a bunch of designs where the manufacturer key can be replaced by a user one. I don't think they actually add value. What I am proposing for a threshold co-processor to address SPECTRE, ROWHAMMER etc. attacks is the following: Secret key key installed during manufacture are ka, ks Operation Threshold Agree: P, a, c -> (a.ka+c).P Operation Threshold Sign: Rin, a, c, m1, m2 -> r.P, r + H(m1 || (r.P+Rin) || m2). (a.ks+c) Such a co-processor should always offer operations on (a.k+c) rather than just k. This allows the platform to make use of Lagrange/Shamir sharing approaches and to construct as many virtual application keys as are needed . Changing the manufacturer key just introduces a point of possible failure without really achieving anything because the application should always be adding in its own mix-in. Unless one is prohibited from using the manufacturer key because of a doctrine, I can't see why it would be a requirement. The manufacturer key should never be used except in the process of application key provisioning. And there the benefit of being able to print a QR Code on the device that has real meaning probably outweighs that concern. Doctrines can be a useful tool but we cannot develop specification responsive to classified doctrines in an open process. > > So none of the solutions are good. What should we do? The best > answer is to > > do all of them and combine the keys using threshold techniques. That > allows > > us to get a key that combines all the properties we want and is only > > vulnerable if there are multiple failures. > > > The math is explained in this draft: > > https://tools.ietf.org/id/draft-hallambaker-threshold-02.html > > I would like to include this in my list, but we have a chicken and egg > situation on it. > There is a NIST program looking at threshold. It is certainly an option even if IETF isn't supporting it right now. --000000000000a152e705ab962038 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=

= On Thu, Jul 23, 2020 at 3:35 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Phillip Hallam-Baker <phill@hallambaker.com> wrote:
=C2=A0 =C2=A0 > Just thought I would weigh in with some points.

Thank you.
I don't quite understand how XKMS can be used to provision private keys= , but
I do agree that I do agree that the rest is a mess
There is= a key provisioning protocol in the spec.



=C2=A0
My goal is to just collect and describe the methods.

I originally started with the idea of being prescriptive about the shape of=
of the PKI that is used to provision the certificates.=C2=A0 I am pulling b= ack
from the prescriptive part, and instead I intend to just describe the
different considerations, giving them names.

=C2=A0 =C2=A0 > There are no good choices for creating key pairs. All ha= ve drawbacks.

=C2=A0 =C2=A0 > * Any key generated by the manufacturer can leak at mult= iple points in the
=C2=A0 =C2=A0 > supply chain. But it can be welded to the device in such= a way that it
=C2=A0 =C2=A0 > cannot be extracted without extreme persuasion.

=C2=A0 =C2=A0 > * Any key that is generated by the device can also be co= mpromised through
=C2=A0 =C2=A0 > an intentional side channel or by weak key generation. A= nd once generated
=C2=A0 =C2=A0 > can usually be extracted.

I am interested in why you say that the key can be welded into place
by the factory, but a key generated internally can't be welded in place= in
the same way.

I have been through a bunch of designs where = the manufacturer key can be replaced by a user one. I don't think they = actually add value.

What = I am proposing for a threshold co-processor to address SPECTRE, ROWHAMMER e= tc. attacks is the following:

Secret key key installed during manufacture are ka, ks

Operation Threshold Agree: P, a, c ->= (a.ka+c).P
Operation Thr= eshold=C2=A0Sign: Rin, a, c, m1, m2 -> r.P,=C2=A0 r + H(m1 ||=C2=A0 (r.P= +Rin) || m2). (a.ks+c)

Such a co-processor should always offer operations o= n (a.k+c) rather than just k. This allows the platform to make use of Lagra= nge/Shamir sharing approaches and to construct as many virtual application = keys as are needed .

Changing the manufacturer key just introduces a point = of possible failure without really achieving anything because the applicati= on should always be adding in its own mix-in.

Unless one is prohibited from using the manufacturer k= ey because of a doctrine, I can't see why it would be a requirement. Th= e manufacturer key should never be used except in the process of applicatio= n key provisioning. And there the benefit of being able to print a QR Code = on the device that has real meaning probably outweighs that concern.
<= /div>
Doctrines can be a usefu= l tool but we cannot develop specification responsive to classified doctrin= es in an open process.


=C2=A0
=C2=A0 =C2=A0 > So none of the solutions are good. What should we do? Th= e best answer is to
=C2=A0 =C2=A0 > do all of them and combine the keys using threshold tech= niques. That allows
=C2=A0 =C2=A0 > us to get a key that combines all the properties we want= and is only
=C2=A0 =C2=A0 > vulnerable if there are multiple failures.

=C2=A0 =C2=A0 > The math is explained in this draft:
=C2=A0 =C2=A0 > https://tools.ietf.o= rg/id/draft-hallambaker-threshold-02.html

I would like to include this in my list, but we have a chicken and egg
situation on it.

There is a NIST program looking at threshold. I= t is certainly an option even if IETF isn't supporting it right now.
--000000000000a152e705ab962038-- From nobody Thu Jul 30 05:05:23 2020 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 745F33A07D7 for ; Thu, 30 Jul 2020 05:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 0D-DtrXLH_Kt for ; Thu, 30 Jul 2020 05:05:19 -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 34BF23A0BFB for ; Thu, 30 Jul 2020 05:05:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A5200300B7D for ; Thu, 30 Jul 2020 08:05:00 -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 92tRAKqbdqKB for ; Thu, 30 Jul 2020 08:04:59 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 02744300AAB; Thu, 30 Jul 2020 08:04:58 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: <123C83B5-DFCB-4409-80A7-7DFA45056B7F@akamai.com> Date: Thu, 30 Jul 2020 08:05:00 -0400 Cc: Wang Guilin Content-Transfer-Encoding: quoted-printable Message-Id: <65725789-6DF6-48C3-A71A-F63558E971EC@vigilsec.com> References: <123C83B5-DFCB-4409-80A7-7DFA45056B7F@akamai.com> To: LAMPS WG X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [lamps] [Cfrg] How to issue CRLs after the private key of old root certificate has been destroyed? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 30 Jul 2020 12:05:22 -0000 Using the correct WG mail list address ... > On Jul 28, 2020, at 8:16 AM, Salz, Rich = wrote: >=20 > Moving CFRG to BCC; the LAMPS working group is a better place (it = handles 5280 updates) to discuss this. >=20 > =EF=BB=BFOn 7/28/20, 6:22 AM, "Wang Guilin" = wrote: >=20 > Dear all,=20 >=20 > I am here to enquire one question about revoking PKI certificates.=20= >=20 > In practice, to guarantee high security, the validity (say 10 = years) of a root certificate private key may be essentially shorter that = the validity (say 30 years) of the corresponding public key. After the = first 10 years, a new root certificate with a new key pair will be = generated, and the old root private may be even destroyed. After that, = however, how can we use the new root private key to issue CRLs to revoke = certificates previously signed by the old root private key?=20 >=20 > At first, I thought this is the case of using indirect revocation = mechanism discussed in RFC 5280, which may involve the link certificate = NewWithOld, which is a certificate for the new root public key signed by = the old root private key. However, it seems that indirect revocation = only works for different entities. Namely, by using indirect revocation, = the certificates issued by A can be revoked by a different entity B. = However, in the above case, the old and new root certificates are for = the same entity (or owner). So, my real questions is: Can indirect = revocation be used in such a scenario? If not, is there any good way to = do this, especially if interoperability with TLS, SSL, IPSec etc is = required?=20 >=20 > Thanks a lot in advance,=20 >=20 > Guilin From nobody Fri Jul 31 03:05:22 2020 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 3CFCA3A11E2 for ; Fri, 31 Jul 2020 03:05:20 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.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 8W-VFXQ3ztMY for ; Fri, 31 Jul 2020 03:05:17 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20058.outbound.protection.outlook.com [40.107.2.58]) (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 3AC8D3A11D9 for ; Fri, 31 Jul 2020 03:05:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CZudTWIEhzaFtKy/jbdMZ+lRHbCVh15tt4ZOwVChdu48TGq5OUI6+dkxYaa51XoXl7I2y2j+E5ZJ016Bm34I/DB11LbXsCwTuKSlmDVSiKTMgkE55t9BMJ5o4bvmJqheXqaQ82ziW7PXOm0s1m4J9yRPKlk7NQv79LKyH8LbOXqUCc7qx1ohpTOJ+8l7xCN5JezUWxDwoG3kUDBu9Kl/ulJxBgED8aeEqH8nnV/08ttb6A99YG4S4bCX6Cpa9NOT1AVHqZ2zipxW6h5MMiD1w8OL2+VoswesVpSMHstL5tb0InWpcjc7sRrHUUSlcd5fEaFZvDmwzv6rJncDHgED5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aeBvgIEuuPbJocEiD0kyWcDb/R37c8yw8q5ppUzIf5I=; b=AqP9oVnxeg+PtymmO967zLBmUz18bgdSi+R4R1NtLh6QgqFc8jA1gnfn00IIbQUEs4og4JTPTzuWVJ+QcEFJ0LS5ExxPioWFBL9i9wS/ySykQZODADqQos2bbH3Xowo6s1mm2hoyizB30iqSzyNAtTVkFQ2HSGd4FIb4j9oHUxuuzcOFf62KGPi/KYuMKItXjozLLx/QJwQ0L3syY+EHsTfqsODPC6LqbYri+yVH02mejnjWt2ju15qrAD1qq+7cNc22hOYgaeU3Hkd0z7TsHsVjritUmyrgA84sllD5Fc7W0hRfvk1+kGfxPlAcTdwNR8ocXdHrk2qAq0w5RmIvXg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aeBvgIEuuPbJocEiD0kyWcDb/R37c8yw8q5ppUzIf5I=; b=JYsvpLZL2HQwH4s7T/jjHyrXiwZ87SvXe3lOXkbKM15bdPlDTj+FzH9Oj8hkZmb2q/+R4QExxjHHno9h1X8tMvOkhbYskMlSTAVgkP4v2gxY00Gn7C5mK2jmc/BSz/uLsCyf8AlK6pS0gPke4rTwBYOj++mW4W4wJqx1db8whA0= Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:184::10) by AM0PR10MB3361.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:155::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.22; Fri, 31 Jul 2020 10:05:14 +0000 Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0]) by AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0%9]) with mapi id 15.20.3239.020; Fri, 31 Jul 2020 10:05:14 +0000 From: "Brockhaus, Hendrik" To: Russ Housley CC: LAMPS WG Thread-Topic: [lamps] draft-ietf-lamps-cmp-updates Thread-Index: AQHWY4Otd7XI25AWCU2d90xbJWNT86kbmGwggAAF5ICAAN4GQIAAqx6AgARPCPA= Content-Class: Date: Fri, 31 Jul 2020 10:05:14 +0000 Message-ID: References: <97AAAE51-45E0-4363-ACAD-99144085E710@vigilsec.com> <6637BD5E-96EF-4982-8F4B-289209D1EBD2@vigilsec.com> <9E8DDD8B-1F37-40C5-B49D-A6B8D2B3F9A1@vigilsec.com> In-Reply-To: <9E8DDD8B-1F37-40C5-B49D-A6B8D2B3F9A1@vigilsec.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-07-31T10:05:12Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=10ace11d-6f50-41a0-827c-2b2af1926772; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.166] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d5d3324c-c3ea-4cd6-79b0-08d835393835 x-ms-traffictypediagnostic: AM0PR10MB3361: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SVcv0mlvo7IDQwym9DNh9eEMoLg6hoLiSHQQQFGagSEXrEbhUG1FQoetW9ysvrhCC4Qke/UP2rDRQCDNj6yHm6J7XcXBtbEM33TfVW8dAiuMPXAEgFyqOhXKcUf3kBnLrsm7nGtbywjf2pTKIDdg8LWxNIHKS9kiwxdEEQqhDc7tLnNy7KAD+/yzuSzDGAW63of8ZwOlH3y+pcV9FUKxEXHMCEarlbJEUDEpB3j4y5VO3ZCRxso70Ne1JKtjci5dMLJoJGIubywRSNMlg/umOoJHa9MnZNwIB12Xpq4/UH7zNGgXqaneCpNV3vOOKvW0Pj6mWh5h0b6XDaugCh0jlw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(136003)(39860400002)(346002)(376002)(66946007)(76116006)(4326008)(66446008)(83380400001)(66476007)(7696005)(478600001)(64756008)(66556008)(15650500001)(316002)(33656002)(86362001)(6916009)(186003)(55016002)(5660300002)(9686003)(71200400001)(8936002)(6506007)(2906002)(55236004)(26005)(53546011)(8676002)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: VvRLtQASg1+TwQNiM0tEFJT8q15w1NaCQNhzpMBM8GQ+GIuD4b/91Zfc7QFriq5A8ynGtDJ0k8H4FzY6bftlE5iG140f9so63K8XMMozu1w+/ynZapFngYw7Fj4rAB4LVtWjoiScLn7izeIJD7/HvACb0fNKl5nd+otxEdRnPYSVkrMR2oEFUeq1xU70fGrtzdKBrPVqMcP+qQYkTEL+pxJL2OTWrx71X4xo1eBm50GMNiUiBwe9R8YoPj7dz3QjqRpYvJoUlcmzLF9cytTI5WCabRhTD5VGxkUaE4u+HNce6aeGzxIcMLiD+rcAr2NFaKrUFQip97GMPrvndd5E+YsgwpCOCM0J/UJKme09rO2bQTcyQTXQnRFV911wGVeNdK9lJjyQ0/srWBCo2koTEOyhlgMZgro+6xEfC6drmEMWwYOa8WEzlp+8P9i/xJBsoWbYypsgV8/M4hqHvQEZB84V1mjaBaeV0kg+AbVD8uPMs9YQ/8bI978nEjwF/Noy x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: d5d3324c-c3ea-4cd6-79b0-08d835393835 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2020 10:05:14.4644 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JtEeWX7qtQOY5R8wI1Tc3svUKGhejsmWZYiDQGtXdNOzLGgj0Qx4X7Cwe+13//m+4/RLUPfqoHLNmYc3B+obLEQ1BTOg/Z47YlnuEm/sIMg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB3361 Archived-At: Subject: Re: [lamps] draft-ietf-lamps-cmp-updates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 31 Jul 2020 10:05:20 -0000 Russ After having another look into the ASN.1 module in RFC4210 it up to the imp= lementer which ITV he/she wants to use. It is specified like this: > Von: Russ Housley >=20 > Hendrik: >=20 > >> Von: Russ Housley > >> > >>> On Jul 27, 2020, at 12:22 PM, Brockhaus, Hendrik > >> wrote: > >>> > >>>> Third, id-it-revPassphrase (which is in a comment) is associated > >>>> with EncryptedKey instead of EncryptedValue. > >>> > >>> Finally, I do not fully understand this specification, too. > >>> My goal is to update OID {id-it 12} as specified in section > >>> 5.3.19.9 and the > >> only lines in the ASN.1 module on this OID is in comments? > >> > >> Right, so it is just and updated comment; however, the place were > >> this is defined needs to be updated too, right? > > > > Yes. But the only place I am aware of where this OID is defined is in s= ection > 5.3.19.9 of RFC4210. I update this section in section 2.6 of the draft. > > Are there any other place I should update? >=20 >=20 > If that is the case, I suspect that all of the id-it- OID values need to = appear in > this new module. >=20 > Looking at RFC 5912, is seem that Jim and Paul defined these constructs f= or this > purpose: >=20 > ~~~ > INFO-TYPE-AND-VALUE ::=3D TYPE-IDENTIFIER >=20 > InfoTypeAndValue ::=3D SEQUENCE { > infoType INFO-TYPE-AND-VALUE. > &id({SupportedInfoSet}), > infoValue INFO-TYPE-AND-VALUE. > &Type({SupportedInfoSet}{@infoType}) } ~~~ >=20 > This is probably something that should be carried forward. >=20 > So, for example, that would lead to this in the ASN.1 module: >=20 > ~~~ > it-caProtEncCert INFO-TYPE-AND-VALUE ::=3D { > CMPCertificate IDENTIFIED BY id-it-caProtEncCert } ~~~ >=20 > You need a statement like this for each of the id-it- OID values. Thanks for that hint.=20 I added this section to the ASN.1 module: INFO-TYPE-AND-VALUE ::=3D TYPE-IDENTIFIER InfoTypeAndValue ::=3D SEQUENCE { infoType INFO-TYPE-AND-VALUE. &id({SupportedInfoSet}), infoValue INFO-TYPE-AND-VALUE. &Type({SupportedInfoSet}{@infoType}) } SupportedInfoSet INFO-TYPE-AND-VALUE ::=3D { ... } id-it-revPassphrase OBJECT IDENTIFIER ::=3D {id-it 12} RevPassphraseValue ::=3D EncryptedKey In the ASN.1 module in RFC 4210 as well as RFC 5912 (page 50) all definitio= ns for specific id-it OIDs are in comments and supposed to be uncommented a= ccording to the given environment. Is it sufficient to only add id-it-revPassphrase, which I changed, to the A= SN.1 module of CMP Updates? Or would you recommend to copy the complete section 9 of RFC5912 to CMP Upd= ates and perform the changes? Hendrik