From nobody Wed Jan 2 10:26:17 2019 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 4DF8C130EEA; Wed, 2 Jan 2019 10:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h08-BEofiuCg; Wed, 2 Jan 2019 10:26:07 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 799A8130EE5; Wed, 2 Jan 2019 10:26:07 -0800 (PST) Received: from [169.254.31.115] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id x02IOsRB024385 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 2 Jan 2019 11:24:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.31.115] From: "Paul Hoffman" To: ietf@ietf.org Cc: draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org, spasm@ietf.org Date: Wed, 02 Jan 2019 10:26:05 -0800 X-Mailer: MailMate (1.12.3r5579) Message-ID: <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> In-Reply-To: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 02 Jan 2019 18:26:09 -0000 On 27 Dec 2018, at 14:13, The IESG wrote: > The IESG has received a request from the Limited Additional Mechanisms > for > PKIX and SMIME WG (lamps) to consider the following document: - 'Hash > Of Root > Key Certificate Extension' > as > Informational RFC > > 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 > ietf@ietf.org mailing lists by 2019-01-10. This extension seems useful to CAs that understand the increased risks that using it incurs, but those risks are not mentioned in the document. The document implicitly assumes that the CA will in fact use the key named in the extension next. Using this extension increases the risk of a bad trust anchor rollover at the same time that it makes good rollover more secure. If the key listed in this extension cannot be used when the CA eventually changes the trust anchor, relying parties will mistrust the new trust anchor. There are many reasons why a CA might think they know the next key but cannot use that key when they change trust anchors, such as if the HSM that holds the next key fails or is destroyed. Given the last sentence in Section 2, this could mean that a CA might never be able to issue a new trust anchor, even if the key for its current trust anchor is compromised. Given the severity of the new risks of using this extension, they need to be introduced at the beginning of the document and then discussed in more detail in the Security Considerations. Note that this risk affects the last paragraph of the Security Considerations section as well. Editorial: The abstract says: This document specifies the Hash Of Root Key certificate extension. This certificate extension is carried in the self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate. This certificate extension unambiguously identifies the next public key that will be used by the trust anchor at some point in the future. The term "trust anchor" is used as the concept, not the bits in the certificate. As such, the last sentence is confusing because the trust anchor will change when the key changes. A possible fix is to replace "will be used by the trust anchor at some point in the future" with "will be used in a trust anchor at some point in the future". The first list in Section 2 would be clearer if the order was R1, R2, H2, C1; this would also then match the order in the second list. Later in Section 2, a sentence appears to be missing its subject. "That is, verify the signature on the self-signed certificate..." should probably be "That is, the recipient verifies the signature on the self-signed certificate...". --Paul Hoffman From nobody Wed Jan 2 11:57:16 2019 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 8EEDC130ED4 for ; Wed, 2 Jan 2019 11:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48VZgyqPaZtm for ; Wed, 2 Jan 2019 11:57:13 -0800 (PST) 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 D927E1271FF for ; Wed, 2 Jan 2019 11:57:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E5DC6300A4E for ; Wed, 2 Jan 2019 14:38:54 -0500 (EST) 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 KhgdnFsUaSaR for ; Wed, 2 Jan 2019 14:38:52 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 53CE5300425; Wed, 2 Jan 2019 14:38:52 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> Date: Wed, 2 Jan 2019 14:57:08 -0500 Cc: IETF , draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org, spasm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3D85A45C-FE94-45A7-BF37-C3F8C1B3F5AA@vigilsec.com> References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 02 Jan 2019 19:57:16 -0000 > On Jan 2, 2019, at 1:26 PM, Paul Hoffman = wrote: >=20 > On 27 Dec 2018, at 14:13, The IESG wrote: >=20 >> The IESG has received a request from the Limited Additional = Mechanisms for >> PKIX and SMIME WG (lamps) to consider the following document: - 'Hash = Of Root >> Key Certificate Extension' >> as = Informational RFC >>=20 >> 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 >> ietf@ietf.org mailing lists by 2019-01-10. >=20 > This extension seems useful to CAs that understand the increased risks = that using it incurs, but those risks are not mentioned in the document. >=20 > The document implicitly assumes that the CA will in fact use the key = named in the extension next. Using this extension increases the risk of = a bad trust anchor rollover at the same time that it makes good rollover = more secure. If the key listed in this extension cannot be used when the = CA eventually changes the trust anchor, relying parties will mistrust = the new trust anchor. There are many reasons why a CA might think they = know the next key but cannot use that key when they change trust = anchors, such as if the HSM that holds the next key fails or is = destroyed. Given the last sentence in Section 2, this could mean that a = CA might never be able to issue a new trust anchor, even if the key for = its current trust anchor is compromised. >=20 > Given the severity of the new risks of using this extension, they need = to be introduced at the beginning of the document and then discussed in = more detail in the Security Considerations. Note that this risk affects = the last paragraph of the Security Considerations section as well. The point is to facilitate the transition from one Root CA certificate = to the next. The last sentence in Section 2 says: If either check fails, then potential Root CA certificate is not a valid replacement, and the recipient continues to use the current Root CA certificate. Indeed, these check are necessary to make sure that the relying party = makes the transition to the proper replacement. Any failure of the = checks leave the trust anchor unchanged, which seems like the right = result to me. Recall the definition of trust anchor from RFC 5280, Section 6.1.1: (d) trust anchor information, describing a CA that serves as a trust anchor for the certification path. The trust anchor information includes: (1) the trusted issuer name, (2) the trusted public key algorithm, (3) the trusted public key, and (4) optionally, the trusted public key parameters associated with the public key. The checks make sure that the replacement self-signed certificate = contains the intended information. > Editorial: >=20 > The abstract says: > This document specifies the Hash Of Root Key certificate extension. > This certificate extension is carried in the self-signed certificate > for a trust anchor, which is often called a Root Certification > Authority (CA) certificate. This certificate extension = unambiguously > identifies the next public key that will be used by the trust anchor > at some point in the future. > The term "trust anchor" is used as the concept, not the bits in the = certificate. As such, the last sentence is confusing because the trust = anchor will change when the key changes. A possible fix is to replace = "will be used by the trust anchor at some point in the future" with = "will be used in a trust anchor at some point in the future". I think I understand your point. Does this text resolve the concern? This document specifies the Hash Of Root Key certificate extension. This certificate extension is carried in the self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate. This certificate extension unambiguously identifies the next public key that will be used at some point in the future as the next Root CA certificate, replacing the current one. > The first list in Section 2 would be clearer if the order was R1, R2, = H2, C1; this would also then match the order in the second list. Okay. I changed that in my edit buffer. > Later in Section 2, a sentence appears to be missing its subject. = "That is, verify the signature on the self-signed certificate..." should = probably be "That is, the recipient verifies the signature on the = self-signed certificate...". Okay. I changed that in my edit buffer. In addition, I added a bit more detail about the relationship to = certification path validation, which I hope adds clarity around your = first comment. It now reads: The successor to the Root CA self-signed certificate can be delivered by any means. Whenever a new Root CA certificate is received, the recipient is able to verify that the potential Root CA certificate links back to a previously authenticated Root CA certificate with the hashOfRootKey certificate extension. That is, the recipient verifies the signature on the self-signed certificate and verifies that the hash of the DER-encoded SubjectPublicKeyInfo from the potential Root CA certificate matches the value from the HashOfRootKey certificate extension of the current Root CA certificate. Checking the self-signed certificate signature ensures that the certificate contains the subject name, public key algorithm identifier, and public key algorithm parameters intended by the key owner intends; these are important inputs to certification path validation as defined in Section 6 of [RFC5280]. Checking the hash of the SubjectPublicKeyInfo ensures that the certificate contains the intended public key. If either check fails, then potential Root CA certificate is not a valid replacement, and the recipient continues to use the current Root CA certificate. Russ From nobody Wed Jan 2 12:17:24 2019 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 BC168130F06; Wed, 2 Jan 2019 12:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aD-6Jz4Fq36M; Wed, 2 Jan 2019 12:17:12 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 C4DC9126C01; Wed, 2 Jan 2019 12:17:12 -0800 (PST) Received: from [10.32.60.109] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id x02KFxTe034061 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 2 Jan 2019 13:16:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.109] From: "Paul Hoffman" To: "Russ Housley" Cc: IETF , draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org, spasm@ietf.org Date: Wed, 02 Jan 2019 12:17:10 -0800 X-Mailer: MailMate (1.12.3r5579) Message-ID: <869BCE27-2AB5-4550-AC89-335BFE749123@vpnc.org> In-Reply-To: <3D85A45C-FE94-45A7-BF37-C3F8C1B3F5AA@vigilsec.com> References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <3D85A45C-FE94-45A7-BF37-C3F8C1B3F5AA@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 02 Jan 2019 20:17:15 -0000 On 2 Jan 2019, at 11:57, Russ Housley wrote: >> On Jan 2, 2019, at 1:26 PM, Paul Hoffman >> wrote: >> >> This extension seems useful to CAs that understand the increased >> risks that using it incurs, but those risks are not mentioned in the >> document. >> >> The document implicitly assumes that the CA will in fact use the key >> named in the extension next. Using this extension increases the risk >> of a bad trust anchor rollover at the same time that it makes good >> rollover more secure. If the key listed in this extension cannot be >> used when the CA eventually changes the trust anchor, relying parties >> will mistrust the new trust anchor. There are many reasons why a CA >> might think they know the next key but cannot use that key when they >> change trust anchors, such as if the HSM that holds the next key >> fails or is destroyed. Given the last sentence in Section 2, this >> could mean that a CA might never be able to issue a new trust anchor, >> even if the key for its current trust anchor is compromised. >> >> Given the severity of the new risks of using this extension, they >> need to be introduced at the beginning of the document and then >> discussed in more detail in the Security Considerations. Note that >> this risk affects the last paragraph of the Security Considerations >> section as well. > > The point is to facilitate the transition from one Root CA certificate > to the next. To be clear, the transition is from one public key to the next, not from one certificate to the next. But, more importantly, the point of this extension is to facilitate the transition from one Root CA certificate to what is supposed to be the next key. However, if that next key is not seen by every relying party during the transition, the extension prevents the CA from ever making the transition for the relying parties that do not see the new key in a revised trust anchor. This seems like a huge restriction that is only mentioned in the document in exactly one sentence: > The last sentence in Section 2 says: > > If either check fails, then potential Root CA > certificate is not a valid replacement, and the recipient continues > to use the current Root CA certificate. > > Indeed, these check are necessary to make sure that the relying party > makes the transition to the proper replacement. Any failure of the > checks leave the trust anchor unchanged, which seems like the right > result to me. It seems right to me as well, but it still seems to be wholly insufficient to not talk about the risks of using the extension early in the document. > > Recall the definition of trust anchor from RFC 5280, Section 6.1.1: > > (d) trust anchor information, describing a CA that serves as a > trust anchor for the certification path. The trust anchor > information includes: > > (1) the trusted issuer name, > > (2) the trusted public key algorithm, > > (3) the trusted public key, and > > (4) optionally, the trusted public key parameters associated > with the public key. > > The checks make sure that the replacement self-signed certificate > contains the intended information. That is all fine, but it does not address the significant risk a CA is undertaking by promising what the next key will be. >> Editorial: >> >> The abstract says: >> This document specifies the Hash Of Root Key certificate extension. >> This certificate extension is carried in the self-signed >> certificate >> for a trust anchor, which is often called a Root Certification >> Authority (CA) certificate. This certificate extension >> unambiguously >> identifies the next public key that will be used by the trust >> anchor >> at some point in the future. >> The term "trust anchor" is used as the concept, not the bits in the >> certificate. As such, the last sentence is confusing because the >> trust anchor will change when the key changes. A possible fix is to >> replace "will be used by the trust anchor at some point in the >> future" with "will be used in a trust anchor at some point in the >> future". > > I think I understand your point. Does this text resolve the concern? > > This document specifies the Hash Of Root Key certificate extension. > This certificate extension is carried in the self-signed > certificate > for a trust anchor, which is often called a Root Certification > Authority (CA) certificate. This certificate extension > unambiguously > identifies the next public key that will be used at some point in > the > future as the next Root CA certificate, replacing the current one. Not really. A key will not be used as a certificate: it is just a key. A key might be used as the signing key for a certificate, but not as the certificate itself. Maybe instead: "will be used to sign a trust anchor at some point in the future"? >> The first list in Section 2 would be clearer if the order was R1, R2, >> H2, C1; this would also then match the order in the second list. > > Okay. I changed that in my edit buffer. > >> Later in Section 2, a sentence appears to be missing its subject. >> "That is, verify the signature on the self-signed certificate..." >> should probably be "That is, the recipient verifies the signature on >> the self-signed certificate...". > > Okay. I changed that in my edit buffer. > > In addition, I added a bit more detail about the relationship to > certification path validation, which I hope adds clarity around your > first comment. It now reads: > > The successor to the Root CA self-signed certificate can be > delivered by any means. Whenever a new Root CA certificate is > received, the recipient is able to verify that the potential Root > CA > certificate links back to a previously authenticated Root CA > certificate with the hashOfRootKey certificate extension. That is, > the recipient verifies the signature on the self-signed certificate > and verifies that the hash of the DER-encoded SubjectPublicKeyInfo > from the potential Root CA certificate matches the value from the > HashOfRootKey certificate extension of the current Root CA > certificate. Checking the self-signed certificate signature > ensures > that the certificate contains the subject name, public key > algorithm > identifier, and public key algorithm parameters intended by the key > owner intends; these are important inputs to certification path > validation as defined in Section 6 of [RFC5280]. Checking the hash > of the SubjectPublicKeyInfo ensures that the certificate contains > the > intended public key. If either check fails, then potential Root CA > certificate is not a valid replacement, and the recipient continues > to use the current Root CA certificate. Yes, adding this clarifies how all the trust anchor information is linked through the validation process. This is a good addition. --Paul Hoffman From nobody Wed Jan 2 12:32:39 2019 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 755871274D0; Wed, 2 Jan 2019 12:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 36DSCSmiF3F1; Wed, 2 Jan 2019 12:32:30 -0800 (PST) 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 40BE9129AB8; Wed, 2 Jan 2019 12:32:27 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x02KRglj003571; Wed, 2 Jan 2019 20:32:27 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=iZUTYBFx2Iw3kfGcBHtHdkqsNdKZpEU2KSJo0f2dZmc=; b=Z6PwkeUy1Tqho/p6HirgZkGAb7sfkK8a9f8e560uN/KvMoLlc0dkPRy2IOdfHgnOFjzP PWvw9gAQ8NYwP7kVKyWGPfnrSYTcP0NBkE2K//iyt7fkpzDwmI/AyQxncoZYdNR5LRP8 188Ul/Lh36F47URkH6pECr0hEffk1Y3NwviFtK904gIrRb8IkDvXxMwGgY0tZCuhGSEj R1i1KTLtwF/CedvDVSG8CElgNrhX6f7AHqFTJ9aknJ5q3oB29qf+zJ/hB69XVltSHSyx hQhVOFsKsa/+RPK24c71VwNrBjJlMt3O8nSt3eUyg+idjY/+GF/v0Qad3qiiy1TJxGe8 5g== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2prj4htkhg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 02 Jan 2019 20:32:26 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id x02KVutP024453; Wed, 2 Jan 2019 15:32:25 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2pp552qwde-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 02 Jan 2019 15:32:25 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 2 Jan 2019 14:32:23 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Wed, 2 Jan 2019 14:32:23 -0600 From: "Salz, Rich" To: Paul Hoffman , Russ Housley CC: "spasm@ietf.org" , "draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org" , IETF Thread-Topic: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC Thread-Index: AQHUnjGB95DAqnv0tkCxg+ex07oDdqWcuXCAgAAZcQCAAAWZAP//sG0A Date: Wed, 2 Jan 2019 20:32:22 +0000 Message-ID: References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <3D85A45C-FE94-45A7-BF37-C3F8C1B3F5AA@vigilsec.com> <869BCE27-2AB5-4550-AC89-335BFE749123@vpnc.org> In-Reply-To: <869BCE27-2AB5-4550-AC89-335BFE749123@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.14.0.181208 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.122] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-02_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=798 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901020180 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-02_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=794 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901020180 Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 02 Jan 2019 20:32:32 -0000 SSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgdGhlIHJpc2sgaXMuDQogDQpJZiBhIGNsaWVudCBzZWVz IGFuZCB1bmRlcnN0YW5kcyB0aGUgZXh0ZW5zaW9uLCBpdCBjYW4gdXBkYXRlIGl0cyB0cnVzdCBz dG9yZSB0byBoYXZlIHRoZSBuZXcga2V5LiAgSWYgYSBjbGllbnQgZG9lcyBub3Qgc2VlLCBvciBk b2VzIG5vdCB1bmRlcnN0YW5kLCB0aGUgZXh0ZW5zaW9uLCB0aGVuIHRoZSB0cnVzdCBzdG9yZSB3 aWxsIGhhdmUgdG8gYmUgdXBkYXRlZCBvdXQgb2YgYmFuZCwganVzdCBsaWtlIGl0IGlzIG5vdy4N Cg0KQ0EncyB0aGF0IHVzZSB0aGlzIGV4dGVuc2lvbiBtdXN0IHRha2UgcHJvcGVyIGNhcmUgdG8g ZW5zdXJlIHRoYXQgdGhlIHByaXZhdGUga2V5IGlzIG5vdCBleHBvc2VkLg0KDQoNCg== From nobody Wed Jan 2 12:57:27 2019 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 ED02A129B88; Wed, 2 Jan 2019 12:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkeeRRMPGcO0; Wed, 2 Jan 2019 12:57:23 -0800 (PST) Received: from mail1.bemta23.messagelabs.com (mail1.bemta23.messagelabs.com [67.219.246.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1993A129AB8; Wed, 2 Jan 2019 12:57:22 -0800 (PST) Received: from [67.219.247.52] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-d.us-east-1.aws.symcld.net id 2C/F3-21706-1B52D2C5; Wed, 02 Jan 2019 20:57:21 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTWUwTURSGuZ3pdCDUDAXl2KDGijFBplBjTMX 9Qe2D4hJ90boMdmirbamdgoA+uCQqIC4RDCBbRAlWCBQluNVoNSJoDCJqioJBcauSqGDcojhL 3V4m/z3/d5Z7cofEVN8JNclmu1mXg7FpiAjckkSn0E2TaWNye1mKvrLVj+mDrwMK/UtvFa7va RyW60fO5eH6yoeb5hOGozeqMcPJk19lBs+TYblh6PgDbDm+Rm51pGVkb5RbbnovEM6RBdmDJ4 aJnahhXj6KIHHqAAbDg8eQcFBRB2UQuPZULh36EJTWBPB8FE4SVDI89LXJBB1DZcCZtv0yAcK oegTNtT6FYERTRQjyr8ULRgxVjGD/GW8oIxUqgp8xQeNUPHzp8IhaSa2D2o8luNSuRAa9u4fE hHBqLpx9HBAhRI2Bzx31YhyjYqFnoErUQMVA/73bhKRHw5vnP+USb4SKIT8fJ/n4RAi00BIyD rqqCsR7ArVHAU+6G0N1aHhfXIxJeikEjl4PQY8RnPreFTIS4NK+7lCCDWqu7CMkqAcD77MHuG TEQfu3cizUgoC+Lw3ieCrKBEUef2jU8eAp7MclaIDfd8txxWGUUPbP9crEzVYjKLzdjpeJi4q C9tIBXIJouHjlKibpCdA6WM5rBa9nwzmTFJ0IRQX9CknPgL13PxDViPSgGWkuq9nitjNWG61L TqZ1umn0TP6r1zK5tEmbydEsw7lpnZbZxmm5HPsmm0nrYN3NiH+IJmd41nkUPGX2o7GkTDNa6 elINKpGpWWYciwMZ9ngyrSxnB/FkaQGlPmTaKMqysWa2ex0q41/zb9tICM1MUq7YCs5J2PnrG bJ6kA02Zb3qRxT4Y4MB6uOVabF8xAlQJZMx58Sv/+JLjROHa1EYWFhqkgn67Jb3f/7QRRLIk2 0khCqRFod7j+dgvwQMn6I6ZAoDOFm/lrqnWjzIeaF4fq7dHPt1qzEyi0LFqdkzUn5yl1emPpj 1emGKFKr276jsSTd+6lzyojPnxdhi1rdnXtEndRXoKqrKKpse95rDCy7Vz576Y8VSwrqbLvu+ 1aeXxT8cAs9io8rHXvsVVLnnfU1xIQaxte5JbV3/dSctYVNdSOz3t5x5rbIWptvaHDOwugSMB fH/ALtivYIDgQAAA== X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-20.tower-424.messagelabs.com!1546462638!4225435!1 X-Originating-IP: [104.47.45.58] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.14.24; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1793 invoked from network); 2 Jan 2019 20:57:20 -0000 Received: from mail-co1nam04lp2058.outbound.protection.outlook.com (HELO NAM04-CO1-obe.outbound.protection.outlook.com) (104.47.45.58) by server-20.tower-424.messagelabs.com with AES256-SHA256 encrypted SMTP; 2 Jan 2019 20:57:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BO8passwIlIPDU0t4BdILC/LtekZYhI43LgJlNIaYvU=; b=cMqTp6BnwTGrrL0p2oI5WdkT92mjYCpG3kCX9L/Ha/e5AC63h6mIqmp2zs6uJYaik/n7iLYeA2Q10u6ggQxEl7jFeytPedW+LSV0poUXTT5/7x/ehfURo+Uc0m2aFmzONrRpoNScM4qJb9KHLhBoK5skG1l0Iwqq1jAmGIBZJzg= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1410.namprd14.prod.outlook.com (10.172.150.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.6; Wed, 2 Jan 2019 20:57:17 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::60f0:c4cd:7c30:59c4]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::60f0:c4cd:7c30:59c4%2]) with mapi id 15.20.1471.019; Wed, 2 Jan 2019 20:57:17 +0000 From: Tim Hollebeek To: "Salz, Rich" , Paul Hoffman , Russ Housley CC: "spasm@ietf.org" , "draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org" , IETF Thread-Topic: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC Thread-Index: AQHUnjFsG1mFhr8NEEGYNgqXXTDizqWcVNuAgAAZcQCAAAWZAIAABD8AgAAGM7A= Date: Wed, 2 Jan 2019 20:57:17 +0000 Message-ID: References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <3D85A45C-FE94-45A7-BF37-C3F8C1B3F5AA@vigilsec.com> <869BCE27-2AB5-4550-AC89-335BFE749123@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [98.111.253.32] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1410; 6:JGrk4nftKG7MUbebznx2ZpQnWoe4U+N0/CAqRhkCD7VlNFVWvdyZz/qf+xq65VLYMqL1uY9K80mHOkQGZdn7B5T7rooz7yfQw/Mnsfwq/Vn5PA1o7nbAcO/C0deHZXYvHZy+ZiRigj1OB7nifGoQoE9bIpuqip1/CB0dD9Cd6HI0o8iE3eduYQUAOEi9klCzU4zl+d4+wAlrFwOAhiOtrUxtdZm5wTjyMC+5m6E7Eiv/jnn2Gi3u6ucqsDgpS9Ui0XmuLPCw+PFceE8vn4PS6JfWPhopwhdp9Kdj75J5d7z+kc02J+g05tkZP2ksYY8g3vnWZqHQwSJCBVGjNWxc559e6pA8cDcFYcUj44ltyQ+YjNvmHqUK5OQhbOHNbKMyI9S/LjJOq0eFb+XV8XpGQTQVuKeKmkOHZidGtrgqfSM4gon71Ebwn57k46G4jyMsi7oAcauwl848xYqCHasqdw==; 5:h07oySPwBibmXyh8x9g0EKPI6nJbX8GxKBWlr33vmb1ziIBFy9/dzMgzqTlT8c8Lx1eRd1bhkbFKUuDD7TgyN2z/l/Amrid+ErtP5RR4nlnVnSFxw0rl383hqfx4kDaxa4sNaPtl16AwKJLF5Gfy4qPpAQkPkQBEPnJvEUvr2R+cxWayc0GWz84x0CHFfj/fOrZnxzvEo6lFjcqvl2glgQ==; 7:4FbKd/YjGi3KAII8Bx0XwUEVDjUzIWz3Pi/aNbPZ3a8wsY3yEH8J4w0oKGFWByUfJbbdAwhJQwgUCnDErEN0tPjQ62vZxVWUPJu5oYk4V/lUCYxMbeiUXrCiv9DfO4J9f+Ic+6anOpzuceF3JCf1nA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a63a83b0-a20e-4b1a-58b3-08d670f4e148 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1410; x-ms-traffictypediagnostic: BN6PR14MB1410: x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(3230021)(908002)(999002)(5005026)(102415395)(6040522)(8220060)(2401047)(8121501046)(3002001)(93006095)(93001095)(3231475)(944501520)(4983020)(52105112)(10201501046)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:BN6PR14MB1410; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1410; x-forefront-prvs: 0905A6B2C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(376002)(346002)(396003)(136003)(13464003)(189003)(199004)(53936002)(6116002)(5660300001)(186003)(55016002)(66066001)(11346002)(446003)(256004)(6246003)(14444005)(33656002)(476003)(68736007)(3846002)(74316002)(229853002)(102836004)(316002)(81156014)(81166006)(305945005)(7736002)(93886005)(86362001)(99286004)(99936001)(7696005)(25786009)(97736004)(105586002)(6436002)(76176011)(110136005)(54906003)(44832011)(486006)(53546011)(6506007)(8936002)(71200400001)(966005)(71190400001)(478600001)(106356001)(14454004)(6306002)(9686003)(2906002)(26005)(8676002)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1410; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: r3HX8t0Nvm9KowaLTOPhNt9//C7rf9P6lKUG9V7roKoyd1We0a9pFil67o9Y2inab7Rc8SjFfVaCkrSXuv5ZJwvgS31DOtGu9zGdPz6LWsZyseuGjHy3NMIe3YmZIADLMPuPfWCQBU5UPKVCy0bBG4JG38/snuccydI+PuFyPOD+n5soIiRRkbhWWiMycjHQ123BMaV6Y4JODm4B6fH792bG6Bl856b5OHEVsVbgLbqaXOSmD3fex8bqvs0/otUDuUcUh/gFRt3BdhzNlGxVISXiIuw/rnanp5eZHTcsckbXLjAkDN3jnxGn5W87eUCC spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_00AC_01D4A2B3.CC30E870" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: a63a83b0-a20e-4b1a-58b3-08d670f4e148 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2019 20:57:17.1718 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1410 Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 02 Jan 2019 20:57:26 -0000 ------=_NextPart_000_00AC_01D4A2B3.CC30E870 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm sympathetic to perhaps adding a sentence or two, but otherwise I'm struggling to understand the risk as well. If an entity is incapable of managing and protecting a replacement root key, perhaps they shouldn't be in the CA business. And since, at worst, they lose the ability to replace the root key, they aren't in a worse situation than they were if this capability didn't exist. -Tim > -----Original Message----- > From: Spasm On Behalf Of Salz, Rich > Sent: Wednesday, January 2, 2019 3:32 PM > To: Paul Hoffman ; Russ Housley > > Cc: spasm@ietf.org; draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org; IETF > > Subject: Re: [lamps] Last Call: 02.txt> (Hash Of Root Key Certificate Extension) to Informational RFC > > I don't understand what the risk is. > > If a client sees and understands the extension, it can update its trust store to > have the new key. If a client does not see, or does not understand, the > extension, then the trust store will have to be updated out of band, just like it > is now. > > CA's that use this extension must take proper care to ensure that the private > key is not exposed. > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm ------=_NextPart_000_00AC_01D4A2B3.CC30E870 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 CQUxDxcNMTkwMTAyMjA1NzAwWjAvBgkqhkiG9w0BCQQxIgQgYG0d4JJCG3PO+/2QCXN8NRfT9Hbj +qP8xcMy9TC0bxYwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAK+/UtT7PBrw0mjXztYE3+lXvjzdNCwpVXjPOOFUooirluyX1FO5CaBbxdpcbvz5ZD+XcUoL TAVjUW21DwKaGtT8io0lKPeV3DrmTE2dI4Jl/BqoFdU0+M2QS1OMmxZwioGIVnZ962ZAysWePDcP cyIWIhw6xIpGgyFhVcAzHsRQUs3KCg4n24Nn46GkZd+i5iw145bHL8G3eQM1M61JFnNGw0XMw0uV r9xBjTAWLFuk4GaM83OfjDMyqNFxleTQgTWoXLqT0RJbHHzTdEn5Zf2oyixA+5tr4Gt6cKLgfJDo N/ftRto1/bMyfR2oJQy4csCsVj5g3oRBxCTAHHTf6YEAAAAAAAA= ------=_NextPart_000_00AC_01D4A2B3.CC30E870-- From nobody Wed Jan 2 13:20:03 2019 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 1C3F7126C01; Wed, 2 Jan 2019 13:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6D65TOvTTTz; Wed, 2 Jan 2019 13:19:51 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07FB8129B88; Wed, 2 Jan 2019 13:19:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 290A0BE38; Wed, 2 Jan 2019 21:19:48 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gk8OitQs0D29; Wed, 2 Jan 2019 21:19:44 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2E33BBE2E; Wed, 2 Jan 2019 21:19:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1546463984; bh=yizS9k4KyDs1y9COqX1kOq+BO9X/AEm4+xliXz6VZ+U=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=zIrXRvwrjRyssYdSD1JWRb1UcSZfKbBwqooipxCAtMSH6la2EB3aG7Iai9inb6EEn p3kCGg9u58r8TW/NaLRtnPralxsBF3BN3XaJACGjHqvFOrkFrK2TJR62YBLPlAh17v mHEn1439W3Nt5Hef6BsX4vuJ0Qw881Bz33obtgL0= To: Tim Hollebeek , "Salz, Rich" , Paul Hoffman , Russ Housley Cc: "spasm@ietf.org" , "draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org" , IETF References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <3D85A45C-FE94-45A7-BF37-C3F8C1B3F5AA@vigilsec.com> <869BCE27-2AB5-4550-AC89-335BFE749123@vpnc.org> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <790efc1b-12ee-d960-c4cd-c7e44b5b7ccf@cs.tcd.ie> Date: Wed, 2 Jan 2019 21:19:43 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vNjRArCwaEODfQqfBFxpjRTYAmJfaxrVS" Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 02 Jan 2019 21:19:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vNjRArCwaEODfQqfBFxpjRTYAmJfaxrVS Content-Type: multipart/mixed; boundary="Sudiapok6u2fDTDRMyNgvVMcus9A0E29c"; protected-headers="v1" From: Stephen Farrell To: Tim Hollebeek , "Salz, Rich" , Paul Hoffman , Russ Housley Cc: "spasm@ietf.org" , "draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org" , IETF Message-ID: <790efc1b-12ee-d960-c4cd-c7e44b5b7ccf@cs.tcd.ie> Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <3D85A45C-FE94-45A7-BF37-C3F8C1B3F5AA@vigilsec.com> <869BCE27-2AB5-4550-AC89-335BFE749123@vpnc.org> In-Reply-To: --Sudiapok6u2fDTDRMyNgvVMcus9A0E29c Content-Type: multipart/mixed; boundary="------------04D8DD9D8E7D30C17887652F" Content-Language: en-GB This is a multi-part message in MIME format. --------------04D8DD9D8E7D30C17887652F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 02/01/2019 20:57, Tim Hollebeek wrote: > I'm sympathetic to perhaps adding a sentence or two, but=20 > otherwise I'm struggling to understand the risk as well. I assume Paul's pointing out that this is another form of key pinning, and other instances of pinning haven't worked out so well. > If an entity is incapable of managing and protecting a replacement root= key, > perhaps they shouldn't be in the CA business. And since, at worst, the= y > lose the ability to replace the root key, they aren't in a worse situat= ion > than they were if this capability didn't exist. IIUC Paul's concern is for the relying party, not the CA. Compared to RPs who do not support this extension, RPs who do support this extension may have a harder time with a CA that mucks up pinning, e.g. because the CA's HSM vendor has gone out of business or something. I'm not sure how big a deal that is really but it seems like a fine LC comment worthy of resolution to me. Having just read the draft (for the 1st time), I think it ought say (by inclusion or reference) how RPs could handle bad pins, given that there are a small set of trust store distributors (browsers, debian etc.) who aren't quite sync'd up. Cheers, S. >=20 > -Tim >=20 >> -----Original Message----- >> From: Spasm On Behalf Of Salz, Rich >> Sent: Wednesday, January 2, 2019 3:32 PM >> To: Paul Hoffman ; Russ Housley >> >> Cc: spasm@ietf.org; draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.o= rg; > IETF >> >> Subject: Re: [lamps] Last Call: > > 02.txt> (Hash Of Root Key Certificate Extension) to Informational RFC >> >> I don't understand what the risk is. >> >> If a client sees and understands the extension, it can update its trus= t > store to >> have the new key. If a client does not see, or does not understand, t= he >> extension, then the trust store will have to be updated out of band, j= ust > like it >> is now. >> >> CA's that use this extension must take proper care to ensure that the > private >> key is not exposed. >> >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm --------------04D8DD9D8E7D30C17887652F Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------04D8DD9D8E7D30C17887652F-- --Sudiapok6u2fDTDRMyNgvVMcus9A0E29c-- --vNjRArCwaEODfQqfBFxpjRTYAmJfaxrVS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlwtKu8ACgkQWrL68XsX K+r5+g//csyvDF8o83Jrkn+OTiNYx/dUzRJQAgUDMg2padvH/DXjcld4CUwqTX2p 2u+0QJEVWLKiDlpX2zNQoKBR0QfOZ5r15+NsFyaivthRHkHhufnmLd/gwzxzZqfP yYCXBrZEtV0RvQCfIiDroFGbU/cbuqNEpc59+ZzC05V/UHuXwKUyIqt/0Ql+TbPl wQoIRN1w/FvSZp6AeSxxtBQryxO0Hxzavt2JehJzQyBhIzdX+rkv95i7jgiYdIms 3bEdCit77gM3xinlOdGJ2C8nx3XInOFUDAwYIqs3ueDyAaEzq+kE1NDzO8AZJwc/ FGm9XU81aAqifwJ/2QzcmsN4nopWkwffwf7vLAcjuBhIVBD0BD9d7jiGWE7snlu6 SJsje+zzEO6RmIMgmLRepMovtdTCvGTIfNUlvuJPwwvUREZvxLZsQZScJWyCfe6g Rb0a9cg3UMuYWGjnZ91TqhWidE+FmaaBq7uIo0VsIiPX921LHGEwoTBMB/Bg8OLM cD8OoWM4Yv4xAg1ddFwO2D3oILZEBY9IG/K1aeXnnA7g+0rX7hPUUluUtcQwt3YL Sn2RVO5NhsCgZuxhPySU8s/GRzwVwNccK5q7zbInyKi7C1l6UzVurtQh13n6ZeRg hHzMx0i026HdG9P2A0ATtOcYtutsm62lg37Hx/3GI27BBGLA7fw= =Oedp -----END PGP SIGNATURE----- --vNjRArCwaEODfQqfBFxpjRTYAmJfaxrVS-- From nobody Wed Jan 2 13:27:40 2019 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 B76B61274D0; Wed, 2 Jan 2019 13:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOdJ_asCxnSS; Wed, 2 Jan 2019 13:27:28 -0800 (PST) Received: from mail1.bemta23.messagelabs.com (mail1.bemta23.messagelabs.com [67.219.246.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 51BB7126C01; Wed, 2 Jan 2019 13:27:28 -0800 (PST) Received: from [67.219.246.100] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-b.us-east-1.aws.symcld.net id BF/0E-10856-EBC2D2C5; Wed, 02 Jan 2019 21:27:26 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTfUwTZxzHefpcryeh7iwVfjY4Q2fM0nFdi4Z 0RhJNTNY/BtPEl2S86JWebZdSsHdEdEtmMGNC1ZABYbIC1SCNlcVgmCxGNBYngpFkEFCQTFBU XiSA4JCZFHu9+vbf53m+3999v8+T5yisKlFoKK5Y4Nwu1qklYwn7l6mpzLUUJttwbybBVN8Wx KbJ8UGF6WlLA2EaurggNy23lhGm+oE8U037gGKrwlx504fNf3j6SXNj45LMHBhekJvnf+/HO+ TfyR0uS0Hxfrn9t6VxsnBxZ3Go4zk6is59U45iKYI+gWGhaVkmLlR0hQx+fnEdSYt/EYzMzRL laAVF0gYYaO+Uiaym6xBcDx0UTZhuRnCpqV0hCvF0FYLyG+tFQU1XIzh+oSU6kQWnfP1hpsKB 6+GkVxC3lXQODC92yaU0Lwb/3UdYFFbQ6TA0MxKZRXQCLHY3RxjTiTA01hBhoNUw+s8dUuLVM PE4JJf82VA3HyTFLKCTYfBPRrKshd4GT+RkQN8j4Yz/jFwSGJitrsYSZ0DVMw8pmR4gmArdj4 bpoHywImpywi8dVwmJpzDU9KklToKu/71YGvaQ0PLKHxlQ0VaoCgSjTT+FwMnR6PCYDAJNGRV IV/vB4Woj1+pDMFs2iWoj17QKuk6PEZJJB40lywqJ10HbtBfXIkWYt0CrVdpNhirPaNSRBqU9 c6QPUQGUZnE7bHYhn3U4GaPBwBiNqYyBSd34lZ49wlj0RTzDsbzAGPXsIV7PH87Pc1r1Lk64h MLv0VoYM/MX8p21BdEaSqZdrQx0p2SrVloKrIftLG/f5y5ycnwQJVGUFpSVOiZbtcrN2bjiAw 5n+FG/lYGK06qVPV+EZSVfyObzDpskdSOG6ix76cUqwlXg4jSJygTRRIsme5Hr3Sfe/hq9aK0 mXoliYmJUcYWcO98hfKxPokQKaeOVD8QmcQ6X8C5pMlxCFi6xCVLEEgL7XtIcRe4NLXmPJnCn 8VRb7lLRhbyHtm3L8X9XekLn03cc+OzpD/PqvcN9m5NubnBNv/pxZOXXx+4L3t2fZHasu3qwL 3f7ts1M7K6GLQw1k3M7x4wyHa+T95zfU3+R9+Oh2bQrv7Z56r7PKP2vyXkl/fKA5dvL41m39i 6VPnnx+U/4tClYstWv0RK8nTXqsJtn3wB+YG14FQQAAA== X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-39.tower-384.messagelabs.com!1546464445!4474753!1 X-Originating-IP: [104.47.50.50] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.14.24; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29410 invoked from network); 2 Jan 2019 21:27:26 -0000 Received: from mail-by2nam05lp2050.outbound.protection.outlook.com (HELO NAM05-BY2-obe.outbound.protection.outlook.com) (104.47.50.50) by server-39.tower-384.messagelabs.com with AES256-SHA256 encrypted SMTP; 2 Jan 2019 21:27:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0s/afXDoWaJcKgTlfg6yayxuA1cM6iB53PELLGLOyF4=; b=qq6WNvVA7YbdziMO8W17+GHtEe90bOD8bxy3msqIzB7RpgBHza3QYYfC8fzmvtfg9q33gXb04wBs1yGe066DYhqyCjLOJ7YjgExUOl8mYxD+BHABT4JvR1TqUOQoT216yuqjvJNVq5MEnfrH9gms3RcZqjejLIEKQwb6D/1ANpg= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1491.namprd14.prod.outlook.com (10.172.151.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1471.20; Wed, 2 Jan 2019 21:27:23 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::60f0:c4cd:7c30:59c4]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::60f0:c4cd:7c30:59c4%2]) with mapi id 15.20.1471.019; Wed, 2 Jan 2019 21:27:23 +0000 From: Tim Hollebeek To: Stephen Farrell , "Salz, Rich" , Paul Hoffman , Russ Housley CC: "spasm@ietf.org" , "draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org" , IETF Thread-Topic: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC Thread-Index: AQHUnjFsG1mFhr8NEEGYNgqXXTDizqWcVNuAgAAZcQCAAAWZAIAABD8AgAAGM7CAAAcHgIAAAQDw Date: Wed, 2 Jan 2019 21:27:23 +0000 Message-ID: References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <3D85A45C-FE94-45A7-BF37-C3F8C1B3F5AA@vigilsec.com> <869BCE27-2AB5-4550-AC89-335BFE749123@vpnc.org> <790efc1b-12ee-d960-c4cd-c7e44b5b7ccf@cs.tcd.ie> In-Reply-To: <790efc1b-12ee-d960-c4cd-c7e44b5b7ccf@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [98.111.253.32] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1491; 6:taXZdMyqpfL0cVS7VD1YNiuPAyWU5/NaCBM7PwV5ESMfKOiS2Og3l285DqE7c2E/vBz11End24xguvXKv4OSUYKfEWsvocf3Ahn9StW30Poxdo1F/dLYyuymmdiknBHMe5SpaSFKIqKR5WDO7Z0Vn26J6mwrzj2DEYNjJOaGDSdOfSM8gLvAn4/yBIDWq/HkVhg4Tr00lyAw/8gLwh5nzak0kojxZYOThxgJ1grcUUjhexa9V/QsBhgR1C9iAXt+VpJP0qIU72cRS4QH0wDxM5ogTLoQEbjQOodjJau6/Qfmxtjh3VfEY9j2KgNGUzSv6yhY5CE9QmqQR/sCXApzRogR9BrNmbXlHEe5L2AMGCvtjkiG+GE+d8KrobtVU6vPFwGAwiRXfzPyBpCvo+oLsPttL5RtK+/m6TDqKNN7SZmzEu7V0tKWUCpwr3pvVXlKcpKr19VjPE5LEUl12jjLCA==; 5:n/rjHG2bK3S6hslHqkDpWQPZrvloX+HiZKlH6m7AzlsOjUpLwKxwjX6aqYOjXWsuWh26LYj/uPTORyPENG4sGQp93CymIYnavlM9+Q6QFaDrTJ9L7TfwGJlduhipDjW975Py/Z2LlDiUEvoYTNRNSz86viQC/G67wtr5NjyP2TA=; 7:3mmrUx2HtgkPkpSTiQ6fe7VODtbvsXe4WLYPiqydiOyiAPNdm9NATRxD5czqMb7HHymvb6HH9Flb63gw3XIP84hz+oqSdOdEhWTwF1xwyR+mopacTvv3iJqTRHng1f4Lo2F4yd4Y2+d4g3hSb02r7w== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 47bb4542-2642-485e-b58c-08d670f915c5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1491; x-ms-traffictypediagnostic: BN6PR14MB1491: x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(3230021)(908002)(999002)(5005026)(102415395)(6040522)(8220060)(2401047)(8121501046)(93006095)(93001095)(3231475)(944501520)(4983020)(52105112)(3002001)(10201501046)(6041310)(20161123562045)(20161123564045)(201703131423095)(201703031522075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:BN6PR14MB1491; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1491; x-forefront-prvs: 0905A6B2C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(346002)(136003)(396003)(376002)(13464003)(199004)(189003)(2906002)(476003)(71190400001)(74316002)(446003)(81166006)(33656002)(54906003)(71200400001)(55016002)(26005)(6246003)(296002)(478600001)(81156014)(3846002)(110136005)(316002)(186003)(6116002)(53936002)(7736002)(8676002)(97736004)(93886005)(8936002)(9686003)(305945005)(11346002)(256004)(14444005)(86362001)(229853002)(76176011)(66066001)(25786009)(102836004)(4326008)(966005)(7696005)(68736007)(14454004)(105586002)(486006)(6506007)(99286004)(106356001)(5660300001)(6436002)(53546011)(99936001)(44832011)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1491; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: zK+Pxvm/fTenG8nywSlO3xMOqglP/5AcUiViYwBA+iR8u+OisNFrj3dhs3cqs8mLynbS/3bkDE+9e7Tsjoh+8nsRKVmuPypQRqVlaTf4qCSEUvINeXi0CVPhwB/yufzWlwmmGCQTW0iyxEle5pxL2EvYrMJZVtiETxAalswOba8QbBuTg0bPgh2htJKKN0Gn95sDIygDaCRqwyIIBl0wQyx5ja5QC50nuiN17eLRGly4US+Q+svmOHYK1EYRyhqy9Vm0iGJlJynx01hBPSu6tO0GQfc9Ezg7e5RsLv3QCqV31u12tyMHVZoU/qXgP5Qh spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_00B4_01D4A2B8.010C6A20" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 47bb4542-2642-485e-b58c-08d670f915c5 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2019 21:27:23.2588 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1491 Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 02 Jan 2019 21:27:32 -0000 ------=_NextPart_000_00B4_01D4A2B8.010C6A20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit I'm not sure the comparison with pins is that useful, because existing pins generally work out badly because they prevent changing keys, while this mechanism provides the opportunity to change a key, where no such opportunity otherwise exists. If anything, this makes roots of trust _less_ like pinned keys, and in a good way. But I agree that even if this is a minor issue, perhaps a few sentences noting it is appropriate. Just to help out anyone who might not have thought about it. -Tim > -----Original Message----- > From: Stephen Farrell > Sent: Wednesday, January 2, 2019 4:20 PM > To: Tim Hollebeek ; Salz, Rich > ; Paul Hoffman ; Russ > Housley > Cc: spasm@ietf.org; draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org; > IETF > Subject: Re: [lamps] Last Call: > 02.txt> (Hash Of Root Key Certificate Extension) to Informational RFC > > > Hiya, > > On 02/01/2019 20:57, Tim Hollebeek wrote: > > I'm sympathetic to perhaps adding a sentence or two, but otherwise I'm > > struggling to understand the risk as well. > > I assume Paul's pointing out that this is another form of key pinning, and > other instances of pinning haven't worked out so well. > > > If an entity is incapable of managing and protecting a replacement > > root key, perhaps they shouldn't be in the CA business. And since, at > > worst, they lose the ability to replace the root key, they aren't in a > > worse situation than they were if this capability didn't exist. > > IIUC Paul's concern is for the relying party, not the CA. > > Compared to RPs who do not support this extension, RPs who do support this > extension may have a harder time with a CA that mucks up pinning, e.g. > because the CA's HSM vendor has gone out of business or something. > > I'm not sure how big a deal that is really but it seems like a fine LC > comment > worthy of resolution to me. > > Having just read the draft (for the 1st time), I think it ought say (by > inclusion > or reference) how RPs could handle bad pins, given that there are a small > set > of trust store distributors (browsers, debian etc.) who aren't quite sync'd > up. > > Cheers, > S. > > > > > > -Tim > > > >> -----Original Message----- > >> From: Spasm On Behalf Of Salz, Rich > >> Sent: Wednesday, January 2, 2019 3:32 PM > >> To: Paul Hoffman ; Russ Housley > >> > >> Cc: spasm@ietf.org; > >> draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org; > > IETF > >> > >> Subject: Re: [lamps] Last Call: > > >> 02.txt> (Hash Of Root Key Certificate Extension) to Informational RFC > >> > >> I don't understand what the risk is. > >> > >> If a client sees and understands the extension, it can update its > >> trust > > store to > >> have the new key. If a client does not see, or does not understand, > >> the extension, then the trust store will have to be updated out of > >> band, just > > like it > >> is now. > >> > >> CA's that use this extension must take proper care to ensure that the > > private > >> key is not exposed. > >> > >> > >> _______________________________________________ > >> Spasm mailing list > >> Spasm@ietf.org > >> https://www.ietf.org/mailman/listinfo/spasm ------=_NextPart_000_00B4_01D4A2B8.010C6A20 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 CQUxDxcNMTkwMTAyMjEyNzA3WjAvBgkqhkiG9w0BCQQxIgQghLZEqB5SrmvrzZ88QGTUm0fs33w8 MYKpemFkIljPwZcwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBABKKTvpEu+A0uddj4OjYVU1ElnDFkXAqxBXB8NkQuJIhV8lI0SazTeaWU9MiTl7ZcnhfPTE9 zk2wBxCVsGqGfSku+KMxHTigKeBcf6TBfQ9ijZVvcaIYfd24IYkqf3nf/YIoN80Bde5ieMfo4aG+ NOc+2gpOXR2Y6oniNU8iBiKM4GPljPfMM3rTWXBE9DHrGVXTgftlZkH52nAHsjMyKGJFsi5f8CQS uAStIY8b1VHeSuCo+OFN1Nk5irWwZsRnKNfP+Awi2f/FQuUubr5qbtNhSL+dmf0U1my4SLkl2LGU keXHXle289Lr77SsWfUfEwVNguvLVyEeFEC31k1JB8UAAAAAAAA= ------=_NextPart_000_00B4_01D4A2B8.010C6A20-- From nobody Wed Jan 2 14:04:57 2019 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 00BC712D4E9 for ; Wed, 2 Jan 2019 14:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJmGuAvAVyCg for ; Wed, 2 Jan 2019 14:04:52 -0800 (PST) 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 5E93B12D4E7 for ; Wed, 2 Jan 2019 14:04:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9E083300A55 for ; Wed, 2 Jan 2019 16:46:34 -0500 (EST) 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 8EHBG3G2hV4j for ; Wed, 2 Jan 2019 16:46:32 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id D56173001FD; Wed, 2 Jan 2019 16:46:31 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: <869BCE27-2AB5-4550-AC89-335BFE749123@vpnc.org> Date: Wed, 2 Jan 2019 17:04:48 -0500 Cc: IETF , draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org, SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <921BDA50-166B-4BDA-B587-E5ABF95BE1E0@vigilsec.com> References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <3D85A45C-FE94-45A7-BF37-C3F8C1B3F5AA@vigilsec.com> <869BCE27-2AB5-4550-AC89-335BFE749123@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 02 Jan 2019 22:04:55 -0000 Paul: >>> This extension seems useful to CAs that understand the increased = risks that using it incurs, but those risks are not mentioned in the = document. >>>=20 >>> The document implicitly assumes that the CA will in fact use the key = named in the extension next. Using this extension increases the risk of = a bad trust anchor rollover at the same time that it makes good rollover = more secure. If the key listed in this extension cannot be used when the = CA eventually changes the trust anchor, relying parties will mistrust = the new trust anchor. There are many reasons why a CA might think they = know the next key but cannot use that key when they change trust = anchors, such as if the HSM that holds the next key fails or is = destroyed. Given the last sentence in Section 2, this could mean that a = CA might never be able to issue a new trust anchor, even if the key for = its current trust anchor is compromised. >>>=20 >>> Given the severity of the new risks of using this extension, they = need to be introduced at the beginning of the document and then = discussed in more detail in the Security Considerations. Note that this = risk affects the last paragraph of the Security Considerations section = as well. >>=20 >> The point is to facilitate the transition from one Root CA = certificate to the next. >=20 > To be clear, the transition is from one public key to the next, not = from one certificate to the next. But, more importantly, the point of = this extension is to facilitate the transition from one Root CA = certificate to what is supposed to be the next key. However, if that = next key is not seen by every relying party during the transition, the = extension prevents the CA from ever making the transition for the = relying parties that do not see the new key in a revised trust anchor. This is not correct. The public key in the next self-signed certificate = is identified by the hash of the public key that will appear in the = subsequent certificate. At the time of the actual transition, the = recipient has the original self-signed certificate and the subsequent = one. Thus, the recipient has both in hand. All replying parties will not see the subsequent self-signed certificate = at the same time, but that is not a concern, The old-in-new and = new-in-old technique described in RFC 2510 (and referenced in Section 5) = keeps all subordinate certificates valid until they expire. > This seems like a huge restriction that is only mentioned in the = document in exactly one sentence: I think that the Abstract as reworded is pretty clear. I will make a similar adjustment to the Introduction. >> The last sentence in Section 2 says: >>=20 >> If either check fails, then potential Root CA >> certificate is not a valid replacement, and the recipient continues >> to use the current Root CA certificate. >>=20 >> Indeed, these check are necessary to make sure that the relying party = makes the transition to the proper replacement. Any failure of the = checks leave the trust anchor unchanged, which seems like the right = result to me. >=20 > It seems right to me as well, but it still seems to be wholly = insufficient to not talk about the risks of using the extension early in = the document. >=20 >> Recall the definition of trust anchor from RFC 5280, Section 6.1.1: >>=20 >> (d) trust anchor information, describing a CA that serves as a >> trust anchor for the certification path. The trust anchor >> information includes: >>=20 >> (1) the trusted issuer name, >>=20 >> (2) the trusted public key algorithm, >>=20 >> (3) the trusted public key, and >>=20 >> (4) optionally, the trusted public key parameters associated >> with the public key. >>=20 >> The checks make sure that the replacement self-signed certificate = contains the intended information. >=20 > That is all fine, but it does not address the significant risk a CA is = undertaking by promising what the next key will be. That is not a significant risk. In fact, the LAMPS WG had a fairly = lengthy discussion on that point at IETF 101. The conclusion from that = discussion is summarized in the Security Considerations. That is, if = the Root CA decides that the committed public key is no longer the = desire destination, then two transition done fairly quickly can sort it = out. I observe that standing up a new Root CA from scratch would likely be = harder than two quick transitions. >>> Editorial: >>>=20 >>> The abstract says: >>> This document specifies the Hash Of Root Key certificate extension. >>> This certificate extension is carried in the self-signed = certificate >>> for a trust anchor, which is often called a Root Certification >>> Authority (CA) certificate. This certificate extension = unambiguously >>> identifies the next public key that will be used by the trust = anchor >>> at some point in the future. >>> The term "trust anchor" is used as the concept, not the bits in the = certificate. As such, the last sentence is confusing because the trust = anchor will change when the key changes. A possible fix is to replace = "will be used by the trust anchor at some point in the future" with = "will be used in a trust anchor at some point in the future". >>=20 >> I think I understand your point. Does this text resolve the concern? >>=20 >> This document specifies the Hash Of Root Key certificate extension. >> This certificate extension is carried in the self-signed = certificate >> for a trust anchor, which is often called a Root Certification >> Authority (CA) certificate. This certificate extension = unambiguously >> identifies the next public key that will be used at some point in = the >> future as the next Root CA certificate, replacing the current one. >=20 > Not really. A key will not be used as a certificate: it is just a key. = A key might be used as the signing key for a certificate, but not as the = certificate itself. Maybe instead: "will be used to sign a trust anchor = at some point in the future"? The public key is identified by the hash value. The public key that = matches the hash value will appear in a self-signed certificate in the = future. All four of the components of the trust anchor (listed above) = that are replaced, not just the public key. Russ From nobody Thu Jan 3 07:28:19 2019 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 6B922130DED for ; Thu, 3 Jan 2019 07:28:17 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 JPMuRat8HuSn for ; Thu, 3 Jan 2019 07:28:15 -0800 (PST) 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 28B29130E3E for ; Thu, 3 Jan 2019 07:28:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 75ED9300A4E for ; Thu, 3 Jan 2019 10:09:57 -0500 (EST) 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 Ndsv64TLt143 for ; Thu, 3 Jan 2019 10:09:55 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id E4D873002C1; Thu, 3 Jan 2019 10:09:54 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: <869BCE27-2AB5-4550-AC89-335BFE749123@vpnc.org> Date: Thu, 3 Jan 2019 10:28:11 -0500 Cc: IETF , draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8D8915DD-E57E-44B1-9B5C-1AF9E631F335@vigilsec.com> References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <3D85A45C-FE94-45A7-BF37-C3F8C1B3F5AA@vigilsec.com> <869BCE27-2AB5-4550-AC89-335BFE749123@vpnc.org> To: SPASM X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 03 Jan 2019 15:28:18 -0000 I had a voice conversation with Paul Hoffman, and I think that I now = understand the things that he would like to see added to the document. = Essentially, the Hash Of Root Key certificate extension is a commitment = to the next generation public key and algorithm. Recall that the hash = covers the SubjectPublicKeyInfo, which is: SubjectPublicKeyInfo ::=3D SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } So, a few things can go wrong after making this commitment. (Stephen = called it pinning.) The Root CA needs to choose a next generation = public key and algorithm that will be secure for the full lifetime. Of = course, a cryptoanalytic break through is very difficult to predict, and = if one happens before the new key is used, the Root CA remains committed = to the now broken key. The remedy is to deploy a new public key and = algorithm in the same manner as the initial Root CA self-signed = certificate. The benefits of automatic detection of the new public key = are lost, but that is a minor concern is the scope of a cryptoanalytic = break through. In addition, from an operational perspective, the Root CA must securely = back up the yet-to-be-deployed key pair. If the Root CA stores it in a = hardware security module, and that module fails, the Root CA remains = committed to the now unavailable key. The remedy is the same as above: = deploy a new public key in the same manner as the initial Root CA = self-signed certificate. Russ > On Jan 2, 2019, at 3:17 PM, Paul Hoffman = wrote: >=20 > On 2 Jan 2019, at 11:57, Russ Housley wrote: >=20 >>> On Jan 2, 2019, at 1:26 PM, Paul Hoffman = wrote: >>>=20 >>> This extension seems useful to CAs that understand the increased = risks that using it incurs, but those risks are not mentioned in the = document. >>>=20 >>> The document implicitly assumes that the CA will in fact use the key = named in the extension next. Using this extension increases the risk of = a bad trust anchor rollover at the same time that it makes good rollover = more secure. If the key listed in this extension cannot be used when the = CA eventually changes the trust anchor, relying parties will mistrust = the new trust anchor. There are many reasons why a CA might think they = know the next key but cannot use that key when they change trust = anchors, such as if the HSM that holds the next key fails or is = destroyed. Given the last sentence in Section 2, this could mean that a = CA might never be able to issue a new trust anchor, even if the key for = its current trust anchor is compromised. >>>=20 >>> Given the severity of the new risks of using this extension, they = need to be introduced at the beginning of the document and then = discussed in more detail in the Security Considerations. Note that this = risk affects the last paragraph of the Security Considerations section = as well. >>=20 >> The point is to facilitate the transition from one Root CA = certificate to the next. >=20 > To be clear, the transition is from one public key to the next, not = from one certificate to the next. But, more importantly, the point of = this extension is to facilitate the transition from one Root CA = certificate to what is supposed to be the next key. However, if that = next key is not seen by every relying party during the transition, the = extension prevents the CA from ever making the transition for the = relying parties that do not see the new key in a revised trust anchor. = This seems like a huge restriction that is only mentioned in the = document in exactly one sentence: >=20 >> The last sentence in Section 2 says: >>=20 >> If either check fails, then potential Root CA >> certificate is not a valid replacement, and the recipient continues >> to use the current Root CA certificate. >>=20 >> Indeed, these check are necessary to make sure that the relying party = makes the transition to the proper replacement. Any failure of the = checks leave the trust anchor unchanged, which seems like the right = result to me. >=20 > It seems right to me as well, but it still seems to be wholly = insufficient to not talk about the risks of using the extension early in = the document. >=20 >>=20 >> Recall the definition of trust anchor from RFC 5280, Section 6.1.1: >>=20 >> (d) trust anchor information, describing a CA that serves as a >> trust anchor for the certification path. The trust anchor >> information includes: >>=20 >> (1) the trusted issuer name, >>=20 >> (2) the trusted public key algorithm, >>=20 >> (3) the trusted public key, and >>=20 >> (4) optionally, the trusted public key parameters associated >> with the public key. >>=20 >> The checks make sure that the replacement self-signed certificate = contains the intended information. >=20 > That is all fine, but it does not address the significant risk a CA is = undertaking by promising what the next key will be. >=20 >>> Editorial: >>>=20 >>> The abstract says: >>> This document specifies the Hash Of Root Key certificate extension. >>> This certificate extension is carried in the self-signed = certificate >>> for a trust anchor, which is often called a Root Certification >>> Authority (CA) certificate. This certificate extension = unambiguously >>> identifies the next public key that will be used by the trust = anchor >>> at some point in the future. >>> The term "trust anchor" is used as the concept, not the bits in the = certificate. As such, the last sentence is confusing because the trust = anchor will change when the key changes. A possible fix is to replace = "will be used by the trust anchor at some point in the future" with = "will be used in a trust anchor at some point in the future". >>=20 >> I think I understand your point. Does this text resolve the concern? >>=20 >> This document specifies the Hash Of Root Key certificate extension. >> This certificate extension is carried in the self-signed = certificate >> for a trust anchor, which is often called a Root Certification >> Authority (CA) certificate. This certificate extension = unambiguously >> identifies the next public key that will be used at some point in = the >> future as the next Root CA certificate, replacing the current one. >=20 > Not really. A key will not be used as a certificate: it is just a key. = A key might be used as the signing key for a certificate, but not as the = certificate itself. Maybe instead: "will be used to sign a trust anchor = at some point in the future"? >=20 >>> The first list in Section 2 would be clearer if the order was R1, = R2, H2, C1; this would also then match the order in the second list. >>=20 >> Okay. I changed that in my edit buffer. >>=20 >>> Later in Section 2, a sentence appears to be missing its subject. = "That is, verify the signature on the self-signed certificate..." should = probably be "That is, the recipient verifies the signature on the = self-signed certificate...". >>=20 >> Okay. I changed that in my edit buffer. >>=20 >> In addition, I added a bit more detail about the relationship to = certification path validation, which I hope adds clarity around your = first comment. It now reads: >>=20 >> The successor to the Root CA self-signed certificate can be >> delivered by any means. Whenever a new Root CA certificate is >> received, the recipient is able to verify that the potential Root = CA >> certificate links back to a previously authenticated Root CA >> certificate with the hashOfRootKey certificate extension. That is, >> the recipient verifies the signature on the self-signed certificate >> and verifies that the hash of the DER-encoded SubjectPublicKeyInfo >> from the potential Root CA certificate matches the value from the >> HashOfRootKey certificate extension of the current Root CA >> certificate. Checking the self-signed certificate signature = ensures >> that the certificate contains the subject name, public key = algorithm >> identifier, and public key algorithm parameters intended by the key >> owner intends; these are important inputs to certification path >> validation as defined in Section 6 of [RFC5280]. Checking the hash >> of the SubjectPublicKeyInfo ensures that the certificate contains = the >> intended public key. If either check fails, then potential Root CA >> certificate is not a valid replacement, and the recipient continues >> to use the current Root CA certificate. >=20 > Yes, adding this clarifies how all the trust anchor information is = linked through the validation process. This is a good addition. >=20 > --Paul Hoffman From nobody Thu Jan 3 08:27:41 2019 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 4FAAF13112E; Thu, 3 Jan 2019 08:27:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <154653285929.29641.1740557360800703044@ietfa.amsl.com> Date: Thu, 03 Jan 2019 08:27:39 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-hash-of-root-key-cert-extn-03.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: Thu, 03 Jan 2019 16:27:39 -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 : Hash Of Root Key Certificate Extension Author : Russ Housley Filename : draft-ietf-lamps-hash-of-root-key-cert-extn-03.txt Pages : 9 Date : 2019-01-03 Abstract: This document specifies the Hash Of Root Key certificate extension. This certificate extension is carried in the self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate. This certificate extension unambiguously identifies the next public key that will be used at some point in the future as the next Root CA certificate, replacing the current one. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-extn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-hash-of-root-key-cert-extn-03 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-hash-of-root-key-cert-extn-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-hash-of-root-key-cert-extn-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 3 08:28:59 2019 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 C295F13113D for ; Thu, 3 Jan 2019 08:28:57 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enn1QZ9Jwm_a for ; Thu, 3 Jan 2019 08:28:55 -0800 (PST) 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 DBEA513113A for ; Thu, 3 Jan 2019 08:28:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 43B29300464 for ; Thu, 3 Jan 2019 11:10:35 -0500 (EST) 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 iLzsLtxS81x7 for ; Thu, 3 Jan 2019 11:10:34 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 23F763002B3 for ; Thu, 3 Jan 2019 11:10:34 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 3 Jan 2019 11:28:50 -0500 References: <154653285929.29641.1740557360800703044@ietfa.amsl.com> To: SPASM In-Reply-To: <154653285929.29641.1740557360800703044@ietfa.amsl.com> Message-Id: <52B49DC9-E9E8-48C8-8A9B-FBDBD4BB0058@vigilsec.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-hash-of-root-key-cert-extn-03.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: Thu, 03 Jan 2019 16:28:58 -0000 This version addresses the IETF Last Call comments from Paul Hoffman. Russ > On Jan 3, 2019, at 11:27 AM, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : Hash Of Root Key Certificate Extension > Author : Russ Housley > Filename : = draft-ietf-lamps-hash-of-root-key-cert-extn-03.txt > Pages : 9 > Date : 2019-01-03 >=20 > Abstract: > This document specifies the Hash Of Root Key certificate extension. > This certificate extension is carried in the self-signed certificate > for a trust anchor, which is often called a Root Certification > Authority (CA) certificate. This certificate extension = unambiguously > identifies the next public key that will be used at some point in = the > future as the next Root CA certificate, replacing the current one. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-ex= tn/ >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-lamps-hash-of-root-key-cert-extn-03= > = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-hash-of-root-key-ce= rt-extn-03 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-hash-of-root-key-cert= -extn-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 3 09:30:39 2019 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 B2EA61311B9 for ; Thu, 3 Jan 2019 09:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHw_o8SofvHr for ; Thu, 3 Jan 2019 09:30:36 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 B81AB1311BE for ; Thu, 3 Jan 2019 09:30:35 -0800 (PST) Received: from [10.32.60.60] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id x03HTLGu038625 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Jan 2019 10:29:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.60] From: "Paul Hoffman" To: "Russ Housley" Cc: SPASM Date: Thu, 03 Jan 2019 09:30:32 -0800 X-Mailer: MailMate (1.12.3r5579) Message-ID: In-Reply-To: <52B49DC9-E9E8-48C8-8A9B-FBDBD4BB0058@vigilsec.com> References: <154653285929.29641.1740557360800703044@ietfa.amsl.com> <52B49DC9-E9E8-48C8-8A9B-FBDBD4BB0058@vigilsec.com> MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-hash-of-root-key-cert-extn-03.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: Thu, 03 Jan 2019 17:30:38 -0000 On 3 Jan 2019, at 8:28, Russ Housley wrote: > This version addresses the IETF Last Call comments from Paul Hoffman. It does indeed. Thanks! --Paul Hoffman From nobody Thu Jan 3 09:33:19 2019 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 3BD811311BE; Thu, 3 Jan 2019 09:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lnx8N6wZXDwm; Thu, 3 Jan 2019 09:33:09 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 E53D113113C; Thu, 3 Jan 2019 09:33:08 -0800 (PST) Received: from [10.32.60.60] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id x03HVt4T038871 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Jan 2019 10:31:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.60] From: "Paul Hoffman" To: IETF Cc: SPASM , draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org Date: Thu, 03 Jan 2019 09:33:06 -0800 X-Mailer: MailMate (1.12.3r5579) Message-ID: In-Reply-To: <8D8915DD-E57E-44B1-9B5C-1AF9E631F335@vigilsec.com> References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <3D85A45C-FE94-45A7-BF37-C3F8C1B3F5AA@vigilsec.com> <869BCE27-2AB5-4550-AC89-335BFE749123@vpnc.org> <8D8915DD-E57E-44B1-9B5C-1AF9E631F335@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 03 Jan 2019 17:33:10 -0000 On 3 Jan 2019, at 7:28, Russ Housley wrote: > I had a voice conversation with Paul Hoffman, and I think that I now > understand the things that he would like to see added to the document. > Essentially, the Hash Of Root Key certificate extension is a > commitment to the next generation public key and algorithm. Recall > that the hash covers the SubjectPublicKeyInfo, which is: > > SubjectPublicKeyInfo ::= SEQUENCE { > algorithm AlgorithmIdentifier, > subjectPublicKey BIT STRING } > > So, a few things can go wrong after making this commitment. (Stephen > called it pinning.) The Root CA needs to choose a next generation > public key and algorithm that will be secure for the full lifetime. > Of course, a cryptoanalytic break through is very difficult to > predict, and if one happens before the new key is used, the Root CA > remains committed to the now broken key. The remedy is to deploy a > new public key and algorithm in the same manner as the initial Root CA > self-signed certificate. The benefits of automatic detection of the > new public key are lost, but that is a minor concern is the scope of a > cryptoanalytic break through. > > In addition, from an operational perspective, the Root CA must > securely back up the yet-to-be-deployed key pair. If the Root CA > stores it in a hardware security module, and that module fails, the > Root CA remains committed to the now unavailable key. The remedy is > the same as above: deploy a new public key in the same manner as the > initial Root CA self-signed certificate. Russ has issued an -03 that adds text about the commitment that comes with using this extension. That alleviates my concern about a CA not realizing that there is a risk in adding the extension to trust anchor certificates. --Paul Hoffman From nobody Thu Jan 3 11:18:14 2019 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 29E461312B2 for ; Thu, 3 Jan 2019 11:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIEnNg4yF5PG for ; Thu, 3 Jan 2019 11:18:07 -0800 (PST) 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 54DF41312B9 for ; Thu, 3 Jan 2019 11:18:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A1F1E300A42 for ; Thu, 3 Jan 2019 13:59:49 -0500 (EST) 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 Oi0Z6Y-AWAwl for ; Thu, 3 Jan 2019 13:59:48 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 576B63001CB for ; Thu, 3 Jan 2019 13:59:48 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 3 Jan 2019 14:18:04 -0500 References: <87bm5hxdn0.fsf@fifthhorseman.net> To: LAMPS WG In-Reply-To: <87bm5hxdn0.fsf@fifthhorseman.net> Message-Id: <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [lamps] Draft addition of header protection to the LAMPS charter 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, 03 Jan 2019 19:18:13 -0000 At the LAMPS session in Bangkok, there was interest in adding a header protection work item to the charter. Alexey talked about this in Montreal, and he posted a draft a few weeks ago: draft-melnikov-lamps-header-protection. Several people said that they would implement a solution if the LAMPS WG produced an RFC on this topic. Shortly before the holidays, DKG proposed charter text: > 7. Specify a mechanism for the cryptographic protection of e-mail > headers. Most current implementations protect only the body of the > message, which leaves significant room for attacks against > otherwise-protected messages. Cryptographic protection (both for > signatures and encryption) which applies to the headers in conjunction > with the message body are necessary to close significant security and > usability gaps in cryptographically-protected electronic mail. Does anyone have any concerns with this text? If not, we will ask the Security ADs to add this to the existing charter. Russ From nobody Thu Jan 3 11:25:54 2019 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 34DE613128B for ; Thu, 3 Jan 2019 11:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npyblAgJ2kCN for ; Thu, 3 Jan 2019 11:25:50 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE842131288 for ; Thu, 3 Jan 2019 11:25:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F19F2BE38; Thu, 3 Jan 2019 19:25:47 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uT8-gMUloDpy; Thu, 3 Jan 2019 19:25:46 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B2A2EBE2E; Thu, 3 Jan 2019 19:25:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1546543546; bh=MucKNqc4n1ick3wrygYk/Ehbq45PcTdp4f8yx1f9Omo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=z4/cdWTa5hV7yFY/jhVTol8usyaj1GqFf1Nh6e9vFRL2l3NBgnQVS+/Z3WH6eY6NL oLtF9gsWteErgpoKNK5S767zSeKI6Z6d0dGikJcMES0i3ETaUJZurxTUe2m9IufrkD k0qYy/4bygIZ+UNU4IkICJxj7Ez7uoc7BoMpsocY= To: Russ Housley , LAMPS WG References: <87bm5hxdn0.fsf@fifthhorseman.net> <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <262028c9-5474-f227-85ce-215a958ba125@cs.tcd.ie> Date: Thu, 3 Jan 2019 19:25:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ddFEttg9VnkpPaIRPYdbDlrphWrGRzXdX" Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 03 Jan 2019 19:25:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ddFEttg9VnkpPaIRPYdbDlrphWrGRzXdX Content-Type: multipart/mixed; boundary="2DlQqwK4BM5zWRhhzL31s78Z6ZqLIYXC6"; protected-headers="v1" From: Stephen Farrell To: Russ Housley , LAMPS WG Message-ID: <262028c9-5474-f227-85ce-215a958ba125@cs.tcd.ie> Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter References: <87bm5hxdn0.fsf@fifthhorseman.net> <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> In-Reply-To: <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> --2DlQqwK4BM5zWRhhzL31s78Z6ZqLIYXC6 Content-Type: multipart/mixed; boundary="------------5B976007B1822378000C82FD" Content-Language: en-GB This is a multi-part message in MIME format. --------------5B976007B1822378000C82FD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 03/01/2019 19:18, Russ Housley wrote: > Does anyone have any concerns with this text? If not, we will ask the > Security ADs to add this to the existing charter. In case it helps: I previously voiced support for this on the assumption that implementations were likely. Subsequent mails to the list convinced me that's a safe assumption. Cheers, S. --------------5B976007B1822378000C82FD Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------5B976007B1822378000C82FD-- --2DlQqwK4BM5zWRhhzL31s78Z6ZqLIYXC6-- --ddFEttg9VnkpPaIRPYdbDlrphWrGRzXdX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlwuYbgACgkQWrL68XsX K+pOng//Z0EY/cAiaKqI2pjfnX1H41+Y0hJfQ2vCeQRuVXT7tUmVP6f6FGBm2SuB bd9YDxTXXJo7RAmed60LpbCPA+DZ2NQz0yjzr2RE3o9SRs//HyB2CmQhFSIrGAR/ fGpXtAmlUcmHwJd0PmHDosAjNhpha9gG0Tphk0Dr7xhpGewwTAJ+3bfbhWy2FHPy OBF25MXhEz2n1Y2uWxWtKAN3p3WLNzcxWzGxPneG/FTnqTZmFoj81r8lYCIvaLw6 g17HsKFi2F1/5Ksgad8CjRqnxKe+NffUh8/oQQfh1X1kaCMjfka92JTvPZ7Fhb0H 8TNoa4t/WVAQGsztYoRS46DWrfagjvZ4B5unTO5E/nWG5jlwVXkG7ZB2/yNHFQk2 PkO9urEzbW95zQ+1VobFMPoUTIjW5x+8FCEvN76Z5/AD+XSvRr5E3geAvcVFi2Pq 8PT/V5D32u88Ia9CdrnLkd7O824wm12nGFGJc5WpWFBTC6T/HXNm0QWlt7rwZe7/ UxgbTy6eTjum5K4PveeFG41W69sZMjlY9aXc4Snrm30N5GWF/HrIOKsMYW5pDfBZ V0Q7Oievp/fGYqWBVwXvlgFiS9tL/3e5RsIukk3LccxFwigHXHb+E8nhcPqYIiTA X7AOnH2hNy9H0AQIt1ZNSWv7/yMZIt3U5LJuwcWREOhs8oU8l9A= =VJnu -----END PGP SIGNATURE----- --ddFEttg9VnkpPaIRPYdbDlrphWrGRzXdX-- From nobody Thu Jan 3 11:32:59 2019 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 E617F131294 for ; Thu, 3 Jan 2019 11:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 8qvhKP7jaaCK for ; Thu, 3 Jan 2019 11:32:56 -0800 (PST) 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 B3C031312A0 for ; Thu, 3 Jan 2019 11:32:56 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x03JRunh019251; Thu, 3 Jan 2019 19:32:56 GMT 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=8aK8PTBsiajfKJgVa601d1+MTP6VwDdpP3h+QOELOyI=; b=oVfndCp1HczYGNEtB8qVyA4mqltoJ2QG3e/IgJZqNjvn5WVyJAb/2y3Gomm6CHDbirl2 on2JhX9vIpqGYx3uPeeveAMf3a+AR2CQFjfhwKRt05vNfGxZbmsgEffTS5a/sEQT3NLm l82uyeo+VBMvbZs/US6any7xJVQp3B3Uzq0c4CpaYPsTVhXadsqe7J4898EFp2Pw+zVz 7IMH1v2pf1qWqRVp4fho7aF5FTBocwrdCXOJDZY6ZpKdkdZY4WoefXkIaT8LBm1UC5I3 xZoqQfg7vhy5MoTJkIK/v9Z/xB1gSonay1RxBfhGcr92Hn1iedyIiRRD20Z/CjeN4Rc4 kQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2ps5esb4jj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 Jan 2019 19:32:56 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id x03JWMXM025626; Thu, 3 Jan 2019 14:32:54 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2pp55f3037-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 03 Jan 2019 14:32:53 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 3 Jan 2019 13:32:48 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Thu, 3 Jan 2019 13:32:48 -0600 From: "Salz, Rich" To: Russ Housley , LAMPS WG Thread-Topic: [lamps] Draft addition of header protection to the LAMPS charter Thread-Index: AQHUo5kWvx146W5QP0KbogMFRFdq/KWd/8eA Date: Thu, 3 Jan 2019 19:32:47 +0000 Message-ID: <7E97D758-BC5A-4911-AC15-958D25D1A88F@akamai.com> References: <87bm5hxdn0.fsf@fifthhorseman.net> <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> In-Reply-To: <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.14.0.181208 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.68] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-03_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=937 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901030169 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-03_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=948 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901030169 Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 03 Jan 2019 19:32:58 -0000 TWlub3Igbml0LCBJIGZvdW5kIG9uZSBzZW50ZW5jZSBhIGJpdCBjb25mdXNpbmcuICBEb2VzIHRo aXMgZXhwcmVzcyB0aGUgaW50ZW50Pw0KCUNyeXB0b2dyYXBoaWMgcHJvdGVjdGlvbiwgYm90aCBz aWduYXR1cmVzIGFuZCBlbmNyeXB0aW9uLCBhcHBsaWVkIHRvIHRoZSBoZWFkZXJzIGluIGNvbmp1 bmN0aW9uIC4uLg0KDQpPciBpcyAiYm90aCIgYmV0dGVyIGFzICJzdWNoIGFzIiA/DQoNCg== From nobody Thu Jan 3 11:35:47 2019 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 116721312AD; Thu, 3 Jan 2019 11:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgczlVz-DASb; Thu, 3 Jan 2019 11:35:35 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A1FB1312A8; Thu, 3 Jan 2019 11:35:35 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id B0B98F99A; Thu, 3 Jan 2019 14:35:33 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id EF2712039A; Thu, 3 Jan 2019 14:35:28 -0500 (EST) From: Daniel Kahn Gillmor To: Paul Hoffman , ietf@ietf.org Cc: spasm@ietf.org, draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org In-Reply-To: <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> Date: Thu, 03 Jan 2019 14:35:25 -0500 Message-ID: <87va35o7pe.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 03 Jan 2019 19:35:37 -0000 --=-=-= Content-Type: text/plain On Wed 2019-01-02 10:26:05 -0800, Paul Hoffman wrote: > Using this extension increases the risk of a bad trust anchor rollover > at the same time that it makes good rollover more secure. I think this may be the root (ha ha) of confusion about the purpose of this draft, and it raises some additional concerns for me about whether it is clear and useful as it stands (i've been reading -03). This draft serves one main purpose as far as i can tell: * It provides a technical mechanism that facilitates a root authority releasing a new root certificate. This is a good purpose i can get behind, but the introduction implies that it also offers another purpose: remove the previous one from the trust anchor store. but the only detail in this draft that suggests how that is supposed to happen is in the end of the Overview: If either check fails, then [the] potential Root CA certificate is not a valid replacement, and the recipient continues to use the current Root CA certificate. The implication here is of course that if both checks succeed, then the current Root CA certificate is discarded. But that is explicitly stated nowhere in the document. Should it be? If it should, we need more text. If it does not, the draft should remove the text about "remove the previous one" and "continues to use the current Root CA certificate". Section 5 ("Operational Considerations") talks about RFC 2510 (should maybe be 4210 today, no?), and refers to oldWithNew and newWithOld. However, the final sentence of that paragraph is ambiguous: Further, this technique avoids the need for all relying parties to make the transition at the same time. Which technique? The technique in the current draft? oldWithNew? newWithOld? Both oldWithNew and newWithOld? If the sentence is talking about the two mechanisms from RFC 4210, then Operational Considerations should clarify that the current draft explicitly *does* require all relying parties (and all subscribers!) to make the transition at the same time, since the escape of C2 into the wild means that all subscribers MUST start shipping certs signed by C2, because they can't know whether their relying parties have switched from C1 to C2 yet. The safest thing is for the subscriber to force the relying party to switch to C2 by shipping C2, but of course that will screw over any other subscribe that hasn't switched yet. So i'm not convinced that we can safely say that reciept of C2 MUST (or even SHOULD) effectively revoke C1. Additionally, the two paragraphs added in -03 make it clear that the traditional new-root-cert import mechanism will remain enabled for all relying parties, subject to all the pre-existing vagaries and risks. (perhaps some other draft can tighten those up, but this draft does not do so on its own.) So, without this draft offering a strong and immediate revocation mechanism, and without it cleaning up the pre-existing new-root-cert import mechanism, it does *not* make "rollover more secure" (since all existing insecure channels will continue to exist). It just makes good rollover more convenient/automatic. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCXC5j/QAKCRBsHx7ezFD6 U+XAAP9iA8ebUeLdKYn6mYM0zsNv6ZzD3gPuIp314EXmfZ58hQD9F8khQH6Nb9SA 6u3gyEKc6VHPw3F+mUFj75ehmkYS+gA= =jhun -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 3 11:50:31 2019 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 0A2531312B0 for ; Thu, 3 Jan 2019 11:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KY0tv1aR6oH for ; Thu, 3 Jan 2019 11:50:27 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C00741312AE for ; Thu, 3 Jan 2019 11:50:27 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 7A253F99B; Thu, 3 Jan 2019 14:50:25 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 1FAAB2039A; Thu, 3 Jan 2019 14:39:16 -0500 (EST) From: Daniel Kahn Gillmor To: "Salz\, Rich" , Russ Housley , LAMPS WG In-Reply-To: <7E97D758-BC5A-4911-AC15-958D25D1A88F@akamai.com> References: <87bm5hxdn0.fsf@fifthhorseman.net> <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> <7E97D758-BC5A-4911-AC15-958D25D1A88F@akamai.com> Date: Thu, 03 Jan 2019 14:39:16 -0500 Message-ID: <87sgy9o7iz.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 03 Jan 2019 19:50:29 -0000 On Thu 2019-01-03 19:32:47 +0000, Salz, Rich wrote: > Minor nit, I found one sentence a bit confusing. Does this express the intent? > Cryptographic protection, both signatures and encryption, applied to the headers in conjunction ... > > Or is "both" better as "such as" ? I'm fine with either (or with "including"), but i prefer to say "both" because i want to stress that these are the two forms of cryptographic protection of e-mail messages that we're talking about (are there others?), and that we want to ensure that we actually do handle them both. --dkg From nobody Thu Jan 3 12:07:50 2019 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 C7DAA1312AE for ; Thu, 3 Jan 2019 12:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGvs-zGU4Dvq for ; Thu, 3 Jan 2019 12:07:46 -0800 (PST) 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 1D422130F03 for ; Thu, 3 Jan 2019 12:07:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 65957300A99 for ; Thu, 3 Jan 2019 14:49:28 -0500 (EST) 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 XyYH5Itv1fkG for ; Thu, 3 Jan 2019 14:49:26 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id DBB623002B3; Thu, 3 Jan 2019 14:49:25 -0500 (EST) From: Russ Housley Message-Id: <38891959-38F6-4FA5-B7B1-ACB50921E300@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F8000356-3320-45D4-A1E7-B8E3D14F6EA6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 3 Jan 2019 15:07:42 -0500 In-Reply-To: <87va35o7pe.fsf@fifthhorseman.net> Cc: IETF , LAMPS WG , draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org To: Daniel Kahn Gillmor References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <87va35o7pe.fsf@fifthhorseman.net> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 03 Jan 2019 20:07:49 -0000 --Apple-Mail=_F8000356-3320-45D4-A1E7-B8E3D14F6EA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii DKG: > On Wed 2019-01-02 10:26:05 -0800, Paul Hoffman wrote: >> Using this extension increases the risk of a bad trust anchor = rollover >> at the same time that it makes good rollover more secure. >=20 > I think this may be the root (ha ha) of confusion about the purpose of > this draft, and it raises some additional concerns for me about = whether > it is clear and useful as it stands (i've been reading -03). >=20 > This draft serves one main purpose as far as i can tell: >=20 > * It provides a technical mechanism that facilitates a root authority > releasing a new root certificate. >=20 > This is a good purpose i can get behind, but the introduction implies > that it also offers another purpose: >=20 > remove the previous one from the trust anchor store. >=20 > but the only detail in this draft that suggests how that is supposed = to > happen is in the end of the Overview: >=20 > If either check fails, then [the] potential Root CA > certificate is not a valid replacement, and the recipient continues > to use the current Root CA certificate. >=20 > The implication here is of course that if both checks succeed, then = the > current Root CA certificate is discarded. But that is explicitly = stated > nowhere in the document. Should it be? If it should, we need more > text. If it does not, the draft should remove the text about "remove > the previous one" and "continues to use the current Root CA > certificate". The Abstract of -03 includes: This certificate extension unambiguously identifies the next public key that will be used at some point in the future as the next Root CA certificate, replacing the current one. And, the Introduction of -03 includes: This hash value is a commitment to a particular public key in the next generation self-signed certificate. This commitment allows a relying party to unambiguously recognize the next generation self-signed certificate when it becomes available, install the new self-signed certificate in the trust anchor = store, and remove the previous one from the trust anchor store. And, Section 2 of -03 includes: Checking the hash of the SubjectPublicKeyInfo ensures that the certificate contains the intended public key. If either = check fails, then potential Root CA certificate is not a valid = replacement, and the recipient continues to use the current Root CA = certificate. I could add a sentence here: If both checks succeed, then the potential Root CA certificate = is added to the trust anchor store and the current Root CA certificate is removed. Does that resolve your concern? > Section 5 ("Operational Considerations") talks about RFC 2510 (should > maybe be 4210 today, no?), Yes, it should be referencing RFC 4210. > and refers to oldWithNew and newWithOld. > However, the final sentence of that paragraph is ambiguous: >=20 > Further, this technique avoids the need for all relying parties to > make the transition at the same time. >=20 > Which technique? The technique in the current draft? oldWithNew? > newWithOld? Both oldWithNew and newWithOld? If the sentence is = talking > about the two mechanisms from RFC 4210, then Operational = Considerations > should clarify that the current draft explicitly *does* require all > relying parties (and all subscribers!) to make the transition at the > same time, since the escape of C2 into the wild means that all > subscribers MUST start shipping certs signed by C2, because they can't > know whether their relying parties have switched from C1 to C2 yet. Please take a look at RFC 4210, Section 4.4 ("Root CA Key Update"). The = way that I read the section, it is describing a technique for protecting = the new public key using the previous private key and vice versa. The = technique involves both old-with-new and new-with-old. To be more clear, I will refer to "this advice" in all of the places = that reference RFC 4210. The current text uses "this advice" in one = place and "this technique" in another place. I hope that will be more = clear. > The safest thing is for the subscriber to force the relying party to > switch to C2 by shipping C2, but of course that will screw over any > other subscribe that hasn't switched yet. So i'm not convinced that = we > can safely say that reciept of C2 MUST (or even SHOULD) effectively > revoke C1. The whole point of the old-with-new and new-with-old advice is that all = of the certificates can be validated to either the old trust anchor or = the new one. > Additionally, the two paragraphs added in -03 make it clear that the > traditional new-root-cert import mechanism will remain enabled for all > relying parties, subject to all the pre-existing vagaries and risks. > (perhaps some other draft can tighten those up, but this draft does = not > do so on its own.) >=20 > So, without this draft offering a strong and immediate revocation > mechanism, and without it cleaning up the pre-existing new-root-cert > import mechanism, it does *not* make "rollover more secure" (since all > existing insecure channels will continue to exist). It just makes = good > rollover more convenient/automatic. Yes, that is the point of the extension. Russ --Apple-Mail=_F8000356-3320-45D4-A1E7-B8E3D14F6EA6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCXC5rjgAKCRCK5O7Q9ZwR yx99AJ9b0ho3gdTx65nlHntay3opJFNU3QCgsGqZpgsTuBPdwh+/dFzpQ2bgAHU= =2zvf -----END PGP SIGNATURE----- --Apple-Mail=_F8000356-3320-45D4-A1E7-B8E3D14F6EA6-- From nobody Thu Jan 3 12:07:58 2019 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 34B9E1312E8 for ; Thu, 3 Jan 2019 12:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 6ghRIt_N2HNC for ; Thu, 3 Jan 2019 12:07:54 -0800 (PST) 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 9BB781312CF for ; Thu, 3 Jan 2019 12:07:54 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x03K6rYI005681; Thu, 3 Jan 2019 20:07:52 GMT 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=bOo3iD4pf3vmd2mEedB9PNXf8Q3v2scNwckPbY8GKBY=; b=Bl48eELYBbqbzIZ/UrOv1TWCsbCS4Y+hUulte1JMqk4veeiyDiHIC8GiW+RFLC5N86Bo Jej81fzDdeCy7tlHW9xs+hVqObS/v7EgPcI8HLjhFtKfqq+6nlhPczGRyxn+7WhEbQAi 8eNmbVu/TxeFz6oUSaFgNrpkaK7TR1hg3JZ5IsCqw5DkIrcmlLN7D+QwoyaZnrBhY2vn oGX5Ej24AwY09DeyI50FVdWZXZXo1Jm3UO98nRPrYX0c+on3x40GO5iT7zhmDVQARInV cGjyPJhZPydcjWkSyQvEVFLPod8eOsJ5WKYmweENfjzIXXzo4BCNRiZMVAeviJ5CE2uY Xw== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2prvp34dxc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 Jan 2019 20:07:52 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id x03K27ex001535; Thu, 3 Jan 2019 15:07:51 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2pp552446t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 03 Jan 2019 15:07:51 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 3 Jan 2019 14:07:51 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Thu, 3 Jan 2019 14:07:51 -0600 From: "Salz, Rich" To: Daniel Kahn Gillmor , Russ Housley , LAMPS WG Thread-Topic: [lamps] Draft addition of header protection to the LAMPS charter Thread-Index: AQHUo5kWvx146W5QP0KbogMFRFdq/KWd/8eAgABVoQD//7QqAA== Date: Thu, 3 Jan 2019 20:07:50 +0000 Message-ID: <5F238DF7-56AE-4074-8DF1-E55FAEFFCCEC@akamai.com> References: <87bm5hxdn0.fsf@fifthhorseman.net> <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> <7E97D758-BC5A-4911-AC15-958D25D1A88F@akamai.com> <87sgy9o7iz.fsf@fifthhorseman.net> In-Reply-To: <87sgy9o7iz.fsf@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.14.0.181208 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.68] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-03_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=826 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901030173 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-03_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=834 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901030174 Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 03 Jan 2019 20:07:56 -0000 PiAgICBJJ20gZmluZSB3aXRoIGVpdGhlciAob3Igd2l0aCAiaW5jbHVkaW5nIiksIGJ1dCBpIHBy ZWZlciB0byBzYXkgImJvdGgiDQogIA0KV29ya3MgZm9yIG1lLg0KDQo= From nobody Thu Jan 3 13:00:54 2019 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 23B5E130F04; Thu, 3 Jan 2019 13:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npWOGnmt9gUI; Thu, 3 Jan 2019 13:00:42 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4A6F126BED; Thu, 3 Jan 2019 13:00:41 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 3 Jan 2019 13:00:32 -0800 From: Jim Schaad To: 'Russ Housley' , 'SPASM' CC: , 'IETF' References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <3D85A45C-FE94-45A7-BF37-C3F8C1B3F5AA@vigilsec.com> <869BCE27-2AB5-4550-AC89-335BFE749123@vpnc.org> <8D8915DD-E57E-44B1-9B5C-1AF9E631F335@vigilsec.com> In-Reply-To: <8D8915DD-E57E-44B1-9B5C-1AF9E631F335@vigilsec.com> Date: Thu, 3 Jan 2019 13:00:27 -0800 Message-ID: <032401d4a3a7$5e423450$1ac69cf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEWKigwIEwMKlbSF2L4QnBCPIILnAI96U1GAY7BbjIB3QVAcQGAmYlMpuGluNA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 03 Jan 2019 21:00:45 -0000 > -----Original Message----- > From: Spasm On Behalf Of Russ Housley > Sent: Thursday, January 3, 2019 7:28 AM > To: SPASM > Cc: draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org; IETF > Subject: Re: [lamps] Last Call: 02.txt> (Hash Of Root Key Certificate Extension) to Informational RFC > > I had a voice conversation with Paul Hoffman, and I think that I now understand > the things that he would like to see added to the document. Essentially, the > Hash Of Root Key certificate extension is a commitment to the next generation > public key and algorithm. Recall that the hash covers the SubjectPublicKeyInfo, > which is: > > SubjectPublicKeyInfo ::= SEQUENCE { > algorithm AlgorithmIdentifier, > subjectPublicKey BIT STRING } > > So, a few things can go wrong after making this commitment. (Stephen called > it pinning.) The Root CA needs to choose a next generation public key and > algorithm that will be secure for the full lifetime. Of course, a cryptoanalytic > break through is very difficult to predict, and if one happens before the new key > is used, the Root CA remains committed to the now broken key. The remedy is > to deploy a new public key and algorithm in the same manner as the initial > Root CA self-signed certificate. The benefits of automatic detection of the new > public key are lost, but that is a minor concern is the scope of a cryptoanalytic > break through. I don't think this needs to be put into the document, but in the extremely unlikely event that both the hash algorithm and the public key algorithm are broken, then an adversary could issue new root certificates. I believe that they could probably issue the old/new key pair as well in most cases as generally both the old and new roots are going to be using the same algorithm. If just the algorithm is broken, then it would be possible for an adversary to intercept the new root and then issue a new set of roots and cross certificates using the new key pair as they would then not need to invert the hash. Jim > > In addition, from an operational perspective, the Root CA must securely back > up the yet-to-be-deployed key pair. If the Root CA stores it in a hardware > security module, and that module fails, the Root CA remains committed to the > now unavailable key. The remedy is the same as above: deploy a new public > key in the same manner as the initial Root CA self-signed certificate. > > Russ > > > > On Jan 2, 2019, at 3:17 PM, Paul Hoffman wrote: > > > > On 2 Jan 2019, at 11:57, Russ Housley wrote: > > > >>> On Jan 2, 2019, at 1:26 PM, Paul Hoffman > wrote: > >>> > >>> This extension seems useful to CAs that understand the increased risks that > using it incurs, but those risks are not mentioned in the document. > >>> > >>> The document implicitly assumes that the CA will in fact use the key named > in the extension next. Using this extension increases the risk of a bad trust > anchor rollover at the same time that it makes good rollover more secure. If > the key listed in this extension cannot be used when the CA eventually changes > the trust anchor, relying parties will mistrust the new trust anchor. There are > many reasons why a CA might think they know the next key but cannot use that > key when they change trust anchors, such as if the HSM that holds the next key > fails or is destroyed. Given the last sentence in Section 2, this could mean that a > CA might never be able to issue a new trust anchor, even if the key for its > current trust anchor is compromised. > >>> > >>> Given the severity of the new risks of using this extension, they need to be > introduced at the beginning of the document and then discussed in more detail > in the Security Considerations. Note that this risk affects the last paragraph of > the Security Considerations section as well. > >> > >> The point is to facilitate the transition from one Root CA certificate to the > next. > > > > To be clear, the transition is from one public key to the next, not from one > certificate to the next. But, more importantly, the point of this extension is to > facilitate the transition from one Root CA certificate to what is supposed to be > the next key. However, if that next key is not seen by every relying party during > the transition, the extension prevents the CA from ever making the transition > for the relying parties that do not see the new key in a revised trust anchor. > This seems like a huge restriction that is only mentioned in the document in > exactly one sentence: > > > >> The last sentence in Section 2 says: > >> > >> If either check fails, then potential Root CA > >> certificate is not a valid replacement, and the recipient continues > >> to use the current Root CA certificate. > >> > >> Indeed, these check are necessary to make sure that the relying party makes > the transition to the proper replacement. Any failure of the checks leave the > trust anchor unchanged, which seems like the right result to me. > > > > It seems right to me as well, but it still seems to be wholly insufficient to not > talk about the risks of using the extension early in the document. > > > >> > >> Recall the definition of trust anchor from RFC 5280, Section 6.1.1: > >> > >> (d) trust anchor information, describing a CA that serves as a > >> trust anchor for the certification path. The trust anchor > >> information includes: > >> > >> (1) the trusted issuer name, > >> > >> (2) the trusted public key algorithm, > >> > >> (3) the trusted public key, and > >> > >> (4) optionally, the trusted public key parameters associated > >> with the public key. > >> > >> The checks make sure that the replacement self-signed certificate contains > the intended information. > > > > That is all fine, but it does not address the significant risk a CA is undertaking > by promising what the next key will be. > > > >>> Editorial: > >>> > >>> The abstract says: > >>> This document specifies the Hash Of Root Key certificate extension. > >>> This certificate extension is carried in the self-signed > >>> certificate for a trust anchor, which is often called a Root > >>> Certification Authority (CA) certificate. This certificate > >>> extension unambiguously identifies the next public key that will be > >>> used by the trust anchor at some point in the future. > >>> The term "trust anchor" is used as the concept, not the bits in the > certificate. As such, the last sentence is confusing because the trust anchor will > change when the key changes. A possible fix is to replace "will be used by the > trust anchor at some point in the future" with "will be used in a trust anchor at > some point in the future". > >> > >> I think I understand your point. Does this text resolve the concern? > >> > >> This document specifies the Hash Of Root Key certificate extension. > >> This certificate extension is carried in the self-signed certificate > >> for a trust anchor, which is often called a Root Certification > >> Authority (CA) certificate. This certificate extension unambiguously > >> identifies the next public key that will be used at some point in the > >> future as the next Root CA certificate, replacing the current one. > > > > Not really. A key will not be used as a certificate: it is just a key. A key might > be used as the signing key for a certificate, but not as the certificate itself. > Maybe instead: "will be used to sign a trust anchor at some point in the > future"? > > > >>> The first list in Section 2 would be clearer if the order was R1, R2, H2, C1; > this would also then match the order in the second list. > >> > >> Okay. I changed that in my edit buffer. > >> > >>> Later in Section 2, a sentence appears to be missing its subject. "That is, > verify the signature on the self-signed certificate..." should probably be "That is, > the recipient verifies the signature on the self-signed certificate...". > >> > >> Okay. I changed that in my edit buffer. > >> > >> In addition, I added a bit more detail about the relationship to certification > path validation, which I hope adds clarity around your first comment. It now > reads: > >> > >> The successor to the Root CA self-signed certificate can be > >> delivered by any means. Whenever a new Root CA certificate is > >> received, the recipient is able to verify that the potential Root CA > >> certificate links back to a previously authenticated Root CA > >> certificate with the hashOfRootKey certificate extension. That is, > >> the recipient verifies the signature on the self-signed certificate > >> and verifies that the hash of the DER-encoded SubjectPublicKeyInfo > >> from the potential Root CA certificate matches the value from the > >> HashOfRootKey certificate extension of the current Root CA > >> certificate. Checking the self-signed certificate signature ensures > >> that the certificate contains the subject name, public key algorithm > >> identifier, and public key algorithm parameters intended by the key > >> owner intends; these are important inputs to certification path > >> validation as defined in Section 6 of [RFC5280]. Checking the hash > >> of the SubjectPublicKeyInfo ensures that the certificate contains the > >> intended public key. If either check fails, then potential Root CA > >> certificate is not a valid replacement, and the recipient continues > >> to use the current Root CA certificate. > > > > Yes, adding this clarifies how all the trust anchor information is linked > through the validation process. This is a good addition. > > > > --Paul Hoffman > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Jan 3 13:32:50 2019 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 9B75D130F55 for ; Thu, 3 Jan 2019 13:32:47 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeUvhqQIg8CA for ; Thu, 3 Jan 2019 13:32:44 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 9D19C130F3C for ; Thu, 3 Jan 2019 13:32:44 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1gfAbY-0003gn-O3; Thu, 03 Jan 2019 22:32:40 +0100 Date: Thu, 3 Jan 2019 22:32:40 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Russ Housley cc: LAMPS WG In-Reply-To: <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> Message-ID: References: <87bm5hxdn0.fsf@fifthhorseman.net> <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) 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] Draft addition of header protection to the LAMPS charter 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, 03 Jan 2019 21:32:48 -0000 Hi DKG, Russ et al. I think we need to include what's the current situation with this issue, in particular mention that there is a solution in on Standards Track already (RFC5751). How about something like this: --- BEGIN --- 7. Cryptographic protection of electronic mail headers: RFC5751 defines a mechanism that is somewhat underspecified and thus not widely implemented. Most current implementations of cryptographically-protected electronic mail protect only the body of the message - but not the header part - which leaves significant room for attacks on otherwise-protected messages. The WG shall improve the specification to cryptographic protection of email-headers (both for integrity and encryption) to close significant privacy, security and usability gaps in cryptographically-protected electronic mail. --- END --- cheers Bernie -- http://ucom.ch/ Modern Telephony Solutions and Tech Consulting for Internet Technology On Thu, 3 Jan 2019, Russ Housley wrote: > At the LAMPS session in Bangkok, there was interest in adding a header > protection work item to the charter. Alexey talked about this in Montreal, > and he posted a draft a few weeks ago: > > draft-melnikov-lamps-header-protection. > > Several people said that they would implement a solution if the LAMPS WG > produced an RFC on this topic. > > Shortly before the holidays, DKG proposed charter text: > >> 7. Specify a mechanism for the cryptographic protection of e-mail >> headers. Most current implementations protect only the body of the >> message, which leaves significant room for attacks against >> otherwise-protected messages. Cryptographic protection (both for >> signatures and encryption) which applies to the headers in conjunction >> with the message body are necessary to close significant security and >> usability gaps in cryptographically-protected electronic mail. > > Does anyone have any concerns with this text? If not, we will ask the > Security ADs to add this to the existing charter. > > Russ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Thu Jan 3 14:28:25 2019 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 5AEC113132F for ; Thu, 3 Jan 2019 14:28:24 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVIJQs0zHFvj for ; Thu, 3 Jan 2019 14:28:21 -0800 (PST) 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 9C35A13132E for ; Thu, 3 Jan 2019 14:28:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7B032300A51 for ; Thu, 3 Jan 2019 17:10:03 -0500 (EST) 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 YChxb1YpWiZK for ; Thu, 3 Jan 2019 17:10:02 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id D833E300464; Thu, 3 Jan 2019 17:10:01 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: Date: Thu, 3 Jan 2019 17:28:18 -0500 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <47C7E616-F930-44B0-AAF5-895795F22C43@vigilsec.com> References: <87bm5hxdn0.fsf@fifthhorseman.net> <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> To: Bernie Hoeneisen X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 03 Jan 2019 22:28:24 -0000 Bernie: I do not agree that it is underspecified, but I do agree that it is not = widely implemented. The presentation to the user is not specified at = all, which is quite normal for IETF protocol specifications. Also, S/MIME and OpenPGP offer signature and encryption. With S/MIME = 4.0, you can get authenticated-encryption. In any case, I think that = "signature and encryption" was a better description. Russ > On Jan 3, 2019, at 4:32 PM, Bernie Hoeneisen = wrote: >=20 > Hi DKG, Russ et al. >=20 > I think we need to include what's the current situation with this = issue, in particular mention that there is a solution in on Standards = Track already (RFC5751). How about something like this: >=20 > --- BEGIN --- >=20 > 7. Cryptographic protection of electronic mail headers: RFC5751 = defines a mechanism that is somewhat underspecified and thus not widely = implemented. Most current implementations of cryptographically-protected = electronic mail protect only the body of the message - but not the = header part - which leaves significant room for attacks on = otherwise-protected messages. The WG shall improve the specification to = cryptographic protection of email-headers (both for integrity and = encryption) to close significant privacy, security and usability gaps in = cryptographically-protected electronic mail. >=20 > --- END --- >=20 >=20 > cheers > Bernie >=20 >=20 >=20 > -- >=20 > http://ucom.ch/ > Modern Telephony Solutions and Tech Consulting for Internet Technology >=20 >=20 > On Thu, 3 Jan 2019, Russ Housley wrote: >=20 >> At the LAMPS session in Bangkok, there was interest in adding a = header >> protection work item to the charter. Alexey talked about this in = Montreal, >> and he posted a draft a few weeks ago: >>=20 >> draft-melnikov-lamps-header-protection. >>=20 >> Several people said that they would implement a solution if the LAMPS = WG >> produced an RFC on this topic. >>=20 >> Shortly before the holidays, DKG proposed charter text: >>=20 >>> 7. Specify a mechanism for the cryptographic protection of e-mail >>> headers. Most current implementations protect only the body of the >>> message, which leaves significant room for attacks against >>> otherwise-protected messages. Cryptographic protection (both for >>> signatures and encryption) which applies to the headers in = conjunction >>> with the message body are necessary to close significant security = and >>> usability gaps in cryptographically-protected electronic mail. >>=20 >> Does anyone have any concerns with this text? If not, we will ask = the >> Security ADs to add this to the existing charter. >>=20 >> Russ >>=20 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >>=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Jan 3 15:02:47 2019 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 14E3B130F11 for ; Thu, 3 Jan 2019 15:02:46 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqHt5TTk93VR for ; Thu, 3 Jan 2019 15:02:43 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 B7794130DE3 for ; Thu, 3 Jan 2019 15:02:43 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1gfC0f-0000W4-5L; Fri, 04 Jan 2019 00:02:41 +0100 Date: Fri, 4 Jan 2019 00:02:41 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Russ Housley cc: LAMPS WG In-Reply-To: <47C7E616-F930-44B0-AAF5-895795F22C43@vigilsec.com> Message-ID: References: <87bm5hxdn0.fsf@fifthhorseman.net> <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> <47C7E616-F930-44B0-AAF5-895795F22C43@vigilsec.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) 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] Draft addition of header protection to the LAMPS charter 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, 03 Jan 2019 23:02:46 -0000 Hi Russ Thanks for your feedback. On Thu, 3 Jan 2019, Russ Housley wrote: > I do not agree that it is underspecified, but I do agree that it is not > widely implemented. The presentation to the user is not specified at > all, which is quite normal for IETF protocol specifications. Obviously, we have different opinion on this. At least, there is the issue that encapsulated messages can not (always) be distiguished from forwarded messages. Alexey proposed a mechanism to include "forwarded=no" to the Content-Type HF to easily keep the two cases appart. See https://tools.ietf.org/html/draft-melnikov-lamps-header-protection-00 (Section 3.2) However, I do not insist on including 'which is somewhat underspecified', as long as there is a clear mention / reference to the existing standardized solution. > Also, S/MIME and OpenPGP offer signature and encryption. With S/MIME > 4.0, you can get authenticated-encryption. In any case, I think that > "signature and encryption" was a better description. Both variants for wording are fine with me. Here's my updated suggestion with your feedback included: --- BEGIN --- 7. Cryptographic protection of electronic mail headers: RFC5751 defines a mechanism that is not widely implemented. Most current implementations of cryptographically-protected electronic mail protect only the body of the message - but not the header part - which leaves significant room for attacks on otherwise-protected messages. The WG shall improve the specification to cryptographic protection of email-headers (both for signature and encryption) to close significant privacy, security and usability gaps in cryptographically-protected electronic mail. --- END --- cheers Bernie > > Russ > > > >> On Jan 3, 2019, at 4:32 PM, Bernie Hoeneisen wrote: >> >> Hi DKG, Russ et al. >> >> I think we need to include what's the current situation with this >> issue, in particular mention that there is a solution in on Standards >> Track already (RFC5751). How about something like this: >> >> --- BEGIN --- >> >> 7. Cryptographic protection of electronic mail headers: RFC5751 defines >> a mechanism that is somewhat underspecified and thus not widely >> implemented. Most current implementations of >> cryptographically-protected electronic mail protect only the body of >> the message - but not the header part - which leaves significant room >> for attacks on otherwise-protected messages. The WG shall improve the >> specification to cryptographic protection of email-headers (both for >> integrity and encryption) to close significant privacy, security and >> usability gaps in cryptographically-protected electronic mail. >> >> --- END --- >> >> >> cheers >> Bernie >> >> >> >> -- >> >> http://ucom.ch/ >> Modern Telephony Solutions and Tech Consulting for Internet Technology >> >> >> On Thu, 3 Jan 2019, Russ Housley wrote: >> >>> At the LAMPS session in Bangkok, there was interest in adding a header >>> protection work item to the charter. Alexey talked about this in Montreal, >>> and he posted a draft a few weeks ago: >>> >>> draft-melnikov-lamps-header-protection. >>> >>> Several people said that they would implement a solution if the LAMPS WG >>> produced an RFC on this topic. >>> >>> Shortly before the holidays, DKG proposed charter text: >>> >>>> 7. Specify a mechanism for the cryptographic protection of e-mail >>>> headers. Most current implementations protect only the body of the >>>> message, which leaves significant room for attacks against >>>> otherwise-protected messages. Cryptographic protection (both for >>>> signatures and encryption) which applies to the headers in conjunction >>>> with the message body are necessary to close significant security and >>>> usability gaps in cryptographically-protected electronic mail. >>> >>> Does anyone have any concerns with this text? If not, we will ask the >>> Security ADs to add this to the existing charter. >>> >>> Russ >>> >>> _______________________________________________ >>> 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 > > From nobody Thu Jan 3 16:08:01 2019 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 A9EEC130DEE; Thu, 3 Jan 2019 16:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhh7bfo73R6X; Thu, 3 Jan 2019 16:07:50 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43CF5131379; Thu, 3 Jan 2019 16:07:50 -0800 (PST) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 68BEAF99A; Thu, 3 Jan 2019 19:07:46 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 978842039A; Thu, 3 Jan 2019 18:12:29 -0500 (EST) From: Daniel Kahn Gillmor To: Russ Housley Cc: IETF , LAMPS WG , draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org In-Reply-To: <38891959-38F6-4FA5-B7B1-ACB50921E300@vigilsec.com> References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <87va35o7pe.fsf@fifthhorseman.net> <38891959-38F6-4FA5-B7B1-ACB50921E300@vigilsec.com> Date: Thu, 03 Jan 2019 18:12:21 -0500 Message-ID: <87k1jlnxnu.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 04 Jan 2019 00:07:53 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Russ-- thanks for the followup. On Thu 2019-01-03 15:07:42 -0500, Russ Housley wrote: > I could add a sentence here: > > If both checks succeed, then the potential Root CA certificate is > added to the trust anchor store and the current Root CA > certificate is removed. > > Does that resolve your concern? Yes, this final addition clarifies the intent of the document, thank you. I might prefer if it was active voice instead of passive, just to be clearer about who is doing the addition and removal to the trust store. Is there a reason to avoid RFC 2119 language in these descriptions? > Please take a look at RFC 4210, Section 4.4 ("Root CA Key Update"). Please cite the relevant section number directly in the draft! > The way that I read the section, it is describing a technique for > protecting the new public key using the previous private key and vice > versa. The technique involves both old-with-new and new-with-old. > > To be more clear, I will refer to "this advice" in all of the places > that reference RFC 4210. The current text uses "this advice" in one > place and "this technique" in another place. I hope that will be more > clear. So i think you're now saying that people updating a key should use RFC 4210=C2=A74.4 guidance *in addition* to including the HashOfRootKey extensi= on in C1. If that's what you mean, the draft should say it explicitly. But (using the RFC 4210 terms), let's think about what happens to the PSE (Personal Security Environment), the trust store (meaning the list of trusted roots, which is a subset of the PSE, i guess, feel free to correct if i'm misunderstanding 4210) and various certificates assuming there are multiple heterogeneous subscribers seen by a single relying party. I'm working here on a TLS assumption -- if you're using these certs for some other purpose (like LAMPS) maybe it won't apply, i'm not sure. The "Repository" referred to in RFC 4210 isn't something that many X.509 verification stacks have access to (and even if it was, checking it during failed verification might raise privacy or latency concerns). In my notation below, the CA starts with self-signed C1, and then moves (via HashOfRootKey) to self-signed C2. Meanwhile, the CA has also generated COwN (the oldWithNew cert) and CNwO (the newWithOld cert). (C1 is oldWithOld, and C2 is newWithNew, in 4210 lingo). In my example, an end-entity cert might be written as EA or EB, and will be signed by the root authority directly (i'm omitting traditional intermediate certs for the sake of simplicity, though i note that COwN and CNwO are effectively intermediate certs). A valid simple certificate chain where end entity A is certified by the first version of the CA looks like this: EA=E2=86=90C1. Let's assume that = all servers ship their root CA certs as well (though TLS doesn't explicitly require that, and people who care about latency are likely to try to omit them -- should this draft explicitly recommend that TLS servers ship root certs all the time just in case?). in this example scenario, the relying party visits site end entity A (which whose cert has been issued by the new C2), and then end entity B (which is still using a cert issued by C1). | Trust | | cert | event | Store | PSE | chain | valid?=20=20=20 =2D-------+-------+-------+-------+---------- start | C1 | C1 | | visit A | C2 | C1,C2 | EA=E2=86=90C2 | EA =3D =E2=9C=93 visit B | C2 | C1,C2 | EB=E2=86=90C1 | EB =3D ? It looks to me like EB will not validate, since: 1) C1 is no longer a trusted root, despite being in the PSE =20 2) COwN is not available to the relying party (and might not be known to server B either), so no chain can be formed to the only trusted root, C2 What am i missing? This looks like a recipe for one party (A) to accidentally damage another party (B) due to lack of coordination. Furthermore, what happens if the relying party comes across CNwO before C2? It validates (signed by C1) but it is not self-signed. But its SPKI also matches C1's HashOfRootKey extension. If it gets processed as a new root, then C2 will *not* get processed (because C1 is already out of the trust store, and C2 doesn't have the same HashOfRootKey as C1). So now you'll have some RPs that have CNwO in their root store, and others that have C2, depending on when they encountered it. Hopefully that won't cause any problems, but it makes me nervous. Alternately, maybe this process *only* triggers when the cert we're examining is self-signed. Maybe the text "Whenever a new Root CA certificate is received" is meant to only apply to self-signed certificates? perhaps it should be clearer on that, if that's the case (subsequent text in that paragraph refers to "the self-signed certificate", but the only "self-signed" antecedent in that paragraph is the original "Root CA self-signed certificate" -- C1, not a potential C2). > The whole point of the old-with-new and new-with-old advice is that > all of the certificates can be validated to either the old trust > anchor or the new one. only if the relying party has access both COwN cert as well as C2, right? If the TLS server ships only C1, then the RP is out of luck. should COwN have the same subjectPublicKeyIdentifier extension as C1? should CNwO have the same subjectPublicKeyIdentifier as C2? if so, should we say so explicitly? >> So, without this draft offering a strong and immediate revocation >> mechanism, and without it cleaning up the pre-existing new-root-cert >> import mechanism, it does *not* make "rollover more secure" (since all >> existing insecure channels will continue to exist). It just makes good >> rollover more convenient/automatic. > > Yes, that is the point of the extension. thanks, that matches my mental model. One other open question occurs to me: Should the relying party also verify that Subject information (or other identity info) in the new cert matches the old certificate? I'm imagining a case where the old root CA ("O=3DL'Emporium de Foobar,OU=3DAuthorit=C3=A9 Racine,C=3DFR") ends up repl= acing itself with ("O=3D=D0=92=D0=BE=D0=BE=D1=80=D1=83=D0=B6=D1=91=D0=BD=D0=BD=D1= =8B=D0=B5 =D0=A1=D0=B8=D0=BB=D1=8B =D0=A1=D0=BE=D1=8E=D0=B7=D0=B0 =D0=A1=D0= =BE=D0=B2=D0=B5=D1=82=D1=81=D0=BA=D0=B8=D1=85 =D0=A1=D0=BE=D1=86=D0=B8=D0= =B0=D0=BB=D0=B8=D1=81=D1=82=D0=B8=D1=87=D0=B5=D1=81=D0=BA=D0=B8=D1=85 =D0=A0=D0=B5=D1=81=D0=BF=D1=83=D0=B1=D0=BB=D0=B8=D0=BA,C=3DSU"). That woul= d be pretty weird and upsetting, especially if i didn't know how my "new" Soviet military cert got into my trust store. Would it be legitimate to cabin the scope of this rollover to identical Subjects? Finally, should a relying party place any bounds on the lifetime of the new cert? What if C2 appears, but has an *earlier* notBefore date than C1? that seems weird but maybe it isn't a problem. But what if i've added a cert to my root store with an known expiration date, and i don't *want* a subsequent cert to suddenly have a later expiration date? (for example, perhaps i'm in school and the school issues its own annual certificate authority which i'm fine with accepting for now, but i don't want to trust it after graduation) How can an implementation determine the intent of the local system's inclusion of certificate in the root store? Should we encourage trust store implementations to be able mark certificates as DO NOT UPDATE? or should we instead encourage users to understand inclusion of a certificate in a root store as effectively unbounded in duration, despite the existence of a validUntil field? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCXC6W1QAKCRBsHx7ezFD6 U7a5AP44Hvby+3cYmGngqkSN9z8OBN9zwxPlGDCX8ir9010gAwEAthp18Kr9nck0 XlkoTqDV9PVAXkCiUAx0crmA70w5JQ4= =NHST -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 3 17:24:21 2019 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 1B7ED131028 for ; Thu, 3 Jan 2019 17:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=VmDfzyP+; dkim=pass (1536-bit key) header.d=taugh.com header.b=XOdf24nA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXrvBtINtk80 for ; Thu, 3 Jan 2019 17:24:17 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1D97130EF9 for ; Thu, 3 Jan 2019 17:24:17 -0800 (PST) Received: (qmail 19062 invoked from network); 4 Jan 2019 01:24:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=4a74.5c2eb5c0.k1901; bh=S8q2CmbP087EXAI8SbvhphzHZfD0YWzja8YYvcbQN3Y=; b=VmDfzyP+puy4wImwCGcKNrRPaGAcHsFeDfUpJtXiR+As8UF1KM7bb+ul9Ya6lWGbRvsEpnEmHClDhdjgfUajDpCgBrTEQ44vqPA8jJlKsTPDZXlTj5iebKI78in+pvvSwgRmHtnVWrNYZYI7jXT1FZrS/BNRw0t1BTFWNOkzNIkF+aKbL4EISK5yDOZCVAKIl8qQbc2M9a9AhAlVYNGy5mGhNO/1W3pYCtYn2dwGv548W7r+VD7EX0mghCa4PacH DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=4a74.5c2eb5c0.k1901; bh=S8q2CmbP087EXAI8SbvhphzHZfD0YWzja8YYvcbQN3Y=; b=XOdf24nAfG3aXS9Nh1ZPkNrepVUWZQim6UBKGx+pisoDonHqGYU97XdjI6FEDaJqZutCiNHdGjV9WZ3UujrcWqUdUR4i6tInPP7QZbBbYl/AlN/wWrpJjRA8OJ6BMko1BICKSpY+/+ZmbKhM1zoqL51vm8rjM1EajdDhxCORlUvKGLKsWI5uzz9fEY4loUVsN3AXVCREg3WP0W4ZtVhfjhjIS/bzwaCdrA85UiKm82pWb2/z8+kQvaJbKyHbr5i/ Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 04 Jan 2019 01:24:15 -0000 Received: by ary.qy (Postfix, from userid 501) id AA6C3200C425F9; Thu, 3 Jan 2019 20:24:15 -0500 (EST) Date: 3 Jan 2019 20:24:15 -0500 Message-Id: <20190104012415.AA6C3200C425F9@ary.qy> From: "John Levine" To: spasm@ietf.org Cc: bernie@ietf.hoeneisen.ch In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 04 Jan 2019 01:24:20 -0000 In article you write: >Hi DKG, Russ et al. > >I think we need to include what's the current situation with this >issue, in particular mention that there is a solution in on Standards >Track already (RFC5751). How about something like this: If we're adding references to the charter which seems to me a premature optimization, add RFC 6376, which is a well-specified mechanism for full-message signatures, too. > >--- BEGIN --- > >7. Cryptographic protection of electronic mail headers: RFC5751 defines a >mechanism that is somewhat underspecified and thus not widely implemented. >Most current implementations of cryptographically-protected electronic >mail protect only the body of the message - but not the header part - >which leaves significant room for attacks on otherwise-protected messages. >The WG shall improve the specification to cryptographic protection of >email-headers (both for integrity and encryption) to close significant >privacy, security and usability gaps in cryptographically-protected >electronic mail. > >--- END --- > > >cheers > Bernie > > > >-- > >http://ucom.ch/ >Modern Telephony Solutions and Tech Consulting for Internet Technology > > >On Thu, 3 Jan 2019, Russ Housley wrote: > >> At the LAMPS session in Bangkok, there was interest in adding a header >> protection work item to the charter. Alexey talked about this in Montreal, >> and he posted a draft a few weeks ago: >> >> draft-melnikov-lamps-header-protection. >> >> Several people said that they would implement a solution if the LAMPS WG >> produced an RFC on this topic. >> >> Shortly before the holidays, DKG proposed charter text: >> >>> 7. Specify a mechanism for the cryptographic protection of e-mail >>> headers. Most current implementations protect only the body of the >>> message, which leaves significant room for attacks against >>> otherwise-protected messages. Cryptographic protection (both for >>> signatures and encryption) which applies to the headers in conjunction >>> with the message body are necessary to close significant security and >>> usability gaps in cryptographically-protected electronic mail. >> >> Does anyone have any concerns with this text? If not, we will ask the >> Security ADs to add this to the existing charter. >> >> Russ >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >> > From nobody Fri Jan 4 08:35:34 2019 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 2E31C130E33 for ; Fri, 4 Jan 2019 08:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKOECVRQ3rGd for ; Fri, 4 Jan 2019 08:35:30 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB49130E30 for ; Fri, 4 Jan 2019 08:35:30 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 3BD63F99B; Fri, 4 Jan 2019 11:35:27 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 4DD3B203C1; Fri, 4 Jan 2019 11:35:26 -0500 (EST) From: Daniel Kahn Gillmor To: John Levine , spasm@ietf.org Cc: bernie@ietf.hoeneisen.ch In-Reply-To: <20190104012415.AA6C3200C425F9@ary.qy> References: <20190104012415.AA6C3200C425F9@ary.qy> Date: Fri, 04 Jan 2019 11:35:22 -0500 Message-ID: <87h8eonzxx.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 04 Jan 2019 16:35:32 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu 2019-01-03 20:24:15 -0500, John Levine wrote: > In article = you write: > >>I think we need to include what's the current situation with this=20 >>issue, in particular mention that there is a solution in on Standards=20 >>Track already (RFC5751). How about something like this: Bernie, thanks for your proposed change. The second revision of your text looks fine to me. It is certainly "not widely implemented" -- iirc, there was only one implementation of it anywhere last i looked. FWIW, i lean in Bernie's direction as far as "somewhat underspecified" because the specification does lead to significant usability gaps (as identified later in the proposed charter text) due to lack of guidance about how a receiving MUA should interpret conflicting headers on the inside and outside of the message's cryptographic envelope ("This entity SHOULD be presented as the top-level message, taking into account header merging issues as previously discussed." -- but with no mention of "merging" anywhere else in the document). This isn't so much a UI issue (which would be out of scope, as Russ says) as it is an open semantic question, and i do think that's within scope here. > If we're adding references to the charter which seems to me a > premature optimization, add RFC 6376, which is a well-specified > mechanism for full-message signatures, too. John, would you be ok with leaving out RFC 6376 (DKIM) if we changed the charter text to say "end-to-end cryptographic protection" instead of just "cryptographic protection"? is DKIM ever used by the sender themselves, instead of by the domain itself (for example, with a user-specific selector)? I'm not sure that the charter text is a good place for such a catalog, though perhaps these references could show up in a "related mechanisms" section of the resultant document. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCXC+LSgAKCRBsHx7ezFD6 U87FAP9Mf9AUN3EXezqRzGViyWSMAhEi6bBRBYGb2aoCT52D9gEAithwrr3imjwM DMFRr75mFdurS0ZjuzCxTp7l2hQcrQc= =IyCy -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 4 08:35:52 2019 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 C6DA2130E33 for ; Fri, 4 Jan 2019 08:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNDuifwfmxoJ for ; Fri, 4 Jan 2019 08:35:49 -0800 (PST) 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 5236B130E30 for ; Fri, 4 Jan 2019 08:35:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 87D28300A58 for ; Fri, 4 Jan 2019 11:17:31 -0500 (EST) 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 jnPkXGI0I01H for ; Fri, 4 Jan 2019 11:17:29 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 9D927300A46; Fri, 4 Jan 2019 11:17:29 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: <20190104012415.AA6C3200C425F9@ary.qy> Date: Fri, 4 Jan 2019 11:35:46 -0500 Cc: spasm@ietf.org, bernie@ietf.hoeneisen.ch Content-Transfer-Encoding: quoted-printable Message-Id: <657B60E6-2310-4D58-918C-010FFE74BFA9@vigilsec.com> References: <20190104012415.AA6C3200C425F9@ary.qy> To: John Levine X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 04 Jan 2019 16:35:51 -0000 >> Hi DKG, Russ et al. >>=20 >> I think we need to include what's the current situation with this=20 >> issue, in particular mention that there is a solution in on Standards=20= >> Track already (RFC5751). How about something like this: >=20 > If we're adding references to the charter which seems to me a > premature optimization, add RFC 6376, which is a well-specified > mechanism for full-message signatures, too. John: It is true that DKIM signs the headers, but the signature is applied by = the sending server, not the originator. Bernie wants to point out that = S/MIME includes a header protection mechanism, but it is not used. Russ From nobody Fri Jan 4 09:06:42 2019 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 41ACC12F1A5 for ; Fri, 4 Jan 2019 09:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=NdqJe+Mx; dkim=pass (1536-bit key) header.d=taugh.com header.b=GMalT1Zh Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXAutU4WT_H0 for ; Fri, 4 Jan 2019 09:06:38 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE7A130E4D for ; Fri, 4 Jan 2019 09:06:37 -0800 (PST) Received: (qmail 6007 invoked from network); 4 Jan 2019 17:06:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1772.5c2f929b.k1901; bh=yqppay/g9UK1tv9tQm7f6IzLKhj24njk1bMrsvVsad8=; b=NdqJe+MxB90cLKzi7peSinON/2Hobpd/OAs7D+fD3GoUZMwv283/5Hnvp2WjOcvX04GYsuAI/lYsaEI3tei7j//e3AfbRV4JuGf+tzFeCRn9SjXE35Y0Imrx/VT2rFbxUZvl8rAlcemhxIWktHgl2MfDuuBLIMykhAAg1ga3jusZS+KnUHef6ivENb+kzYUEDh1Se/Vp49pN1a6nmHBfj6gM7JneEiokxmgD+vsaLre2m0euH8+3djT8R46+ijIl DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1772.5c2f929b.k1901; bh=yqppay/g9UK1tv9tQm7f6IzLKhj24njk1bMrsvVsad8=; b=GMalT1Zh6LzKSsxoqkth8KnL5LaqwMlUI1pV0IulksInG3/9keMMkXHMh80qcGuqU44LAPPOKsPMO09K626LW8MGAetByniTsQ6wcYQTWAx3IBSpAGk2NRPuveWmZQzd7tANdpkImtVOShnr9CeSVvkogSnfbrtS8J7A0egqj4KwO6pUgHL9eRoFxM5K8c+wTwoW7v1FRoW8fGfG9IPERAr38sOByjQoWsJpS9v5ltaB/+MjwX+qujiAqwmCxnHR Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 04 Jan 2019 17:06:35 -0000 Date: 4 Jan 2019 12:06:35 -0500 Message-ID: From: "John R Levine" To: "Daniel Kahn Gillmor" Cc: spasm@ietf.org, bernie@ietf.hoeneisen.ch In-Reply-To: <87h8eonzxx.fsf@fifthhorseman.net> References: <20190104012415.AA6C3200C425F9@ary.qy> <87h8eonzxx.fsf@fifthhorseman.net> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 04 Jan 2019 17:06:40 -0000 > John, would you be ok with leaving out RFC 6376 (DKIM) if we changed the > charter text to say "end-to-end cryptographic protection" instead of > just "cryptographic protection"? is DKIM ever used by the sender > themselves, instead of by the domain itself (for example, with a > user-specific selector)? That doesn't strike me as a meaningful distinction. We designed DKIM so polciy about assigning selectors and where signatures are added are out of scope. On my mail system, every DKIM signature has a unique selector. On the other hand, I'm pretty sure I know of systems where S/MIME signatures are generated and checked in MTAs and mailing list packages. My preference would be to leave out the prior history catalog completely. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Jan 4 12:49:25 2019 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 A54D1130E9A for ; Fri, 4 Jan 2019 12:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0L20Cjmcnn8 for ; Fri, 4 Jan 2019 12:49:21 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6154A130E8F for ; Fri, 4 Jan 2019 12:49:21 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 5D331F99B; Fri, 4 Jan 2019 15:49:19 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id E27B82027E; Fri, 4 Jan 2019 15:19:48 -0500 (EST) From: Daniel Kahn Gillmor To: John R Levine Cc: spasm@ietf.org, bernie@ietf.hoeneisen.ch In-Reply-To: References: <20190104012415.AA6C3200C425F9@ary.qy> <87h8eonzxx.fsf@fifthhorseman.net> Date: Fri, 04 Jan 2019 15:19:45 -0500 Message-ID: <8736q8npjy.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 04 Jan 2019 20:49:24 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri 2019-01-04 12:06:35 -0500, John R Levine wrote: > That doesn't strike me as a meaningful distinction. We designed DKIM > so polciy about assigning selectors and where signatures are added are > out of scope. On my mail system, every DKIM signature has a unique > selector. Hm, that creates an interesting metadata phone-home situation! Thanks for pointing it out. and taugh.com is a signed zone as well. So you're re-signing your zone with every message sent, or do you have a batch of pre-signed selectors, and you just tick them off and regenerate a batch when you're running low? (apologies for the off-topic nature here -- feel free to reply to me privately on this if you want). > On the other hand, I'm pretty sure I know of systems where S/MIME=20 > signatures are generated and checked in MTAs and mailing list packages. yep, understood. I know such systems exist. How would you expect DKIM signatures to interact with protected encrypted headers? do you think this should be part of the scope of this work in LAMPS? > My preference would be to leave out the prior history catalog completely. Leaving out the prior history catalog works for me, too. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCXC+/4QAKCRBsHx7ezFD6 U5cPAQC+W53AiwYchQxzkcXy/sYAC3D211IjiFY5nR/97XiZBAEAuo3BVlDMdKYe iHy9UMpzMuhM66vonDskxsiMaVUSCAY= =+8jt -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 4 13:20:44 2019 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 AD2D2130E50; Fri, 4 Jan 2019 13:20:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: spasm@ietf.org, draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154663683668.18349.10721321094359754098@ietfa.amsl.com> Date: Fri, 04 Jan 2019 13:20:36 -0800 Archived-At: Subject: [lamps] Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03 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, 04 Jan 2019 21:20:37 -0000 Reviewer: Joel Halpern Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-lamps-hash-of-root-key-cert-extn-03 Reviewer: Joel Halpern Review Date: 2019-01-04 IETF LC End Date: 2019-01-10 IESG Telechat date: Not scheduled for a telechat Summary: This draft is nearly ready for publication as an Informational RFC. Major issues: N/A Minor issues: The explanation at the end of section 5 about the remedy for losing access to the new root key left me confused. It looks like the situation is that there is a certificate out there, with the hash of root key extensions. The certificate owner loses access to the new key pair underlying the hash. The certificate owner clearly has to issue a new key pair. So far, so good. What the text seems to say is to simply issue a new self-signed certificate. There are two possibilities for what is intended. I think the idea is that the new certificate will use the existing key pair (not the promised one, nor another new one) for its own signature, and include a new hash of root key for the newly generated pair. If the certificate owner can do that (I have not dived into the rest of the certificate operations to figure out if that is legal) then it works. Please add some words explaining that better. If the certificate owner can not simply issue a new self-signed certificate with the existing key pair, then I am lost. It appears that the text says that the certificate owner issues a new self-signed certificate using a new key pair. But that will fail the check against the previous certificate hash of root key. I am hoping that it is the first of these alternatives, and all that is needed is clearer explanatory text stating that the new cert uses the existing key pair, and includes a new hash of root key promise. Nits/editorial comments: N/A From nobody Fri Jan 4 14:57:27 2019 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 AB598130EA1 for ; Fri, 4 Jan 2019 14:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTwyUSx4qdXy for ; Fri, 4 Jan 2019 14:57:22 -0800 (PST) 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 8E28B126BED for ; Fri, 4 Jan 2019 14:57:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B3604300A41 for ; Fri, 4 Jan 2019 17:39:04 -0500 (EST) 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 BQNo87DkaKHq for ; Fri, 4 Jan 2019 17:39:02 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 98D8B300400; Fri, 4 Jan 2019 17:39:02 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: <154663683668.18349.10721321094359754098@ietfa.amsl.com> Date: Fri, 4 Jan 2019 17:57:19 -0500 Cc: IETF Gen-ART , spasm@ietf.org, draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <154663683668.18349.10721321094359754098@ietfa.amsl.com> To: Joel Halpern X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03 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, 04 Jan 2019 22:57:25 -0000 Joel: Thanks for the review. > Document: draft-ietf-lamps-hash-of-root-key-cert-extn-03 > Reviewer: Joel Halpern > Review Date: 2019-01-04 > IETF LC End Date: 2019-01-10 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: This draft is nearly ready for publication as an = Informational RFC. >=20 > Major issues: N/A >=20 > Minor issues: > The explanation at the end of section 5 about the remedy for losing = access > to the new root key left me confused. > It looks like the situation is that there is a certificate out there, = with the > hash of root key extensions. The certificate owner loses access to the = new key > pair underlying the hash. The certificate owner clearly has to issue a = new key > pair. So far, so good. >=20 > What the text seems to say is to simply issue a new self-signed = certificate.=20 > There are two possibilities for what is intended. I think the idea is = that the > new certificate will use the existing key pair (not the promised one, = nor > another new one) for its own signature, and include a new hash of root = key for > the newly generated pair. If the certificate owner can do that (I = have not > dived into the rest of the certificate operations to figure out if = that is > legal) then it works. Please add some words explaining that better. = If the > certificate owner can not simply issue a new self-signed certificate = with the > existing key pair, then I am lost. It appears that the text says that = the > certificate owner issues a new self-signed certificate using a new key = pair.=20 > But that will fail the check against the previous certificate hash of = root key. > I am hoping that it is the first of these alternatives, and all that = is needed > is clearer explanatory text stating that the new cert uses the = existing key > pair, and includes a new hash of root key promise. Joel, the Root CA want to start using a different key par, but they have = lost access to the one that was previously generated for that purpose. = So, the remedy is to create a new self-signed certificate with a newly = generated key. Does that help? If so, what would make the paragraph more clear? Russ From nobody Fri Jan 4 16:00:36 2019 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 53DDE130EB4; Fri, 4 Jan 2019 16:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 5X0NDHvEfMVv; Fri, 4 Jan 2019 16:00:17 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 C97DF130EA8; Fri, 4 Jan 2019 16:00:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 43WhcG2VWWzpbmd; Fri, 4 Jan 2019 16:00:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1546646414; bh=34302JSCjLQyPOFWNtXjo2k1dV25NOD1OBKF/EigSxE=; h=Date:Subject:In-Reply-To:From:To:Cc:From; b=m6yoCEvPeXwwcPfCpOtmN5iARplK5+gJZkRIbvHIn/b7R2fqPrEpp9w9IUN94Y1Yp IGwf0XMjgb7E6t9bd4HkoFTHL/ZTD415al3049oOj2ngIelvBnCtuP8TMOO46Zi0eB TzJw2rUtRIN6z6moVHpskGRrIdn0kjD2GA9o/ND8= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [IPv6:2600:380:1877:75b1:bcac:e14f:943e:9b2d] (unknown [IPv6:2600:380:1877:75b1:bcac:e14f:943e:9b2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 43Whc14jRZzpblx; Fri, 4 Jan 2019 16:00:01 -0800 (PST) SavedFromEmail: jmh.direct@joelhalpern.com Date: Fri, 04 Jan 2019 18:42:09 -0500 In-Reply-To: Importance: normal From: "jmh.direct@joelhalpern.com" To: Russ Housley , Joel Halpern Cc: IETF Gen-ART , spasm@ietf.org, draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_532330076118780" Message-Id: <20190105000017.C97DF130EA8@ietfa.amsl.com> Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03 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, 05 Jan 2019 00:00:21 -0000 ----_com.samsung.android.email_532330076118780 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SWYgdGhlIG5ldyBzZWxmLXNpZ25lZCBjZXJ0IHVzZXMgYSBuZXcga2V5LCB3b3VsZG4ndCB0aGF0 IGJlIHJlamVjdGVkIGFzIHZpb2xhdGluZyB0aGUgcHJvbWlzZSBpbiB0aGUgY3VycmVudCBjZXJ0 P8KgIEkgYW0gbWlzc2luZyBzb21ldGhpbmcuClRoYW5rcyxKb2VsCgoKU2VudCB2aWEgdGhlIFNh bXN1bmcgR2FsYXh5IFM3LCBhbiBBVCZUIDRHIExURSBzbWFydHBob25lCi0tLS0tLS0tIE9yaWdp bmFsIG1lc3NhZ2UgLS0tLS0tLS1Gcm9tOiBSdXNzIEhvdXNsZXkgPGhvdXNsZXlAdmlnaWxzZWMu Y29tPiBEYXRlOiAxLzQvMTkgIDE3OjU3ICAoR01ULTA1OjAwKSBUbzogSm9lbCBIYWxwZXJuIDxq bWhAam9lbGhhbHBlcm4uY29tPiBDYzogSUVURiBHZW4tQVJUIDxnZW4tYXJ0QGlldGYub3JnPiwg c3Bhc21AaWV0Zi5vcmcsIGRyYWZ0LWlldGYtbGFtcHMtaGFzaC1vZi1yb290LWtleS1jZXJ0LWV4 dG4uYWxsQGlldGYub3JnLCBJRVRGIDxpZXRmQGlldGYub3JnPiBTdWJqZWN0OiBSZTogR2VuYXJ0 IGxhc3QgY2FsbCByZXZpZXcgb2YKwqAgZHJhZnQtaWV0Zi1sYW1wcy1oYXNoLW9mLXJvb3Qta2V5 LWNlcnQtZXh0bi0wMyAKSm9lbDoKClRoYW5rcyBmb3IgdGhlIHJldmlldy4KCj4gRG9jdW1lbnQ6 IGRyYWZ0LWlldGYtbGFtcHMtaGFzaC1vZi1yb290LWtleS1jZXJ0LWV4dG4tMDMKPiBSZXZpZXdl cjogSm9lbCBIYWxwZXJuCj4gUmV2aWV3IERhdGU6IDIwMTktMDEtMDQKPiBJRVRGIExDIEVuZCBE YXRlOiAyMDE5LTAxLTEwCj4gSUVTRyBUZWxlY2hhdCBkYXRlOiBOb3Qgc2NoZWR1bGVkIGZvciBh IHRlbGVjaGF0Cj4gCj4gU3VtbWFyeTogVGhpcyBkcmFmdCBpcyBuZWFybHkgcmVhZHkgZm9yIHB1 YmxpY2F0aW9uIGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDLgo+IAo+IE1ham9yIGlzc3VlczogTi9B Cj4gCj4gTWlub3IgaXNzdWVzOgo+wqDCoMKgIFRoZSBleHBsYW5hdGlvbiBhdCB0aGUgZW5kIG9m IHNlY3Rpb24gNSBhYm91dCB0aGUgcmVtZWR5IGZvciBsb3NpbmcgYWNjZXNzCj7CoMKgwqAgdG8g dGhlIG5ldyByb290IGtleSBsZWZ0IG1lIGNvbmZ1c2VkLgo+IEl0IGxvb2tzIGxpa2UgdGhlIHNp dHVhdGlvbiBpcyB0aGF0IHRoZXJlIGlzIGEgY2VydGlmaWNhdGUgb3V0IHRoZXJlLCB3aXRoIHRo ZQo+IGhhc2ggb2Ygcm9vdCBrZXkgZXh0ZW5zaW9ucy4gVGhlIGNlcnRpZmljYXRlIG93bmVyIGxv c2VzIGFjY2VzcyB0byB0aGUgbmV3IGtleQo+IHBhaXIgdW5kZXJseWluZyB0aGUgaGFzaC4gVGhl IGNlcnRpZmljYXRlIG93bmVyIGNsZWFybHkgaGFzIHRvIGlzc3VlIGEgbmV3IGtleQo+IHBhaXIu wqAgU28gZmFyLCBzbyBnb29kLgo+IAo+IFdoYXQgdGhlIHRleHQgc2VlbXMgdG8gc2F5IGlzIHRv IHNpbXBseSBpc3N1ZSBhIG5ldyBzZWxmLXNpZ25lZCBjZXJ0aWZpY2F0ZS4gCj4gVGhlcmUgYXJl IHR3byBwb3NzaWJpbGl0aWVzIGZvciB3aGF0IGlzIGludGVuZGVkLiBJIHRoaW5rIHRoZSBpZGVh IGlzIHRoYXQgdGhlCj4gbmV3IGNlcnRpZmljYXRlIHdpbGwgdXNlIHRoZSBleGlzdGluZyBrZXkg cGFpciAobm90IHRoZSBwcm9taXNlZCBvbmUsIG5vcgo+IGFub3RoZXIgbmV3IG9uZSkgZm9yIGl0 cyBvd24gc2lnbmF0dXJlLCBhbmQgaW5jbHVkZSBhIG5ldyBoYXNoIG9mIHJvb3Qga2V5IGZvcgo+ IHRoZSBuZXdseSBnZW5lcmF0ZWQgcGFpci7CoCBJZiB0aGUgY2VydGlmaWNhdGUgb3duZXIgY2Fu IGRvIHRoYXQgKEkgaGF2ZSBub3QKPiBkaXZlZCBpbnRvIHRoZSByZXN0IG9mIHRoZSBjZXJ0aWZp Y2F0ZSBvcGVyYXRpb25zIHRvIGZpZ3VyZSBvdXQgaWYgdGhhdCBpcwo+IGxlZ2FsKSB0aGVuIGl0 IHdvcmtzLsKgIFBsZWFzZSBhZGQgc29tZSB3b3JkcyBleHBsYWluaW5nIHRoYXQgYmV0dGVyLiBJ ZiB0aGUKPiBjZXJ0aWZpY2F0ZSBvd25lciBjYW4gbm90IHNpbXBseSBpc3N1ZSBhIG5ldyBzZWxm LXNpZ25lZCBjZXJ0aWZpY2F0ZSB3aXRoIHRoZQo+IGV4aXN0aW5nIGtleSBwYWlyLCB0aGVuIEkg YW0gbG9zdC7CoCBJdCBhcHBlYXJzIHRoYXQgdGhlIHRleHQgc2F5cyB0aGF0IHRoZQo+IGNlcnRp ZmljYXRlIG93bmVyIGlzc3VlcyBhIG5ldyBzZWxmLXNpZ25lZCBjZXJ0aWZpY2F0ZSB1c2luZyBh IG5ldyBrZXkgcGFpci4gCj4gQnV0IHRoYXQgd2lsbCBmYWlsIHRoZSBjaGVjayBhZ2FpbnN0IHRo ZSBwcmV2aW91cyBjZXJ0aWZpY2F0ZSBoYXNoIG9mIHJvb3Qga2V5Lgo+IEkgYW0gaG9waW5nIHRo YXQgaXQgaXMgdGhlIGZpcnN0IG9mIHRoZXNlIGFsdGVybmF0aXZlcywgYW5kIGFsbCB0aGF0IGlz IG5lZWRlZAo+IGlzIGNsZWFyZXIgZXhwbGFuYXRvcnkgdGV4dCBzdGF0aW5nIHRoYXQgdGhlIG5l dyBjZXJ0IHVzZXMgdGhlIGV4aXN0aW5nIGtleQo+IHBhaXIsIGFuZCBpbmNsdWRlcyBhIG5ldyBo YXNoIG9mIHJvb3Qga2V5IHByb21pc2UuCgpKb2VsLCB0aGUgUm9vdCBDQSB3YW50IHRvIHN0YXJ0 IHVzaW5nIGEgZGlmZmVyZW50IGtleSBwYXIsIGJ1dCB0aGV5IGhhdmUgbG9zdCBhY2Nlc3MgdG8g dGhlIG9uZSB0aGF0IHdhcyBwcmV2aW91c2x5IGdlbmVyYXRlZCBmb3IgdGhhdCBwdXJwb3NlLsKg IFNvLCB0aGUgcmVtZWR5IGlzIHRvIGNyZWF0ZSBhIG5ldyBzZWxmLXNpZ25lZCBjZXJ0aWZpY2F0 ZSB3aXRoIGEgbmV3bHkgZ2VuZXJhdGVkIGtleS4KCkRvZXMgdGhhdCBoZWxwP8KgIElmIHNvLCB3 aGF0IHdvdWxkIG1ha2UgdGhlIHBhcmFncmFwaCBtb3JlIGNsZWFyPwoKUnVzcwoK ----_com.samsung.android.email_532330076118780 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PklmIHRoZSBuZXcgc2VsZi1z aWduZWQgY2VydCB1c2VzIGEgbmV3IGtleSwgd291bGRuJ3QgdGhhdCBiZSByZWplY3RlZCBhcyB2 aW9sYXRpbmcgdGhlIHByb21pc2UgaW4gdGhlIGN1cnJlbnQgY2VydD8mbmJzcDsgSSBhbSBtaXNz aW5nIHNvbWV0aGluZy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoYW5rcyw8L2Rpdj48ZGl2 PkpvZWw8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2IGlkPSJjb21wb3Nlcl9zaWduYXR1cmUiPjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTo4NSU7Y29s b3I6IzU3NTc1NyIgZGlyPSJhdXRvIj5TZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgUzcsIGFu IEFUJmFtcDtUIDRHIExURSBzbWFydHBob25lPC9kaXY+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRp diBzdHlsZT0iZm9udC1zaXplOjEwMCU7Y29sb3I6IzAwMDAwMCI+PCEtLSBvcmlnaW5hbE1lc3Nh Z2UgLS0+PGRpdj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5G cm9tOiBSdXNzIEhvdXNsZXkgJmx0O2hvdXNsZXlAdmlnaWxzZWMuY29tJmd0OyA8L2Rpdj48ZGl2 PkRhdGU6IDEvNC8xOSAgMTc6NTcgIChHTVQtMDU6MDApIDwvZGl2PjxkaXY+VG86IEpvZWwgSGFs cGVybiAmbHQ7am1oQGpvZWxoYWxwZXJuLmNvbSZndDsgPC9kaXY+PGRpdj5DYzogSUVURiBHZW4t QVJUICZsdDtnZW4tYXJ0QGlldGYub3JnJmd0Oywgc3Bhc21AaWV0Zi5vcmcsIGRyYWZ0LWlldGYt bGFtcHMtaGFzaC1vZi1yb290LWtleS1jZXJ0LWV4dG4uYWxsQGlldGYub3JnLCBJRVRGICZsdDtp ZXRmQGlldGYub3JnJmd0OyA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJlOiBHZW5hcnQgbGFzdCBjYWxs IHJldmlldyBvZgombmJzcDsgZHJhZnQtaWV0Zi1sYW1wcy1oYXNoLW9mLXJvb3Qta2V5LWNlcnQt ZXh0bi0wMyA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rpdj5Kb2VsOjxicj48YnI+VGhhbmtzIGZv ciB0aGUgcmV2aWV3Ljxicj48YnI+Jmd0OyBEb2N1bWVudDogZHJhZnQtaWV0Zi1sYW1wcy1oYXNo LW9mLXJvb3Qta2V5LWNlcnQtZXh0bi0wMzxicj4mZ3Q7IFJldmlld2VyOiBKb2VsIEhhbHBlcm48 YnI+Jmd0OyBSZXZpZXcgRGF0ZTogMjAxOS0wMS0wNDxicj4mZ3Q7IElFVEYgTEMgRW5kIERhdGU6 IDIwMTktMDEtMTA8YnI+Jmd0OyBJRVNHIFRlbGVjaGF0IGRhdGU6IE5vdCBzY2hlZHVsZWQgZm9y IGEgdGVsZWNoYXQ8YnI+Jmd0OyA8YnI+Jmd0OyBTdW1tYXJ5OiBUaGlzIGRyYWZ0IGlzIG5lYXJs eSByZWFkeSBmb3IgcHVibGljYXRpb24gYXMgYW4gSW5mb3JtYXRpb25hbCBSRkMuPGJyPiZndDsg PGJyPiZndDsgTWFqb3IgaXNzdWVzOiBOL0E8YnI+Jmd0OyA8YnI+Jmd0OyBNaW5vciBpc3N1ZXM6 PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIGV4cGxhbmF0aW9uIGF0IHRoZSBlbmQgb2Yg c2VjdGlvbiA1IGFib3V0IHRoZSByZW1lZHkgZm9yIGxvc2luZyBhY2Nlc3M8YnI+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyB0byB0aGUgbmV3IHJvb3Qga2V5IGxlZnQgbWUgY29uZnVzZWQuPGJyPiZn dDsgSXQgbG9va3MgbGlrZSB0aGUgc2l0dWF0aW9uIGlzIHRoYXQgdGhlcmUgaXMgYSBjZXJ0aWZp Y2F0ZSBvdXQgdGhlcmUsIHdpdGggdGhlPGJyPiZndDsgaGFzaCBvZiByb290IGtleSBleHRlbnNp b25zLiBUaGUgY2VydGlmaWNhdGUgb3duZXIgbG9zZXMgYWNjZXNzIHRvIHRoZSBuZXcga2V5PGJy PiZndDsgcGFpciB1bmRlcmx5aW5nIHRoZSBoYXNoLiBUaGUgY2VydGlmaWNhdGUgb3duZXIgY2xl YXJseSBoYXMgdG8gaXNzdWUgYSBuZXcga2V5PGJyPiZndDsgcGFpci4mbmJzcDsgU28gZmFyLCBz byBnb29kLjxicj4mZ3Q7IDxicj4mZ3Q7IFdoYXQgdGhlIHRleHQgc2VlbXMgdG8gc2F5IGlzIHRv IHNpbXBseSBpc3N1ZSBhIG5ldyBzZWxmLXNpZ25lZCBjZXJ0aWZpY2F0ZS4gPGJyPiZndDsgVGhl cmUgYXJlIHR3byBwb3NzaWJpbGl0aWVzIGZvciB3aGF0IGlzIGludGVuZGVkLiBJIHRoaW5rIHRo ZSBpZGVhIGlzIHRoYXQgdGhlPGJyPiZndDsgbmV3IGNlcnRpZmljYXRlIHdpbGwgdXNlIHRoZSBl eGlzdGluZyBrZXkgcGFpciAobm90IHRoZSBwcm9taXNlZCBvbmUsIG5vcjxicj4mZ3Q7IGFub3Ro ZXIgbmV3IG9uZSkgZm9yIGl0cyBvd24gc2lnbmF0dXJlLCBhbmQgaW5jbHVkZSBhIG5ldyBoYXNo IG9mIHJvb3Qga2V5IGZvcjxicj4mZ3Q7IHRoZSBuZXdseSBnZW5lcmF0ZWQgcGFpci4mbmJzcDsg SWYgdGhlIGNlcnRpZmljYXRlIG93bmVyIGNhbiBkbyB0aGF0IChJIGhhdmUgbm90PGJyPiZndDsg ZGl2ZWQgaW50byB0aGUgcmVzdCBvZiB0aGUgY2VydGlmaWNhdGUgb3BlcmF0aW9ucyB0byBmaWd1 cmUgb3V0IGlmIHRoYXQgaXM8YnI+Jmd0OyBsZWdhbCkgdGhlbiBpdCB3b3Jrcy4mbmJzcDsgUGxl YXNlIGFkZCBzb21lIHdvcmRzIGV4cGxhaW5pbmcgdGhhdCBiZXR0ZXIuIElmIHRoZTxicj4mZ3Q7 IGNlcnRpZmljYXRlIG93bmVyIGNhbiBub3Qgc2ltcGx5IGlzc3VlIGEgbmV3IHNlbGYtc2lnbmVk IGNlcnRpZmljYXRlIHdpdGggdGhlPGJyPiZndDsgZXhpc3Rpbmcga2V5IHBhaXIsIHRoZW4gSSBh bSBsb3N0LiZuYnNwOyBJdCBhcHBlYXJzIHRoYXQgdGhlIHRleHQgc2F5cyB0aGF0IHRoZTxicj4m Z3Q7IGNlcnRpZmljYXRlIG93bmVyIGlzc3VlcyBhIG5ldyBzZWxmLXNpZ25lZCBjZXJ0aWZpY2F0 ZSB1c2luZyBhIG5ldyBrZXkgcGFpci4gPGJyPiZndDsgQnV0IHRoYXQgd2lsbCBmYWlsIHRoZSBj aGVjayBhZ2FpbnN0IHRoZSBwcmV2aW91cyBjZXJ0aWZpY2F0ZSBoYXNoIG9mIHJvb3Qga2V5Ljxi cj4mZ3Q7IEkgYW0gaG9waW5nIHRoYXQgaXQgaXMgdGhlIGZpcnN0IG9mIHRoZXNlIGFsdGVybmF0 aXZlcywgYW5kIGFsbCB0aGF0IGlzIG5lZWRlZDxicj4mZ3Q7IGlzIGNsZWFyZXIgZXhwbGFuYXRv cnkgdGV4dCBzdGF0aW5nIHRoYXQgdGhlIG5ldyBjZXJ0IHVzZXMgdGhlIGV4aXN0aW5nIGtleTxi cj4mZ3Q7IHBhaXIsIGFuZCBpbmNsdWRlcyBhIG5ldyBoYXNoIG9mIHJvb3Qga2V5IHByb21pc2Uu PGJyPjxicj5Kb2VsLCB0aGUgUm9vdCBDQSB3YW50IHRvIHN0YXJ0IHVzaW5nIGEgZGlmZmVyZW50 IGtleSBwYXIsIGJ1dCB0aGV5IGhhdmUgbG9zdCBhY2Nlc3MgdG8gdGhlIG9uZSB0aGF0IHdhcyBw cmV2aW91c2x5IGdlbmVyYXRlZCBmb3IgdGhhdCBwdXJwb3NlLiZuYnNwOyBTbywgdGhlIHJlbWVk eSBpcyB0byBjcmVhdGUgYSBuZXcgc2VsZi1zaWduZWQgY2VydGlmaWNhdGUgd2l0aCBhIG5ld2x5 IGdlbmVyYXRlZCBrZXkuPGJyPjxicj5Eb2VzIHRoYXQgaGVscD8mbmJzcDsgSWYgc28sIHdoYXQg d291bGQgbWFrZSB0aGUgcGFyYWdyYXBoIG1vcmUgY2xlYXI/PGJyPjxicj5SdXNzPGJyPjxicj48 L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_532330076118780-- From nobody Fri Jan 4 18:41:25 2019 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 708F0130DCD for ; Fri, 4 Jan 2019 18:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5dP_gW6DePv for ; Fri, 4 Jan 2019 18:41:21 -0800 (PST) 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 CA51C130DC8 for ; Fri, 4 Jan 2019 18:41:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EE3AE300AA1 for ; Fri, 4 Jan 2019 21:23:02 -0500 (EST) 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 0_Tt8GMrdyk7 for ; Fri, 4 Jan 2019 21:22:59 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id AFE93300435; Fri, 4 Jan 2019 21:22:58 -0500 (EST) From: Russ Housley Message-Id: <19CF295C-85C1-4692-896F-D89C7DD58581@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_83297BB7-33F0-4CAE-8E61-BECCB5A61D92" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 4 Jan 2019 21:41:15 -0500 In-Reply-To: <20190105000017.C97DF130EA8@ietfa.amsl.com> Cc: Joel Halpern , LAMPS WG , IETF Gen-ART , draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF To: "jmh.direct@joelhalpern.com" References: <20190105000017.C97DF130EA8@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03 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, 05 Jan 2019 02:41:24 -0000 --Apple-Mail=_83297BB7-33F0-4CAE-8E61-BECCB5A61D92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Joel: If access to the key is lost, the commitment is broken, so the Root CA = must make a fresh start using a completely unrelated key. Maybe the = word "remedy" is creating the wrong impression for you. Russ > On Jan 4, 2019, at 6:42 PM, jmh.direct@joelhalpern.com wrote: >=20 > If the new self-signed cert uses a new key, wouldn't that be rejected = as violating the promise in the current cert? I am missing something. >=20 > Thanks, > Joel >=20 >=20 >=20 > Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone >=20 > -------- Original message -------- > From: Russ Housley > Date: 1/4/19 17:57 (GMT-05:00) > To: Joel Halpern > Cc: IETF Gen-ART , spasm@ietf.org, = draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF = > Subject: Re: Genart last call review of = draft-ietf-lamps-hash-of-root-key-cert-extn-03 >=20 > Joel: >=20 > Thanks for the review. >=20 > > Document: draft-ietf-lamps-hash-of-root-key-cert-extn-03 > > Reviewer: Joel Halpern > > Review Date: 2019-01-04 > > IETF LC End Date: 2019-01-10 > > IESG Telechat date: Not scheduled for a telechat > >=20 > > Summary: This draft is nearly ready for publication as an = Informational RFC. > >=20 > > Major issues: N/A > >=20 > > Minor issues: > > The explanation at the end of section 5 about the remedy for = losing access > > to the new root key left me confused. > > It looks like the situation is that there is a certificate out = there, with the > > hash of root key extensions. The certificate owner loses access to = the new key > > pair underlying the hash. The certificate owner clearly has to issue = a new key > > pair. So far, so good. > >=20 > > What the text seems to say is to simply issue a new self-signed = certificate.=20 > > There are two possibilities for what is intended. I think the idea = is that the > > new certificate will use the existing key pair (not the promised = one, nor > > another new one) for its own signature, and include a new hash of = root key for > > the newly generated pair. If the certificate owner can do that (I = have not > > dived into the rest of the certificate operations to figure out if = that is > > legal) then it works. Please add some words explaining that better. = If the > > certificate owner can not simply issue a new self-signed certificate = with the > > existing key pair, then I am lost. It appears that the text says = that the > > certificate owner issues a new self-signed certificate using a new = key pair.=20 > > But that will fail the check against the previous certificate hash = of root key. > > I am hoping that it is the first of these alternatives, and all that = is needed > > is clearer explanatory text stating that the new cert uses the = existing key > > pair, and includes a new hash of root key promise. >=20 > Joel, the Root CA want to start using a different key par, but they = have lost access to the one that was previously generated for that = purpose. So, the remedy is to create a new self-signed certificate with = a newly generated key. >=20 > Does that help? If so, what would make the paragraph more clear? >=20 > Russ >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --Apple-Mail=_83297BB7-33F0-4CAE-8E61-BECCB5A61D92 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Joel:

If = access to the key is lost, the commitment is broken, so the Root CA must = make a fresh start using a completely unrelated key.  Maybe the = word "remedy" is creating the wrong impression for you.

Russ


On Jan 4, 2019, at 6:42 PM, jmh.direct@joelhalpern.com wrote:

If the new self-signed cert = uses a new key, wouldn't that be rejected as violating the promise in = the current cert?  I am missing something.

Thanks,
Joel



Sent via = the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original = message --------
From: Russ Housley <housley@vigilsec.com>
Date: = 1/4/19 17:57 (GMT-05:00)
To: Joel Halpern <jmh@joelhalpern.com>=
Cc: IETF Gen-ART <gen-art@ietf.org>, spasm@ietf.org, draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, = IETF <ietf@ietf.org>=
Subject: Re: Genart last call review of   draft-ietf-lamps-hash-of-root-key-cert-extn-03

Joel:

Thanks for the review.

> = Document: draft-ietf-lamps-hash-of-root-key-cert-extn-03
> Reviewer: Joel Halpern
> Review Date: = 2019-01-04
> IETF LC End Date: 2019-01-10
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: This draft is nearly ready = for publication as an Informational RFC.
>
> Major issues: N/A
>
> = Minor issues:
>    The explanation at = the end of section 5 about the remedy for losing access
>    to the new root key left me = confused.
> It looks like the situation is that there = is a certificate out there, with the
> hash of root key = extensions. The certificate owner loses access to the new key
> pair underlying the hash. The certificate owner clearly = has to issue a new key
> pair.  So far, so = good.
>
> What the text seems to say = is to simply issue a new self-signed certificate.
> = There are two possibilities for what is intended. I think the idea is = that the
> new certificate will use the existing key = pair (not the promised one, nor
> another new one) for = its own signature, and include a new hash of root key for
> the newly generated pair.  If the certificate owner = can do that (I have not
> dived into the rest of the = certificate operations to figure out if that is
> = legal) then it works.  Please add some words explaining that = better. If the
> certificate owner can not simply issue = a new self-signed certificate with the
> existing key = pair, then I am lost.  It appears that the text says that the
> certificate owner issues a new self-signed certificate = using a new key pair.
> But that will fail the check = against the previous certificate hash of root key.
> I = am hoping that it is the first of these alternatives, and all that is = needed
> is clearer explanatory text stating that the = new cert uses the existing key
> pair, and includes a = new hash of root key promise.

Joel, the = Root CA want to start using a different key par, but they have lost = access to the one that was previously generated for that purpose.  = So, the remedy is to create a new self-signed certificate with a newly = generated key.

Does that help?  If so, = what would make the paragraph more clear?

Russ

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

= --Apple-Mail=_83297BB7-33F0-4CAE-8E61-BECCB5A61D92-- From nobody Fri Jan 4 19:10:36 2019 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 C4840130DD1; Fri, 4 Jan 2019 19:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 hxFNwSzyW6N0; Fri, 4 Jan 2019 19:10:17 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 78DAB130DCD; Fri, 4 Jan 2019 19:10:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 43WmqY1dP8z27fjx; Fri, 4 Jan 2019 19:10:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1546657817; bh=VO3P+fkz+6gtNA7oOGLEuvYpWYO1oPpnfQZkIpXPreA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=nBdmH1XRnNb+7CSi5S3FeM0uWs8LxRLrML0He6HOxMHdzRAZXWDah6n0maMKiWZZ1 +VrMzI7e874BUopITYYMnehugiVcowr6hLxxyribJrkfsr5CMQPUmpx/kKANn5Ar6M OAO2UN4H2N3j3iX1RLEebKubsCK530v9QMVATGXY= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 43WmqX2qncz27fjG; Fri, 4 Jan 2019 19:10:16 -0800 (PST) To: Russ Housley Cc: LAMPS WG , IETF Gen-ART , draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF References: <20190105000017.C97DF130EA8@ietfa.amsl.com> <19CF295C-85C1-4692-896F-D89C7DD58581@vigilsec.com> From: "Joel M. Halpern" Message-ID: <838a234a-d069-7f0a-4d3d-2dadb0f651ff@joelhalpern.com> Date: Fri, 4 Jan 2019 22:10:14 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <19CF295C-85C1-4692-896F-D89C7DD58581@vigilsec.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03 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, 05 Jan 2019 03:10:20 -0000 I understand that the issuer has no choice. What I can't see is how any validator will accept the new certificate. The new cert will fail the validation check required by the field in the existing certificate. So it seems that the only remedy is to wait until the exist certificate expires, so that the hash is no longer valid, and then a new cleann cert can be issued that will be accepted. But there is no reference in the "remedy" to waiting for the expiration. In fact, it is only imiplictly stated that the hash expectation is no longer valid once the certificate is expired. Another possibility is that I am completely missing the point of the new field. If the new clean unexpected cert will be accepted, what behavior is improved by having the hash in the current cert. Yours, Joel On 1/4/19 9:41 PM, Russ Housley wrote: > Joel: > > If access to the key is lost, the commitment is broken, so the Root CA > must make a fresh start using a completely unrelated key.  Maybe the > word "remedy" is creating the wrong impression for you. > > Russ > > >> On Jan 4, 2019, at 6:42 PM, jmh.direct@joelhalpern.com >> wrote: >> >> If the new self-signed cert uses a new key, wouldn't that be rejected >> as violating the promise in the current cert?  I am missing something. >> >> Thanks, >> Joel >> >> >> >> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone >> >> -------- Original message -------- >> From: Russ Housley > >> Date: 1/4/19 17:57 (GMT-05:00) >> To: Joel Halpern > >> Cc: IETF Gen-ART >, >> spasm@ietf.org , >> draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org >> , >> IETF > >> Subject: Re: Genart last call review of >> draft-ietf-lamps-hash-of-root-key-cert-extn-03 >> >> Joel: >> >> Thanks for the review. >> >> > Document: draft-ietf-lamps-hash-of-root-key-cert-extn-03 >> > Reviewer: Joel Halpern >> > Review Date: 2019-01-04 >> > IETF LC End Date: 2019-01-10 >> > IESG Telechat date: Not scheduled for a telechat >> > >> > Summary: This draft is nearly ready for publication as an >> Informational RFC. >> > >> > Major issues: N/A >> > >> > Minor issues: >> >    The explanation at the end of section 5 about the remedy for >> losing access >> >    to the new root key left me confused. >> > It looks like the situation is that there is a certificate out >> there, with the >> > hash of root key extensions. The certificate owner loses access to >> the new key >> > pair underlying the hash. The certificate owner clearly has to issue >> a new key >> > pair.  So far, so good. >> > >> > What the text seems to say is to simply issue a new self-signed >> certificate. >> > There are two possibilities for what is intended. I think the idea >> is that the >> > new certificate will use the existing key pair (not the promised >> one, nor >> > another new one) for its own signature, and include a new hash of >> root key for >> > the newly generated pair.  If the certificate owner can do that (I >> have not >> > dived into the rest of the certificate operations to figure out if >> that is >> > legal) then it works.  Please add some words explaining that better. >> If the >> > certificate owner can not simply issue a new self-signed certificate >> with the >> > existing key pair, then I am lost.  It appears that the text says >> that the >> > certificate owner issues a new self-signed certificate using a new >> key pair. >> > But that will fail the check against the previous certificate hash >> of root key. >> > I am hoping that it is the first of these alternatives, and all that >> is needed >> > is clearer explanatory text stating that the new cert uses the >> existing key >> > pair, and includes a new hash of root key promise. >> >> Joel, the Root CA want to start using a different key par, but they >> have lost access to the one that was previously generated for that >> purpose.  So, the remedy is to create a new self-signed certificate >> with a newly generated key. >> >> Does that help?  If so, what would make the paragraph more clear? >> >> Russ >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm > From nobody Sat Jan 5 02:09:13 2019 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 04CF5128CB7 for ; Sat, 5 Jan 2019 02:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3-sC9W1YDTw for ; Sat, 5 Jan 2019 02:09:09 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 A73B5124B0C for ; Sat, 5 Jan 2019 02:09:08 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1gfit5-00038i-KW; Sat, 05 Jan 2019 11:09:03 +0100 Date: Sat, 5 Jan 2019 11:09:03 +0100 (CET) From: bernie@ietf.hoeneisen.ch X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Daniel Kahn Gillmor cc: John Levine , spasm@ietf.org In-Reply-To: <87h8eonzxx.fsf@fifthhorseman.net> Message-ID: References: <20190104012415.AA6C3200C425F9@ary.qy> <87h8eonzxx.fsf@fifthhorseman.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII 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] Draft addition of header protection to the LAMPS charter 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, 05 Jan 2019 10:09:12 -0000 Hi Daniel Thanks for your comments. On Fri, 4 Jan 2019, Daniel Kahn Gillmor wrote: > On Thu 2019-01-03 20:24:15 -0500, John Levine wrote: >> In article you write: >> >>> I think we need to include what's the current situation with this >>> issue, in particular mention that there is a solution in on Standards >>> Track already (RFC5751). How about something like this: > > Bernie, thanks for your proposed change. The second revision of your > text looks fine to me. It is certainly "not widely implemented" -- > iirc, there was only one implementation of it anywhere last i looked. There are certainly more than just one implementation of S/MIME version 3.1 / 3.2 Header Protection in the wild. Unfortunately, most of these implementations offer this as an optional feature only (e.g. to prevent interoperability issues). As a consequence, the Header protection feature is mostly hidden. Outside the S/MIME world I am aware of at least 4 further implementations that use RFC 5751 mechanisms for doing header protection. > FWIW, i lean in Bernie's direction as far as "somewhat underspecified" > because the specification does lead to significant usability gaps (as > identified later in the proposed charter text) due to lack of guidance > about how a receiving MUA should interpret conflicting headers on the > inside and outside of the message's cryptographic envelope ("This entity > SHOULD be presented as the top-level message, taking into account header > merging issues as previously discussed." -- but with no mention of > "merging" anywhere else in the document). Yep, that's another challenge faced. Furthermore, we probably should also look into "feature negotiation" capabilities, e.g. to detect whether the other party is (parties are) capable of handling Header protection messages. cheers, Bernie From nobody Sat Jan 5 04:40:09 2019 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 738611277CC for ; Sat, 5 Jan 2019 04:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSt6G5_Bh3JK for ; Sat, 5 Jan 2019 04:40:05 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 44F3A124B0C for ; Sat, 5 Jan 2019 04:40:04 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1gflF8-0003Qa-It; Sat, 05 Jan 2019 13:39:58 +0100 Date: Sat, 5 Jan 2019 13:39:58 +0100 (CET) From: bernie@ietf.hoeneisen.ch X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: John R Levine cc: Daniel Kahn Gillmor , spasm@ietf.org In-Reply-To: Message-ID: References: <20190104012415.AA6C3200C425F9@ary.qy> <87h8eonzxx.fsf@fifthhorseman.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) 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] Draft addition of header protection to the LAMPS charter 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, 05 Jan 2019 12:40:08 -0000 Hi John Thanks for your feedback On Fri, 4 Jan 2019, John R Levine wrote: > My preference would be to leave out the prior history catalog completely. This is not about prior history. S/MIME Version 3.2 (RFC 5751) defines a mechanism to perform Header Protection, which has some implementations out there. The outcome of the new Charter Item on Header Protection is almost certainly going to have an impact on the currently standardized version and therefore to update RFC 5751 (or rather its bis). Although, I hope (and still believe) we can find a viable solution that remains backwards compatible to S/MIME Version 3.2 (i.e. minor updates and additions to the existing standards only), there are other proposals that suggest to change the way Header Protection is done in S/MIME rather fundamentally. Therefore, I am of the opinion we ought to mention / reference what existing standards are directly going to be affected by the outcome of the new charter item. cheers, Bernie From nobody Sat Jan 5 07:04:23 2019 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 9626A126CB6 for ; Sat, 5 Jan 2019 07:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUakcD3lhyL0 for ; Sat, 5 Jan 2019 07:04:19 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 86E05126C7E for ; Sat, 5 Jan 2019 07:04:18 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1gfnUk-0003ar-1i; Sat, 05 Jan 2019 16:04:14 +0100 Date: Sat, 5 Jan 2019 16:04:14 +0100 (CET) From: bernie@ietf.hoeneisen.ch X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Daniel Kahn Gillmor cc: John R Levine , spasm@ietf.org In-Reply-To: <8736q8npjy.fsf@fifthhorseman.net> Message-ID: References: <20190104012415.AA6C3200C425F9@ary.qy> <87h8eonzxx.fsf@fifthhorseman.net> <8736q8npjy.fsf@fifthhorseman.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII 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] Draft addition of header protection to the LAMPS charter 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, 05 Jan 2019 15:04:21 -0000 Hi John, Daniel, et al. On Fri, 4 Jan 2019, Daniel Kahn Gillmor wrote: > On Fri 2019-01-04 12:06:35 -0500, John R Levine wrote: >> My preference would be to leave out the prior history catalog completely. > > Leaving out the prior history catalog works for me, too. Would the following proposal (HB-3) be more acceptable? I tried to eleminate "redundancy" and removed any assumptions on prior implementations, i.e. short and concise: --- BEGIN HB-3 --- 7. Cryptographic protection of electronic mail headers: A mechanism to address this in S/MIME has been standardized in RFC 5751. The WG shall improve the specification (both for signature and encryption) to close significant privacy, security and usability gaps in cryptographically-protected electronic mail. --- END HB-3 --- cheers Bernie --- PS: Just for reference and better overview the earlier suggestions (with labels added to keep them appart): --- BEGIN HB-2--- 7. Cryptographic protection of electronic mail headers: RFC5751 defines a mechanism that is not widely implemented. Most current implementations of cryptographically-protected electronic mail protect only the body of the message - but not the header part - which leaves significant room for attacks on otherwise-protected messages. The WG shall improve the specification to cryptographic protection of email-headers (both for signature and encryption) to close significant privacy, security and usability gaps in cryptographically-protected electronic mail. --- END HB-2--- --- BEGIN HB-1 --- 7. Cryptographic protection of electronic mail headers: RFC5751 defines a mechanism that is somewhat underspecified and thus not widely implemented. Most current implementations of cryptographically-protected electronic mail protect only the body of the message - but not the header part - which leaves significant room for attacks on otherwise-protected messages. The WG shall improve the specification to cryptographic protection of email-headers (both for integrity and encryption) to close significant privacy, security and usability gaps in cryptographically-protected electronic mail. --- END HB-1 --- --- BEGIN DKG-1 --- 7. Specify a mechanism for the cryptographic protection of e-mail headers. Most current implementations protect only the body of the message, which leaves significant room for attacks against otherwise-protected messages. Cryptographic protection (both for signatures and encryption) which applies to the headers in conjunction with the message body are necessary to close significant security and usability gaps in cryptographically-protected electronic mail. --- END DKG-1 --- Any suggestion I missed? From nobody Sat Jan 5 07:05:41 2019 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 7D309126CB6 for ; Sat, 5 Jan 2019 07:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=1wqyGiFo; dkim=pass (1536-bit key) header.d=taugh.com header.b=Hn9l9r1m Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4lseon_bf0q for ; Sat, 5 Jan 2019 07:05:38 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC95126C7E for ; Sat, 5 Jan 2019 07:05:38 -0800 (PST) Received: (qmail 15492 invoked from network); 5 Jan 2019 15:05:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=3c82.5c30c7c0.k1901; bh=D3zeDlfuUYcuft+HZM5B8Q3u+yFCalUhcI0+Wf7bO7w=; b=1wqyGiFofqvyZ2ww6EEwNzxFTXamqZf0gMPzPeUa29Zts5xQB+nNTOyTOtBKRgOjQ0790Elqz5S+QGgcn6sxkRtaOoPNxHUFbeYJWtw01zHDpEG54oyFGHkVZsk7zlstR9ZpJs6STKAX5LsYSP3nyW7/YZWV1iZLycXdAbktfbxhY2a/K/z+v9XnturRkU689W4GxxCk1itaZl1LgLYT0Sbk8+WfDxeri5wjXdEW3f+gGncYROe838NlOwx7L1Pt DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=3c82.5c30c7c0.k1901; bh=D3zeDlfuUYcuft+HZM5B8Q3u+yFCalUhcI0+Wf7bO7w=; b=Hn9l9r1msnIgxEoTnxf6YsUYIcNTD1s3XYLFJYaaYWGlrtRZChJSIVjLc5wBFYEJDc/Xd4nhrk1g8RKzXuZsFoE5lQ6teNpNOn/AnDynlFKZxT/Xaf7JruQ6sUUHBB6rQu9rH7bjSdLlEl+sJPIDYlxYyBeRT3QHwXyXzib/WCkn4aJzMcs+w4PxBeb5/UcobPyp8vL9Zqldxq8RwtaWXfklchsMq6f01xdSzPxOPxtmQQlo3XfMidfrZOlX46d6 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 05 Jan 2019 15:05:36 -0000 Date: 5 Jan 2019 10:05:36 -0500 Message-ID: From: "John R Levine" To: bernie@ietf.hoeneisen.ch Cc: spasm@ietf.org In-Reply-To: References: <20190104012415.AA6C3200C425F9@ary.qy> <87h8eonzxx.fsf@fifthhorseman.net> <8736q8npjy.fsf@fifthhorseman.net> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 05 Jan 2019 15:05:40 -0000 > --- BEGIN HB-3 --- > > 7. Cryptographic protection of electronic mail headers: A mechanism to > address this in S/MIME has been standardized in RFC 5751. The WG shall > improve the specification (both for signature and encryption) to close > significant privacy, security and usability gaps in > cryptographically-protected electronic mail. > > --- END HB-3 --- Sure. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Jan 5 07:13:33 2019 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 13069129508 for ; Sat, 5 Jan 2019 07:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxVrIIfytjkk for ; Sat, 5 Jan 2019 07:13:30 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8206128D52 for ; Sat, 5 Jan 2019 07:13:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 07051BE38; Sat, 5 Jan 2019 15:13:27 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC76AyySJvRp; Sat, 5 Jan 2019 15:13:25 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 88919BE2C; Sat, 5 Jan 2019 15:13:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1546701205; bh=0u9+myaEnBe5aLsc4vUKy/HhiNVRn20FWM3MCj5Sh10=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=y+VTzl+n3VNTJJVy1s8XJfwNfYQ4ADTFkiA3yaKxnnZRi0fX6+Bx0P7CAfQspSWr2 5DSN37WR5/xefkWg5yxW+nAz78JN5cAM9XxQbZOID+HoYku6cgs7F8GViOcXPBppEB a5W8crnwzW1s5XT6DtQrxxnNCZRLN1jTcW1AlNRQ= To: bernie@ietf.hoeneisen.ch, Daniel Kahn Gillmor Cc: spasm@ietf.org, John R Levine References: <20190104012415.AA6C3200C425F9@ary.qy> <87h8eonzxx.fsf@fifthhorseman.net> <8736q8npjy.fsf@fifthhorseman.net> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Sat, 5 Jan 2019 15:13:24 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lCHGHdp2v3WwvGtFz7U1KVWXz9kGF5UIp" Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 05 Jan 2019 15:13:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lCHGHdp2v3WwvGtFz7U1KVWXz9kGF5UIp Content-Type: multipart/mixed; boundary="HXaeaFBSEsNy9kMP8eHaU9F6TA6OONMKe"; protected-headers="v1" From: Stephen Farrell To: bernie@ietf.hoeneisen.ch, Daniel Kahn Gillmor Cc: spasm@ietf.org, John R Levine Message-ID: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter References: <20190104012415.AA6C3200C425F9@ary.qy> <87h8eonzxx.fsf@fifthhorseman.net> <8736q8npjy.fsf@fifthhorseman.net> In-Reply-To: --HXaeaFBSEsNy9kMP8eHaU9F6TA6OONMKe Content-Type: multipart/mixed; boundary="------------4403327465978B838412B737" Content-Language: en-GB This is a multi-part message in MIME format. --------------4403327465978B838412B737 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Bernie, Clarifying question and a comment. On 05/01/2019 15:04, bernie@ietf.hoeneisen.ch wrote: >=20 > --- BEGIN HB-3 --- >=20 > 7. Cryptographic protection of electronic mail headers: A mechanism to > address this in S/MIME has been standardized in RFC 5751. The WG shall > improve the specification (both for signature and encryption) to close > significant privacy, security and usability gaps in > cryptographically-protected electronic mail. >=20 > --- END HB-3 --- The above reads to me like it constrains the work to be backwards compatible with 5751 if that is possible. Is that your intent? I'd be against having such a constraint myself. If you don't intend such a constraint then I think wording that makes that clear would be better. All told though, I'd prefer if the history was just omitted - I think we're better focusing on what's likely to get implemented, deployed and used, rather than our collective historic failures wrt e2e security for mail. Cheers, S. --------------4403327465978B838412B737 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------4403327465978B838412B737-- --HXaeaFBSEsNy9kMP8eHaU9F6TA6OONMKe-- --lCHGHdp2v3WwvGtFz7U1KVWXz9kGF5UIp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlwwyZQACgkQWrL68XsX K+oaSw/9HAo6X6MyemcteLzKxSeRKH6cKdsrUQ3nbjpamvDdbjZsxa5HLpDZrjC6 vd27MTdz50fUV9fAca5EZiGcrS2xvozKaxMGpRKBTdOtJjqTdrahcfB1tgSohp1I A/VA1ynhLGlDOFLL6MO1yWPI2+cJ1UbTvdVIIZvqE+aI6KbDdnkDI+ITOPnHhyqu Do1r37zQ4JRzELiAZW08F9wsdD2HVMPCUc8kTBQ7xaQMnpk4Kavco3S6yT8J84oe 7kimT7fqVnl2MQv6pj8IGvYITpmdB/B3FXmEZOGYVYluVYn7Q9wsdLMDPgxggCHs HEcY0QoME2DARulKS1vX35gI8Lk0dWk/xycmjsoRTroPJZKOOaR+xgcC4uwQUVFi 34xy3eKIetGpi6UjRXizHlkX2+B25pv6cxsLMx7BFoU0BUcu77H79AIkB7it0Y3b y8iBzsZhYvJeGHNn5BgG1dQziMb/YzajFnFMFz97cs5HzEiSP1lnnvW1Ld9eU/Nn YCAD2151aQQRwdmuJ6UYnvulK/Wx3XfMbrtRmswfe+ATxjA/+Dkw5QHf7njksBJf kRqkN3WywiE7MdKUfaOLUmQKUj9dvaToQOkvlJ++/m09QQI0eLbqjCAsuwBchINC jrjqkEhqRdrPVRQs1djHzzZbUWGNYNQN6MHJSPUzM7fD3NCuzGc= =5+VF -----END PGP SIGNATURE----- --lCHGHdp2v3WwvGtFz7U1KVWXz9kGF5UIp-- From nobody Sat Jan 5 07:29:12 2019 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 7F90612D4F2 for ; Sat, 5 Jan 2019 07:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=z8H0mZ7b; dkim=pass (1536-bit key) header.d=taugh.com header.b=Qr0mrlNm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oacXu-YzXgI for ; Sat, 5 Jan 2019 07:29:08 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF1C012D4EC for ; Sat, 5 Jan 2019 07:29:08 -0800 (PST) Received: (qmail 19588 invoked from network); 5 Jan 2019 15:29:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=4c82.5c30cd43.k1901; bh=Q8rLsVTKAoyhcOotUsG6/DSCxde9r8v6zwJBRw8fKDE=; b=z8H0mZ7bDk83jBwF7CSQR8g9NSpNDSmbD3OJlHiNHprZRb/l6j7Gb2yLe8ygpnR0Rc4v+MxUBl97T0YdE6lY1kHa+KrL22cqVtQnr1WFoC39Dxks9t7k9MHcwaLdoPJ9qtr5ZD9iD9/wPm+KskI+yeckgRb9ddIEhf1oUIaTYEQ8XxNbleuy1k/lKGkiBSN8ujGmCKoBo6t42qDH54p6QZBNTjbuwINolbvpqOZ7Yf9m+AjTcLXMFDUnTe1x7d4D DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=4c82.5c30cd43.k1901; bh=Q8rLsVTKAoyhcOotUsG6/DSCxde9r8v6zwJBRw8fKDE=; b=Qr0mrlNmIhT0TeUjUtCCz8qeu+wKwZuV4BkXdjY6eFZm+Na/q84vqsFSIP2krCUH31MtVOlT0fXPVmvx3Cl1fDZu2nZz1iFf6GvKpviRmE/3AM5CaV0wDU/u+bxW8T/vqXRR6QYi7K7EQigG5kjLueJjvOuR6CvdsKETiVVreXJYXiB85ptBE4A+H1i4JyuOGuE2sBMXxNLGxCVFgjna4tCP4SNJLNP8rPLrsBb0rkWyy+3+WHkALMvVdViWoabv Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 05 Jan 2019 15:29:07 -0000 Date: 5 Jan 2019 10:29:07 -0500 Message-ID: From: "John R Levine" To: "Stephen Farrell" Cc: bernie@ietf.hoeneisen.ch, spasm@ietf.org In-Reply-To: References: <20190104012415.AA6C3200C425F9@ary.qy> <87h8eonzxx.fsf@fifthhorseman.net> <8736q8npjy.fsf@fifthhorseman.net> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 05 Jan 2019 15:29:10 -0000 > The above reads to me like it constrains the work to be backwards > compatible with 5751 if that is possible. > > Is that your intent? > > I'd be against having such a constraint myself. This is a good point. The message wrapping in 5751 makes some fundamental assumptions about the environment in which a message is sent and received. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Jan 5 08:05:00 2019 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 A285712F295 for ; Sat, 5 Jan 2019 08:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVV1Iwbdk0iG for ; Sat, 5 Jan 2019 08:04:56 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 D4678130DC0 for ; Sat, 5 Jan 2019 08:04:55 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1gfoRO-0003nz-9V; Sat, 05 Jan 2019 17:04:50 +0100 Date: Sat, 5 Jan 2019 17:04:50 +0100 (CET) From: bernie@ietf.hoeneisen.ch X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Stephen Farrell cc: Daniel Kahn Gillmor , spasm@ietf.org, John R Levine In-Reply-To: Message-ID: References: <20190104012415.AA6C3200C425F9@ary.qy> <87h8eonzxx.fsf@fifthhorseman.net> <8736q8npjy.fsf@fifthhorseman.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII 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] Draft addition of header protection to the LAMPS charter 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, 05 Jan 2019 16:04:59 -0000 Hi Stephen Thanks for pointing this out. Trying to answer your question: It is _not_ my intent to include any constraints on the solution to the new charter item, in fact IMHO the charter shall _not_ limit the solution space. At the end of the day, we need to be able select the best solution. However, I just noticed what likely triggers your concern with the wording in HB-3, i.e. different people may interpret the text in HB-3 differently (which should to be avoided). Would the following improved suggestion HB-3.1 address your concern adequately? --- BEGIN HB-3.1 --- 7. Cryptographic protection of electronic mail headers: A mechanism to address this in S/MIME has been standardized in RFC 5751. The WG shall define solutions (both for signature and encryption) to close significant privacy, security and usability gaps in cryptographically-protected electronic mail. --- END HB-3.1 --- cheers, Bernie -- http://ucom.ch/ Modern Telephony Solutions and Tech Consulting for Internet Technology On Sat, 5 Jan 2019, Stephen Farrell wrote: > > Hi Bernie, > > Clarifying question and a comment. > > On 05/01/2019 15:04, bernie@ietf.hoeneisen.ch wrote: >> >> --- BEGIN HB-3 --- >> >> 7. Cryptographic protection of electronic mail headers: A mechanism to >> address this in S/MIME has been standardized in RFC 5751. The WG shall >> improve the specification (both for signature and encryption) to close >> significant privacy, security and usability gaps in >> cryptographically-protected electronic mail. >> >> --- END HB-3 --- > > The above reads to me like it constrains the work to be backwards > compatible with 5751 if that is possible. > > Is that your intent? > > I'd be against having such a constraint myself. > > If you don't intend such a constraint then I think wording that > makes that clear would be better. > > All told though, I'd prefer if the history was just omitted - I > think we're better focusing on what's likely to get implemented, > deployed and used, rather than our collective historic failures > wrt e2e security for mail. > > Cheers, > S. > > From nobody Sat Jan 5 08:09:12 2019 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 0A6F5130DC0 for ; Sat, 5 Jan 2019 08:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0Zpyu4tQu8V for ; Sat, 5 Jan 2019 08:09:08 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E76C12E7C1 for ; Sat, 5 Jan 2019 08:09:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C1D21BE38; Sat, 5 Jan 2019 16:09:05 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmvhhz039xcf; Sat, 5 Jan 2019 16:09:04 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 63E4ABE2C; Sat, 5 Jan 2019 16:09:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1546704544; bh=QQo/XyPQy0bbcCF9dobbQ1xiGSiHkWmOmMQX8niMoww=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=gSB1HH2aC4ivi6fjvdxeel83RNS8WikQziDGq9fmvFlp71xBkADO+AUGfb8X+OQaU Tumo+KJlRjfBCLqWODA5eAcqYGURMuiBHSQNhuh8tSnBPvEHvGEwXtTyV6HjNYuKxE bE79skYq5Iu6XYyhuL01CnjRRYB/cyppYaiF/KzA= To: bernie@ietf.hoeneisen.ch Cc: spasm@ietf.org, John R Levine , Daniel Kahn Gillmor References: <20190104012415.AA6C3200C425F9@ary.qy> <87h8eonzxx.fsf@fifthhorseman.net> <8736q8npjy.fsf@fifthhorseman.net> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Sat, 5 Jan 2019 16:09:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dJ77V5xRmVx4t2Zk7yxEP77ybr1jQBrDK" Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 05 Jan 2019 16:09:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dJ77V5xRmVx4t2Zk7yxEP77ybr1jQBrDK Content-Type: multipart/mixed; boundary="1UvDBeDiJ9YujvVE5TyqfOpJuZMoPAkI5"; protected-headers="v1" From: Stephen Farrell To: bernie@ietf.hoeneisen.ch Cc: spasm@ietf.org, John R Levine , Daniel Kahn Gillmor Message-ID: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter References: <20190104012415.AA6C3200C425F9@ary.qy> <87h8eonzxx.fsf@fifthhorseman.net> <8736q8npjy.fsf@fifthhorseman.net> In-Reply-To: --1UvDBeDiJ9YujvVE5TyqfOpJuZMoPAkI5 Content-Type: multipart/mixed; boundary="------------DB4BCEB04A6EC2123482106E" Content-Language: en-GB This is a multi-part message in MIME format. --------------DB4BCEB04A6EC2123482106E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 05/01/2019 16:04, bernie@ietf.hoeneisen.ch wrote: >=20 > --- BEGIN HB-3.1 --- >=20 > 7. Cryptographic protection of electronic mail headers: A mechanism to > address this in S/MIME has been standardized in RFC 5751. The WG shall > define solutions (both for signature and encryption) to close > significant privacy, security and usability gaps in > cryptographically-protected electronic mail. >=20 > --- END HB-3.1 --- Thanks. That would allay my concern yes. That said, I'd still prefer omit the reference as I reckon it's more likely to confuse than help, but the above form is not a problem. Cheers, S. --------------DB4BCEB04A6EC2123482106E Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------DB4BCEB04A6EC2123482106E-- --1UvDBeDiJ9YujvVE5TyqfOpJuZMoPAkI5-- --dJ77V5xRmVx4t2Zk7yxEP77ybr1jQBrDK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlww1p8ACgkQWrL68XsX K+rgLw//d0dm1CXYcw3syiLQXq8Niw2Fo5Pi0GfmWA1GIdcDQUqO+qlFXPU8YmjJ bHKKJhAXuk0MuzlpwX0BGsnLQC0kDHv+yyEe2zY6DOt9pRBbB+gyw9dhsV+34fKs rwcKI4lnBFu6HkJ66cIXys9RM9GWlOo2ikBWdHz6vBMWwh7s8+CPReFPKHFkK6eC Gemupo4ivpH1nhI4n9T1qUP3A5/bTt3hxGVxjJUhuKNwrxxjEgvg+7H+n5H4ehXI qy+fbcqRIf9eu+k26AfkBbMtC16+VcYfw3VR9LP0rS2WZOQ+mNiTEuP/mFqG1mZE YOewqBIqIxJEA89e2KnWnnWgoSnGO7QEwoOJu4IQmfqC5IHp1D73ZKGXig0Aht1Q E3OpFyGPZC8goqi7Nu6YeDu68/ETl8dt+gnRZ+GvljB972h1P6pkjDIwnLnvfVq+ iYFOi1NZPB0XwnI9Z3t1PhTHoZPSvLrC4WHuUAMXfWrsSmav5WP5iZFVdIWObdGu Jt52QHcnDamMnScA5Peza+YQhTyI9xYf+VlGhGAkfIEYFM1fz/Jbn6jzUwcb4vAa 0ZuxmrGEVCyTXt4keY0ExG3lcaY+rrHS9dEIVavUHcI/3TTyPz1GnRXbqTksdg9o 96yeUJpn2X3Zh0o+/2111kj55+exd1wCGE3fUaQ6oSiQZeY9DlY= =0r45 -----END PGP SIGNATURE----- --dJ77V5xRmVx4t2Zk7yxEP77ybr1jQBrDK-- From nobody Sat Jan 5 16:05:50 2019 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 9FC85130DEC for ; Sat, 5 Jan 2019 16:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3A1wo8z8ekox for ; Sat, 5 Jan 2019 16:05:48 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3023A126BED for ; Sat, 5 Jan 2019 16:05:48 -0800 (PST) Received: from fifthhorseman.net (adfb5642.cst.lightpath.net [173.251.86.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id BE0FCF99D; Sat, 5 Jan 2019 19:05:46 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 8ADD22027E; Sat, 5 Jan 2019 17:16:02 -0500 (EST) From: Daniel Kahn Gillmor To: bernie@ietf.hoeneisen.ch Cc: spasm@ietf.org In-Reply-To: References: <20190104012415.AA6C3200C425F9@ary.qy> <87h8eonzxx.fsf@fifthhorseman.net> Date: Sat, 05 Jan 2019 17:16:02 -0500 Message-ID: <87imz2lpi5.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 06 Jan 2019 00:05:50 -0000 On Sat 2019-01-05 11:09:03 +0100, bernie@ietf.hoeneisen.ch wrote: > There are certainly more than just one implementation of S/MIME version > 3.1 / 3.2 Header Protection in the wild. Unfortunately, most of these > implementations offer this as an optional feature only (e.g. to prevent > interoperability issues). As a consequence, the Header protection feature > is mostly hidden. > > Outside the S/MIME world I am aware of at least 4 further implementations > that use RFC 5751 mechanisms for doing header protection. Thanks for doing this research, Bernie. It would inform the discussion if you could point to the implementations you're talking about here. --dkg From nobody Sun Jan 6 09:15:05 2019 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 2F63112896A for ; Sun, 6 Jan 2019 09:15:03 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 t78PMyu4XRgo for ; Sun, 6 Jan 2019 09:15:01 -0800 (PST) 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 52BB912785F for ; Sun, 6 Jan 2019 09:15:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 245A0300AA0 for ; Sun, 6 Jan 2019 11:50:58 -0500 (EST) 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 Q9SH-36ZNpnM for ; Sun, 6 Jan 2019 11:50:55 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id C01403001FD; Sun, 6 Jan 2019 11:50:54 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: <838a234a-d069-7f0a-4d3d-2dadb0f651ff@joelhalpern.com> Date: Sun, 6 Jan 2019 12:09:11 -0500 Cc: LAMPS WG , IETF Gen-ART , draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190105000017.C97DF130EA8@ietfa.amsl.com> <19CF295C-85C1-4692-896F-D89C7DD58581@vigilsec.com> <838a234a-d069-7f0a-4d3d-2dadb0f651ff@joelhalpern.com> To: Joel Halpern X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03 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, 06 Jan 2019 17:15:03 -0000 Joel: As the text already says, the Root CA will need to go through the = process that was used to set up the initial trust anchor. The relying = party will not accept the new self-signed certificate until that is = done, and that process is completely disconnected from the previous = certificate. The paragraph we are discussing is all about handling a failure, and the = new certificate extension is not offering any assistance if the failure = occurs. That is what the paragraph is trying to say. Russ > On Jan 4, 2019, at 10:10 PM, Joel M. Halpern = wrote: >=20 > I understand that the issuer has no choice. > What I can't see is how any validator will accept the new certificate. > The new cert will fail the validation check required by the field in = the existing certificate. > So it seems that the only remedy is to wait until the exist = certificate expires, so that the hash is no longer valid, and then a new = cleann cert can be issued that will be accepted. >=20 > But there is no reference in the "remedy" to waiting for the = expiration. > In fact, it is only imiplictly stated that the hash expectation is no = longer valid once the certificate is expired. >=20 > Another possibility is that I am completely missing the point of the = new field. If the new clean unexpected cert will be accepted, what = behavior is improved by having the hash in the current cert. >=20 > Yours, > Joel >=20 > On 1/4/19 9:41 PM, Russ Housley wrote: >> Joel: >> If access to the key is lost, the commitment is broken, so the Root = CA must make a fresh start using a completely unrelated key. Maybe the = word "remedy" is creating the wrong impression for you. >> Russ >>> On Jan 4, 2019, at 6:42 PM, jmh.direct@joelhalpern.com = wrote: >>>=20 >>> If the new self-signed cert uses a new key, wouldn't that be = rejected as violating the promise in the current cert? I am missing = something. >>>=20 >>> Thanks, >>> Joel >>>=20 >>>=20 >>>=20 >>> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone >>>=20 >>> -------- Original message -------- >>> From: Russ Housley > >>> Date: 1/4/19 17:57 (GMT-05:00) >>> To: Joel Halpern > >>> Cc: IETF Gen-ART >, = spasm@ietf.org , = draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org = , IETF = > >>> Subject: Re: Genart last call review of = draft-ietf-lamps-hash-of-root-key-cert-extn-03 >>>=20 >>> Joel: >>>=20 >>> Thanks for the review. >>>=20 >>> > Document: draft-ietf-lamps-hash-of-root-key-cert-extn-03 >>> > Reviewer: Joel Halpern >>> > Review Date: 2019-01-04 >>> > IETF LC End Date: 2019-01-10 >>> > IESG Telechat date: Not scheduled for a telechat >>> > >>> > Summary: This draft is nearly ready for publication as an = Informational RFC. >>> > >>> > Major issues: N/A >>> > >>> > Minor issues: >>> > The explanation at the end of section 5 about the remedy for = losing access >>> > to the new root key left me confused. >>> > It looks like the situation is that there is a certificate out = there, with the >>> > hash of root key extensions. The certificate owner loses access to = the new key >>> > pair underlying the hash. The certificate owner clearly has to = issue a new key >>> > pair. So far, so good. >>> > >>> > What the text seems to say is to simply issue a new self-signed = certificate. >>> > There are two possibilities for what is intended. I think the idea = is that the >>> > new certificate will use the existing key pair (not the promised = one, nor >>> > another new one) for its own signature, and include a new hash of = root key for >>> > the newly generated pair. If the certificate owner can do that (I = have not >>> > dived into the rest of the certificate operations to figure out if = that is >>> > legal) then it works. Please add some words explaining that = better. If the >>> > certificate owner can not simply issue a new self-signed = certificate with the >>> > existing key pair, then I am lost. It appears that the text says = that the >>> > certificate owner issues a new self-signed certificate using a new = key pair. >>> > But that will fail the check against the previous certificate hash = of root key. >>> > I am hoping that it is the first of these alternatives, and all = that is needed >>> > is clearer explanatory text stating that the new cert uses the = existing key >>> > pair, and includes a new hash of root key promise. >>>=20 >>> Joel, the Root CA want to start using a different key par, but they = have lost access to the one that was previously generated for that = purpose. So, the remedy is to create a new self-signed certificate with = a newly generated key. >>>=20 >>> Does that help? If so, what would make the paragraph more clear? >>>=20 >>> Russ >>>=20 >>> _______________________________________________ >>> Spasm mailing list >>> Spasm@ietf.org >>> https://www.ietf.org/mailman/listinfo/spasm From nobody Sun Jan 6 09:27:22 2019 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 0FCAB12426E; Sun, 6 Jan 2019 09:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 rf69sPEXK-Zs; Sun, 6 Jan 2019 09:27:18 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 54B9012867A; Sun, 6 Jan 2019 09:27:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 43Xlny0SP4zS1Fy; Sun, 6 Jan 2019 09:27:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1546795638; bh=zhBSZijxQctFjvNDULLggvz2ZZIxibK9yAI8nq5otBA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=BSkAncOBQV3WHPjYSNv+ySFPXJJe5lLyNEw7fRucOLY/AEg2wT59Kbk0bTX9Po/US uBDatg4xtdxKYySmYeO5Araz1vvl/yGC0uP770R4wIfJXHE53iMvOVnW5my0u5MJ1D OIYAZdajZyQR0SZG6qfEf/17cLWxloXzfB/x3ivQ= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 43Xlnx03BNzS1Fv; Sun, 6 Jan 2019 09:27:16 -0800 (PST) To: Russ Housley Cc: LAMPS WG , IETF Gen-ART , draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF References: <20190105000017.C97DF130EA8@ietfa.amsl.com> <19CF295C-85C1-4692-896F-D89C7DD58581@vigilsec.com> <838a234a-d069-7f0a-4d3d-2dadb0f651ff@joelhalpern.com> From: "Joel M. Halpern" Message-ID: Date: Sun, 6 Jan 2019 12:27:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03 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, 06 Jan 2019 17:27:20 -0000 Maybe I am missing something simple, but I do not see where the text in section 5 on dealing with a lost promised key says anything about the need to "go through the process that was used to set up the initial trust anchor." All it seems to say is "to deploy a new self-signed certificate." Maybe what is needed is a little elaboration on what that deployment is to be, as it is not the same as deploying a properly promised new key pair. Yours, Joel On 1/6/19 12:09 PM, Russ Housley wrote: > Joel: > > As the text already says, the Root CA will need to go through the process that was used to set up the initial trust anchor. The relying party will not accept the new self-signed certificate until that is done, and that process is completely disconnected from the previous certificate. > > The paragraph we are discussing is all about handling a failure, and the new certificate extension is not offering any assistance if the failure occurs. That is what the paragraph is trying to say. > > Russ > > >> On Jan 4, 2019, at 10:10 PM, Joel M. Halpern wrote: >> >> I understand that the issuer has no choice. >> What I can't see is how any validator will accept the new certificate. >> The new cert will fail the validation check required by the field in the existing certificate. >> So it seems that the only remedy is to wait until the exist certificate expires, so that the hash is no longer valid, and then a new cleann cert can be issued that will be accepted. >> >> But there is no reference in the "remedy" to waiting for the expiration. >> In fact, it is only imiplictly stated that the hash expectation is no longer valid once the certificate is expired. >> >> Another possibility is that I am completely missing the point of the new field. If the new clean unexpected cert will be accepted, what behavior is improved by having the hash in the current cert. >> >> Yours, >> Joel >> >> On 1/4/19 9:41 PM, Russ Housley wrote: >>> Joel: >>> If access to the key is lost, the commitment is broken, so the Root CA must make a fresh start using a completely unrelated key. Maybe the word "remedy" is creating the wrong impression for you. >>> Russ >>>> On Jan 4, 2019, at 6:42 PM, jmh.direct@joelhalpern.com wrote: >>>> >>>> If the new self-signed cert uses a new key, wouldn't that be rejected as violating the promise in the current cert? I am missing something. >>>> >>>> Thanks, >>>> Joel >>>> >>>> >>>> >>>> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone >>>> >>>> -------- Original message -------- >>>> From: Russ Housley > >>>> Date: 1/4/19 17:57 (GMT-05:00) >>>> To: Joel Halpern > >>>> Cc: IETF Gen-ART >, spasm@ietf.org , draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org , IETF > >>>> Subject: Re: Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03 >>>> >>>> Joel: >>>> >>>> Thanks for the review. >>>> >>>>> Document: draft-ietf-lamps-hash-of-root-key-cert-extn-03 >>>>> Reviewer: Joel Halpern >>>>> Review Date: 2019-01-04 >>>>> IETF LC End Date: 2019-01-10 >>>>> IESG Telechat date: Not scheduled for a telechat >>>>> >>>>> Summary: This draft is nearly ready for publication as an Informational RFC. >>>>> >>>>> Major issues: N/A >>>>> >>>>> Minor issues: >>>>> The explanation at the end of section 5 about the remedy for losing access >>>>> to the new root key left me confused. >>>>> It looks like the situation is that there is a certificate out there, with the >>>>> hash of root key extensions. The certificate owner loses access to the new key >>>>> pair underlying the hash. The certificate owner clearly has to issue a new key >>>>> pair. So far, so good. >>>>> >>>>> What the text seems to say is to simply issue a new self-signed certificate. >>>>> There are two possibilities for what is intended. I think the idea is that the >>>>> new certificate will use the existing key pair (not the promised one, nor >>>>> another new one) for its own signature, and include a new hash of root key for >>>>> the newly generated pair. If the certificate owner can do that (I have not >>>>> dived into the rest of the certificate operations to figure out if that is >>>>> legal) then it works. Please add some words explaining that better. If the >>>>> certificate owner can not simply issue a new self-signed certificate with the >>>>> existing key pair, then I am lost. It appears that the text says that the >>>>> certificate owner issues a new self-signed certificate using a new key pair. >>>>> But that will fail the check against the previous certificate hash of root key. >>>>> I am hoping that it is the first of these alternatives, and all that is needed >>>>> is clearer explanatory text stating that the new cert uses the existing key >>>>> pair, and includes a new hash of root key promise. >>>> >>>> Joel, the Root CA want to start using a different key par, but they have lost access to the one that was previously generated for that purpose. So, the remedy is to create a new self-signed certificate with a newly generated key. >>>> >>>> Does that help? If so, what would make the paragraph more clear? >>>> >>>> Russ >>>> >>>> _______________________________________________ >>>> Spasm mailing list >>>> Spasm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spasm > From nobody Sun Jan 6 11:25:34 2019 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 85D3212DDA3 for ; Sun, 6 Jan 2019 11:25:28 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 5uIERfADCeeB for ; Sun, 6 Jan 2019 11:25:25 -0800 (PST) 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 DAF1B12EB11 for ; Sun, 6 Jan 2019 11:25:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F11DE300A98 for ; Sun, 6 Jan 2019 14:07:06 -0500 (EST) 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 HRvs86WMd1Fo for ; Sun, 6 Jan 2019 14:07:03 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 2ED453001FD; Sun, 6 Jan 2019 14:07:03 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: Date: Sun, 6 Jan 2019 14:25:19 -0500 Cc: LAMPS WG , IETF Gen-ART , draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF Content-Transfer-Encoding: quoted-printable Message-Id: <8CC5F804-13A9-4AA8-B15B-B99929E67F7E@vigilsec.com> References: <20190105000017.C97DF130EA8@ietfa.amsl.com> <19CF295C-85C1-4692-896F-D89C7DD58581@vigilsec.com> <838a234a-d069-7f0a-4d3d-2dadb0f651ff@joelhalpern.com> To: Joel Halpern X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03 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, 06 Jan 2019 19:25:29 -0000 Joel: I propose a replacement paragraph. I hope it is more clear on the = points raised on this thread: The Root CA needs to ensure that the public key in the next generation certificate is as strong or stronger than the key that it is replacing. Of course, a significant advance in cryptoanalytic capability can break the yet-to-be-deployed key pair. Such advances are rare and difficult to predict. If such an advance occurs, the Root CA remains committed to the now broken key. This leaves the Root CA with no alternative but to deploy a new self-signed certificate that contains a newly-generated key pair, most likely using a different signature algorithm, in the same manner as the initial self-signed certificate, thus losing the benefits of the Hash Of Root Key certificate extension altogether. Let me know if this helps... Russ > On Jan 6, 2019, at 12:27 PM, Joel M. Halpern = wrote: >=20 > Maybe I am missing something simple, but I do not see where the text = in section 5 on dealing with a lost promised key says anything about the = need to "go through the process that was used to set up the initial = trust anchor." All it seems to say is "to deploy a new self-signed = certificate." Maybe what is needed is a little elaboration on what that = deployment is to be, as it is not the same as deploying a properly = promised new key pair. >=20 > Yours, > Joel >=20 > On 1/6/19 12:09 PM, Russ Housley wrote: >> Joel: >> As the text already says, the Root CA will need to go through the = process that was used to set up the initial trust anchor. The relying = party will not accept the new self-signed certificate until that is = done, and that process is completely disconnected from the previous = certificate. >> The paragraph we are discussing is all about handling a failure, and = the new certificate extension is not offering any assistance if the = failure occurs. That is what the paragraph is trying to say. >> Russ >>> On Jan 4, 2019, at 10:10 PM, Joel M. Halpern = wrote: >>>=20 >>> I understand that the issuer has no choice. >>> What I can't see is how any validator will accept the new = certificate. >>> The new cert will fail the validation check required by the field in = the existing certificate. >>> So it seems that the only remedy is to wait until the exist = certificate expires, so that the hash is no longer valid, and then a new = cleann cert can be issued that will be accepted. >>>=20 >>> But there is no reference in the "remedy" to waiting for the = expiration. >>> In fact, it is only imiplictly stated that the hash expectation is = no longer valid once the certificate is expired. >>>=20 >>> Another possibility is that I am completely missing the point of the = new field. If the new clean unexpected cert will be accepted, what = behavior is improved by having the hash in the current cert. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 1/4/19 9:41 PM, Russ Housley wrote: >>>> Joel: >>>> If access to the key is lost, the commitment is broken, so the Root = CA must make a fresh start using a completely unrelated key. Maybe the = word "remedy" is creating the wrong impression for you. >>>> Russ >>>>> On Jan 4, 2019, at 6:42 PM, jmh.direct@joelhalpern.com = wrote: >>>>>=20 >>>>> If the new self-signed cert uses a new key, wouldn't that be = rejected as violating the promise in the current cert? I am missing = something. >>>>>=20 >>>>> Thanks, >>>>> Joel >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone >>>>>=20 >>>>> -------- Original message -------- >>>>> From: Russ Housley > >>>>> Date: 1/4/19 17:57 (GMT-05:00) >>>>> To: Joel Halpern > >>>>> Cc: IETF Gen-ART >, = spasm@ietf.org , = draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org = , IETF = > >>>>> Subject: Re: Genart last call review of = draft-ietf-lamps-hash-of-root-key-cert-extn-03 >>>>>=20 >>>>> Joel: >>>>>=20 >>>>> Thanks for the review. >>>>>=20 >>>>>> Document: draft-ietf-lamps-hash-of-root-key-cert-extn-03 >>>>>> Reviewer: Joel Halpern >>>>>> Review Date: 2019-01-04 >>>>>> IETF LC End Date: 2019-01-10 >>>>>> IESG Telechat date: Not scheduled for a telechat >>>>>>=20 >>>>>> Summary: This draft is nearly ready for publication as an = Informational RFC. >>>>>>=20 >>>>>> Major issues: N/A >>>>>>=20 >>>>>> Minor issues: >>>>>> The explanation at the end of section 5 about the remedy for = losing access >>>>>> to the new root key left me confused. >>>>>> It looks like the situation is that there is a certificate out = there, with the >>>>>> hash of root key extensions. The certificate owner loses access = to the new key >>>>>> pair underlying the hash. The certificate owner clearly has to = issue a new key >>>>>> pair. So far, so good. >>>>>>=20 >>>>>> What the text seems to say is to simply issue a new self-signed = certificate. >>>>>> There are two possibilities for what is intended. I think the = idea is that the >>>>>> new certificate will use the existing key pair (not the promised = one, nor >>>>>> another new one) for its own signature, and include a new hash of = root key for >>>>>> the newly generated pair. If the certificate owner can do that = (I have not >>>>>> dived into the rest of the certificate operations to figure out = if that is >>>>>> legal) then it works. Please add some words explaining that = better. If the >>>>>> certificate owner can not simply issue a new self-signed = certificate with the >>>>>> existing key pair, then I am lost. It appears that the text says = that the >>>>>> certificate owner issues a new self-signed certificate using a = new key pair. >>>>>> But that will fail the check against the previous certificate = hash of root key. >>>>>> I am hoping that it is the first of these alternatives, and all = that is needed >>>>>> is clearer explanatory text stating that the new cert uses the = existing key >>>>>> pair, and includes a new hash of root key promise. >>>>>=20 >>>>> Joel, the Root CA want to start using a different key par, but = they have lost access to the one that was previously generated for that = purpose. So, the remedy is to create a new self-signed certificate with = a newly generated key. >>>>>=20 >>>>> Does that help? If so, what would make the paragraph more clear? >>>>>=20 >>>>> Russ >>>>>=20 >>>>> _______________________________________________ >>>>> Spasm mailing list >>>>> Spasm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/spasm From nobody Sun Jan 6 14:46:19 2019 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 36FC4130EB3; Sun, 6 Jan 2019 14:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 3kgw3ryO0oMB; Sun, 6 Jan 2019 14:46:03 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 00350130E50; Sun, 6 Jan 2019 14:46:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 43Xtsk4nkHzS1GL; Sun, 6 Jan 2019 14:46:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1546814762; bh=M3PohP3lSyAQs6iEdc15DAGg0gzeMYIKME3bSuaMbdE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ROZTO00DtWnLtSAQihi5JYCpljmGdOqmZQWFTMtfSxB4byTlOsZrgG8TftqGW/Qd9 gPPkeuuwsThPskMnhowPsg9mm4NXOmNfOQT8evJ2iVxzkAkj8MQD3ys6wiTfQqyyR7 DxuIe6K0Pt7V1Wuuio38bhR044Bdjd9BErogb8Ag= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 43Xtsj2cKQzS1GK; Sun, 6 Jan 2019 14:46:00 -0800 (PST) To: Russ Housley Cc: LAMPS WG , IETF Gen-ART , draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF References: <20190105000017.C97DF130EA8@ietfa.amsl.com> <19CF295C-85C1-4692-896F-D89C7DD58581@vigilsec.com> <838a234a-d069-7f0a-4d3d-2dadb0f651ff@joelhalpern.com> <8CC5F804-13A9-4AA8-B15B-B99929E67F7E@vigilsec.com> From: "Joel M. Halpern" Message-ID: Date: Sun, 6 Jan 2019 17:45:59 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <8CC5F804-13A9-4AA8-B15B-B99929E67F7E@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03 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, 06 Jan 2019 22:46:07 -0000 Good enough. I suspect that any effort to refine further would be overkill, given that this is expected to be a rare case. I think the small addition should be enough to alert any implementor or deployer to the challenges they might face. Yours, Joel On 1/6/19 2:25 PM, Russ Housley wrote: > Joel: > > I propose a replacement paragraph. I hope it is more clear on the points raised on this thread: > > The Root CA needs to ensure that the public key in the next > generation certificate is as strong or stronger than the key that it > is replacing. Of course, a significant advance in cryptoanalytic > capability can break the yet-to-be-deployed key pair. Such advances > are rare and difficult to predict. If such an advance occurs, the > Root CA remains committed to the now broken key. This leaves the > Root CA with no alternative but to deploy a new self-signed > certificate that contains a newly-generated key pair, most likely > using a different signature algorithm, in the same manner as the > initial self-signed certificate, thus losing the benefits of the Hash > Of Root Key certificate extension altogether. > > Let me know if this helps... > > Russ > > >> On Jan 6, 2019, at 12:27 PM, Joel M. Halpern wrote: >> >> Maybe I am missing something simple, but I do not see where the text in section 5 on dealing with a lost promised key says anything about the need to "go through the process that was used to set up the initial trust anchor." All it seems to say is "to deploy a new self-signed certificate." Maybe what is needed is a little elaboration on what that deployment is to be, as it is not the same as deploying a properly promised new key pair. >> >> Yours, >> Joel >> >> On 1/6/19 12:09 PM, Russ Housley wrote: >>> Joel: >>> As the text already says, the Root CA will need to go through the process that was used to set up the initial trust anchor. The relying party will not accept the new self-signed certificate until that is done, and that process is completely disconnected from the previous certificate. >>> The paragraph we are discussing is all about handling a failure, and the new certificate extension is not offering any assistance if the failure occurs. That is what the paragraph is trying to say. >>> Russ >>>> On Jan 4, 2019, at 10:10 PM, Joel M. Halpern wrote: >>>> >>>> I understand that the issuer has no choice. >>>> What I can't see is how any validator will accept the new certificate. >>>> The new cert will fail the validation check required by the field in the existing certificate. >>>> So it seems that the only remedy is to wait until the exist certificate expires, so that the hash is no longer valid, and then a new cleann cert can be issued that will be accepted. >>>> >>>> But there is no reference in the "remedy" to waiting for the expiration. >>>> In fact, it is only imiplictly stated that the hash expectation is no longer valid once the certificate is expired. >>>> >>>> Another possibility is that I am completely missing the point of the new field. If the new clean unexpected cert will be accepted, what behavior is improved by having the hash in the current cert. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 1/4/19 9:41 PM, Russ Housley wrote: >>>>> Joel: >>>>> If access to the key is lost, the commitment is broken, so the Root CA must make a fresh start using a completely unrelated key. Maybe the word "remedy" is creating the wrong impression for you. >>>>> Russ >>>>>> On Jan 4, 2019, at 6:42 PM, jmh.direct@joelhalpern.com wrote: >>>>>> >>>>>> If the new self-signed cert uses a new key, wouldn't that be rejected as violating the promise in the current cert? I am missing something. >>>>>> >>>>>> Thanks, >>>>>> Joel >>>>>> >>>>>> >>>>>> >>>>>> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone >>>>>> >>>>>> -------- Original message -------- >>>>>> From: Russ Housley > >>>>>> Date: 1/4/19 17:57 (GMT-05:00) >>>>>> To: Joel Halpern > >>>>>> Cc: IETF Gen-ART >, spasm@ietf.org , draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org , IETF > >>>>>> Subject: Re: Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03 >>>>>> >>>>>> Joel: >>>>>> >>>>>> Thanks for the review. >>>>>> >>>>>>> Document: draft-ietf-lamps-hash-of-root-key-cert-extn-03 >>>>>>> Reviewer: Joel Halpern >>>>>>> Review Date: 2019-01-04 >>>>>>> IETF LC End Date: 2019-01-10 >>>>>>> IESG Telechat date: Not scheduled for a telechat >>>>>>> >>>>>>> Summary: This draft is nearly ready for publication as an Informational RFC. >>>>>>> >>>>>>> Major issues: N/A >>>>>>> >>>>>>> Minor issues: >>>>>>> The explanation at the end of section 5 about the remedy for losing access >>>>>>> to the new root key left me confused. >>>>>>> It looks like the situation is that there is a certificate out there, with the >>>>>>> hash of root key extensions. The certificate owner loses access to the new key >>>>>>> pair underlying the hash. The certificate owner clearly has to issue a new key >>>>>>> pair. So far, so good. >>>>>>> >>>>>>> What the text seems to say is to simply issue a new self-signed certificate. >>>>>>> There are two possibilities for what is intended. I think the idea is that the >>>>>>> new certificate will use the existing key pair (not the promised one, nor >>>>>>> another new one) for its own signature, and include a new hash of root key for >>>>>>> the newly generated pair. If the certificate owner can do that (I have not >>>>>>> dived into the rest of the certificate operations to figure out if that is >>>>>>> legal) then it works. Please add some words explaining that better. If the >>>>>>> certificate owner can not simply issue a new self-signed certificate with the >>>>>>> existing key pair, then I am lost. It appears that the text says that the >>>>>>> certificate owner issues a new self-signed certificate using a new key pair. >>>>>>> But that will fail the check against the previous certificate hash of root key. >>>>>>> I am hoping that it is the first of these alternatives, and all that is needed >>>>>>> is clearer explanatory text stating that the new cert uses the existing key >>>>>>> pair, and includes a new hash of root key promise. >>>>>> >>>>>> Joel, the Root CA want to start using a different key par, but they have lost access to the one that was previously generated for that purpose. So, the remedy is to create a new self-signed certificate with a newly generated key. >>>>>> >>>>>> Does that help? If so, what would make the paragraph more clear? >>>>>> >>>>>> Russ >>>>>> >>>>>> _______________________________________________ >>>>>> Spasm mailing list >>>>>> Spasm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/spasm > From nobody Sun Jan 6 15:03:51 2019 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 5A52C13106C; Sun, 6 Jan 2019 15:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6sCqxB9Hup2; Sun, 6 Jan 2019 15:03:29 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C226613106A; Sun, 6 Jan 2019 15:03:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0DCB4BE2C; Sun, 6 Jan 2019 23:03:26 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FggCw4yanHa; Sun, 6 Jan 2019 23:03:22 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 04D01BE24; Sun, 6 Jan 2019 23:03:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1546815802; bh=fArfKToS+XSgywJNyb8T4hnEp5cxhZ6uA4FbjVDVs2k=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=2UDNcc50l943DsWmqNG0ng/ciqH9xn/JbdXkl6HTJx2nUoYaX3IGgI+pFNCKawF6u 5suAQ/zvw9FmuPIvo0pU8nwxpTaGibqKbOvjnmBB8/ZOi9VDmS8z9NaibhfvBemZ49 TMvnUC9x42OlSVXYY62W0HJUSpQVrbYSf1Pmumtc= To: Russ Housley , Joel Halpern Cc: LAMPS WG , IETF Gen-ART , draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF References: <20190105000017.C97DF130EA8@ietfa.amsl.com> <19CF295C-85C1-4692-896F-D89C7DD58581@vigilsec.com> <838a234a-d069-7f0a-4d3d-2dadb0f651ff@joelhalpern.com> <8CC5F804-13A9-4AA8-B15B-B99929E67F7E@vigilsec.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <4c0b5f67-d1f2-d888-0bd2-c1ff620abfc6@cs.tcd.ie> Date: Sun, 6 Jan 2019 23:03:20 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <8CC5F804-13A9-4AA8-B15B-B99929E67F7E@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="yCtIAcH41JGLfgiSt1gdL3mDiKV72GFuL" Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03 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, 06 Jan 2019 23:03:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --yCtIAcH41JGLfgiSt1gdL3mDiKV72GFuL Content-Type: multipart/mixed; boundary="b6PSrbZsPua1oTY2c9hX8JcoVEpzCGkKr"; protected-headers="v1" From: Stephen Farrell To: Russ Housley , Joel Halpern Cc: LAMPS WG , IETF Gen-ART , draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF Message-ID: <4c0b5f67-d1f2-d888-0bd2-c1ff620abfc6@cs.tcd.ie> Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03 References: <20190105000017.C97DF130EA8@ietfa.amsl.com> <19CF295C-85C1-4692-896F-D89C7DD58581@vigilsec.com> <838a234a-d069-7f0a-4d3d-2dadb0f651ff@joelhalpern.com> <8CC5F804-13A9-4AA8-B15B-B99929E67F7E@vigilsec.com> In-Reply-To: <8CC5F804-13A9-4AA8-B15B-B99929E67F7E@vigilsec.com> --b6PSrbZsPua1oTY2c9hX8JcoVEpzCGkKr Content-Type: multipart/mixed; boundary="------------41E9A21C054DB86438B9D9EC" Content-Language: en-GB This is a multi-part message in MIME format. --------------41E9A21C054DB86438B9D9EC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Russ, I should probably re-read the draft after the latest changes but ISTM that the crypto-break reason for problems here is far far less likely than the mucked-up-HSM reason. I think that means that calling out the more likely reason is perhaps a better plan. In addition, (and this is the bit I need to ponder), if the lifetime of a root key associated with one of these hashes (or commitments/pins) is say 10 years, then I'd say that may make a HSM muck-up sufficiently likely that more than just clarifying text might be needed. For example, perhaps one might say that this extension SHOULD only be used if a new key will go live within a couple of years or something like that. As I said, I'll re-read the latest draft and see if I can suggest some text. (Separately, if anyone has some experience of the relative (in)stability of backup CA keys over that kind of duration, then that'd be useful information.) Cheers, S. On 06/01/2019 19:25, Russ Housley wrote: > Joel: >=20 > I propose a replacement paragraph. I hope it is more clear on the poin= ts raised on this thread: >=20 > The Root CA needs to ensure that the public key in the next > generation certificate is as strong or stronger than the key that it= > is replacing. Of course, a significant advance in cryptoanalytic > capability can break the yet-to-be-deployed key pair. Such advances= > are rare and difficult to predict. If such an advance occurs, the > Root CA remains committed to the now broken key. This leaves the > Root CA with no alternative but to deploy a new self-signed > certificate that contains a newly-generated key pair, most likely > using a different signature algorithm, in the same manner as the > initial self-signed certificate, thus losing the benefits of the Has= h > Of Root Key certificate extension altogether. >=20 > Let me know if this helps... >=20 > Russ >=20 >=20 >> On Jan 6, 2019, at 12:27 PM, Joel M. Halpern wro= te: >> >> Maybe I am missing something simple, but I do not see where the text i= n section 5 on dealing with a lost promised key says anything about the n= eed to "go through the process that was used to set up the initial trust = anchor." All it seems to say is "to deploy a new self-signed certificate= =2E" Maybe what is needed is a little elaboration on what that deploymen= t is to be, as it is not the same as deploying a properly promised new ke= y pair. >> >> Yours, >> Joel >> >> On 1/6/19 12:09 PM, Russ Housley wrote: >>> Joel: >>> As the text already says, the Root CA will need to go through the pro= cess that was used to set up the initial trust anchor. The relying party= will not accept the new self-signed certificate until that is done, and = that process is completely disconnected from the previous certificate. >>> The paragraph we are discussing is all about handling a failure, and = the new certificate extension is not offering any assistance if the failu= re occurs. That is what the paragraph is trying to say. >>> Russ >>>> On Jan 4, 2019, at 10:10 PM, Joel M. Halpern w= rote: >>>> >>>> I understand that the issuer has no choice. >>>> What I can't see is how any validator will accept the new certificat= e. >>>> The new cert will fail the validation check required by the field in= the existing certificate. >>>> So it seems that the only remedy is to wait until the exist certific= ate expires, so that the hash is no longer valid, and then a new cleann c= ert can be issued that will be accepted. >>>> >>>> But there is no reference in the "remedy" to waiting for the expirat= ion. >>>> In fact, it is only imiplictly stated that the hash expectation is n= o longer valid once the certificate is expired. >>>> >>>> Another possibility is that I am completely missing the point of the= new field. If the new clean unexpected cert will be accepted, what beha= vior is improved by having the hash in the current cert. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 1/4/19 9:41 PM, Russ Housley wrote: >>>>> Joel: >>>>> If access to the key is lost, the commitment is broken, so the Root= CA must make a fresh start using a completely unrelated key. Maybe the = word "remedy" is creating the wrong impression for you. >>>>> Russ >>>>>> On Jan 4, 2019, at 6:42 PM, jmh.direct@joelhalpern.com wrote: >>>>>> >>>>>> If the new self-signed cert uses a new key, wouldn't that be rejec= ted as violating the promise in the current cert? I am missing something= =2E >>>>>> >>>>>> Thanks, >>>>>> Joel >>>>>> >>>>>> >>>>>> >>>>>> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone >>>>>> >>>>>> -------- Original message -------- >>>>>> From: Russ Housley > >>>>>> Date: 1/4/19 17:57 (GMT-05:00) >>>>>> To: Joel Halpern = > >>>>>> Cc: IETF Gen-ART >, spa= sm@ietf.org , draft-ietf-lamps-hash-of-root-key-ce= rt-extn.all@ietf.org , IETF > >>>>>> Subject: Re: Genart last call review of draft-ietf-lamps-hash-of= -root-key-cert-extn-03 >>>>>> >>>>>> Joel: >>>>>> >>>>>> Thanks for the review. >>>>>> >>>>>>> Document: draft-ietf-lamps-hash-of-root-key-cert-extn-03 >>>>>>> Reviewer: Joel Halpern >>>>>>> Review Date: 2019-01-04 >>>>>>> IETF LC End Date: 2019-01-10 >>>>>>> IESG Telechat date: Not scheduled for a telechat >>>>>>> >>>>>>> Summary: This draft is nearly ready for publication as an Informa= tional RFC. >>>>>>> >>>>>>> Major issues: N/A >>>>>>> >>>>>>> Minor issues: >>>>>>> The explanation at the end of section 5 about the remedy for l= osing access >>>>>>> to the new root key left me confused. >>>>>>> It looks like the situation is that there is a certificate out th= ere, with the >>>>>>> hash of root key extensions. The certificate owner loses access t= o the new key >>>>>>> pair underlying the hash. The certificate owner clearly has to is= sue a new key >>>>>>> pair. So far, so good. >>>>>>> >>>>>>> What the text seems to say is to simply issue a new self-signed c= ertificate. >>>>>>> There are two possibilities for what is intended. I think the ide= a is that the >>>>>>> new certificate will use the existing key pair (not the promised = one, nor >>>>>>> another new one) for its own signature, and include a new hash of= root key for >>>>>>> the newly generated pair. If the certificate owner can do that (= I have not >>>>>>> dived into the rest of the certificate operations to figure out i= f that is >>>>>>> legal) then it works. Please add some words explaining that bett= er. If the >>>>>>> certificate owner can not simply issue a new self-signed certific= ate with the >>>>>>> existing key pair, then I am lost. It appears that the text says= that the >>>>>>> certificate owner issues a new self-signed certificate using a ne= w key pair. >>>>>>> But that will fail the check against the previous certificate has= h of root key. >>>>>>> I am hoping that it is the first of these alternatives, and all t= hat is needed >>>>>>> is clearer explanatory text stating that the new cert uses the ex= isting key >>>>>>> pair, and includes a new hash of root key promise. >>>>>> >>>>>> Joel, the Root CA want to start using a different key par, but the= y have lost access to the one that was previously generated for that purp= ose. So, the remedy is to create a new self-signed certificate with a ne= wly generated key. >>>>>> >>>>>> Does that help? If so, what would make the paragraph more clear? >>>>>> >>>>>> Russ >>>>>> >>>>>> _______________________________________________ >>>>>> Spasm mailing list >>>>>> Spasm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/spasm >=20 >=20 --------------41E9A21C054DB86438B9D9EC Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------41E9A21C054DB86438B9D9EC-- --b6PSrbZsPua1oTY2c9hX8JcoVEpzCGkKr-- --yCtIAcH41JGLfgiSt1gdL3mDiKV72GFuL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlwyiTkACgkQWrL68XsX K+o30A//fYvwJ10B7XWBsiw6hTSuvPngo94p5+WH0CrfauXCrGPrieVIfTxL67Af mdpEkzjguym226UIwODIA65ai7D45SqeDPX0w4pot1E/fBOR5dBz9cGkxmvgieG+ 3YUzVlyPeK6XGpKStb4BauF6IxA4eOfuHwpPjk6bn5RzfjRtADSf/b1WmWUalaIP qAI8RrViI/kFo1vU5B5EBkYxUeUD9VCI8baE7LziNCb+w1hGi8MX0QRHqEDKua+C 0YQMzVMOoa9zsTKD20D4q4W24FsjV+PvwysOgLz5l7qK5VgS6f+TLXHSc/XNoXEB 6YhXOR05+H8GsOrE1otvN4pxX4FmHlXx5vVCq5Cs690yv7wNZAVE/TEKTauEuAAN UJuppXy4Ve0eRNuP15yNaojskVCS4h89yXtaN7PiZB84YiqplS4/Dx7R29YhbF7e TJfbLU4FyZCTKqg6cmEdJBBg508PKRjvO7JNwtvL10LkeYA0ULY8N8OntZue+9J1 ZvdGReTzv3b0rZ8MUHsYRHG++xlfGxq/OYDX7ZRzt10oSo8O/xwX3OQDFg/UHtHX 0RGmFII/m8aIkAYERC6AjoMzH70LqKKScFqjTHW/7xBSjO/VTaWqEvpe7znoUjYY QUWyumCqKjkgyHEF5+cFjA6T20cRdCNK4Hm5V0UtyUkwIWcBLIg= =1G4n -----END PGP SIGNATURE----- --yCtIAcH41JGLfgiSt1gdL3mDiKV72GFuL-- From nobody Sun Jan 6 16:35:04 2019 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 59E031310BE for ; Sun, 6 Jan 2019 16:35:03 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 0jeGDR_7QsEN for ; Sun, 6 Jan 2019 16:35:01 -0800 (PST) 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 5C128130E3F for ; Sun, 6 Jan 2019 16:35:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 53E4A300AA4 for ; Sun, 6 Jan 2019 19:07:20 -0500 (EST) 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 J7woPPCwe_cf for ; Sun, 6 Jan 2019 19:07:15 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id EBE483001B2; Sun, 6 Jan 2019 19:07:14 -0500 (EST) From: Russ Housley Message-Id: <236EE9E9-4525-4309-B237-400CB19BAC94@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_558E9B47-C1F0-4E91-98E9-6618227BD218"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Sun, 6 Jan 2019 19:25:31 -0500 In-Reply-To: <4c0b5f67-d1f2-d888-0bd2-c1ff620abfc6@cs.tcd.ie> Cc: Joel Halpern , LAMPS WG , IETF Gen-ART , draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF To: Stephen Farrell References: <20190105000017.C97DF130EA8@ietfa.amsl.com> <19CF295C-85C1-4692-896F-D89C7DD58581@vigilsec.com> <838a234a-d069-7f0a-4d3d-2dadb0f651ff@joelhalpern.com> <8CC5F804-13A9-4AA8-B15B-B99929E67F7E@vigilsec.com> <4c0b5f67-d1f2-d888-0bd2-c1ff620abfc6@cs.tcd.ie> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03 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, 07 Jan 2019 00:35:03 -0000 --Apple-Mail=_558E9B47-C1F0-4E91-98E9-6618227BD218 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Stephen: I have text about the need for backup in the Operational Consideration, = which includes the point that HSMs fail. I have text about the significant advance in cryptoanalytic capabilities = in the Security Considerations. Russ > On Jan 6, 2019, at 6:03 PM, Stephen Farrell = wrote: >=20 >=20 > Hi Russ, >=20 > I should probably re-read the draft after the latest changes > but ISTM that the crypto-break reason for problems here is > far far less likely than the mucked-up-HSM reason. I think > that means that calling out the more likely reason is perhaps > a better plan. >=20 > In addition, (and this is the bit I need to ponder), if the > lifetime of a root key associated with one of these hashes > (or commitments/pins) is say 10 years, then I'd say that may > make a HSM muck-up sufficiently likely that more than just > clarifying text might be needed. For example, perhaps one > might say that this extension SHOULD only be used if a new > key will go live within a couple of years or something like > that. As I said, I'll re-read the latest draft and see if > I can suggest some text. (Separately, if anyone has some > experience of the relative (in)stability of backup CA keys > over that kind of duration, then that'd be useful information.) >=20 > Cheers, > S. >=20 > On 06/01/2019 19:25, Russ Housley wrote: >> Joel: >>=20 >> I propose a replacement paragraph. I hope it is more clear on the = points raised on this thread: >>=20 >> The Root CA needs to ensure that the public key in the next >> generation certificate is as strong or stronger than the key that = it >> is replacing. Of course, a significant advance in cryptoanalytic >> capability can break the yet-to-be-deployed key pair. Such = advances >> are rare and difficult to predict. If such an advance occurs, the >> Root CA remains committed to the now broken key. This leaves the >> Root CA with no alternative but to deploy a new self-signed >> certificate that contains a newly-generated key pair, most likely >> using a different signature algorithm, in the same manner as the >> initial self-signed certificate, thus losing the benefits of the = Hash >> Of Root Key certificate extension altogether. >>=20 >> Let me know if this helps... >>=20 >> Russ >>=20 >>=20 >>> On Jan 6, 2019, at 12:27 PM, Joel M. Halpern = wrote: >>>=20 >>> Maybe I am missing something simple, but I do not see where the text = in section 5 on dealing with a lost promised key says anything about the = need to "go through the process that was used to set up the initial = trust anchor." All it seems to say is "to deploy a new self-signed = certificate." Maybe what is needed is a little elaboration on what that = deployment is to be, as it is not the same as deploying a properly = promised new key pair. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 1/6/19 12:09 PM, Russ Housley wrote: >>>> Joel: >>>> As the text already says, the Root CA will need to go through the = process that was used to set up the initial trust anchor. The relying = party will not accept the new self-signed certificate until that is = done, and that process is completely disconnected from the previous = certificate. >>>> The paragraph we are discussing is all about handling a failure, = and the new certificate extension is not offering any assistance if the = failure occurs. That is what the paragraph is trying to say. >>>> Russ >>>>> On Jan 4, 2019, at 10:10 PM, Joel M. Halpern = wrote: >>>>>=20 >>>>> I understand that the issuer has no choice. >>>>> What I can't see is how any validator will accept the new = certificate. >>>>> The new cert will fail the validation check required by the field = in the existing certificate. >>>>> So it seems that the only remedy is to wait until the exist = certificate expires, so that the hash is no longer valid, and then a new = cleann cert can be issued that will be accepted. >>>>>=20 >>>>> But there is no reference in the "remedy" to waiting for the = expiration. >>>>> In fact, it is only imiplictly stated that the hash expectation is = no longer valid once the certificate is expired. >>>>>=20 >>>>> Another possibility is that I am completely missing the point of = the new field. If the new clean unexpected cert will be accepted, what = behavior is improved by having the hash in the current cert. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 1/4/19 9:41 PM, Russ Housley wrote: >>>>>> Joel: >>>>>> If access to the key is lost, the commitment is broken, so the = Root CA must make a fresh start using a completely unrelated key. Maybe = the word "remedy" is creating the wrong impression for you. >>>>>> Russ >>>>>>> On Jan 4, 2019, at 6:42 PM, jmh.direct@joelhalpern.com = wrote: >>>>>>>=20 >>>>>>> If the new self-signed cert uses a new key, wouldn't that be = rejected as violating the promise in the current cert? I am missing = something. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Joel >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone >>>>>>>=20 >>>>>>> -------- Original message -------- >>>>>>> From: Russ Housley > >>>>>>> Date: 1/4/19 17:57 (GMT-05:00) >>>>>>> To: Joel Halpern > >>>>>>> Cc: IETF Gen-ART >, = spasm@ietf.org , = draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org = , IETF = > >>>>>>> Subject: Re: Genart last call review of = draft-ietf-lamps-hash-of-root-key-cert-extn-03 >>>>>>>=20 >>>>>>> Joel: >>>>>>>=20 >>>>>>> Thanks for the review. >>>>>>>=20 >>>>>>>> Document: draft-ietf-lamps-hash-of-root-key-cert-extn-03 >>>>>>>> Reviewer: Joel Halpern >>>>>>>> Review Date: 2019-01-04 >>>>>>>> IETF LC End Date: 2019-01-10 >>>>>>>> IESG Telechat date: Not scheduled for a telechat >>>>>>>>=20 >>>>>>>> Summary: This draft is nearly ready for publication as an = Informational RFC. >>>>>>>>=20 >>>>>>>> Major issues: N/A >>>>>>>>=20 >>>>>>>> Minor issues: >>>>>>>> The explanation at the end of section 5 about the remedy for = losing access >>>>>>>> to the new root key left me confused. >>>>>>>> It looks like the situation is that there is a certificate out = there, with the >>>>>>>> hash of root key extensions. The certificate owner loses access = to the new key >>>>>>>> pair underlying the hash. The certificate owner clearly has to = issue a new key >>>>>>>> pair. So far, so good. >>>>>>>>=20 >>>>>>>> What the text seems to say is to simply issue a new self-signed = certificate. >>>>>>>> There are two possibilities for what is intended. I think the = idea is that the >>>>>>>> new certificate will use the existing key pair (not the = promised one, nor >>>>>>>> another new one) for its own signature, and include a new hash = of root key for >>>>>>>> the newly generated pair. If the certificate owner can do that = (I have not >>>>>>>> dived into the rest of the certificate operations to figure out = if that is >>>>>>>> legal) then it works. Please add some words explaining that = better. If the >>>>>>>> certificate owner can not simply issue a new self-signed = certificate with the >>>>>>>> existing key pair, then I am lost. It appears that the text = says that the >>>>>>>> certificate owner issues a new self-signed certificate using a = new key pair. >>>>>>>> But that will fail the check against the previous certificate = hash of root key. >>>>>>>> I am hoping that it is the first of these alternatives, and all = that is needed >>>>>>>> is clearer explanatory text stating that the new cert uses the = existing key >>>>>>>> pair, and includes a new hash of root key promise. >>>>>>>=20 >>>>>>> Joel, the Root CA want to start using a different key par, but = they have lost access to the one that was previously generated for that = purpose. So, the remedy is to create a new self-signed certificate with = a newly generated key. >>>>>>>=20 >>>>>>> Does that help? If so, what would make the paragraph more = clear? >>>>>>>=20 >>>>>>> Russ >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Spasm mailing list >>>>>>> Spasm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/spasm >>=20 >>=20 > <0x5AB2FAF17B172BEA.asc> --Apple-Mail=_558E9B47-C1F0-4E91-98E9-6618227BD218 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCXDKcewAKCRCK5O7Q9ZwR y0iKAKCt6t85y2UuOwmM8ng0WLBR3/MlZQCdHVMLFjtk1w9vtCqouoYLcbx6EC8= =BSiS -----END PGP SIGNATURE----- --Apple-Mail=_558E9B47-C1F0-4E91-98E9-6618227BD218-- From nobody Mon Jan 7 00:38:32 2019 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 A3D6F129B88 for ; Mon, 7 Jan 2019 00:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHcK29kThdWJ for ; Mon, 7 Jan 2019 00:38:29 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 5E132124BAA for ; Mon, 7 Jan 2019 00:38:28 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1ggQQT-00086s-GS; Mon, 07 Jan 2019 09:38:25 +0100 Date: Mon, 7 Jan 2019 09:38:25 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Daniel Kahn Gillmor cc: spasm@ietf.org In-Reply-To: <87imz2lpi5.fsf@fifthhorseman.net> Message-ID: References: <20190104012415.AA6C3200C425F9@ary.qy> <87h8eonzxx.fsf@fifthhorseman.net> <87imz2lpi5.fsf@fifthhorseman.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) 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] Draft addition of header protection to the LAMPS charter 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, 07 Jan 2019 08:38:32 -0000 Hi Daniel On Sat, 5 Jan 2019, Daniel Kahn Gillmor wrote: > On Sat 2019-01-05 11:09:03 +0100, bernie@ietf.hoeneisen.ch wrote: >> There are certainly more than just one implementation of S/MIME version >> 3.1 / 3.2 Header Protection in the wild. Unfortunately, most of these >> implementations offer this as an optional feature only (e.g. to prevent >> interoperability issues). As a consequence, the Header protection feature >> is mostly hidden. >> >> Outside the S/MIME world I am aware of at least 4 further implementations >> that use RFC 5751 mechanisms for doing header protection. > > Thanks for doing this research, Bernie. Well, my findings are just the result of some rather basic websearch I did some time ago out of curiosity. > It would inform the discussion if you could point to the implementations > you're talking about here. Sure. What I remember from this basic websearch: In S/MIME isode, rebex, and a couple of others (I don't remember the names anymore) appeared to have implemented (full or partial) support for S/MIME version 3.1 / 3.2 Header Protection. Anyways, the total number of implementations is likely rather low. Maybe others on this list have further information on the implementation situation of Header Protection in S/MIME, which they may want to share here. Outside the S/MIME world, I can refer to the four implementations that support pEp (pretty Easy privacy). pEp is specified to perform Header protection (almost) the same way as described in RFC 5751. Said implementations are: - pEp for Outlook as add-on for Microsoft Outlook - pEp for Android (based on a fork of the K9 MUA) - Enigmail/pEp as add-on for Mozilla Thunderbird - pEp for iOS (implemented in a new MUA) Hope that helps. cheers, Bernie From nobody Mon Jan 7 05:58:54 2019 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 5EA32130EA0 for ; Mon, 7 Jan 2019 05:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh1e4vYmTNY9 for ; Mon, 7 Jan 2019 05:58:50 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D158C130E9E for ; Mon, 7 Jan 2019 05:58:50 -0800 (PST) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 05D1FF99A; Mon, 7 Jan 2019 08:58:48 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 815E6201DC; Mon, 7 Jan 2019 08:58:41 -0500 (EST) From: Daniel Kahn Gillmor To: Bernie Hoeneisen Cc: spasm@ietf.org In-Reply-To: References: <20190104012415.AA6C3200C425F9@ary.qy> <87h8eonzxx.fsf@fifthhorseman.net> <87imz2lpi5.fsf@fifthhorseman.net> Date: Mon, 07 Jan 2019 08:58:38 -0500 Message-ID: <87o98sk1rl.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 07 Jan 2019 13:58:54 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon 2019-01-07 09:38:25 +0100, Bernie Hoeneisen wrote: > What I remember from this basic websearch: In S/MIME isode, rebex, and a= =20 > couple of others (I don't remember the names anymore) appeared to=20 > have implemented (full or partial) support for S/MIME version 3.1 / 3.2=20 > Header Protection. Isode is the implementation i was aware of. Can you point me to the rebex implementation? I see: https://www.rebex.net/secure-mail.net/features/s-mime.aspx which says: Please note that only the message body is encrypted - everyone can still read the message headers such as From, To, Date or Subject. If you could remember the names of the couple of others you found, or dig them back up with another websearch, that'd be great. > Anyways, the total number of implementations is likely rather low. yep, that seems to be the consensus on the list. > Maybe others on this list have further information on the implementation= =20 > situation of Header Protection in S/MIME, which they may want to share=20 > here. agreed, that would be great. > Outside the S/MIME world, I can refer to the four implementations that=20 > support pEp (pretty Easy privacy). pEp is specified to perform Header=20 > protection (almost) the same way as described in RFC 5751. RFC 5751 doesn't cover anything outside of S/MIME, but i agree with you =2D- i want whatever header protection LAMPS specifies to work for PGP/MIME as well. Can you explain what the "(almost)" means in the paragraph above? Are you talking about "pEp email format 1" or "pEp email format 2" of https://pep.foundation/dev/repos/internet-drafts/file/tip/pep-email/draft-m= arques-pep-email.mkd or are you talking about something else? it doesn't look to me like either of those two formats specifically are related to RFC 5751-style headers protection -- there's no mention of message/rfc822 content-type in the text, or in the examples, and the headers aren't positioned as headers, but instead they're included "as the first line" of the body (which i confess i don't understand if the Content-Type is anything other than text/plain). Anyway, i don't mean to have the design discussion in this thread, i'm just trying to gather information about what's actually implementing and using RFC 5751, so we can determine how to represent it accurately in the charter text (if we refer to it at all). Can we settle on a single proposal? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCXDNbDgAKCRBsHx7ezFD6 U/jcAP4q0I6UxyZKyTXsZ5f1KjDF2NcRFg+PTfmUU8nSx6oBMgEAslw48rqVsRE3 C04HgaTu27PQ8MsyYktkKFLt0ZwuRAg= =H+OR -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jan 7 08:46:00 2019 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 200DA130F33 for ; Mon, 7 Jan 2019 08:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYo4jFh3yTGb for ; Mon, 7 Jan 2019 08:45:54 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34126130F29 for ; Mon, 7 Jan 2019 08:45:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49898; q=dns/txt; s=iport; t=1546879554; x=1548089154; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=jCYePQ37HrVJxRawP7e+totS7LS81mK4GSi6EIhJTis=; b=PRRTtmjBm812G3VmHwjE/4B3IyF7QFmk0AzX3XFVjaBRG3+HrVbxlH3g jLXyWqJiDdNVnjuBC0ZMxsBR0qdIIm8WCasegbCOLGJJHaHdaP6B5juTo QB1XaKFSUqsDKG45J+Rt0+SFXQewRycOqCGqaNK2J8roIwhDdXaOfj3fo 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAA3gTNc/5ldJa1ZChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYENSC5mgQInCoN1iBqLaIINl24UgWc?= =?us-ascii?q?LAQElhEcCF4FtIjQJDQEDAQECAQECbRwMhUoBAQEEGgkKXAIBCA4DAwEBASE?= =?us-ascii?q?BBgMCAgIwFAkIAgQBEgiDG4EdZA+mO4EvhC0BhXIFjD8XgUA/gRGDEoMeAoE?= =?us-ascii?q?uAQcFBgEDBDgWglKCVwKJLhIShX6GYYpRWgkChxKDR4cOIIFgkA+JYoEHg36?= =?us-ascii?q?IHoMRAhEUgScfOGVxcBWDJ4IkAgEXg0uEWYV6QTEBiDUOF4EIgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.56,451,1539648000"; d="scan'208,217";a="492482197" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jan 2019 16:45:52 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x07Gjqqf017598 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Jan 2019 16:45:52 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 7 Jan 2019 10:45:51 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1395.000; Mon, 7 Jan 2019 10:45:51 -0600 From: "Panos Kampanakis (pkampana)" To: Eric Rescorla , SPASM Thread-Topic: [lamps] Fwd: AD Review draft-ietf-lamps-pkix-shake-06 Thread-Index: AQHUmgTKsLAvzBG4c0a2PWEHEqiUIqWhCj1Q Date: Mon, 7 Jan 2019 16:45:51 +0000 Message-ID: <673fc2acc8394b83961f5d8639a2bfc9@XCH-ALN-010.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.250.174] Content-Type: multipart/alternative; boundary="_000_673fc2acc8394b83961f5d8639a2bfc9XCHALN010ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [lamps] Fwd: AD Review draft-ietf-lamps-pkix-shake-06 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, 07 Jan 2019 16:45:58 -0000 --_000_673fc2acc8394b83961f5d8639a2bfc9XCHALN010ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXJpYywNCg0KVGhhbmsgeW91IGZvciB0aGUgdGhvcm91Z2ggcmV2aWV3LiBJdCBpcyBhcHBy ZWNpYXRlZC4NCkFsbCBhZGRyZXNzZWQuIE1vcmUgZGV0YWlscyBhcmUgYmVsb3cgaW4gdGhpcyBl bWFpbCBpbmxpbmUuIFNlYXJjaCBmb3IgcGs+DQoNCkkgYWxzbyBhZGRlZCB5b3UgaW4gdGhlIGFj a25vd2xlZGdlbWVudHMuIFRoZSB1cGRhdGVkIGRyYWZ0IGlzIGhlcmUgaHR0cHM6Ly9naXRodWIu Y29tL2Nzb3N0by1way9hZGRpbmctc2hha2UtdG8tcGtpeC9ibG9iL21hc3Rlci9kcmFmdC1pZXRm LWxhbXBzLXBraXgtc2hha2UtY3VycmVudC50eHQNCg0KTGV0IG1lIGtub3cgaWYgdGhlcmUgaXMg ZnVydGhlciBmZWVkYmFjay4NCg0KUmdzLA0KUGFub3MNCg0KDQpGcm9tOiBTcGFzbSA8c3Bhc20t Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3Bhc20tYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFs ZiBPZiBFcmljIFJlc2NvcmxhDQpTZW50OiBTYXR1cmRheSwgRGVjZW1iZXIgMjIsIDIwMTggOTo0 MyBBTQ0KVG86IFNQQVNNIDxzcGFzbUBpZXRmLm9yZzxtYWlsdG86c3Bhc21AaWV0Zi5vcmc+Pg0K U3ViamVjdDogW2xhbXBzXSBGd2Q6IEFEIFJldmlldyBkcmFmdC1pZXRmLWxhbXBzLXBraXgtc2hh a2UtMDYNCg0KQ0NpbmcgdGhlIFdHIGJlY2F1c2UgSSB3YXMgd3JvbmcgYWJvdXQgdGhlIGFsaWFz ZXMuDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLQ0KRnJvbTogRXJpYyBS ZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+Pg0KRGF0ZTogRnJpLCBE ZWMgMjEsIDIwMTggYXQgNDoxMSBQTQ0KU3ViamVjdDogQUQgUmV2aWV3IGRyYWZ0LWlldGYtbGFt cHMtcGtpeC1zaGFrZS0wNg0KVG86IDxkcmFmdC1pZXRmLWxhbXBzLXBraXgtc2hha2VAaWV0Zi5v cmc8bWFpbHRvOmRyYWZ0LWlldGYtbGFtcHMtcGtpeC1zaGFrZUBpZXRmLm9yZz4+DQoNClJpY2gg dmVyc2lvbiBvZiB0aGlzIHJldmlldyBhdDoNCmh0dHBzOi8vbW96cGhhYi1pZXRmLmRldnN2Y2Rl di5tb3phd3MubmV0L0Q0OTQ2DQoNCg0KSU1QT1JUQU5UDQpTIDUuMS4yLg0KPiAgICAgIFtTRUMx XSBpZiB0aGV5IGhhdmUgYSBzdGF0ZWQgcG9saWN5IHRoYXQgcmVxdWlyZXMgY29uZm9ybWFuY2Ug dG8NCj4gICAgICB0aGVzZSBzdGFuZGFyZHMuICBUaGVzZSBzdGFuZGFyZHMgbWF5IGhhdmUgbm90 IHNwZWNpZmllZCBTSEFLRTEyOCBhbmQNCj4gICAgICBTSEFLRTI1NiBhcyBoYXNoIGFsZ29yaXRo bSBvcHRpb25zLiAgSG93ZXZlciwgU0hBS0UxMjggYW5kIFNIQUtFMjU2DQo+ICAgICAgd2l0aCBv dXRwdXQgbGVuZ3RoIGJlaW5nIDMyIGFuZCA2NCBvY3RldHMgcmVzcGVjdGl2ZWx5IGFyZQ0KPiAg ICAgIHN1YnRpdHV0aW9ucyBmb3IgMjU2IGFuZCA1MTItYml0IG91dHB1dCBoYXNoIGFsZ29yaXRo bXMgc3VjaCBhcw0KPiAgICAgIFNIQTI1NiBhbmQgU0hBNTEyIHVzZWQgaW4gdGhlIHN0YW5kYXJk cy4NCg0KSSdtIG5vdCBzdXJlIHdoeSB5b3UgYXJlIHJlcXVpcmluZyBkZXRlcm1pbmlzdGljIEVD RFNBIHdpdGggU0hBS0UuIElzDQp0aGVyZSBhbnkgc3BlY2lmaWMgcmVhc29uIHdoeSBpdCdzIG1v cmUgaW1wb3J0YW50IHRoZXJlIHRoYW4gd2l0aA0Kb3RoZXIgaGFzaGVzLg0KDQpwaz4gSXQgaXMg bm90IHNwZWNpZmljIHRvIFNIQUtFLiBXZSBqdXN0IHdhbnRlZCB0byByZWNvbW1lbmQgZGV0ZXJt aW5pc3RpYyBFQ0RTQSBqdXN0IGluIGNhc2UgayBpcyBub3Qg4oCccmFuZG9tIGVub3VnaOKAnS4g VG8gYXZvaWQgY29uZnVzaW9uIEkgcmVuYW1lZCB0aGUgc3Vic2VjdGlvbiDigJxFQ0RTQSBzaWdu YXR1cmVz4oCdIGFuZCByZXBocmFzZWQgdGhlIHBhcmFncmFwaCB0byBzYXkNCuKAnEl0IGlzIFJF Q09NTUVOREVEIHRoYXQgY29uZm9ybWluZyBDQSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBnZW5lcmF0 ZSBFQ0RTQQ0KICAgICAgICAgICAgICAgICAgICAgICAgICB3aXRoIFNIQUtFIHNpZ25hdHVyZXMg aW4gY2VydGlmaWNhdGVzIG9yIENSTHMgZ2VuZXJhdGUgc3VjaCBzaWduYXR1cmVzDQogICAgICAg ICAgICAgICAgICAgICAgICAgIHdpdGggYSBkZXRlcm1pbmlzdGljYWxseSBnZW5lcmF0ZWQsIG5v bi1yYW5kb20gayBpbiBhY2NvcmRhbmNlDQogICAgICAgICAgICAgICAgICAgICAgICAgIHdpdGgg YWxsIHRoZSByZXF1aXJlbWVudHMgc3BlY2lmaWVkIGlu4oCdDQoNCg0KUyA1LjIuDQo+ICAgICAg YW5kIENSTHMuICBDb25mb3JtaW5nIGNsaWVudCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBwcm9jZXNz IFJTQVNTQS1QU1MNCj4gICAgICBvciBFQ0RTQSB3aXRoIFNIQUtFIHB1YmxpYyBrZXkgd2hlbiBw cm9jZXNzaW5nIGNlcnRpZmljYXRlcyBhbmQgQ1JMcw0KPiAgICAgIE1VU1QgcmVjb2duaXplIHRo ZSBjb3JyZXNwb25kaW5nIE9JRHMuICBUaGUgY29udmVudGlvbnMgYW5kIGVuY29kaW5nDQo+ICAg ICAgZm9yIFJTQVNTQS1QU1MgYW5kIEVDRFNBIHB1YmxpYyBrZXlzIGFsZ29yaXRobSBpZGVudGlm aWVycyBhcmUgYXMNCj4gICAgICBzcGVjaWZpZWQgaW4gU2VjdGlvbiAyLjMgb2YgW1JGQzMyNzld LCBTZWN0aW9uIDMuMSBvZiBbUkZDNDA1NV0gYW5kDQo+ICAgICAgU2VjdGlvbiAyLjEgb2YgW1JG QzU0ODBdLg0KDQpUaGlzIGlzIGdvaW5nIHRvIGJlIGEgbWFqb3IgZGlzaW5jZW50aXZlIHRvIHVz ZSBTSEFLRS4gSWYgeW91IGRvbid0DQprbm93IHdoYXQgdGhlIHZlcmlmaWVyIHdpbGwgc3VwcG9y dCwgeW91J3JlIGdvaW5nIHRvIHdhbnQgdG8gdXNlDQpSU0FFbmNyeXB0aW9uLCBidXQgdGhlbiB0 aGlzIHNheXMgeW91IGNhbid0IHVzZSBTSEFLRS4NCg0KcGs+IFlvdSBhcmUgcmlnaHQsIGJ1dCB0 aGlzIGlzIGFsbG93ZWQuIEkgdXBkYXRlZCBzZWN0aW9uIDUuMiB0byByZWZsZWN0IHRoYXQuIE1v cmUgb24gdGhlIHRleHQgSSBhZGRlZCBpcyBiZWxvdyBpbiByZXNwb25zZSB5b3VyIHRoZXIgcnNh RW5jcnlwdGlvbiBjb21tZW50Lg0KDQoNCkNPTU1FTlRTDQpTIDIuDQo+ICAgICAgSW4gdGhlIFNI QS0zIGZhbWlseSwgdHdvIGV4dGVuZGFibGUtb3V0cHV0IGZ1bmN0aW9ucyAoU0hBS0VzKSwNCj4g ICAgICBTSEFLRTEyOCBhbmQgU0hBS0UyNTYsIGFyZSBkZWZpbmVkLiAgRm91ciBvdGhlciBoYXNo IGZ1bmN0aW9uDQo+ICAgICAgaW5zdGFuY2VzLCBTSEEzLTIyNCwgU0hBMy0yNTYsIFNIQTMtMzg0 LCBhbmQgU0hBMy01MTIgYXJlIGFsc28NCj4gICAgICBkZWZpbmVkIGJ1dCBhcmUgb3V0IG9mIHNj b3BlIGZvciB0aGlzIGRvY3VtZW50LiAgQSBTSEFLRSBpcyBhDQo+ICAgICAgdmFyaWFibGUgbGVu Z3RoIGhhc2ggZnVuY3Rpb24uICBUaGUgb3V0cHV0IGxlbmd0aCwgaW4gYml0cywgb2YgYQ0KPiAg ICAgIFNIQUtFIGlzIGRlZmluZWQgYnkgdGhlIGQgcGFyYW1ldGVyLiAgVGhlIGNvcnJlc3BvbmRp bmcgY29sbGlzaW9uIGFuZA0KDQpUaGlzIGlzIHRoZSBmaXJzdCBtZW50aW9uIG9mIGQuIEkgdGhp bmsgeW91IG1lYW4gc29tZXRoaW5nIGxpa2UgIkENClNIQUtFIGlzIGRlZmluZWQgYXMgYSBmdW5j dGlvbiBTSEFLRShNLCBkKSB3aGVyZSB0aGUgb3V0cHV0IGlzIGENCmRpZ2VzdCBvZiBtZXNzYWdl IE0gdGhhdCBpcyBkIGJpdHMgbG9uZykiDQoNCnBrPiBGaXhlZC4g4oCcQSBTSEFLRSBpcyBhIHZh cmlhYmxlIGxlbmd0aCBoYXNoIGZ1bmN0aW9uIGRlZmluZWQgYXMgU0hBS0UoTSwgZCkgd2hlcmUg dGhlDQogICAgICAgICAgICAgIG91dHB1dCBpcyBhIGQtYml0cyBsb25nIGRpZ2VzdCBvZiBtZXNz YWdlIE0uIFRoZSBjb3JyZXNwb25kaW5nIGNvbGxpc2lvbuKAnQ0KDQpTIDQuDQo+ICAgICAgY2Fw aXRhbHMsIGFzIHNob3duIGhlcmUuDQo+DQo+ICAgNC4gIElkZW50aWZpZXJzDQo+DQo+ICAgICAg VGhpcyBzZWN0aW9uIGRlZmluZXMgZm91ciBuZXcgT0lEcyBmb3IgUlNBU1NBLVBTUyBhbmQgRUNE U0Egd2hlbg0KPiAgICAgIFNIQUtFMTI4IGFuZCBTSEFLRTI1NiBhcmUgdXNlZC4gIFRoZSBzYW1l IGFsZ29yaXRobSBpZGVudGlmaWVycyBhcmUNCg0KVGhpcyBpcyBhIGxpdHRsZSB1bmNsZWFyLiBJ IHRoaW5rIHlvdSBtZWFuICJmb3VyIG5ldyBPSURzLCBmb3IgUlNBU1NBLQ0KUFNTIGFuZCBFQ0RT QSB3aXRoIGVhY2ggb2YgU0hBS0UtMTI4IGFuZCBTSEFLRS0yNTYiDQoNCnBrPiBGaXhlZC4NCg0K UyA0Lg0KPiAgICAgIGZvciBlYWNoIHVzZSBvZiBTSEFLRTEyOCBvciBTSEFLRTI1NiBpbiBSU0FT U0EtUFNTIGFuZCBFQ0RTQS4gIEluDQo+ICAgICAgc3VtbWFyeSwgd2hlbiBoYXNoaW5nIG1lc3Nh Z2VzIHRvIGJlIHNpZ25lZCwgb3V0cHV0IGxlbmd0aHMgb2YNCj4gICAgICBTSEFLRTEyOCBhbmQg U0hBS0UyNTYgYXJlIDI1NiBhbmQgNTEyIGJpdHMgcmVzcGVjdGl2ZWx5LiAgV2hlbiB0aGUNCj4g ICAgICBTSEFLRXMgYXJlIHVzZWQgYXMgbWFzayBnZW5lcmF0aW9uIGZ1bmN0aW9ucyBSU0FTU0Et UFNTLCB0aGVpciBvdXRwdXQNCj4gICAgICBsZW5ndGggaXMgKG4gLSAyNjQpIG9yIChuIC0gNTIw KSBiaXRzIHJlc3BlY3RpdmVseSwgd2hlcmUgbiBpcyBhIFJTQQ0KPiAgICAgIG1vZHVsdXMgc2l6 ZSBpbiBiaXRzLg0KDQoibiBpcyB0aGUgUlNBIG1vZHVsdXMgc2l6ZSBpbiBiaXRzIg0KDQpwaz4g Rml4ZWQuDQoNClMgNS4xLg0KPiAgIDUuMS4gIFNpZ25hdHVyZXMNCj4NCj4gICAgICBTaWduYXR1 cmVzIGNhbiBiZSBwbGFjZWQgaW4gYSBudW1iZXIgb2YgZGlmZmVyZW50IEFTTi4xIHN0cnVjdHVy ZXMuDQo+ICAgICAgVGhlIHRvcCBsZXZlbCBzdHJ1Y3R1cmUgZm9yIGFuIFguNTA5IGNlcnRpZmlj YXRlLCB0byBpbGx1c3RyYXRlIGhvdw0KPiAgICAgIHNpZ25hdHVyZXMgYXJlIGZyZXF1ZW50bHkg ZW5jb2RlZCB3aXRoIGFuIGFsZ29yaXRobSBpZGVudGlmaWVyIGFuZCBhDQo+ICAgICAgbG9jYXRp b24gZm9yIHRoZSBzaWduYXR1cmUsIGlzDQoNClRoaXMgc2VudGVuY2UgaXMgdW5ncmFtbWF0aWNh bA0KDQpwaz4gRml4ZWQuIFJlcGhyYXNlZCB0byDigJxJbiBhbiBYLjUwOSBjZXJ0aWZpY2F0ZSBh IHNpZ25hdHVyZSBpcyBlbmNvZGVkIHdpdGggYW4NCiAgICAgICAgICAgICAgICAgICAgICAgIGFs Z29yaXRobSBpZGVudGlmaWVyIGluIHRoZSBzaWduYXR1cmVBbGdvcml0aG0gYXR0cmlidXRlIGFu ZA0KICAgICAgICAgICAgICAgICAgICAgICAgYSBzaWduYXR1cmVWYWx1ZSB0aGF0IGNvbnRhaW5z IHRoZSBhY3R1YWwgc2lnbmF0dXJlLuKAnQ0KDQoNClMgNS4xLg0KPiAgICAgICAgICAgIHNpZ25h dHVyZVZhbHVlICAgICAgIEJJVCBTVFJJTkcgIH0NCj4NCj4gICAgICBUaGUgaWRlbnRpZmllcnMg ZGVmaW5lZCBpbiBTZWN0aW9uIDQgY2FuIGJlIHVzZWQgYXMgdGhlDQo+ICAgICAgQWxnb3JpdGht SWRlbnRpZmllciBpbiB0aGUgc2lnbmF0dXJlQWxnb3JpdGhtIGZpZWxkIGluIHRoZSBzZXF1ZW5j ZQ0KPiAgICAgIENlcnRpZmljYXRlIGFuZCB0aGUgc2lnbmF0dXJlIGZpZWxkIGluIHRoZSBzZXF1 ZW5jZSB0YnNDZXJ0aWZpY2F0ZSBpbg0KPiAgICAgIFguNTA5IFtSRkM1MjgwXS4NCg0KV2hhdCBn b2VzIGluICJwYXJhbWV0ZXJzIj8NCg0KcGs+IEZpeGVkLiBBZGRlZCB0ZXh0IOKAnFRoZSBwYXJh bWV0ZXJzIG9mIHRoZXNlIHNpZ25hdHVyZSBhbGdvcml0aG1zIGFyZSBhYnNlbnQgYXMgZXhwbGFp bmVkDQogICAgICAgICAgICAgICAgICAgICAgICBpbiBTZWN0aW9uIDQu4oCdDQoNCg0KUyA1LjEu DQo+ICAgICAgRUNEU0Egd2l0aCBTSEFLRSBzaWduYXR1cmVzIGluIGNlcnRpZmljYXRlcyBhbmQg Q1JMcy4gIENvbmZvcm1pbmcNCj4gICAgICBjbGllbnQgaW1wbGVtZW50YXRpb25zIHRoYXQgcHJv Y2VzcyBSU0FTU0EtUFNTIG9yIEVDRFNBIHdpdGggU0hBS0UNCj4gICAgICBzaWduYXR1cmVzIHdo ZW4gcHJvY2Vzc2luZyBjZXJ0aWZpY2F0ZXMgYW5kIENSTHMgTVVTVCByZWNvZ25pemUgdGhlDQo+ ICAgICAgY29ycmVzcG9uZGluZyBPSURzLiAgRW5jb2RpbmcgcnVsZXMgZm9yIFJTQVNTQS1QU1Mg YW5kIEVDRFNBDQo+ICAgICAgc2lnbmF0dXJlIHZhbHVlcyBhcmUgc3BlY2lmaWVkIGluIFtSRkM0 MDU1XSBhbmQgW1JGQzU0ODBdDQo+ICAgICAgcmVzcGVjdGl2ZWx5Lg0KDQpJcyBpdCBmb3JiaWRk ZW4gdG8gdmVyaWZ5IFJTQVBTU0EvU0hBS0Ugc2lnbmF0dXJlcyB3aXRoIFJTQUVuY3J5cHRpb24N CmluIHRoZSBjZXJ0PyBJIGV4cGVjdCBub3QuDQoNCnBrPiBJdCBpcyBhbGxvd2VkIHRvIHVzZSBy c2FFbmNyeXB0aW9uIHB1YmxpYyBrZXkgd2l0aCBhbiBSU0FTU0EtUFNTIHNpZ25hdHVyZS4gSSB1 cGRhdGVkIHNlY3Rpb24gNS4yIHRvIHJlZmxlY3QgdGhhdC4gSXQgbm93IHNheXMg4oCcVHJhZGl0 aW9uYWxseSwgdGhlIHJzYUVuY3J5cHRpb24gb2JqZWN0IGlkZW50aWZpZXIgaXMgdXNlZCB0bw0K ICAgaWRlbnRpZnkgUlNBIHB1YmxpYyBrZXlzLiAgVGhlIHJzYUVuY3J5cHRpb24gb2JqZWN0IGlk ZW50aWZpZXINCiAgIGNvbnRpbnVlcyB0byBpZGVudGlmeSB0aGUgc3ViamVjdCBwdWJsaWMga2V5 IHdoZW4gdGhlIFJTQSBwcml2YXRlIGtleQ0KICAgb3duZXIgZG9lcyBub3Qgd2lzaCB0byBsaW1p dCB0aGUgdXNlIG9mIHRoZSBwdWJsaWMga2V5IGV4Y2x1c2l2ZWx5IHRvDQogICBSU0FTU0EtUFNT IHdpdGggU0hBS0VzLiAgV2hlbiB0aGUgUlNBIHByaXZhdGUga2V5IG93bmVyIHdpc2hlcyB0bw0K ICAgbGltaXQgdGhlIHVzZSBvZiB0aGUgcHVibGljIGtleSBleGNsdXNpdmVseSB0byBSU0FTU0Et UFNTIHdpdGgNCiAgIFNIQUtFcywgdGhlIEFsZ29yaXRobUlkZW50aWZpZXJzIGZvciBSU0FTU0Et UFNTIGRlZmluZWQgaW4gU2VjdGlvbiA0DQogICBTSE9VTEQgYmUgdXNlZCBhcyB0aGUgYWxnb3Jp dGhtIGZpZWxkIGluIHRoZSBTdWJqZWN0UHVibGljS2V5SW5mbw0KICAgc2VxdWVuY2UgW1JGQzUy ODBdLiAgQ29uZm9ybWluZyBjbGllbnQgaW1wbGVtZW50YXRpb25zIHRoYXQgcHJvY2Vzcw0KICAg UlNBU1NBLVBTUyBFQ0RTQSB3aXRoIFNIQUtFIHB1YmxpYyBrZXlzIHdoZW4gcHJvY2Vzc2luZyBj ZXJ0aWZpY2F0ZXMNCiAgIGFuZCBDUkxzIE1VU1QgcmVjb2duaXplIHRoZSBjb3JyZXNwb25kaW5n IE9JRHMu4oCdDQoNCg0KUyA1LjEuMS4NCj4gICAgICBzZWVkIGZyb20gd2hpY2ggbWFzayBpcyBn ZW5lcmF0ZWQsIGFuIG9jdGV0IHN0cmluZyBbUkZDODAxN10uICBUaGUNCj4gICAgICBvdXRwdXQg bGVuZ3RoIGlzIChuIC0gMjY0KS84IG9yIChuIC0gNTIwKS84IGJ5dGVzIHJlc3BlY3RpdmVseSwg d2hlcmUNCj4gICAgICBuIGlzIHRoZSBSU0EgbW9kdWx1cyBpbiBiaXRzLiAgRm9yIGV4YW1wbGUs IHdoZW4gUlNBIG1vZHVsdXMgbiBpcw0KPiAgICAgIDIwNDgsIHRoZSBvdXRwdXQgbGVuZ3RoIG9m IFNIQUtFMTI4IG9yIFNIQUtFMjU2IGFzIHRoZSBNR0Ygd2lsbCBiZQ0KPiAgICAgIDIyMyBvciAx OTEtYml0cyB3aGVuIGlkLVJTQVNTQS1QU1MtU0hBS0UxMjggb3IgaWQtUlNBU1NBLVBTUy1TSEFL RTI1Ng0KPiAgICAgIGlzIHVzZWQgcmVzcGVjdGl2ZWx5Lg0KDQpJIHRoaW5rIHlvdSBhcmUgbWl4 aW5nIGJpdHMgYW5kIGJ5dGVzIGhlcmUsIGJlY2F1c2UgMjA0OCAtIDI2NCAhPSAyMjMuDQoNCkl0 IHdvdWxkIGFsc28gYmUgaGVscGZ1bCB0byBleHBsYWluIHdoYXQncyBnb2luZyBvbiBoZXJlLCBi eQ0KZXhwbGFpbmluZyBob3cgdGhlc2UgdmFsdWVzIGFyZSBjb21wdXRlZC4NCg0KcGs+IEZpeGVk LiBSZXBocmFzZWQgYXMg4oCcQXMNCiAgIGV4cGxhaW5lZCBpbiBTdGVwIDkgb2Ygc2VjdGlvbiA5 LjEuMSBvZiBbUkZDODAxN10sIHRoZSBvdXRwdXQgbGVuZ3RoDQogICBvZiB0aGUgTUdGIGlzIGVt TGVuIC0gaExlbiAtIDEgYnl0ZXMuIGVtTGVuIGlzIHRoZSBtYXhpbXVtIG1lc3NhZ2UNCiAgIGxl bmd0aCBjZWlsKChuLTEpLzgpLCB3aGVyZSBuIGlzIHRoZSBSU0EgbW9kdWx1cyBpbiBiaXRzLiBo TGVuIGlzIDMyDQogICBhbmQgNjQtYnl0ZXMgZm9yIGlkLVJTQVNTQS1QU1MtU0hBS0UxMjggYW5k IGlkLVJTQVNTQS1QU1MtU0hBS0UyNTYNCiAgIHJlc3BlY3RpdmVseS4gIFRodXMgd2hlbiBTSEFL RSBpcyB1c2VkIGFzIHRoZSBNR0YsIHRoZSBTSEFLRSBvdXRwdXQNCiAgIGxlbmd0aCBtYXNrTGVu IGlzIChuIC0gMjY0KSBvciAobiAtIDUyMCkgYml0cyByZXNwZWN0aXZlbHkuICBGb3INCiAgIGV4 YW1wbGUsIHdoZW4gUlNBIG1vZHVsdXMgbiBpcyAyMDQ4LCB0aGUgb3V0cHV0IGxlbmd0aCBvZiBT SEFLRTEyOCBvcg0KICAgU0hBS0UyNTYgYXMgdGhlIE1HRiB3aWxsIGJlIDE3ODQgb3IgMTUyOC1i aXRzIHdoZW4gaWQtUlNBU1NBLVBTUy0NCiAgIFNIQUtFMTI4IG9yIGlkLVJTQVNTQS1QU1MtU0hB S0UyNTYgaXMgdXNlZCByZXNwZWN0aXZlbHku4oCdDQoNCg0KUyA1LjEuMi4NCj4gICAgICBbWDku NjJdLiAgV2hlbiB0aGUgaWQtZWNkc2Etd2l0aC1TSEFLRTEyOCBvciBpZC1lY2RzYS13aXRoLVNI QUtFMjU2DQo+ICAgICAgKHNwZWNpZmllZCBpbiBTZWN0aW9uIDQpIGFsZ29yaXRobSBpZGVudGlm aWVyIGFwcGVhcnMsIHRoZSByZXNwZWN0aXZlDQo+ICAgICAgU0hBS0UgZnVuY3Rpb24gKFNIQUtF MTI4IG9yIFNIQUtFMjU2KSBpcyB1c2VkIGFzIHRoZSBoYXNoLiAgVGhlDQo+ICAgICAgZW5jb2Rp bmcgTVVTVCBvbWl0IHRoZSBwYXJhbWV0ZXJzIGZpZWxkLiAgVGhhdCBpcywgdGhlDQo+ICAgICAg QWxnb3JpdGhtSWRlbnRpZmllciBTSEFMTCBiZSBhIFNFUVVFTkNFIG9mIG9uZSBjb21wb25lbnQs IHRoZSBPSUQgaWQtDQo+ICAgICAgZWNkc2Etd2l0aC1TSEFLRTEyOCBvciBpZC1lY2RzYS13aXRo LVNIQUtFMjU2Lg0KDQpTaG91bGRuJ3Qgd2UgYmUgcmVxdWlyaW5nIHRoYXQgdGhlIGhhc2ggbWF0 Y2ggdGhlIHNpemUgb2YgdGhlIGN1cnZlLg0KDQpwaz4gSG1tbSwgZ29vZCBwb2ludC4gU2luY2Ug dGhlIGhhc2ggc2l6ZXMgYXJlIHByZS1kZWNpZGVkIGJ5IHRoZSBPSUQgSSB3b3VsZCBzYXkgdGhl IGN1cnZlIHNob3VsZCBiZSBjaG9zZW4gaW4gbGluZSB3aXRoIHRoZSBPSUQuIEluIG9yZGVyIHRv IG1ha2UgcmVjb21tZW5kYXRpb25zIEkgYWRkZWQgYSBwYXJhZ3JhcGggaW4gdGhlIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zIHNheWluZw0K4oCcICBXaGVuIHVzaW5nIEVDRFNBIHdpdGggU0hBS0Vz LCB0aGUgRUNEU0EgY3VydmUgb3JkZXIgU0hPVUxEIGJlDQogICBjaG9zZW4gaW4gbGluZSB3aXRo IHRoZSBTSEFLRSBvdXRwdXQgbGVuZ3RoLiAgTklTVCBoYXMgZGVmaW5lZA0KICAgYXBwcm9wcmlh dGUgdXNlIG9mIHRoZSBoYXNoIGZ1bmN0aW9ucyBpbiB0ZXJtcyBvZiB0aGUgYWxnb3JpdGhtDQog ICBzdHJlbmd0aHMgYW5kIGV4cGVjdGVkIHRpbWUgZnJhbWVzIGZvciBzZWN1cmUgdXNlIGluIFNw ZWNpYWwNCiAgIFB1YmxpY2F0aW9ucyAoU1BzKSBbU1A4MDAtNzgtNF0gYW5kIFtTUDgwMC0xMDdd LiAgVGhlc2UgZG9jdW1lbnRzIGNhbg0KICAgYmUgdXNlZCBhcyBndWlkZXMgdG8gY2hvb3NlIGFw cHJvcHJpYXRlIGtleSBzaXplcyBmb3IgdmFyaW91cw0KICAgc2VjdXJpdHkgc2NlbmFyaW9zLiAg SW4gdGhlIGNvbnRleHQgb2YgdGhpcyBkb2N1bWVudCBpZC1lY2RzYS13aXRoLQ0KICAgc2hha2Ux MjggaXMgUkVDT01NRU5ERUQgZm9yIGN1cnZlcyB3aXRoIGdyb3VwIG9yZGVyIG9mIDI1Ni1iaXRz LiBpZC0NCiAgIGVjZHNhLXdpdGgtc2hha2UyNTYgaXMgUkVDT01NRU5ERUQgZm9yIGN1cnZlcyB3 aXRoIGdyb3VwIG9yZGVyIG9mDQogICAzODQtYml0cyBvciBtb3JlLuKAnQ0KDQpTIDUuMi4NCj4g ICAgICBrZXkgZXhjbHVzaXZlbHkgdG8gUlNBU1NBLVBTUywgdGhlIEFsZ29yaXRobUlkZW50aWZp ZXJzIGZvciBSU0FTU0EtDQo+ICAgICAgUFNTIGRlZmluZWQgaW4gU2VjdGlvbiA0IGNhbiBiZSB1 c2VkIGFzIHRoZSBhbGdvcml0aG0gZmllbGQgaW4gdGhlDQo+ICAgICAgU3ViamVjdFB1YmxpY0tl eUluZm8gc2VxdWVuY2UgW1JGQzUyODBdLiAgVGhlIGlkZW50aWZpZXIgcGFyYW1ldGVycywNCj4g ICAgICBhcyBleHBsYWluZWQgaW4gc2VjdGlvbiBTZWN0aW9uIDQsIE1VU1QgYmUgYWJzZW50LiAg VGhlIFJTQVNTQS1QU1MNCj4gICAgICBhbGdvcml0aG0gZnVuY3Rpb25zIGFuZCBvdXRwdXQgbGVu Z3RocyBhcmUgdGhlIHNhbWUgYXMgZGVmaW5lZCBpbg0KPiAgICAgIFNlY3Rpb24gNS4xLjEuDQoN CkkgbXVzdCBiZSBtaXNzaW5nIHNvbWV0aGluZy4gd2hhdCBkb2VzIHRoaXMgdGV4dCByZWZlciB0 bywgZ2l2ZW4gdGhlDQp0ZXh0IGFib3ZlIGFib3V0IHdoYXQncyBpbiB0aGUgY2VydGlmaWNhdGUu DQoNCnBrPiBUaGlzIHBhcmFncmFwaCBpcyBzaW1pbGFyIHRvIGEgcGFyYWdyYXBoIHVzZWQgaW4g UkZDNDA1NS4gSXQgdHJpZXMgdG8gcG9pbnQgb3V0IHRoYXQgdGhlIHB1YmxpYyBrZXkgY2FuIHN0 aWxsIGJlIHJzYUVuY3J5cHRpb24uIEJ1dCBpZiBzb21lb25lIHdhbnRzIHRvIGp1c3QgdXNlIHRo aXMga2V5IGZvciBSU0FTU0EtUFNTIGhlIGNhbiB1c2UgdGhlIFJTQVNTQS1QU1MgaWRlbnRpZmll cnMuIEFzIGFsc28gbWVudGlvbmVkIGluIGEgY29tbWVudCBhYm92ZSwgSSByZXBocmFzZWQgdGhl IHBhcmFncmFwaCBhIGJpdCB0byBtYWtlIGl0IG1vcmUgaW50dWl0aXZlDQrigJxUcmFkaXRpb25h bGx5LCB0aGUgcnNhRW5jcnlwdGlvbiBvYmplY3QgaWRlbnRpZmllciBpcyB1c2VkIHRvDQogICBp ZGVudGlmeSBSU0EgcHVibGljIGtleXMuICBUaGUgcnNhRW5jcnlwdGlvbiBvYmplY3QgaWRlbnRp Zmllcg0KICAgY29udGludWVzIHRvIGlkZW50aWZ5IHRoZSBzdWJqZWN0IHB1YmxpYyBrZXkgd2hl biB0aGUgUlNBIHByaXZhdGUga2V5DQogICBvd25lciBkb2VzIG5vdCB3aXNoIHRvIGxpbWl0IHRo ZSB1c2Ugb2YgdGhlIHB1YmxpYyBrZXkgZXhjbHVzaXZlbHkgdG8NCiAgIFJTQVNTQS1QU1Mgd2l0 aCBTSEFLRXMuICBXaGVuIHRoZSBSU0EgcHJpdmF0ZSBrZXkgb3duZXIgd2lzaGVzIHRvDQogICBs aW1pdCB0aGUgdXNlIG9mIHRoZSBwdWJsaWMga2V5IGV4Y2x1c2l2ZWx5IHRvIFJTQVNTQS1QU1Mg d2l0aA0KICAgU0hBS0VzLCB0aGUgQWxnb3JpdGhtSWRlbnRpZmllcnMgZm9yIFJTQVNTQS1QU1Mg ZGVmaW5lZCBpbiBTZWN0aW9uIDQNCiAgIFNIT1VMRCBiZSB1c2VkIGFzIHRoZSBhbGdvcml0aG0g ZmllbGQgaW4gdGhlIFN1YmplY3RQdWJsaWNLZXlJbmZvDQogICBzZXF1ZW5jZSBbUkZDNTI4MF0u ICBDb25mb3JtaW5nIGNsaWVudCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBwcm9jZXNzDQogICBSU0FT U0EtUFNTIEVDRFNBIHdpdGggU0hBS0UgcHVibGljIGtleXMgd2hlbiBwcm9jZXNzaW5nIGNlcnRp ZmljYXRlcw0KICAgYW5kIENSTHMgTVVTVCByZWNvZ25pemUgdGhlIGNvcnJlc3BvbmRpbmcgT0lE cy7igJ0NCg0KUyA3Lg0KPiAgICAgIG9mIHRoZSBsb25nZXIgb25lLiAgSXQgaXMgYSBzaW1pbGFy IHNpdHVhdGlvbiBhcyB0cnVuY2F0aW5nIGEgNTEyLWJpdA0KPiAgICAgIG91dHB1dCBvZiBTSEEt NTEyIGJ5IHRha2luZyBpdHMgMjU2IGxlZnQtbW9zdCBiaXRzLiAgVGhlc2UgMjU2IGxlZnQtDQo+ ICAgICAgbW9zdCBiaXRzIGFyZSBhIHByZWZpeCBvZiB0aGUgNTEyLWJpdCBvdXRwdXQuDQo+DQo+ ICAgICAgSW1wbGVtZW50YXRpb25zIG11c3QgcHJvdGVjdCB0aGUgc2lnbmVyJ3MgcHJpdmF0ZSBr ZXkuICBDb21wcm9taXNlIG9mDQo+ICAgICAgdGhlIHNpZ25lcidzIHByaXZhdGUga2V5IHBlcm1p dHMgbWFzcXVlcmFkZSBhdHRhY2tzLg0KDQpUaGlzIHNlZW1zIHVubmVjZXNzYXJ5DQoNCnBrPiBG aXhlZCwgcmVtb3ZlZC4NCg0KUyA3Lg0KPiAgICAgIGNvbXB1dGluZyBwb3dlciBpbmNyZWFzZXMs IHRoZSB3b3JrIGZhY3RvciBvciB0aW1lIHJlcXVpcmVkIHRvIGJyZWFrDQo+ICAgICAgYSBwYXJ0 aWN1bGFyIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtIG1heSBkZWNyZWFzZS4gIFRoZXJlZm9yZSwN Cj4gICAgICBjcnlwdG9ncmFwaGljIGFsZ29yaXRobSBpbXBsZW1lbnRhdGlvbnMgc2hvdWxkIGJl IG1vZHVsYXIgYWxsb3dpbmcNCj4gICAgICBuZXcgYWxnb3JpdGhtcyB0byBiZSByZWFkaWx5IGlu c2VydGVkLiAgVGhhdCBpcywgaW1wbGVtZW50ZXJzIHNob3VsZA0KPiAgICAgIGJlIHByZXBhcmVk IHRvIHJlZ3VsYXJseSB1cGRhdGUgdGhlIHNldCBvZiBhbGdvcml0aG1zIGluIHRoZWlyDQo+ICAg ICAgaW1wbGVtZW50YXRpb25zLg0KDQpUaGlzIGFsc28gc2VlbXMgdW5uZWNlc3NhcnkuDQoNCnBr PiBGaXhlZCwgcmVtb3ZlZC4NCg0K --_000_673fc2acc8394b83961f5d8639a2bfc9XCHALN010ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZv bnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBFcmljLA0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFuayB5b3UgZm9yIHRoZSB0aG9yb3VnaCBy ZXZpZXcuIEl0IGlzIGFwcHJlY2lhdGVkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFsbCBhZGRyZXNz ZWQuIE1vcmUgZGV0YWlscyBhcmUgYmVsb3cgaW4gdGhpcyBlbWFpbCBpbmxpbmUuIFNlYXJjaCBm b3IgcGsmZ3Q7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkg YWxzbyBhZGRlZCB5b3UgaW4gdGhlIGFja25vd2xlZGdlbWVudHMuIFRoZSB1cGRhdGVkIGRyYWZ0 IGlzIGhlcmUNCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jc29zdG8tcGsvYWRkaW5nLXNo YWtlLXRvLXBraXgvYmxvYi9tYXN0ZXIvZHJhZnQtaWV0Zi1sYW1wcy1wa2l4LXNoYWtlLWN1cnJl bnQudHh0Ij4NCmh0dHBzOi8vZ2l0aHViLmNvbS9jc29zdG8tcGsvYWRkaW5nLXNoYWtlLXRvLXBr aXgvYmxvYi9tYXN0ZXIvZHJhZnQtaWV0Zi1sYW1wcy1wa2l4LXNoYWtlLWN1cnJlbnQudHh0PC9h Pg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5MZXQgbWUga25v dyBpZiB0aGVyZSBpcyBmdXJ0aGVyIGZlZWRiYWNrLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5SZ3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBhbm9zPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBTcGFzbSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpzcGFzbS1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPnNwYXNtLWJvdW5jZXNA aWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ow0KPGI+T24gQmVoYWxmIE9m IDwvYj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBEZWNlbWJlciAy MiwgMjAxOCA5OjQzIEFNPGJyPg0KPGI+VG86PC9iPiBTUEFTTSAmbHQ7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpzcGFzbUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5zcGFzbUBpZXRmLm9yZzwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtsYW1w c10gRndkOiBBRCBSZXZpZXcgZHJhZnQtaWV0Zi1sYW1wcy1wa2l4LXNoYWtlLTA2PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij5DQ2luZyB0aGUgV0cgYmVjYXVzZSBJIHdhcyB3cm9uZyBhYm91dCB0aGUgYWxpYXNlcy48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0t LSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS08YnI+DQpGcm9tOiA8Yj5FcmljIFJlc2Nvcmxh PC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPiZn dDs8YnI+DQpEYXRlOiBGcmksIERlYyAyMSwgMjAxOCBhdCA0OjExIFBNPGJyPg0KU3ViamVjdDog QUQgUmV2aWV3IGRyYWZ0LWlldGYtbGFtcHMtcGtpeC1zaGFrZS0wNjxicj4NClRvOiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbGFtcHMtcGtpeC1zaGFrZUBpZXRmLm9yZyI+ZHJhZnQt aWV0Zi1sYW1wcy1wa2l4LXNoYWtlQGlldGYub3JnPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ UmljaCB2ZXJzaW9uIG9mIHRoaXMgcmV2aWV3IGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbW96 cGhhYi1pZXRmLmRldnN2Y2Rldi5tb3phd3MubmV0L0Q0OTQ2IiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDQ5NDY8L2E+PGJyPg0KPGJy Pg0KPGJyPg0KSU1QT1JUQU5UPGJyPg0KUyA1LjEuMi48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFtTRUMxXSBpZiB0aGV5IGhhdmUgYSBzdGF0ZWQgcG9saWN5IHRoYXQg cmVxdWlyZXMgY29uZm9ybWFuY2UgdG88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHRoZXNlIHN0YW5kYXJkcy4mbmJzcDsgVGhlc2Ugc3RhbmRhcmRzIG1heSBoYXZlIG5v dCBzcGVjaWZpZWQgU0hBS0UxMjggYW5kPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBTSEFLRTI1NiBhcyBoYXNoIGFsZ29yaXRobSBvcHRpb25zLiZuYnNwOyBIb3dldmVy LCBTSEFLRTEyOCBhbmQgU0hBS0UyNTY8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHdpdGggb3V0cHV0IGxlbmd0aCBiZWluZyAzMiBhbmQgNjQgb2N0ZXRzIHJlc3BlY3Rp dmVseSBhcmU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN1YnRpdHV0 aW9ucyBmb3IgMjU2IGFuZCA1MTItYml0IG91dHB1dCBoYXNoIGFsZ29yaXRobXMgc3VjaCBhczxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU0hBMjU2IGFuZCBTSEE1MTIg dXNlZCBpbiB0aGUgc3RhbmRhcmRzLjxicj4NCjxicj4NCkknbSBub3Qgc3VyZSB3aHkgeW91IGFy ZSByZXF1aXJpbmcgZGV0ZXJtaW5pc3RpYyBFQ0RTQSB3aXRoIFNIQUtFLiBJczxicj4NCnRoZXJl IGFueSBzcGVjaWZpYyByZWFzb24gd2h5IGl0J3MgbW9yZSBpbXBvcnRhbnQgdGhlcmUgdGhhbiB3 aXRoPGJyPg0Kb3RoZXIgaGFzaGVzLjxicj4NCjxicj4NCnBrJmd0OyBJdCBpcyBub3Qgc3BlY2lm aWMgdG8gU0hBS0UuIFdlIGp1c3Qgd2FudGVkIHRvIHJlY29tbWVuZCBkZXRlcm1pbmlzdGljIEVD RFNBIGp1c3QgaW4gY2FzZSBrIGlzIG5vdCDigJxyYW5kb20gZW5vdWdo4oCdLiBUbyBhdm9pZCBj b25mdXNpb24gSSByZW5hbWVkIHRoZSBzdWJzZWN0aW9uIOKAnEVDRFNBIHNpZ25hdHVyZXPigJ0g YW5kIHJlcGhyYXNlZCB0aGUgcGFyYWdyYXBoIHRvIHNheQ0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDouNWlu Ij7igJxJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGNvbmZvcm1pbmcgQ0EgaW1wbGVtZW50YXRpb25z IHRoYXQgZ2VuZXJhdGUgRUNEU0ENCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwO3dpdGggU0hBS0Ugc2lnbmF0 dXJlcyBpbiBjZXJ0aWZpY2F0ZXMgb3IgQ1JMcyBnZW5lcmF0ZSBzdWNoIHNpZ25hdHVyZXMNCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwO3dpdGggYSBkZXRlcm1pbmlzdGljYWxseSBnZW5lcmF0ZWQsIG5vbi1y YW5kb20gayBpbiBhY2NvcmRhbmNlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDt3aXRoIGFsbCB0aGUgcmVx dWlyZW1lbnRzIHNwZWNpZmllZCBpbuKAnTxicj4NCjxicj4NCjxicj4NClMgNS4yLjxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW5kIENSTHMuJm5ic3A7IENvbmZvcm1p bmcgY2xpZW50IGltcGxlbWVudGF0aW9ucyB0aGF0IHByb2Nlc3MgUlNBU1NBLVBTUzxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3IgRUNEU0Egd2l0aCBTSEFLRSBwdWJs aWMga2V5IHdoZW4gcHJvY2Vzc2luZyBjZXJ0aWZpY2F0ZXMgYW5kIENSTHM8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1VU1QgcmVjb2duaXplIHRoZSBjb3JyZXNwb25k aW5nIE9JRHMuJm5ic3A7IFRoZSBjb252ZW50aW9ucyBhbmQgZW5jb2Rpbmc8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZvciBSU0FTU0EtUFNTIGFuZCBFQ0RTQSBwdWJs aWMga2V5cyBhbGdvcml0aG0gaWRlbnRpZmllcnMgYXJlIGFzPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBzcGVjaWZpZWQgaW4gU2VjdGlvbiAyLjMgb2YgW1JGQzMyNzld LCBTZWN0aW9uIDMuMSBvZiBbUkZDNDA1NV0gYW5kPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBTZWN0aW9uIDIuMSBvZiBbUkZDNTQ4MF0uPGJyPg0KPGJyPg0KVGhpcyBp cyBnb2luZyB0byBiZSBhIG1ham9yIGRpc2luY2VudGl2ZSB0byB1c2UgU0hBS0UuIElmIHlvdSBk b24ndDxicj4NCmtub3cgd2hhdCB0aGUgdmVyaWZpZXIgd2lsbCBzdXBwb3J0LCB5b3UncmUgZ29p bmcgdG8gd2FudCB0byB1c2U8YnI+DQpSU0FFbmNyeXB0aW9uLCBidXQgdGhlbiB0aGlzIHNheXMg eW91IGNhbid0IHVzZSBTSEFLRS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cGsmZ3Q7IFlvdSBh cmUgcmlnaHQsIGJ1dCB0aGlzIGlzIGFsbG93ZWQuIEkgdXBkYXRlZCBzZWN0aW9uIDUuMiB0byBy ZWZsZWN0IHRoYXQuIE1vcmUgb24gdGhlIHRleHQgSSBhZGRlZCBpcyBiZWxvdyBpbiByZXNwb25z ZSB5b3VyIHRoZXIgcnNhRW5jcnlwdGlvbiBjb21tZW50Lg0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCkNPTU1FTlRTPGJyPg0KUyAyLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgSW4gdGhlIFNIQS0zIGZhbWlseSwgdHdvIGV4dGVuZGFibGUtb3V0cHV0IGZ1 bmN0aW9ucyAoU0hBS0VzKSw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFNIQUtFMTI4IGFuZCBTSEFLRTI1NiwgYXJlIGRlZmluZWQuJm5ic3A7IEZvdXIgb3RoZXIgaGFz aCBmdW5jdGlvbjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5zdGFu Y2VzLCBTSEEzLTIyNCwgU0hBMy0yNTYsIFNIQTMtMzg0LCBhbmQgU0hBMy01MTIgYXJlIGFsc288 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlZmluZWQgYnV0IGFyZSBv dXQgb2Ygc2NvcGUgZm9yIHRoaXMgZG9jdW1lbnQuJm5ic3A7IEEgU0hBS0UgaXMgYTxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdmFyaWFibGUgbGVuZ3RoIGhhc2ggZnVu Y3Rpb24uJm5ic3A7IFRoZSBvdXRwdXQgbGVuZ3RoLCBpbiBiaXRzLCBvZiBhPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTSEFLRSBpcyBkZWZpbmVkIGJ5IHRoZSBkIHBh cmFtZXRlci4mbmJzcDsgVGhlIGNvcnJlc3BvbmRpbmcgY29sbGlzaW9uIGFuZDxicj4NCjxicj4N ClRoaXMgaXMgdGhlIGZpcnN0IG1lbnRpb24gb2YgZC4gSSB0aGluayB5b3UgbWVhbiBzb21ldGhp bmcgbGlrZSAmcXVvdDtBPGJyPg0KU0hBS0UgaXMgZGVmaW5lZCBhcyBhIGZ1bmN0aW9uIFNIQUtF KE0sIGQpIHdoZXJlIHRoZSBvdXRwdXQgaXMgYTxicj4NCmRpZ2VzdCBvZiBtZXNzYWdlIE0gdGhh dCBpcyBkIGJpdHMgbG9uZykmcXVvdDs8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnBrJmd0OyBGaXhlZC4g4oCcQSBTSEFLRSBpcyBhIHZhcmlhYmxlIGxl bmd0aCBoYXNoIGZ1bmN0aW9uIGRlZmluZWQgYXMgU0hBS0UoTSwgZCkgd2hlcmUgdGhlDQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDtv dXRwdXQgaXMgYSBkLWJpdHMgbG9uZyBkaWdlc3Qgb2YgbWVzc2FnZSBNLiBUaGUgY29ycmVzcG9u ZGluZyBjb2xsaXNpb27igJ08YnI+DQo8YnI+DQpTIDQuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBjYXBpdGFscywgYXMgc2hvd24gaGVyZS48YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsgNC4mbmJzcDsgSWRlbnRpZmllcnM8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg VGhpcyBzZWN0aW9uIGRlZmluZXMgZm91ciBuZXcgT0lEcyBmb3IgUlNBU1NBLVBTUyBhbmQgRUNE U0Egd2hlbjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU0hBS0UxMjgg YW5kIFNIQUtFMjU2IGFyZSB1c2VkLiZuYnNwOyBUaGUgc2FtZSBhbGdvcml0aG0gaWRlbnRpZmll cnMgYXJlPGJyPg0KPGJyPg0KVGhpcyBpcyBhIGxpdHRsZSB1bmNsZWFyLiBJIHRoaW5rIHlvdSBt ZWFuICZxdW90O2ZvdXIgbmV3IE9JRHMsIGZvciBSU0FTU0EtPGJyPg0KUFNTIGFuZCBFQ0RTQSB3 aXRoIGVhY2ggb2YgU0hBS0UtMTI4IGFuZCBTSEFLRS0yNTYmcXVvdDs8YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnBrJmd0OyBGaXhlZC48YnI+DQo8YnI+ DQpTIDQuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmb3IgZWFjaCB1 c2Ugb2YgU0hBS0UxMjggb3IgU0hBS0UyNTYgaW4gUlNBU1NBLVBTUyBhbmQgRUNEU0EuJm5ic3A7 IEluPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdW1tYXJ5LCB3aGVu IGhhc2hpbmcgbWVzc2FnZXMgdG8gYmUgc2lnbmVkLCBvdXRwdXQgbGVuZ3RocyBvZjxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU0hBS0UxMjggYW5kIFNIQUtFMjU2IGFy ZSAyNTYgYW5kIDUxMiBiaXRzIHJlc3BlY3RpdmVseS4mbmJzcDsgV2hlbiB0aGU8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNIQUtFcyBhcmUgdXNlZCBhcyBtYXNrIGdl bmVyYXRpb24gZnVuY3Rpb25zIFJTQVNTQS1QU1MsIHRoZWlyIG91dHB1dDxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVuZ3RoIGlzIChuIC0gMjY0KSBvciAobiAtIDUy MCkgYml0cyByZXNwZWN0aXZlbHksIHdoZXJlIG4gaXMgYSBSU0E8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1vZHVsdXMgc2l6ZSBpbiBiaXRzLjxicj4NCjxicj4NCiZx dW90O24gaXMgdGhlIFJTQSBtb2R1bHVzIHNpemUgaW4gYml0cyZxdW90Ozxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cGsmZ3Q7IEZpeGVkLjxicj4NCjxi cj4NClMgNS4xLjxicj4NCiZndDsmbmJzcDsmbmJzcDsgNS4xLiZuYnNwOyBTaWduYXR1cmVzPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFNpZ25hdHVyZXMgY2FuIGJlIHBsYWNlZCBpbiBhIG51bWJlciBvZiBkaWZmZXJlbnQgQVNO LjEgc3RydWN0dXJlcy48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo ZSB0b3AgbGV2ZWwgc3RydWN0dXJlIGZvciBhbiBYLjUwOSBjZXJ0aWZpY2F0ZSwgdG8gaWxsdXN0 cmF0ZSBob3c8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNpZ25hdHVy ZXMgYXJlIGZyZXF1ZW50bHkgZW5jb2RlZCB3aXRoIGFuIGFsZ29yaXRobSBpZGVudGlmaWVyIGFu ZCBhPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsb2NhdGlvbiBmb3Ig dGhlIHNpZ25hdHVyZSwgaXM8YnI+DQo8YnI+DQpUaGlzIHNlbnRlbmNlIGlzIHVuZ3JhbW1hdGlj YWw8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnBrJmd0 OyBGaXhlZC4gUmVwaHJhc2VkIHRvIOKAnEluIGFuIFguNTA5IGNlcnRpZmljYXRlIGEgc2lnbmF0 dXJlIGlzIGVuY29kZWQgd2l0aCBhbg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWxnb3JpdGhtIGlkZW50aWZpZXIgaW4gdGhl IHNpZ25hdHVyZUFsZ29yaXRobSBhdHRyaWJ1dGUgYW5kDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhIHNpZ25hdHVyZVZhbHVl IHRoYXQgY29udGFpbnMgdGhlIGFjdHVhbCBzaWduYXR1cmUu4oCdPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NClMgNS4xLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2lnbmF0dXJlVmFsdWUmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQklUIFNUUklORyZuYnNwOyB9PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFRoZSBpZGVudGlmaWVycyBkZWZpbmVkIGluIFNlY3Rpb24gNCBjYW4gYmUgdXNlZCBhcyB0aGU8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFsZ29yaXRobUlkZW50aWZp ZXIgaW4gdGhlIHNpZ25hdHVyZUFsZ29yaXRobSBmaWVsZCBpbiB0aGUgc2VxdWVuY2U8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENlcnRpZmljYXRlIGFuZCB0aGUgc2ln bmF0dXJlIGZpZWxkIGluIHRoZSBzZXF1ZW5jZSB0YnNDZXJ0aWZpY2F0ZSBpbjxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWC41MDkgW1JGQzUyODBdLjxicj4NCjxicj4N CldoYXQgZ29lcyBpbiAmcXVvdDtwYXJhbWV0ZXJzJnF1b3Q7PzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5wayZndDsgRml4ZWQuIEFkZGVkIHRleHQg4oCcVGhlIHBhcmFtZXRlcnMgb2YgdGhlc2Ug c2lnbmF0dXJlIGFsZ29yaXRobXMgYXJlIGFic2VudCBhcyBleHBsYWluZWQNCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluIFNl Y3Rpb24gNC7igJ08YnI+DQo8YnI+DQo8YnI+DQpTIDUuMS48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVDRFNBIHdpdGggU0hBS0Ugc2lnbmF0dXJlcyBpbiBjZXJ0aWZp Y2F0ZXMgYW5kIENSTHMuJm5ic3A7IENvbmZvcm1pbmc8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGNsaWVudCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBwcm9jZXNzIFJTQVNT QS1QU1Mgb3IgRUNEU0Egd2l0aCBTSEFLRTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgc2lnbmF0dXJlcyB3aGVuIHByb2Nlc3NpbmcgY2VydGlmaWNhdGVzIGFuZCBDUkxz IE1VU1QgcmVjb2duaXplIHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgY29ycmVzcG9uZGluZyBPSURzLiZuYnNwOyBFbmNvZGluZyBydWxlcyBmb3IgUlNBU1NBLVBT UyBhbmQgRUNEU0E8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNpZ25h dHVyZSB2YWx1ZXMgYXJlIHNwZWNpZmllZCBpbiBbUkZDNDA1NV0gYW5kIFtSRkM1NDgwXTxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVzcGVjdGl2ZWx5Ljxicj4NCjxi cj4NCklzIGl0IGZvcmJpZGRlbiB0byB2ZXJpZnkgUlNBUFNTQS9TSEFLRSBzaWduYXR1cmVzIHdp dGggUlNBRW5jcnlwdGlvbjxicj4NCmluIHRoZSBjZXJ0PyBJIGV4cGVjdCBub3QuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnBrJmd0OyBJdCBpcyBhbGxvd2VkIHRvIHVzZSByc2FFbmNyeXB0aW9u IHB1YmxpYyBrZXkgd2l0aCBhbiBSU0FTU0EtUFNTIHNpZ25hdHVyZS4gSSB1cGRhdGVkIHNlY3Rp b24gNS4yIHRvIHJlZmxlY3QgdGhhdC4gSXQgbm93IHNheXMg4oCcVHJhZGl0aW9uYWxseSwgdGhl IHJzYUVuY3J5cHRpb24gb2JqZWN0IGlkZW50aWZpZXIgaXMgdXNlZCB0bzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IGlkZW50aWZ5IFJTQSBwdWJsaWMg a2V5cy4mbmJzcDsgVGhlIHJzYUVuY3J5cHRpb24gb2JqZWN0IGlkZW50aWZpZXI8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBjb250aW51ZXMgdG8gaWRl bnRpZnkgdGhlIHN1YmplY3QgcHVibGljIGtleSB3aGVuIHRoZSBSU0EgcHJpdmF0ZSBrZXk8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBvd25lciBkb2Vz IG5vdCB3aXNoIHRvIGxpbWl0IHRoZSB1c2Ugb2YgdGhlIHB1YmxpYyBrZXkgZXhjbHVzaXZlbHkg dG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBSU0FT U0EtUFNTIHdpdGggU0hBS0VzLiZuYnNwOyBXaGVuIHRoZSBSU0EgcHJpdmF0ZSBrZXkgb3duZXIg d2lzaGVzIHRvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz cDsgbGltaXQgdGhlIHVzZSBvZiB0aGUgcHVibGljIGtleSBleGNsdXNpdmVseSB0byBSU0FTU0Et UFNTIHdpdGg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyBTSEFLRXMsIHRoZSBBbGdvcml0aG1JZGVudGlmaWVycyBmb3IgUlNBU1NBLVBTUyBkZWZpbmVk IGluIFNlY3Rpb24gNDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 Jm5ic3A7IFNIT1VMRCBiZSB1c2VkIGFzIHRoZSBhbGdvcml0aG0gZmllbGQgaW4gdGhlIFN1Ympl Y3RQdWJsaWNLZXlJbmZvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsmbmJzcDsgc2VxdWVuY2UgW1JGQzUyODBdLiZuYnNwOyBDb25mb3JtaW5nIGNsaWVudCBpbXBs ZW1lbnRhdGlvbnMgdGhhdCBwcm9jZXNzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsgUlNBU1NBLVBTUyBFQ0RTQSB3aXRoIFNIQUtFIHB1YmxpYyBrZXlz IHdoZW4gcHJvY2Vzc2luZyBjZXJ0aWZpY2F0ZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBhbmQgQ1JMcyBNVVNUIHJlY29nbml6ZSB0aGUgY29ycmVz cG9uZGluZyBPSURzLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KPGJyPg0KUyA1LjEuMS48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHNlZWQgZnJvbSB3aGljaCBtYXNrIGlzIGdlbmVyYXRlZCwgYW4gb2N0ZXQgc3RyaW5nIFtSRkM4 MDE3XS4mbmJzcDsgVGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBv dXRwdXQgbGVuZ3RoIGlzIChuIC0gMjY0KS84IG9yIChuIC0gNTIwKS84IGJ5dGVzIHJlc3BlY3Rp dmVseSwgd2hlcmU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG4gaXMg dGhlIFJTQSBtb2R1bHVzIGluIGJpdHMuJm5ic3A7IEZvciBleGFtcGxlLCB3aGVuIFJTQSBtb2R1 bHVzIG4gaXM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIwNDgsIHRo ZSBvdXRwdXQgbGVuZ3RoIG9mIFNIQUtFMTI4IG9yIFNIQUtFMjU2IGFzIHRoZSBNR0Ygd2lsbCBi ZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjIzIG9yIDE5MS1iaXRz IHdoZW4gaWQtUlNBU1NBLVBTUy1TSEFLRTEyOCBvciBpZC1SU0FTU0EtUFNTLVNIQUtFMjU2PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpcyB1c2VkIHJlc3BlY3RpdmVs eS48YnI+DQo8YnI+DQpJIHRoaW5rIHlvdSBhcmUgbWl4aW5nIGJpdHMgYW5kIGJ5dGVzIGhlcmUs IGJlY2F1c2UgMjA0OCAtIDI2NCAhPSAyMjMuPGJyPg0KPGJyPg0KSXQgd291bGQgYWxzbyBiZSBo ZWxwZnVsIHRvIGV4cGxhaW4gd2hhdCdzIGdvaW5nIG9uIGhlcmUsIGJ5PGJyPg0KZXhwbGFpbmlu ZyBob3cgdGhlc2UgdmFsdWVzIGFyZSBjb21wdXRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ cGsmZ3Q7IEZpeGVkLiBSZXBocmFzZWQgYXMg4oCcQXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBleHBsYWluZWQgaW4gU3RlcCA5IG9mIHNlY3Rpb24g OS4xLjEgb2YgW1JGQzgwMTddLCB0aGUgb3V0cHV0IGxlbmd0aDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IG9mIHRoZSBNR0YgaXMgZW1MZW4gLSBoTGVu IC0gMSBieXRlcy4gZW1MZW4gaXMgdGhlIG1heGltdW0gbWVzc2FnZTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IGxlbmd0aCBjZWlsKChuLTEpLzgpLCB3 aGVyZSBuIGlzIHRoZSBSU0EgbW9kdWx1cyBpbiBiaXRzLiBoTGVuIGlzIDMyPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgYW5kIDY0LWJ5dGVzIGZvciBp ZC1SU0FTU0EtUFNTLVNIQUtFMTI4IGFuZCBpZC1SU0FTU0EtUFNTLVNIQUtFMjU2PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgcmVzcGVjdGl2ZWx5LiZu YnNwOyBUaHVzIHdoZW4gU0hBS0UgaXMgdXNlZCBhcyB0aGUgTUdGLCB0aGUgU0hBS0Ugb3V0cHV0 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgbGVuZ3Ro IG1hc2tMZW4gaXMgKG4gLSAyNjQpIG9yIChuIC0gNTIwKSBiaXRzIHJlc3BlY3RpdmVseS4mbmJz cDsgRm9yDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyZuYnNwO2V4YW1wbGUsIHdoZW4gUlNBIG1vZHVsdXMgbiBpcyAyMDQ4LCB0aGUgb3V0cHV0IGxl bmd0aCBvZiBTSEFLRTEyOCBvcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7Jm5ic3A7IFNIQUtFMjU2IGFzIHRoZSBNR0Ygd2lsbCBiZSAxNzg0IG9yIDE1MjgtYml0 cyB3aGVuIGlkLVJTQVNTQS1QU1MtPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsmbmJzcDsgU0hBS0UxMjggb3IgaWQtUlNBU1NBLVBTUy1TSEFLRTI1NiBpcyB1c2Vk IHJlc3BlY3RpdmVseS7igJ0NCjxicj4NCjxicj4NCjxicj4NClMgNS4xLjIuPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbWDkuNjJdLiZuYnNwOyBXaGVuIHRoZSBpZC1l Y2RzYS13aXRoLVNIQUtFMTI4IG9yIGlkLWVjZHNhLXdpdGgtU0hBS0UyNTY8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IChzcGVjaWZpZWQgaW4gU2VjdGlvbiA0KSBhbGdv cml0aG0gaWRlbnRpZmllciBhcHBlYXJzLCB0aGUgcmVzcGVjdGl2ZTxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU0hBS0UgZnVuY3Rpb24gKFNIQUtFMTI4IG9yIFNIQUtF MjU2KSBpcyB1c2VkIGFzIHRoZSBoYXNoLiZuYnNwOyBUaGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVuY29kaW5nIE1VU1Qgb21pdCB0aGUgcGFyYW1ldGVycyBmaWVs ZC4mbmJzcDsgVGhhdCBpcywgdGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBBbGdvcml0aG1JZGVudGlmaWVyIFNIQUxMIGJlIGEgU0VRVUVOQ0Ugb2Ygb25lIGNvbXBv bmVudCwgdGhlIE9JRCBpZC08YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGVjZHNhLXdpdGgtU0hBS0UxMjggb3IgaWQtZWNkc2Etd2l0aC1TSEFLRTI1Ni48YnI+DQo8YnI+ DQpTaG91bGRuJ3Qgd2UgYmUgcmVxdWlyaW5nIHRoYXQgdGhlIGhhc2ggbWF0Y2ggdGhlIHNpemUg b2YgdGhlIGN1cnZlLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+cGsmZ3Q7IEhtbW0sIGdvb2QgcG9pbnQuIFNpbmNlIHRoZSBoYXNoIHNpemVzIGFyZSBw cmUtZGVjaWRlZCBieSB0aGUgT0lEIEkgd291bGQgc2F5IHRoZSBjdXJ2ZSBzaG91bGQgYmUgY2hv c2VuIGluIGxpbmUgd2l0aCB0aGUgT0lELiBJbiBvcmRlciB0byBtYWtlIHJlY29tbWVuZGF0aW9u cyBJIGFkZGVkIGEgcGFyYWdyYXBoIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzYXlp bmcNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcJm5ic3A7IFdoZW4g dXNpbmcgRUNEU0Egd2l0aCBTSEFLRXMsIHRoZSBFQ0RTQSBjdXJ2ZSBvcmRlciBTSE9VTEQgYmU8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBjaG9zZW4g aW4gbGluZSB3aXRoIHRoZSBTSEFLRSBvdXRwdXQgbGVuZ3RoLiZuYnNwOyBOSVNUIGhhcyBkZWZp bmVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgYXBw cm9wcmlhdGUgdXNlIG9mIHRoZSBoYXNoIGZ1bmN0aW9ucyBpbiB0ZXJtcyBvZiB0aGUgYWxnb3Jp dGhtPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgc3Ry ZW5ndGhzIGFuZCBleHBlY3RlZCB0aW1lIGZyYW1lcyBmb3Igc2VjdXJlIHVzZSBpbiBTcGVjaWFs PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgUHVibGlj YXRpb25zIChTUHMpIFtTUDgwMC03OC00XSBhbmQgW1NQODAwLTEwN10uJm5ic3A7IFRoZXNlIGRv Y3VtZW50cyBjYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZu YnNwOyBiZSB1c2VkIGFzIGd1aWRlcyB0byBjaG9vc2UgYXBwcm9wcmlhdGUga2V5IHNpemVzIGZv ciB2YXJpb3VzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz cDsgc2VjdXJpdHkgc2NlbmFyaW9zLiZuYnNwOyBJbiB0aGUgY29udGV4dCBvZiB0aGlzIGRvY3Vt ZW50IGlkLWVjZHNhLXdpdGgtPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsmbmJzcDsgc2hha2UxMjggaXMgUkVDT01NRU5ERUQgZm9yIGN1cnZlcyB3aXRoIGdyb3Vw IG9yZGVyIG9mIDI1Ni1iaXRzLiBpZC08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyZuYnNwOyBlY2RzYS13aXRoLXNoYWtlMjU2IGlzIFJFQ09NTUVOREVEIGZvciBj dXJ2ZXMgd2l0aCBncm91cCBvcmRlciBvZjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7Jm5ic3A7IDM4NC1iaXRzIG9yIG1vcmUu4oCdPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpTIDUuMi48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGtleSBleGNsdXNpdmVseSB0byBSU0FTU0EtUFNTLCB0aGUgQWxnb3Jp dGhtSWRlbnRpZmllcnMgZm9yIFJTQVNTQS08YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFBTUyBkZWZpbmVkIGluIFNlY3Rpb24gNCBjYW4gYmUgdXNlZCBhcyB0aGUgYWxn b3JpdGhtIGZpZWxkIGluIHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgU3ViamVjdFB1YmxpY0tleUluZm8gc2VxdWVuY2UgW1JGQzUyODBdLiZuYnNwOyBUaGUgaWRl bnRpZmllciBwYXJhbWV0ZXJzLDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgYXMgZXhwbGFpbmVkIGluIHNlY3Rpb24gU2VjdGlvbiA0LCBNVVNUIGJlIGFic2VudC4mbmJz cDsgVGhlIFJTQVNTQS1QU1M8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGFsZ29yaXRobSBmdW5jdGlvbnMgYW5kIG91dHB1dCBsZW5ndGhzIGFyZSB0aGUgc2FtZSBhcyBk ZWZpbmVkIGluPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZWN0aW9u IDUuMS4xLjxicj4NCjxicj4NCkkgbXVzdCBiZSBtaXNzaW5nIHNvbWV0aGluZy4gd2hhdCBkb2Vz IHRoaXMgdGV4dCByZWZlciB0bywgZ2l2ZW4gdGhlPGJyPg0KdGV4dCBhYm92ZSBhYm91dCB3aGF0 J3MgaW4gdGhlIGNlcnRpZmljYXRlLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+cGsmZ3Q7IFRoaXMgcGFyYWdyYXBoIGlzIHNpbWlsYXIgdG8gYSBwYXJh Z3JhcGggdXNlZCBpbiBSRkM0MDU1LiBJdCB0cmllcyB0byBwb2ludCBvdXQgdGhhdCB0aGUgcHVi bGljIGtleSBjYW4gc3RpbGwgYmUgcnNhRW5jcnlwdGlvbi4gQnV0IGlmIHNvbWVvbmUgd2FudHMg dG8ganVzdCB1c2UgdGhpcyBrZXkgZm9yIFJTQVNTQS1QU1MgaGUgY2FuIHVzZSB0aGUgUlNBU1NB LVBTUyBpZGVudGlmaWVycy4gQXMgYWxzbw0KIG1lbnRpb25lZCBpbiBhIGNvbW1lbnQgYWJvdmUs IEkgcmVwaHJhc2VkIHRoZSBwYXJhZ3JhcGggYSBiaXQgdG8gbWFrZSBpdCBtb3JlIGludHVpdGl2 ZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJxUcmFkaXRpb25hbGx5 LCB0aGUgcnNhRW5jcnlwdGlvbiBvYmplY3QgaWRlbnRpZmllciBpcyB1c2VkIHRvPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgaWRlbnRpZnkgUlNBIHB1 YmxpYyBrZXlzLiZuYnNwOyBUaGUgcnNhRW5jcnlwdGlvbiBvYmplY3QgaWRlbnRpZmllcjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IGNvbnRpbnVlcyB0 byBpZGVudGlmeSB0aGUgc3ViamVjdCBwdWJsaWMga2V5IHdoZW4gdGhlIFJTQSBwcml2YXRlIGtl eTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IG93bmVy IGRvZXMgbm90IHdpc2ggdG8gbGltaXQgdGhlIHVzZSBvZiB0aGUgcHVibGljIGtleSBleGNsdXNp dmVseSB0bzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7 IFJTQVNTQS1QU1Mgd2l0aCBTSEFLRXMuJm5ic3A7IFdoZW4gdGhlIFJTQSBwcml2YXRlIGtleSBv d25lciB3aXNoZXMgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyZuYnNwOyBsaW1pdCB0aGUgdXNlIG9mIHRoZSBwdWJsaWMga2V5IGV4Y2x1c2l2ZWx5IHRvIFJT QVNTQS1QU1Mgd2l0aDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 Jm5ic3A7IFNIQUtFcywgdGhlIEFsZ29yaXRobUlkZW50aWZpZXJzIGZvciBSU0FTU0EtUFNTIGRl ZmluZWQgaW4gU2VjdGlvbiA0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsmbmJzcDsgU0hPVUxEIGJlIHVzZWQgYXMgdGhlIGFsZ29yaXRobSBmaWVsZCBpbiB0aGUg U3ViamVjdFB1YmxpY0tleUluZm88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyZuYnNwOyBzZXF1ZW5jZSBbUkZDNTI4MF0uJm5ic3A7IENvbmZvcm1pbmcgY2xpZW50 IGltcGxlbWVudGF0aW9ucyB0aGF0IHByb2Nlc3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBSU0FTU0EtUFNTIEVDRFNBIHdpdGggU0hBS0UgcHVibGlj IGtleXMgd2hlbiBwcm9jZXNzaW5nIGNlcnRpZmljYXRlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IGFuZCBDUkxzIE1VU1QgcmVjb2duaXplIHRoZSBj b3JyZXNwb25kaW5nIE9JRHMu4oCdPGJyPg0KPGJyPg0KUyA3Ljxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgb2YgdGhlIGxvbmdlciBvbmUuJm5ic3A7IEl0IGlzIGEgc2lt aWxhciBzaXR1YXRpb24gYXMgdHJ1bmNhdGluZyBhIDUxMi1iaXQ8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG91dHB1dCBvZiBTSEEtNTEyIGJ5IHRha2luZyBpdHMgMjU2 IGxlZnQtbW9zdCBiaXRzLiZuYnNwOyBUaGVzZSAyNTYgbGVmdC08YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1vc3QgYml0cyBhcmUgYSBwcmVmaXggb2YgdGhlIDUxMi1i aXQgb3V0cHV0Ljxicj4NCiZndDsmbmJzcDsmbmJzcDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBJbXBsZW1lbnRhdGlvbnMgbXVzdCBwcm90ZWN0IHRoZSBzaWduZXIn cyBwcml2YXRlIGtleS4mbmJzcDsgQ29tcHJvbWlzZSBvZjxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgdGhlIHNpZ25lcidzIHByaXZhdGUga2V5IHBlcm1pdHMgbWFzcXVl cmFkZSBhdHRhY2tzLjxicj4NCjxicj4NClRoaXMgc2VlbXMgdW5uZWNlc3Nhcnk8YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnBrJmd0OyBGaXhlZCwgcmVt b3ZlZC4gPGJyPg0KPGJyPg0KUyA3Ljxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgY29tcHV0aW5nIHBvd2VyIGluY3JlYXNlcywgdGhlIHdvcmsgZmFjdG9yIG9yIHRpbWUg cmVxdWlyZWQgdG8gYnJlYWs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGEgcGFydGljdWxhciBjcnlwdG9ncmFwaGljIGFsZ29yaXRobSBtYXkgZGVjcmVhc2UuJm5ic3A7 IFRoZXJlZm9yZSw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNyeXB0 b2dyYXBoaWMgYWxnb3JpdGhtIGltcGxlbWVudGF0aW9ucyBzaG91bGQgYmUgbW9kdWxhciBhbGxv d2luZzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbmV3IGFsZ29yaXRo bXMgdG8gYmUgcmVhZGlseSBpbnNlcnRlZC4mbmJzcDsgVGhhdCBpcywgaW1wbGVtZW50ZXJzIHNo b3VsZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmUgcHJlcGFyZWQg dG8gcmVndWxhcmx5IHVwZGF0ZSB0aGUgc2V0IG9mIGFsZ29yaXRobXMgaW4gdGhlaXI8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGltcGxlbWVudGF0aW9ucy48YnI+DQo8 YnI+DQpUaGlzIGFsc28gc2VlbXMgdW5uZWNlc3NhcnkuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnBrJmd0OyBGaXhlZCwgcmVtb3ZlZC48YnI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_673fc2acc8394b83961f5d8639a2bfc9XCHALN010ciscocom_-- From nobody Tue Jan 8 06:16:28 2019 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 28D931276D0; Tue, 8 Jan 2019 06:16:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Montville To: Cc: spasm@ietf.org, draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154695697211.25494.5342366287090150478@ietfa.amsl.com> Date: Tue, 08 Jan 2019 06:16:12 -0800 Archived-At: Subject: [lamps] Secdir last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03 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, 08 Jan 2019 14:16:12 -0000 Reviewer: Adam Montville Review result: Ready This draft is ready. It's a clever (though not foolproof) way to prime the pump for root certificate updates. I'm not an ASN.1 expert, so I can't really opine on the structure in Section 3, but from what I can tell it looks sane. Operational considerations seems sane. Security considerations rely on those from RFC5280, and additionally addresses: 1) analysis before the next-generation root certificate is released, 2) key strength considerations (equal or greater than current), 3) unforeseen cryptoanalytic advances, 4) typical hash pre-image attacks, and 5) early release of the next-generation public key. One area in the security considerations that could be enhanced is the recommended action to take in the case of an early next-generation public key release. The language in the draft states: "The second transition occurs when the Root CA is confident that the population of relying parties have completed the first transition, and it takes the Root CA to the freshly generated key pair." The question that came to mind was: What might bring about such confidence? I'm not sure that it's possible to generalize an answer to that question, however. Kind regards, Adam From nobody Tue Jan 8 09:33:53 2019 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 2F83F130F24 for ; Tue, 8 Jan 2019 09:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHBt_VIIR88F for ; Tue, 8 Jan 2019 09:33:49 -0800 (PST) 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 531B6130F26 for ; Tue, 8 Jan 2019 09:33:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 550DE300A81 for ; Tue, 8 Jan 2019 12:15:31 -0500 (EST) 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 nQqw7vcZScJj for ; Tue, 8 Jan 2019 12:15:29 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 4743F30005C; Tue, 8 Jan 2019 12:15:29 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: <154695697211.25494.5342366287090150478@ietfa.amsl.com> Date: Tue, 8 Jan 2019 12:33:45 -0500 Cc: IETF SecDir , spasm@ietf.org, draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF Content-Transfer-Encoding: quoted-printable Message-Id: <38C4C1A8-42E9-4F50-B4F1-356909D81AC9@vigilsec.com> References: <154695697211.25494.5342366287090150478@ietfa.amsl.com> To: Adam Montville X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Secdir last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03 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, 08 Jan 2019 17:33:51 -0000 > On Jan 8, 2019, at 9:16 AM, Adam Montville = wrote: >=20 > Reviewer: Adam Montville > Review result: Ready >=20 > This draft is ready. It's a clever (though not foolproof) way to prime = the pump > for root certificate updates. I'm not an ASN.1 expert, so I can't = really opine > on the structure in Section 3, but from what I can tell it looks sane. > Operational considerations seems sane. Security considerations rely on = those > from RFC5280, and additionally addresses: 1) analysis before the > next-generation root certificate is released, 2) key strength = considerations > (equal or greater than current), 3) unforeseen cryptoanalytic = advances, 4) > typical hash pre-image attacks, and 5) early release of the = next-generation > public key. >=20 > One area in the security considerations that could be enhanced is the > recommended action to take in the case of an early next-generation = public key > release. The language in the draft states: "The second transition = occurs when > the Root CA is confident that the population of relying parties have = completed > the first transition, and it takes the Root CA to the freshly = generated key > pair." The question that came to mind was: What might bring about such > confidence? I'm not sure that it's possible to generalize an answer to = that > question, however. Adam: Thanks for the review. I can assure you that I compiled the ASN.1 module. This paragraph is the result of the discussion in the LAMPS WG session = in London. The timing is not that critical if the oldWithNew and = newWithOld advice from RFC 2510 (updated to RFC 4210) is followed. This = is talked about in Section 5 on "Operational Considerations". I have an = update to the paragraph in Section 5 based on other comments: Guidance on the transition from one trust anchor to another is available in Section 4.4 of [RFC4210]. In particular, the oldWithNew and newWithOld advice ensures that relying parties are able to validate certificates issued under the current Root CA certificate and the next generation Root CA certificate throughout the transition. Further, this advice avoids the need for all relying parties to make the transition at the same time. Russ From nobody Tue Jan 8 17:59:31 2019 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 ED98F12F1A5; Tue, 8 Jan 2019 17:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoVMKMOl7NDo; Tue, 8 Jan 2019 17:59:21 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7598512F1A2; Tue, 8 Jan 2019 17:59:21 -0800 (PST) Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:b4c1:b6ff:fe27:67bb]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id DDE04F99B; Tue, 8 Jan 2019 20:58:48 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 8FFAC202B4; Tue, 8 Jan 2019 13:55:32 -0500 (EST) From: Daniel Kahn Gillmor To: Russ Housley , Adam Montville Cc: spasm@ietf.org, draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF , IETF SecDir In-Reply-To: <38C4C1A8-42E9-4F50-B4F1-356909D81AC9@vigilsec.com> References: <154695697211.25494.5342366287090150478@ietfa.amsl.com> <38C4C1A8-42E9-4F50-B4F1-356909D81AC9@vigilsec.com> Date: Tue, 08 Jan 2019 13:55:28 -0500 Message-ID: <877effhtcv.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] Secdir last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03 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, 09 Jan 2019 01:59:23 -0000 --=-=-= Content-Type: text/plain On Tue 2019-01-08 12:33:45 -0500, Russ Housley wrote: > Guidance on the transition from one trust anchor to another is > available in Section 4.4 of [RFC4210]. In particular, the oldWithNew > and newWithOld advice ensures that relying parties are able to > validate certificates issued under the current Root CA certificate > and the next generation Root CA certificate throughout the > transition. Further, this advice avoids the need for all relying > parties to make the transition at the same time. I'm not convinced that this analysis is correct, as i tried to explain in more detail in Message-Id: <87k1jlnxnu.fsf@fifthhorseman.net>. I hope my analysis in that e-mail is wrong, but i've received no feedback on it yet. Maybe some additional guidance about which parties should ship which certificates in which contexts would clarify matters? Or maybe i'm just missing something obvious to other people -- i'd be happy to see a clarification. Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCXDTyIAAKCRBsHx7ezFD6 U7KEAP0VJvFgWeI58SxWFf02bqy+TDOLUCmdr3sBSLRJ9vimvgD/VUMWNinX3K27 AJFhtmUvlmYXU7C4hHZO+stZPHLnhwg= =iGZD -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 9 09:00:15 2019 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 8EA90130F16 for ; Wed, 9 Jan 2019 09:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSRqRDDittlk for ; Wed, 9 Jan 2019 09:00:12 -0800 (PST) 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 3556E130F14 for ; Wed, 9 Jan 2019 09:00:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 810633005D8 for ; Wed, 9 Jan 2019 11:33:20 -0500 (EST) 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 CxlIsg7sKq5q for ; Wed, 9 Jan 2019 11:33:17 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id CB667300080; Wed, 9 Jan 2019 11:33:16 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: <87k1jlnxnu.fsf@fifthhorseman.net> Date: Wed, 9 Jan 2019 11:51:33 -0500 Cc: LAMPS WG , draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org, IETF Content-Transfer-Encoding: quoted-printable Message-Id: <2AB77CF4-ADD6-4EE6-ABB2-BCDAC4BF6631@vigilsec.com> References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <87va35o7pe.fsf@fifthhorseman.net> <38891959-38F6-4FA5-B7B1-ACB50921E300@vigilsec.com> <87k1jlnxnu.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 09 Jan 2019 17:00:14 -0000 DKG: >> I could add a sentence here: >>=20 >> If both checks succeed, then the potential Root CA certificate = is >> added to the trust anchor store and the current Root CA >> certificate is removed. >>=20 >> Does that resolve your concern? >=20 > Yes, this final addition clarifies the intent of the document, thank > you. I might prefer if it was active voice instead of passive, just = to > be clearer about who is doing the addition and removal to the trust > store. Is there a reason to avoid RFC 2119 language in these > descriptions? Yes, active voice would be better: If both checks succeed, then the recipient adds the potential Root CA certificate to the trust anchor store and removes the current Root CA certificate. I do not see the need for RFC 2119 language in the Overview section. >> Please take a look at RFC 4210, Section 4.4 ("Root CA Key Update"). >=20 > Please cite the relevant section number directly in the draft! I have added it in my edit buffer. >> The way that I read the section, it is describing a technique for >> protecting the new public key using the previous private key and vice >> versa. The technique involves both old-with-new and new-with-old. >>=20 >> To be more clear, I will refer to "this advice" in all of the places >> that reference RFC 4210. The current text uses "this advice" in one >> place and "this technique" in another place. I hope that will be = more >> clear. >=20 > So i think you're now saying that people updating a key should use RFC > 4210=C2=A74.4 guidance *in addition* to including the HashOfRootKey = extension > in C1. If that's what you mean, the draft should say it explicitly. Yes, this advice has been in place since 1999 for root key transition. This is what I have in my edit buffer: Guidance on the transition from one trust anchor to another is available in Section 4.4 of [RFC4210]. In particular, the oldWithNew and newWithOld advice ensures that relying parties are able to validate certificates issued under the current Root CA certificate and the next generation Root CA certificate throughout the transition. Further, this advice SHOULD be followed by Root CAs to avoid the need for all relying parties to make the transition at the same time. > But (using the RFC 4210 terms), let's think about what happens to the > PSE (Personal Security Environment), the trust store (meaning the list > of trusted roots, which is a subset of the PSE, i guess, feel free to > correct if i'm misunderstanding 4210) and various certificates = assuming > there are multiple heterogeneous subscribers seen by a single relying > party. >=20 > I'm working here on a TLS assumption -- if you're using these certs = for > some other purpose (like LAMPS) maybe it won't apply, i'm not sure. = The > "Repository" referred to in RFC 4210 isn't something that many X.509 > verification stacks have access to (and even if it was, checking it > during failed verification might raise privacy or latency concerns). >=20 > In my notation below, the CA starts with self-signed C1, and then = moves > (via HashOfRootKey) to self-signed C2. Meanwhile, the CA has also > generated COwN (the oldWithNew cert) and CNwO (the newWithOld cert). > (C1 is oldWithOld, and C2 is newWithNew, in 4210 lingo). >=20 > In my example, an end-entity cert might be written as EA or EB, and = will > be signed by the root authority directly (i'm omitting traditional > intermediate certs for the sake of simplicity, though i note that COwN > and CNwO are effectively intermediate certs). >=20 > A valid simple certificate chain where end entity A is certified by = the > first version of the CA looks like this: EA=E2=86=90C1. Let's assume = that all > servers ship their root CA certs as well (though TLS doesn't = explicitly > require that, and people who care about latency are likely to try to > omit them -- should this draft explicitly recommend that TLS servers > ship root certs all the time just in case?). >=20 > in this example scenario, the relying party visits site end entity A > (which whose cert has been issued by the new C2), and then end entity = B > (which is still using a cert issued by C1). >=20 > | Trust | | cert | > event | Store | PSE | chain | valid? =20 > --------+-------+-------+-------+---------- > start | C1 | C1 | | > visit A | C2 | C1,C2 | EA=E2=86=90C2 | EA =3D =E2=9C=93 > visit B | C2 | C1,C2 | EB=E2=86=90C1 | EB =3D ? >=20 >=20 > It looks to me like EB will not validate, since: >=20 > 1) C1 is no longer a trusted root, despite being in the PSE >=20 > 2) COwN is not available to the relying party (and might not be known > to server B either), so no chain can be formed to the only trusted > root, C2 >=20 > What am i missing? This looks like a recipe for one party (A) to > accidentally damage another party (B) due to lack of coordination. >=20 > Furthermore, what happens if the relying party comes across CNwO = before > C2? It validates (signed by C1) but it is not self-signed. But its > SPKI also matches C1's HashOfRootKey extension. If it gets processed = as > a new root, then C2 will *not* get processed (because C1 is already = out > of the trust store, and C2 doesn't have the same HashOfRootKey as C1). > So now you'll have some RPs that have CNwO in their root store, and > others that have C2, depending on when they encountered it. Hopefully > that won't cause any problems, but it makes me nervous. >=20 > Alternately, maybe this process *only* triggers when the cert we're > examining is self-signed. Maybe the text "Whenever a new Root CA > certificate is received" is meant to only apply to self-signed > certificates? perhaps it should be clearer on that, if that's the = case > (subsequent text in that paragraph refers to "the self-signed > certificate", but the only "self-signed" antecedent in that paragraph = is > the original "Root CA self-signed certificate" -- C1, not a potential > C2). I think about this quite differently. Let me see if a few high-level = comments can resolve this question in the TLS context. First, TLS explicitly says that intermediate certificates can be = included in the "certificate_list" during a transition. RFC 8446 says: Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it; however, some implementations allowed some flexibility. Servers sometimes send both a current and deprecated intermediate for transitional purposes, and others are simply configured incorrectly, but these cases can nonetheless be validated properly. For maximum compatibility, all implementations SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings from any TLS version, with the exception of the end-entity certificate which MUST be first. So, a server can provide the intermediate certificates needed for a = client that is using the old self-signed certificate and the new = self-signed certificate so that both validate the servers end-entity = certificate. I observe that other protocols, including CMS, allow a bag of = certificates that might be useful to be sent. During a transition, this = could help populate caches. Second, it is quite clear that a global directory has not emerged in the = way envisioned by X.500 and LDAP. However, there are many repositories = within enterprises, and these repositories can be used to locate the = old-in-new and new-in-old certificates during a transition. This is the = situation for the PKI that I know about that will be using this = extension. >> The whole point of the old-with-new and new-with-old advice is that >> all of the certificates can be validated to either the old trust >> anchor or the new one. >=20 > only if the relying party has access both COwN cert as well as C2, > right? If the TLS server ships only C1, then the RP is out of luck. >=20 > should COwN have the same subjectPublicKeyIdentifier extension as C1? > should CNwO have the same subjectPublicKeyIdentifier as C2? if so, > should we say so explicitly? I think my comments above address this point as well. >>> So, without this draft offering a strong and immediate revocation >>> mechanism, and without it cleaning up the pre-existing new-root-cert >>> import mechanism, it does *not* make "rollover more secure" (since = all >>> existing insecure channels will continue to exist). It just makes = good >>> rollover more convenient/automatic. >>=20 >> Yes, that is the point of the extension. >=20 > thanks, that matches my mental model. Okay. Good. > One other open question occurs to me: Should the relying party also > verify that Subject information (or other identity info) in the new = cert > matches the old certificate? I'm imagining a case where the old root = CA > ("O=3DL'Emporium de Foobar,OU=3DAuthorit=C3=A9 Racine,C=3DFR") ends up = replacing > itself with ("O=3D=D0=92=D0=BE=D0=BE=D1=80=D1=83=D0=B6=D1=91=D0=BD=D0=BD= =D1=8B=D0=B5 =D0=A1=D0=B8=D0=BB=D1=8B =D0=A1=D0=BE=D1=8E=D0=B7=D0=B0 = =D0=A1=D0=BE=D0=B2=D0=B5=D1=82=D1=81=D0=BA=D0=B8=D1=85 = =D0=A1=D0=BE=D1=86=D0=B8=D0=B0=D0=BB=D0=B8=D1=81=D1=82=D0=B8=D1=87=D0=B5=D1= =81=D0=BA=D0=B8=D1=85 > =D0=A0=D0=B5=D1=81=D0=BF=D1=83=D0=B1=D0=BB=D0=B8=D0=BA,C=3DSU"). That = would be pretty weird and upsetting, especially > if i didn't know how my "new" Soviet military cert got into my trust > store. Would it be legitimate to cabin the scope of this rollover to > identical Subjects? I do not think so. We have seen cases in the Web PKI were the Root CA = changed names as part of a key rollover. Of course, this happens = without this extension today, so they establish a new self-signed = certificate and once it is well established, they issue new certificate = under the new root and stop issuing certificates under the old one. > Finally, should a relying party place any bounds on the lifetime of = the > new cert? What if C2 appears, but has an *earlier* notBefore date = than > C1? that seems weird but maybe it isn't a problem. But what if i've > added a cert to my root store with an known expiration date, and i = don't > *want* a subsequent cert to suddenly have a later expiration date? = (for > example, perhaps i'm in school and the school issues its own annual > certificate authority which i'm fine with accepting for now, but i = don't > want to trust it after graduation) I cannot think of a reason for the new self-signed certificate to have a = notBefore date that is earlier than the old one. That said, the = certification path validation rules in RFC 5280 do not use the validity = period in the trust anchor. As a result, I cannot see any attack that = would be enabled by this admittedly weird use of notBefore. > How can an implementation determine the intent of the local system's > inclusion of certificate in the root store? Should we encourage trust > store implementations to be able mark certificates as DO NOT UPDATE? = or > should we instead encourage users to understand inclusion of a > certificate in a root store as effectively unbounded in duration, > despite the existence of a validUntil field? I am missing something in this paragraph. If the relying party has = already decided to trust a particular Root CA, and then that Root CA = transitions to a different key pair, what does this have to do with that = decision? If trust in the Root CA is lost by the relying party, then = they ought to remove the self-signed certificate from the trust anchor = store. Further, I do want this extension to say anything about the structure of = the trust anchor store. Rather, it depends on the definition of a trust = anchor in RFC 5280 (on page 76), which says: (d) trust anchor information, describing a CA that serves as a trust anchor for the certification path. The trust anchor information includes: (1) the trusted issuer name, (2) the trusted public key algorithm, (3) the trusted public key, and (4) optionally, the trusted public key parameters associated with the public key. Finally, I want to thank you for all the careful thought that you have = put into this discussion. Russ From nobody Wed Jan 9 12:39:44 2019 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 DDA04130EAB; Wed, 9 Jan 2019 12:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFlkBAk2Wqpe; Wed, 9 Jan 2019 12:39:39 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A096A130FD7; Wed, 9 Jan 2019 12:39:39 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 1614CF99E; Wed, 9 Jan 2019 15:39:37 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 1E59D20B9E; Wed, 9 Jan 2019 15:39:33 -0500 (EST) From: Daniel Kahn Gillmor To: Russ Housley Cc: LAMPS WG , draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org, IETF In-Reply-To: <2AB77CF4-ADD6-4EE6-ABB2-BCDAC4BF6631@vigilsec.com> References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <87va35o7pe.fsf@fifthhorseman.net> <38891959-38F6-4FA5-B7B1-ACB50921E300@vigilsec.com> <87k1jlnxnu.fsf@fifthhorseman.net> <2AB77CF4-ADD6-4EE6-ABB2-BCDAC4BF6631@vigilsec.com> Date: Wed, 09 Jan 2019 15:39:29 -0500 Message-ID: <87imyxh8fy.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 09 Jan 2019 20:39:42 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Russ-- thanks for the responses! On Wed 2019-01-09 11:51:33 -0500, Russ Housley wrote: > Guidance on the transition from one trust anchor to another is > available in Section 4.4 of [RFC4210]. In particular, the oldWithNew > and newWithOld advice ensures that relying parties are able to > validate certificates issued under the current Root CA certificate > and the next generation Root CA certificate throughout the > transition. Further, this advice SHOULD be followed by Root CAs to > avoid the need for all relying parties to make the transition at the > same time. thanks, this looks good so far, and i agree that the draft helps to avoid needing coordination between all relying parties (RPs). But it doesn't cover coordination by the subscribers (e.g. TLS servers) yet, which is what the next point was about: > [ dkg wrote: ] >> in this example scenario, the relying party visits site end entity A >> (which whose cert has been issued by the new C2), and then end entity B >> (which is still using a cert issued by C1). >>=20 >> | Trust | | cert | >> event | Store | PSE | chain | valid?=20=20=20 >> --------+-------+-------+-------+---------- >> start | C1 | C1 | | >> visit A | C2 | C1,C2 | EA=E2=86=90C2 | EA =3D =E2=9C=93 >> visit B | C2 | C1,C2 | EB=E2=86=90C1 | EB =3D ? >>=20 >>=20 >> It looks to me like EB will not validate, since: >>=20 >> 1) C1 is no longer a trusted root, despite being in the PSE >>=20 >> 2) COwN is not available to the relying party (and might not be known >> to server B either), so no chain can be formed to the only trusted >> root, C2 Russ responded: > First, TLS explicitly says that intermediate certificates can be > included in the "certificate_list" during a transition. i agree that this "bag of certs" model is where we're at for certificates shipped in TLS (and with CMS, and probably should be for any other relevant protocols where certificate path discovery is needed). But can you be concrete about which certificates you think which parties will include in their certificate_list? I see two possible proposals: 0) A should ship EA, COwN, and C2 in order to avoid breaking the RP's access to site B 1) B should make sure that B ships COwN *before* A ever ships C2 Or are you suggesting something else? The problem with 0 is that there is no clear incentive for A to take that action (because C2 will Just Work=E2=84=A2 for all clients that implem= ent the rollover), and B can be damaged by A failing to take it. The problem with 1 is that it requires coordination among the subscribers. Or did you have some other suggestion about how to use the "bag of certs" to get COwN to the RP? The revocation functionality of the current draft seems to require distribution of it, but i don't see who is going to reliably distribute it. Perhaps the we need to add some additional guidance in the direction of 0, to give A some incentive to do the right thing, and hopefully to prevent accidental failures when accessing B: * a subscriber (TLS server) cannot guarantee that the RP (TLS client) that currently trusts C1 will implement this draft's cert rollover mechanism; so any subscriber that ships C2 SHOULD also ship COwN in its TLS bag of certs, unless it knows that all of the CA's subscribers have completed the transition to using C2. * any RP that implements this cert rollover mechanism MUST also retain in its PSE all CA intermediate certs issued by the new self-signed certificate, and sent as part of a subscriber's "bag of certs". * all RPs implementing this mechanism MUST perform path discovery based on the union of its PSE and the bag of certs offered by peers. Note that this requires a bit more state management by the RP than simply adjusting the root store -- it requires retaining a list of trusted roots, *and* a distinct pool of certificates (the PSE) that can be used for path discovery. I'm still kind of sad about this, because it looks to me like A might not have super strong incentives to do the right thing. For example, they might have sufficient knowledge about all their RPs to know that COwN isn't strictly necessary, but not have knowledge about all their co-subscribers, for example. And if B is harmed, the cause of the harm is very attenuated and difficult to track down or remedy. > However, there are many repositories within enterprises, and these > repositories can be used to locate the old-in-new and new-in-old > certificates during a transition. This is the situation for the PKI > that I know about that will be using this extension. If it is a requirement of this draft that the RPs have access to some external repository of other certificates, the draft needs to explicitly say so -- it needs to say that those repositories should be made available, how they should be populated, and when. If coordinated access to these repositories is a requirement, though, then the statement that we don't require coordination among RPs isn't well-supported. Without this guidance, someone will implement this who you didn't expect in the initial drafting, and they will experience a very difficult-to-track-down reliability problem. :( >> One other open question occurs to me: Should the relying party also >> verify that Subject information (or other identity info) in the new cert >> matches the old certificate? I'm imagining a case where the old root CA >> ("O=3DL'Emporium de Foobar,OU=3DAuthorit=C3=A9 Racine,C=3DFR") ends up r= eplacing >> itself with ("O=3D=D0=92=D0=BE=D0=BE=D1=80=D1=83=D0=B6=D1=91=D0=BD=D0=BD= =D1=8B=D0=B5 =D0=A1=D0=B8=D0=BB=D1=8B =D0=A1=D0=BE=D1=8E=D0=B7=D0=B0 =D0=A1= =D0=BE=D0=B2=D0=B5=D1=82=D1=81=D0=BA=D0=B8=D1=85 =D0=A1=D0=BE=D1=86=D0=B8= =D0=B0=D0=BB=D0=B8=D1=81=D1=82=D0=B8=D1=87=D0=B5=D1=81=D0=BA=D0=B8=D1=85 >> =D0=A0=D0=B5=D1=81=D0=BF=D1=83=D0=B1=D0=BB=D0=B8=D0=BA,C=3DSU"). That w= ould be pretty weird and upsetting, especially >> if i didn't know how my "new" Soviet military cert got into my trust >> store. Would it be legitimate to cabin the scope of this rollover to >> identical Subjects? > > I do not think so. We have seen cases in the Web PKI were the Root CA > changed names as part of a key rollover. Of course, this happens > without this extension today, so they establish a new self-signed > certificate and once it is well established, they issue new > certificate under the new root and stop issuing certificates under the > old one. I understand that these subject names do often change, sometimes as trivially as from "CN=3DFooCA G1 Root" to "CN=3DFooCA G2 Root". But if we allow arbitrary changes to the name, and if i install "CN=3DJane's CA", i can now end up with no trace of "Jane" in my root store, and an entirely unrelated "CN=3DBob's CA". right? > If trust in the Root CA is lost by the relying party, then they ought > to remove the self-signed certificate from the trust anchor store. So in the case above, the self-signed certificate that the user had added is nowhere to be found, and there is no mention of "Jane". How does the user know which certificate to remove? > Further, I do want this extension to say anything about the structure (i assume you mean "do not want" here) =20=20 > of the trust anchor store. Rather, it depends on the definition of a > trust anchor in RFC 5280 (on page 76), which says: > > (d) trust anchor information, describing a CA that serves as a > trust anchor for the certification path. The trust anchor > information includes: > > (1) the trusted issuer name, > > (2) the trusted public key algorithm, > > (3) the trusted public key, and > > (4) optionally, the trusted public key parameters associated > with the public key. immediately thereafter, RFC 5280 says: >>> The trust anchor information may be provided to the path processing >>> procedure in the form of a self-signed certificate. This draft replaces one self-signed certificate with another, and the new one might have a different "trusted issuer name" than the old. Unless the trust anchor store retains the name from the originally-injected certificate, this makes maintenance and auditing of the trust anchor store by the end user (or local system administrator) rather unstable/uncertain. I don't think that's a great outcome. We could reduce that uncertainty with a few recommendations: a) RPs should retain the original "trusted issuer name" distinctly from the self-signed certificate, and should *not* change the "trusted issuer name" for a root CA even when the certificate rolls over. b) RPs should retain a history of such transitions and be able to display them to local operators or audit systems that inspect the root store. c) require that the Subject of the replacing certificate matches the Subject of the earlier root CA. (maybe we can allow some sort of variance in a field in the DN, so that we permit the semi-standard "G1" =E2=86=92 "G2" naming shifts? i don't have a concrete suggestion h= ere) Failing any of these, the draft should acknowledge that it introduces this difficulty for auditors of the most common/likely implementations of a root store. > Finally, I want to thank you for all the careful thought that you have > put into this discussion. Thanks for your work on this draft, Russ! --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCXDZcAQAKCRBsHx7ezFD6 U6EcAP44rJGrVT/IbI2Hqar44KAXKr9doeg3PyqXwDnII+2TKQEA1yXbAZtUinMJ xUNyckLq/DYC2Z9S1PjPqfOg2z7wDwU= =lFLo -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 9 12:53:39 2019 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 1D7EF130FDF for ; Wed, 9 Jan 2019 12:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1VEzwP5dRpO for ; Wed, 9 Jan 2019 12:53:35 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 E26E5130EAB for ; Wed, 9 Jan 2019 12:53:34 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1ghKqx-0006On-ER; Wed, 09 Jan 2019 21:53:31 +0100 Date: Wed, 9 Jan 2019 21:53:31 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Daniel Kahn Gillmor cc: spasm@ietf.org In-Reply-To: <87o98sk1rl.fsf@fifthhorseman.net> Message-ID: References: <20190104012415.AA6C3200C425F9@ary.qy> <87h8eonzxx.fsf@fifthhorseman.net> <87imz2lpi5.fsf@fifthhorseman.net> <87o98sk1rl.fsf@fifthhorseman.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII 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] Draft addition of header protection to the LAMPS charter 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, 09 Jan 2019 20:53:38 -0000 Hi Daniel On Mon, 7 Jan 2019, Daniel Kahn Gillmor wrote: > On Mon 2019-01-07 09:38:25 +0100, Bernie Hoeneisen wrote: > > If you could remember the names of the couple of others you found, or > dig them back up with another websearch, that'd be great. If I (re-)find more information on rebex and others, I'll share it. >> Outside the S/MIME world, I can refer to the four implementations that >> support pEp (pretty Easy privacy). pEp is specified to perform Header >> protection (almost) the same way as described in RFC 5751. > > RFC 5751 doesn't cover anything outside of S/MIME, but i agree with you > -- i want whatever header protection LAMPS specifies to work for > PGP/MIME as well. If we can agree on a proposal that works for PGP and S/MIME, that would be great. > Can you explain what the "(almost)" means in the paragraph above? As you mention above, RFC 5751 is only defined for S/MIME, though in pEp it works by the same principle. > Are you talking about "pEp email format 1" or "pEp email format 2" of > https://pep.foundation/dev/repos/internet-drafts/file/tip/pep-email/draft-marques-pep-email.mkd > or are you talking about something else? I refer to 'pEp email format 2', which performs header protection by message encapsulation in a similar way as described in RFC 5751. However, I understand that you may be confused by the current version of draft-marques-pep-email, as this draft is rather incomplete at this stage, i.e. it does not yet describe the case, if both ends are pEp-aware. Hernani promised an update of that I-D by the end of this week. > Can we settle on a single proposal? Do you have any issues or counter proposals on the HB-2 or HB-3.1 charter proposals (I sent to this list last week)? cheers Bernie From nobody Wed Jan 9 14:35:00 2019 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 25B4312D84C; Wed, 9 Jan 2019 14:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.254 X-Spam-Level: X-Spam-Status: No, score=-5.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 jh6iVUZwHbZK; Wed, 9 Jan 2019 14:34:51 -0800 (PST) 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 A7CEA124D68; Wed, 9 Jan 2019 14:34:51 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x09MRg5h017514; Wed, 9 Jan 2019 22:34:49 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=/YsoECSu4+q0j9azp5ywkfj4C7htITzGEkZbA8Qx7JE=; b=bi251NyjLntJ7CPz0LcPa6BljnA3n/h3iDmzRIrqA2T29ZaeBcjRP7qcd9NIWI++0z2N rVQJdTKzmOtrI/7/ku4Cmdmea9VC9ic+cByr0As7gYrfqrmpv7yuujynFODb0g9+0+Sd W7f9oIgBHww5A5RMNmtTpRZfVdb/+/TfiKD1h08JY3WdMRKIInhAcH43ZV3SGukJWaST 0EuQh0uPWwOvkDxN3qshRc3ixJKvzLIILvLnwdIumkxqSKWAYNM1rUjM0pz3Otmq4uqK SbiTbO0ekk56K8dyxOaNcwe3qQH9cxvvb5eyFyJ+oKB7Gk7c1sjGkrSK44ziZXj7Hp0K Nw== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2pwc612nys-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Jan 2019 22:34:49 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id x09MWK77029799; Wed, 9 Jan 2019 17:34:48 -0500 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ptrt1srgn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 09 Jan 2019 17:34:48 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 9 Jan 2019 16:34:48 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Wed, 9 Jan 2019 16:34:47 -0600 From: "Salz, Rich" To: Daniel Kahn Gillmor , Russ Housley CC: LAMPS WG , "draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org" , IETF Thread-Topic: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC Thread-Index: AQHUnjGB95DAqnv0tkCxg+ex07oDdqWcuXCAgAGltICAAAkFAIAAM5eAgAkDmICAAD+wgP//zGWA Date: Wed, 9 Jan 2019 22:34:47 +0000 Message-ID: <175B8CA7-17E8-48EC-BEFA-9E5D4B685B48@akamai.com> References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <87va35o7pe.fsf@fifthhorseman.net> <38891959-38F6-4FA5-B7B1-ACB50921E300@vigilsec.com> <87k1jlnxnu.fsf@fifthhorseman.net> <2AB77CF4-ADD6-4EE6-ABB2-BCDAC4BF6631@vigilsec.com> <87imyxh8fy.fsf@fifthhorseman.net> In-Reply-To: <87imyxh8fy.fsf@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.14.0.181208 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.142] Content-Type: text/plain; charset="utf-8" Content-ID: <6F4A1B26F809044E9FCC6A9F92ACEC6D@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-09_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=958 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901090179 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-09_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=957 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901090179 Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 09 Jan 2019 22:34:53 -0000 DQogICAgYXZvaWQgbmVlZGluZyBjb29yZGluYXRpb24gYmV0d2VlbiBhbGwgcmVseWluZyBwYXJ0 aWVzIChSUHMpLiAgQnV0IGl0DQogICAgZG9lc24ndCBjb3ZlciBjb29yZGluYXRpb24gYnkgdGhl IHN1YnNjcmliZXJzIChlLmcuIFRMUyBzZXJ2ZXJzKSB5ZXQsDQogICAgd2hpY2ggaXMgd2hhdCB0 aGUgbmV4dCBwb2ludCB3YXMgYWJvdXQ6DQoNCkkgdGhpbmsgdGhpcyBpcyBiZXlvbmQgdGhlIHNj b3BlIG9mIHRoZSBkb2N1bWVudC4NCg0KSSBkbyBub3Qgc2VlIGhvdyBpdCBpbnRyb2R1Y2VzIG5l dyBwcm9ibGVtcy4gIEl0IGVuYWJsZXMgc29tZSBhdXRvbWF0aW9uIG9mIHRydXN0IHN0b3JlIHVw ZGF0ZXMsIHRoYXQgaXMgYWxsLg0KDQo= From nobody Wed Jan 9 15:16:46 2019 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 4253412D84D for ; Wed, 9 Jan 2019 15:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMRlWL00AsJu for ; Wed, 9 Jan 2019 15:16:43 -0800 (PST) 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 67CE312D7F8 for ; Wed, 9 Jan 2019 15:16:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 50043300A9F for ; Wed, 9 Jan 2019 17:58:25 -0500 (EST) 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 2TQvY9tO1YKz for ; Wed, 9 Jan 2019 17:58:22 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id E04B93002C1; Wed, 9 Jan 2019 17:58:21 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: <87imyxh8fy.fsf@fifthhorseman.net> Date: Wed, 9 Jan 2019 18:16:38 -0500 Cc: LAMPS WG , draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org, IETF Content-Transfer-Encoding: quoted-printable Message-Id: <256EB2FE-C43E-428F-9FB6-66A24EFA7738@vigilsec.com> References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <87va35o7pe.fsf@fifthhorseman.net> <38891959-38F6-4FA5-B7B1-ACB50921E300@vigilsec.com> <87k1jlnxnu.fsf@fifthhorseman.net> <2AB77CF4-ADD6-4EE6-ABB2-BCDAC4BF6631@vigilsec.com> <87imyxh8fy.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 09 Jan 2019 23:16:45 -0000 DKG: > On Wed 2019-01-09 11:51:33 -0500, Russ Housley wrote: >> Guidance on the transition from one trust anchor to another is >> available in Section 4.4 of [RFC4210]. In particular, the = oldWithNew >> and newWithOld advice ensures that relying parties are able to >> validate certificates issued under the current Root CA certificate >> and the next generation Root CA certificate throughout the >> transition. Further, this advice SHOULD be followed by Root CAs to >> avoid the need for all relying parties to make the transition at = the >> same time. >=20 > thanks, this looks good so far, and i agree that the draft helps to > avoid needing coordination between all relying parties (RPs). But it > doesn't cover coordination by the subscribers (e.g. TLS servers) yet, > which is what the next point was about: >=20 >> [ dkg wrote: ] >>> in this example scenario, the relying party visits site end entity A >>> (which whose cert has been issued by the new C2), and then end = entity B >>> (which is still using a cert issued by C1). >>>=20 >>> | Trust | | cert | >>> event | Store | PSE | chain | valid? =20 >>> --------+-------+-------+-------+---------- >>> start | C1 | C1 | | >>> visit A | C2 | C1,C2 | EA=E2=86=90C2 | EA =3D =E2=9C=93 >>> visit B | C2 | C1,C2 | EB=E2=86=90C1 | EB =3D ? >>>=20 >>>=20 >>> It looks to me like EB will not validate, since: >>>=20 >>> 1) C1 is no longer a trusted root, despite being in the PSE >>>=20 >>> 2) COwN is not available to the relying party (and might not be = known >>> to server B either), so no chain can be formed to the only trusted >>> root, C2 >=20 > Russ responded: >> First, TLS explicitly says that intermediate certificates can be >> included in the "certificate_list" during a transition. >=20 > i agree that this "bag of certs" model is where we're at for > certificates shipped in TLS (and with CMS, and probably should be for > any other relevant protocols where certificate path discovery is > needed). But can you be concrete about which certificates you think > which parties will include in their certificate_list? I see two > possible proposals: >=20 > 0) A should ship EA, COwN, and C2 in order to avoid breaking the RP's > access to site B >=20 > 1) B should make sure that B ships COwN *before* A ever ships C2 The self-signed certificates that represent the thrust anchors are not = included in the "certificate_list". I recall a discussion about whether = this behavior should change in TLS 1.3, and after a fairly lengthy = discussion at one of the meetings, it was decided that it should not. = More below ... >=20 > Or are you suggesting something else? >=20 > The problem with 0 is that there is no clear incentive for A to take > that action (because C2 will Just Work=E2=84=A2 for all clients that = implement > the rollover), and B can be damaged by A failing to take it. >=20 > The problem with 1 is that it requires coordination among the > subscribers. >=20 > Or did you have some other suggestion about how to use the "bag of > certs" to get COwN to the RP? The revocation functionality of the > current draft seems to require distribution of it, but i don't see who > is going to reliably distribute it. >=20 >=20 > Perhaps the we need to add some additional guidance in the direction = of > 0, to give A some incentive to do the right thing, and hopefully to > prevent accidental failures when accessing B: >=20 > * a subscriber (TLS server) cannot guarantee that the RP (TLS client) > that currently trusts C1 will implement this draft's cert rollover > mechanism; so any subscriber that ships C2 SHOULD also ship COwN in > its TLS bag of certs, unless it knows that all of the CA's > subscribers have completed the transition to using C2. >=20 > * any RP that implements this cert rollover mechanism MUST also retain > in its PSE all CA intermediate certs issued by the new self-signed > certificate, and sent as part of a subscriber's "bag of certs". >=20 > * all RPs implementing this mechanism MUST perform path discovery = based > on the union of its PSE and the bag of certs offered by peers. >=20 > Note that this requires a bit more state management by the RP than > simply adjusting the root store -- it requires retaining a list of > trusted roots, *and* a distinct pool of certificates (the PSE) that = can > be used for path discovery. There are whole informational RFCs on path discovery. The IETF does not = have a standards-track RFC on this subject. Any way that it is done = that results in valid path is acceptable. MUST statements on this = document on it seem very wrong to me. > I'm still kind of sad about this, because it looks to me like A might > not have super strong incentives to do the right thing. For example, > they might have sufficient knowledge about all their RPs to know that > COwN isn't strictly necessary, but not have knowledge about all their > co-subscribers, for example. And if B is harmed, the cause of the = harm > is very attenuated and difficult to track down or remedy. To the replying party, the old-in-new and new-in-old certificates are = intermediate certificates. They should not really be treated = differently than any other newly issued intermediate certificate. >> However, there are many repositories within enterprises, and these >> repositories can be used to locate the old-in-new and new-in-old >> certificates during a transition. This is the situation for the PKI >> that I know about that will be using this extension. >=20 > If it is a requirement of this draft that the RPs have access to some > external repository of other certificates, the draft needs to = explicitly > say so -- it needs to say that those repositories should be made > available, how they should be populated, and when. If coordinated > access to these repositories is a requirement, though, then the > statement that we don't require coordination among RPs isn't > well-supported. >=20 > Without this guidance, someone will implement this who you didn't = expect > in the initial drafting, and they will experience a very > difficult-to-track-down reliability problem. :( The repositories, where they are available, need to be populated with = the old-in-new and new-in-old certificates before the new self-signed = certificate is released. I will add that to the operational = considerations. >>> One other open question occurs to me: Should the relying party also >>> verify that Subject information (or other identity info) in the new = cert >>> matches the old certificate? I'm imagining a case where the old = root CA >>> ("O=3DL'Emporium de Foobar,OU=3DAuthorit=C3=A9 Racine,C=3DFR") ends = up replacing >>> itself with ("O=3D=D0=92=D0=BE=D0=BE=D1=80=D1=83=D0=B6=D1=91=D0=BD=D0=BD= =D1=8B=D0=B5 =D0=A1=D0=B8=D0=BB=D1=8B =D0=A1=D0=BE=D1=8E=D0=B7=D0=B0 = =D0=A1=D0=BE=D0=B2=D0=B5=D1=82=D1=81=D0=BA=D0=B8=D1=85 = =D0=A1=D0=BE=D1=86=D0=B8=D0=B0=D0=BB=D0=B8=D1=81=D1=82=D0=B8=D1=87=D0=B5=D1= =81=D0=BA=D0=B8=D1=85 >>> =D0=A0=D0=B5=D1=81=D0=BF=D1=83=D0=B1=D0=BB=D0=B8=D0=BA,C=3DSU"). = That would be pretty weird and upsetting, especially >>> if i didn't know how my "new" Soviet military cert got into my trust >>> store. Would it be legitimate to cabin the scope of this rollover = to >>> identical Subjects? >>=20 >> I do not think so. We have seen cases in the Web PKI were the Root = CA >> changed names as part of a key rollover. Of course, this happens >> without this extension today, so they establish a new self-signed >> certificate and once it is well established, they issue new >> certificate under the new root and stop issuing certificates under = the >> old one. >=20 > I understand that these subject names do often change, sometimes as > trivially as from "CN=3DFooCA G1 Root" to "CN=3DFooCA G2 Root". Sure. That is the most common case. > But if we allow arbitrary changes to the name, and if i install > "CN=3DJane's CA", i can now end up with no trace of "Jane" in my root > store, and an entirely unrelated "CN=3DBob's CA". right? They sometime change much more significantly, especially after an = acquisition. >> If trust in the Root CA is lost by the relying party, then they ought >> to remove the self-signed certificate from the trust anchor store. >=20 > So in the case above, the self-signed certificate that the user had > added is nowhere to be found, and there is no mention of "Jane". How > does the user know which certificate to remove? >=20 >> Further, I do want this extension to say anything about the structure >=20 > (i assume you mean "do not want" here) >=20 >> of the trust anchor store. Rather, it depends on the definition of a >> trust anchor in RFC 5280 (on page 76), which says: >>=20 >> (d) trust anchor information, describing a CA that serves as a >> trust anchor for the certification path. The trust anchor >> information includes: >>=20 >> (1) the trusted issuer name, >>=20 >> (2) the trusted public key algorithm, >>=20 >> (3) the trusted public key, and >>=20 >> (4) optionally, the trusted public key parameters associated >> with the public key. >=20 > immediately thereafter, RFC 5280 says: >=20 >>>> The trust anchor information may be provided to the path processing >>>> procedure in the form of a self-signed certificate. Indeed, but the path validation algorithm does not depend on any of the = other fields in the self-signed certificate, including the validity = period. I am aware of some implementations that remove a self-signed = certificate from the trust store when the notAfter date is reached, but = that is a trust store management decision, not a path validation = decision. > This draft replaces one self-signed certificate with another, and the > new one might have a different "trusted issuer name" than the old. > Unless the trust anchor store retains the name from the > originally-injected certificate, this makes maintenance and auditing = of > the trust anchor store by the end user (or local system administrator) > rather unstable/uncertain. I don't think that's a great outcome. I do not think this extension is the place to impose rule about Root CA = naming. > We could reduce that uncertainty with a few recommendations: >=20 > a) RPs should retain the original "trusted issuer name" distinctly = from > the self-signed certificate, and should *not* change the "trusted > issuer name" for a root CA even when the certificate rolls over. It is not a self-signed certificate unless the issuer and subject names = match. > b) RPs should retain a history of such transitions and be able to > display them to local operators or audit systems that inspect the > root store. I can see where this is desirable for audit purposes, but I do not think = the document should be too detailed about it. I think a MAY is = sufficient, especially in cases where the old-in-new and new-in-old = certificates in a repository provide a bit of history in themselves. > c) require that the Subject of the replacing certificate matches the > Subject of the earlier root CA. (maybe we can allow some sort of > variance in a field in the DN, so that we permit the semi-standard > "G1" =E2=86=92 "G2" naming shifts? i don't have a concrete = suggestion here) Again, it is not a self-signed certificate unless the issuer and subject = names match. > Failing any of these, the draft should acknowledge that it introduces > this difficulty for auditors of the most common/likely implementations > of a root store. I will work on some words to acknowledge the concern if the old and new = self-signed certificates have very different names. Russ From nobody Wed Jan 9 21:04:56 2019 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 B532B131138; Wed, 9 Jan 2019 21:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJFBE6-rdTTc; Wed, 9 Jan 2019 21:04:47 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43B0A131137; Wed, 9 Jan 2019 21:04:47 -0800 (PST) Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:b4c1:b6ff:fe27:67bb]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id E2BFFF99D; Thu, 10 Jan 2019 00:04:43 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 9251A20B9E; Wed, 9 Jan 2019 23:52:52 -0500 (EST) From: Daniel Kahn Gillmor To: "Salz\, Rich" , Russ Housley Cc: LAMPS WG , "draft-ietf-lamps-hash-of-root-key-cert-extn\@ietf.org" , IETF In-Reply-To: <175B8CA7-17E8-48EC-BEFA-9E5D4B685B48@akamai.com> References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <87va35o7pe.fsf@fifthhorseman.net> <38891959-38F6-4FA5-B7B1-ACB50921E300@vigilsec.com> <87k1jlnxnu.fsf@fifthhorseman.net> <2AB77CF4-ADD6-4EE6-ABB2-BCDAC4BF6631@vigilsec.com> <87imyxh8fy.fsf@fifthhorseman.net> <175B8CA7-17E8-48EC-BEFA-9E5D4B685B48@akamai.com> Date: Wed, 09 Jan 2019 23:52:49 -0500 Message-ID: <87y37tf71a.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 10 Jan 2019 05:04:50 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed 2019-01-09 22:34:47 +0000, Salz, Rich wrote: > avoid needing coordination between all relying parties (RPs). But it > doesn't cover coordination by the subscribers (e.g. TLS servers) yet, > which is what the next point was about: > > I think this is beyond the scope of the document. > > I do not see how it introduces new problems. It enables some automation = of trust store updates, that is all. What it introduces is the tight coupling of two previously-distinct actions for the relying party: a) rollout of a new root trust anchor b) revocation of the old trust anchor Previously, these two steps were not tightly coupled in time, which gave a window for loosely-coordiated deployment (RFC 5280 =C2=A74.4, with servers shipping OldWithNew and NewWithOld certs, as Russ points out). In the previous model, two things can happen in parallel, in an uncoordinated fashion: x) RPs can learn about the New CA cert y) subscribers can update their cert chains, either by: 1) shipping new end-entity certificates (signed with New, and with their chain extended by NewWithOld), or 2) augmented cert chains (ee cert still signed with Old, but its chain extended by OldWithNew) Once step Y was complete, it was safe to tell the RPs to drop the Old trust anchor as long as they had completed their part of step X. This draft says that as soon as an RP learns about New using this mechanism, it will drop the Old. This is unsafe unless step Y is universally complete. (meanwhile, it also makes Y.2 less plausible, because it's odd to expect a subscriber to bother shipping OldWithNew if New isn't available to the public; yet making New available to the public effectively acts as a revocation of Old for those implementations which see it). This is a new problem, and it doesn't exist without this draft's tight coupling of steps A and B. The only safe way i see to deploy this is in a carefully staged sequence: * all subscribers complete step Y in manner 1 (new EE cert, shipped alongside NewWithOld). During this time, New MUST be hidden from the public, or else subscribers who haven't completed the transition will break! Once that is universally complete: =20 * deploy New to all RPs (which has a side effect of revoking Old) Once that is known to be complete, it is safe to: * tell all subscribers they can stop shipping NewWithOld intermediate certs Is there some other safe way to deploy this that i'm missing? Does no one else see this as a problem? if not, i'll just shut up about it and let things break, i guess. it's not like the ecosystem has never run into transvalidity problems and unreliable root stores before, this is just new and interesting automated ways to arrive there=E2=80=A6 --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCXDbPoQAKCRBsHx7ezFD6 U/RWAQCqFx8soVGVWA9nq77rNE+2/j7/CMeiEs4qmB0D9u7fPwD/VpTxDI9GyfGg 7fRrButRxsW0ViOaxrGFZ77AfPQz+A4= =s8YD -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 10 04:57:38 2019 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 8E357130F40; Thu, 10 Jan 2019 04:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.254 X-Spam-Level: X-Spam-Status: No, score=-5.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 k1TXNR78bgXY; Thu, 10 Jan 2019 04:57:29 -0800 (PST) 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 E9882128766; Thu, 10 Jan 2019 04:57:28 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0ACkvwn004083; Thu, 10 Jan 2019 12:57:26 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=ctoyIGXfHmhvmcJdKCU+ddyTWPQU/2p8SSNO6doN6cc=; b=LaEJPghzPfyoSxQAEIiO/Zm3duxs2fs5LEKYxpl3bl68n+sFTgsFzCv80rrgu31vMLMT 45KljdXtR4KIEsAy8MkE97UEiCfnBSD3OH8v31+jtwqTKiKtu3hGt8cP+jAeIA6XwGws qTlN21b8vbVQbAtV/O3W+QYMJKLUeb0ZQM8NHNclMzE06N5sYa4C3l7sQg5TUvFbhAa0 kDVNsE6W5hxDqbpcnlfIkSF630exjolicY5SjjiNk+zDscbTY6bRhk5Jdj1dgx6c8XJy 1D0NdRpD0gR+YVn/zEwAi2r6Tfk8BoQ1HgmHXB6187VlXKK9Y5EwbUBZxRgLVAWFlnwA lQ== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2px3nr8gws-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Jan 2019 12:57:26 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x0ACl5h1005501; Thu, 10 Jan 2019 07:57:25 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2px22wrvsc-7 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 10 Jan 2019 07:57:22 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 10 Jan 2019 06:56:28 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Thu, 10 Jan 2019 06:56:28 -0600 From: "Salz, Rich" To: Daniel Kahn Gillmor , Russ Housley CC: LAMPS WG , "draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org" , IETF Thread-Topic: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC Thread-Index: AQHUnjGB95DAqnv0tkCxg+ex07oDdqWcuXCAgAGltICAAAkFAIAAM5eAgAkDmICAAD+wgP//zGWAgAC9cYCAADNOgA== Date: Thu, 10 Jan 2019 12:56:27 +0000 Message-ID: References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <87va35o7pe.fsf@fifthhorseman.net> <38891959-38F6-4FA5-B7B1-ACB50921E300@vigilsec.com> <87k1jlnxnu.fsf@fifthhorseman.net> <2AB77CF4-ADD6-4EE6-ABB2-BCDAC4BF6631@vigilsec.com> <87imyxh8fy.fsf@fifthhorseman.net> <175B8CA7-17E8-48EC-BEFA-9E5D4B685B48@akamai.com> <87y37tf71a.fsf@fifthhorseman.net> In-Reply-To: <87y37tf71a.fsf@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190108 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.166] Content-Type: text/plain; charset="utf-8" Content-ID: <47085748C01D7147A5B738EB71D457F1@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-10_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=728 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901100105 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-10_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=727 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901100105 Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 10 Jan 2019 12:57:31 -0000 DQo+ICAgIFdoYXQgaXQgaW50cm9kdWNlcyBpcyB0aGUgdGlnaHQgY291cGxpbmcgb2YgdHdvIHBy ZXZpb3VzbHktZGlzdGluY3QNCiAgICBhY3Rpb25zIGZvciB0aGUgcmVseWluZyBwYXJ0eToNCiAg DQoNCkkgZG9uJ3Qgc2VlIGl0IHRoYXQgd2F5LiAgTm9ib2R5IGlzIGZvcmNpbmcgcmVseWluZyBw YXJ0aWVzIHRvIGNvdXBsZSB0aGluZ3MuDQoNCg== From nobody Thu Jan 10 07:09:38 2019 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 4110F130EA9; Thu, 10 Jan 2019 07:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrEYYttCmYCy; Thu, 10 Jan 2019 07:09:23 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 E84A2130DE3; Thu, 10 Jan 2019 07:09:22 -0800 (PST) Received: from [10.32.60.32] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id x0AF85uX058198 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 Jan 2019 08:08:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.32] From: "Paul Hoffman" To: IETF Cc: "LAMPS WG" , draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org Date: Thu, 10 Jan 2019 07:09:18 -0800 X-Mailer: MailMate (1.12.3r5579) Message-ID: In-Reply-To: References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <87va35o7pe.fsf@fifthhorseman.net> <38891959-38F6-4FA5-B7B1-ACB50921E300@vigilsec.com> <87k1jlnxnu.fsf@fifthhorseman.net> <2AB77CF4-ADD6-4EE6-ABB2-BCDAC4BF6631@vigilsec.com> <87imyxh8fy.fsf@fifthhorseman.net> <175B8CA7-17E8-48EC-BEFA-9E5D4B685B48@akamai.com> <87y37tf71a.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 10 Jan 2019 15:09:24 -0000 On 10 Jan 2019, at 4:56, Salz, Rich wrote: >> What it introduces is the tight coupling of two >> previously-distinct > actions for the relying party: > > > I don't see it that way. Nobody is forcing relying parties to couple > things. DKG didn't say that the new extension is forcing relying parties to do this, but it is giving them a way to do so. There are obvious benefits to coupling rollout and revocation, so this document should be clear on all the decisions that would go along with doing so. --Paul Hoffman From nobody Thu Jan 10 07:56:41 2019 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 D04F2128CF2; Thu, 10 Jan 2019 07:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxDBj5jAxIDc; Thu, 10 Jan 2019 07:56:37 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4A712894E; Thu, 10 Jan 2019 07:56:37 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 74DEDF99E; Thu, 10 Jan 2019 10:56:05 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 551C420A14; Thu, 10 Jan 2019 10:54:58 -0500 (EST) From: Daniel Kahn Gillmor To: "Salz\, Rich" , Russ Housley Cc: LAMPS WG , "draft-ietf-lamps-hash-of-root-key-cert-extn\@ietf.org" , IETF In-Reply-To: References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <87va35o7pe.fsf@fifthhorseman.net> <38891959-38F6-4FA5-B7B1-ACB50921E300@vigilsec.com> <87k1jlnxnu.fsf@fifthhorseman.net> <2AB77CF4-ADD6-4EE6-ABB2-BCDAC4BF6631@vigilsec.com> <87imyxh8fy.fsf@fifthhorseman.net> <175B8CA7-17E8-48EC-BEFA-9E5D4B685B48@akamai.com> <87y37tf71a.fsf@fifthhorseman.net> Date: Thu, 10 Jan 2019 10:54:55 -0500 Message-ID: <8736q0fqy8.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 10 Jan 2019 15:56:39 -0000 --=-=-= Content-Type: text/plain On Thu 2019-01-10 12:56:27 +0000, Salz, Rich wrote: > [ dkg wrote: ] >> What it introduces is the tight coupling of two previously-distinct >> actions for the relying party: > > I don't see it that way. Nobody is forcing relying parties to couple > things. Earlier in the thread, Russ wrote: > If both checks succeed, then the potential Root CA certificate is > added to the trust anchor store and the current Root CA certificate is > removed. Maybe this isn't *forcing* (in the sense that none of our RFCs can force anyone to do anything), but it indicates that relying parties that follow this specification will tightly couple these two actions, with potentially bad consequences. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCXDdqzwAKCRBsHx7ezFD6 UzA6AP9kf9/GuWaocqF1a4v5MBqCYy3CXTNuTMfLQY5CTOCQmwD+J/ywVBXIQ7g8 XP+wuPFi/Hln9BBfSnRemYMFn6TJPwQ= =dTGD -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 10 09:05:51 2019 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 59EE3130EA8; Thu, 10 Jan 2019 09:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5e85gCpN9izy; Thu, 10 Jan 2019 09:05:43 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E318F130E9A; Thu, 10 Jan 2019 09:05:42 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id E982EF99E; Thu, 10 Jan 2019 12:05:41 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 3DF7D2036C; Thu, 10 Jan 2019 12:01:12 -0500 (EST) From: Daniel Kahn Gillmor To: Russ Housley Cc: LAMPS WG , draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org, IETF In-Reply-To: <256EB2FE-C43E-428F-9FB6-66A24EFA7738@vigilsec.com> References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <87va35o7pe.fsf@fifthhorseman.net> <38891959-38F6-4FA5-B7B1-ACB50921E300@vigilsec.com> <87k1jlnxnu.fsf@fifthhorseman.net> <2AB77CF4-ADD6-4EE6-ABB2-BCDAC4BF6631@vigilsec.com> <87imyxh8fy.fsf@fifthhorseman.net> <256EB2FE-C43E-428F-9FB6-66A24EFA7738@vigilsec.com> Date: Thu, 10 Jan 2019 12:01:12 -0500 Message-ID: <87zhs8e9bb.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 10 Jan 2019 17:05:44 -0000 [ i sent this e-mail earlier by accident to Russ offlist, re-sending it on-list now ] On Wed 2019-01-09 18:16:38 -0500, Russ Housley wrote: > The self-signed certificates that represent the thrust anchors are not > included in the "certificate_list". I recall a discussion about > whether this behavior should change in TLS 1.3, and after a fairly > lengthy discussion at one of the meetings, it was decided that it > should not. More below ... I agree -- the root cert is not mandatory to include in the certificate_list. But as you wrote earlier, the certs in certificate_list are a "bag of certs" -- they might contain any certs. I don't think we can *stop* people from shipping C2, and if they do, they'll effectively be revoking C1. > They sometime change much more significantly, especially after an acquisition. This draft doesn't need to support the acquisition case if we decide it's not in the best interest of the relying parties. >> a) RPs should retain the original "trusted issuer name" distinctly from >> the self-signed certificate, and should *not* change the "trusted >> issuer name" for a root CA even when the certificate rolls over. > > It is not a self-signed certificate unless the issuer and subject names match. i know -- but proposal (a) here suggests that the root trust store doesn't need to associate "trusted issuer name" with any field in the current self-signed certificate. rather, it can keep that information independent. anyway, it's one of three suggestions. >> b) RPs should retain a history of such transitions and be able to >> display them to local operators or audit systems that inspect the >> root store. > > I can see where this is desirable for audit purposes, but I do not > think the document should be too detailed about it. I think a MAY is > sufficient, especially in cases where the old-in-new and new-in-old > certificates in a repository provide a bit of history in themselves. i agree that the document doesn't need to be overly detailed about it. I'm not even sure that RFC 2119 language is necessary. but it needs some guidance to point out the problems it creates for auditors if something like this is not done. >> c) require that the Subject of the replacing certificate matches the >> Subject of the earlier root CA. (maybe we can allow some sort of >> variance in a field in the DN, so that we permit the semi-standard >> "G1" → "G2" naming shifts? i don't have a concrete suggestion here) > > Again, it is not a self-signed certificate unless the issuer and > subject names match. both Old and New are self-signed certificates (Old.Issuer == Old.Subject, and New.Issuer == New.Subject). Proposal (c) here suggests that we could require Old.Subject to match New.Subject (fsvo "match"), in order for the replacement/revocation to proceed. > I will work on some words to acknowledge the concern if the old and > new self-signed certificates have very different names. Thanks! --dkg From nobody Thu Jan 10 10:21:52 2019 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 5C6A0130F72 for ; Thu, 10 Jan 2019 10:21:49 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKZWQ45RieRo for ; Thu, 10 Jan 2019 10:21:47 -0800 (PST) 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 B5AAB130F5C for ; Thu, 10 Jan 2019 10:21:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 08CC1300A31 for ; Thu, 10 Jan 2019 13:03:30 -0500 (EST) 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 JvnljwGmu4Qw for ; Thu, 10 Jan 2019 13:03:28 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 8BF343005D5 for ; Thu, 10 Jan 2019 13:03:28 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 10 Jan 2019 13:21:45 -0500 References: <87bm5hxdn0.fsf@fifthhorseman.net> <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> To: LAMPS WG In-Reply-To: <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> Message-Id: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 10 Jan 2019 18:21:49 -0000 We seem to have moved on to other topics. Does that mean we have = settled on the text we want the IESG to add to the charter? 7. Cryptographic protection of electronic mail headers: A mechanism to address this in S/MIME has been standardized in RFC 5751. The WG shall define solutions (both for signature and encryption) to close significant privacy, security and usability gaps in cryptographically-protected electronic mail. Russ > On Jan 3, 2019, at 2:18 PM, Russ Housley wrote: >=20 > At the LAMPS session in Bangkok, there was interest in adding a header > protection work item to the charter. Alexey talked about this in = Montreal, > and he posted a draft a few weeks ago: >=20 > draft-melnikov-lamps-header-protection. >=20 > Several people said that they would implement a solution if the LAMPS = WG > produced an RFC on this topic. >=20 > Shortly before the holidays, DKG proposed charter text: >=20 >> 7. Specify a mechanism for the cryptographic protection of e-mail >> headers. Most current implementations protect only the body of the >> message, which leaves significant room for attacks against >> otherwise-protected messages. Cryptographic protection (both for >> signatures and encryption) which applies to the headers in = conjunction >> with the message body are necessary to close significant security and >> usability gaps in cryptographically-protected electronic mail. >=20 > Does anyone have any concerns with this text? If not, we will ask the > Security ADs to add this to the existing charter. >=20 > Russ >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Jan 10 11:15:26 2019 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 4A62C131213 for ; Thu, 10 Jan 2019 11:15:25 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 2-iq0YPfD0XC for ; Thu, 10 Jan 2019 11:15:22 -0800 (PST) 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 9345B13124A for ; Thu, 10 Jan 2019 11:15:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 96FFB300A2E for ; Thu, 10 Jan 2019 13:57:03 -0500 (EST) 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 4dIOP5o397jg for ; Thu, 10 Jan 2019 13:57:01 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 8CDE2300064; Thu, 10 Jan 2019 13:57:01 -0500 (EST) From: Russ Housley Message-Id: <8FA04872-6DBC-4180-B2FA-517249375B9C@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_682913E7-AD1E-40DC-98A0-3CB81831B550"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 10 Jan 2019 14:15:18 -0500 In-Reply-To: <8736q0fqy8.fsf@fifthhorseman.net> Cc: Rich Salz , LAMPS WG , "draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org" , IETF To: Daniel Kahn Gillmor References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <87va35o7pe.fsf@fifthhorseman.net> <38891959-38F6-4FA5-B7B1-ACB50921E300@vigilsec.com> <87k1jlnxnu.fsf@fifthhorseman.net> <2AB77CF4-ADD6-4EE6-ABB2-BCDAC4BF6631@vigilsec.com> <87imyxh8fy.fsf@fifthhorseman.net> <175B8CA7-17E8-48EC-BEFA-9E5D4B685B48@akamai.com> <87y37tf71a.fsf@fifthhorseman.net> <8736q0fqy8.fsf@fifthhorseman.net> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 10 Jan 2019 19:15:25 -0000 --Apple-Mail=_682913E7-AD1E-40DC-98A0-3CB81831B550 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii DKG: > On Jan 10, 2019, at 10:54 AM, Daniel Kahn Gillmor = wrote: >=20 > On Thu 2019-01-10 12:56:27 +0000, Salz, Rich wrote: >> [ dkg wrote: ] >>> What it introduces is the tight coupling of two = previously-distinct >>> actions for the relying party: >>=20 >> I don't see it that way. Nobody is forcing relying parties to couple >> things. >=20 > Earlier in the thread, Russ wrote: >=20 >> If both checks succeed, then the potential Root CA certificate is >> added to the trust anchor store and the current Root CA certificate = is >> removed. >=20 > Maybe this isn't *forcing* (in the sense that none of our RFCs can = force > anyone to do anything), but it indicates that relying parties that > follow this specification will tightly couple these two actions, with > potentially bad consequences. Again, by following the new-in-old and old-in-new advice referenced in = Section 5, the replacement will not change the validity of any = end-entity certificates. So, I think the "bad consequences" is an = overstatement. Russ --Apple-Mail=_682913E7-AD1E-40DC-98A0-3CB81831B550 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCXDeZxgAKCRCK5O7Q9ZwR y1wGAKDTioIrxNzr6n7uUCfe/s4hBwNeGACguL6SNarH+uZSP0+S2Cy6hedtXYE= =XySd -----END PGP SIGNATURE----- --Apple-Mail=_682913E7-AD1E-40DC-98A0-3CB81831B550-- From nobody Thu Jan 10 11:16:40 2019 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 4F092130F81; Thu, 10 Jan 2019 11:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.254 X-Spam-Level: X-Spam-Status: No, score=-5.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 102f5LtM16qV; Thu, 10 Jan 2019 11:16:16 -0800 (PST) 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 BF441130F34; Thu, 10 Jan 2019 11:16:16 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x0AJ6l9G015051; Thu, 10 Jan 2019 19:16:15 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=3U05ArNx5wcgegEsmfLuneN1k6vJLSzjDXJnxMiSoLY=; b=RD19x1EZYl0dVoNcJhm2XBOu6BdTgckZHnAnalXfsYOMrO/bVe+pr+1usHAPVC8gcQ+/ XUvCCMguKU5zL9xuTIPjwtn4wD7t5R/CGAOAykWhCy7lzhihvmMTQmc5WoJ1ssTKnbpa v6ThFyJMT0KQc5BwEXwTTT7DGs9piWveQrxua+gca9iYy8zLddJgQrLD+g2k4nSV0BnQ 7tvsnxW4x9hKbGjZc5Nan4THU8dlzCN+ztzdV01+c4wHH7RIbFlmvC0pgrIz3dHeN3h6 mw+hQ0LNIRiyUBjHmIxAxLflI5BwOs6Ufi/bPIE29VJD9l8rhgu0T9dpJ9r/4Ki5Esbp uA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050095.ppops.net-00190b01. with ESMTP id 2px6mxh96f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Jan 2019 19:16:14 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x0AJ2QXu016144; Thu, 10 Jan 2019 14:16:13 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2px19030hb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 10 Jan 2019 14:16:09 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 10 Jan 2019 13:15:38 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Thu, 10 Jan 2019 13:15:38 -0600 From: "Salz, Rich" To: Daniel Kahn Gillmor , Russ Housley CC: LAMPS WG , "draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org" , IETF Thread-Topic: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC Thread-Index: AQHUnjGB95DAqnv0tkCxg+ex07oDdqWcuXCAgAGltICAAAkFAIAAM5eAgAkDmICAAD+wgP//zGWAgAC9cYCAADNOgIAAha+A///kQYA= Date: Thu, 10 Jan 2019 19:15:37 +0000 Message-ID: <771552B4-E30D-4B97-B010-32690A86285F@akamai.com> References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <87va35o7pe.fsf@fifthhorseman.net> <38891959-38F6-4FA5-B7B1-ACB50921E300@vigilsec.com> <87k1jlnxnu.fsf@fifthhorseman.net> <2AB77CF4-ADD6-4EE6-ABB2-BCDAC4BF6631@vigilsec.com> <87imyxh8fy.fsf@fifthhorseman.net> <175B8CA7-17E8-48EC-BEFA-9E5D4B685B48@akamai.com> <87y37tf71a.fsf@fifthhorseman.net> <8736q0fqy8.fsf@fifthhorseman.net> In-Reply-To: <8736q0fqy8.fsf@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190108 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.84] Content-Type: text/plain; charset="utf-8" Content-ID: <566361B2573629428A8C400261540207@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-10_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901100147 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-10_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901100148 Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 10 Jan 2019 19:16:18 -0000 ICAgID4gSWYgYm90aCBjaGVja3Mgc3VjY2VlZCwgdGhlbiB0aGUgcG90ZW50aWFsIFJvb3QgQ0Eg Y2VydGlmaWNhdGUgaXMNCiAgICA+IGFkZGVkIHRvIHRoZSB0cnVzdCBhbmNob3Igc3RvcmUgYW5k IHRoZSBjdXJyZW50IFJvb3QgQ0EgY2VydGlmaWNhdGUgaXMNCiAgICA+IHJlbW92ZWQuDQoNCkkg c3VnZ2VzdCBhZGRpbmcgImFmdGVyIGFuIGFwcHJvcHJpYXRlIGFtb3VudCBvZiB0aW1lIChzdWNo IGFzIG5vIG9sZCBjZXJ0aWZpY2F0ZSBjaGFpbnMgYmVpbmcgaW4gdXNlKS4iDQoNCkRvZXMgdGhh dCBzb2x2ZSB0aGUgaXNzdWU/DQogDQoNCg== From nobody Thu Jan 10 11:45:17 2019 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 B5615130F3F for ; Thu, 10 Jan 2019 11:45:15 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 2Lw3n7DmPoVq for ; Thu, 10 Jan 2019 11:45:13 -0800 (PST) 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 9FC2C130F88 for ; Thu, 10 Jan 2019 11:45:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4EEE93005C6 for ; Thu, 10 Jan 2019 14:19:08 -0500 (EST) 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 wB-F9rztyM1u for ; Thu, 10 Jan 2019 14:19:05 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id BC9F630017E; Thu, 10 Jan 2019 14:19:05 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: <87zhs8e9bb.fsf@fifthhorseman.net> Date: Thu, 10 Jan 2019 14:37:22 -0500 Cc: LAMPS WG , draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org, IETF Content-Transfer-Encoding: quoted-printable Message-Id: <2340CD5D-F001-4B5A-8F42-6F2B90E3B7A3@vigilsec.com> References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <87va35o7pe.fsf@fifthhorseman.net> <38891959-38F6-4FA5-B7B1-ACB50921E300@vigilsec.com> <87k1jlnxnu.fsf@fifthhorseman.net> <2AB77CF4-ADD6-4EE6-ABB2-BCDAC4BF6631@vigilsec.com> <87imyxh8fy.fsf@fifthhorseman.net> <256EB2FE-C43E-428F-9FB6-66A24EFA7738@vigilsec.com> <87zhs8e9bb.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 10 Jan 2019 19:45:16 -0000 DKG: > On Jan 10, 2019, at 12:01 PM, Daniel Kahn Gillmor = wrote: >=20 > [ i sent this e-mail earlier by accident to Russ offlist, re-sending = it > on-list now ] >=20 > On Wed 2019-01-09 18:16:38 -0500, Russ Housley wrote: >> The self-signed certificates that represent the thrust anchors are = not >> included in the "certificate_list". I recall a discussion about >> whether this behavior should change in TLS 1.3, and after a fairly >> lengthy discussion at one of the meetings, it was decided that it >> should not. More below ... >=20 > I agree -- the root cert is not mandatory to include in the > certificate_list. >=20 > But as you wrote earlier, the certs in certificate_list are a "bag of > certs" -- they might contain any certs. I don't think we can *stop* > people from shipping C2, and if they do, they'll effectively be = revoking > C1. If the new-in-old and old-in-new advice is followed and the old-in-new = is included in the certificate_list, then the replacement of C1 by C2 = will not change the validity of any end-entity certificates. I think your point is that the distribution of C2 by another server will = cause the recipient to replace C1 by C2 in their trust anchor store. If = all of the servers have not put the old-in-new certificate in their = certificate_list, then the path construction may not have all of the = certificates that are needed. However a small amount of caching will = resolve this, and use of enterprise directory services will resole this. I will work on some text to cover both of these points in the = operational considerations, but I do not think this specification should = mandate any particular behavior one either one. >> They sometime change much more significantly, especially after an = acquisition. >=20 > This draft doesn't need to support the acquisition case if we decide > it's not in the best interest of the relying parties. As I said previously, I do not think this extension specification should = impose any rules on Root CA naming. >>> a) RPs should retain the original "trusted issuer name" distinctly = from >>> the self-signed certificate, and should *not* change the "trusted >>> issuer name" for a root CA even when the certificate rolls over. >>=20 >> It is not a self-signed certificate unless the issuer and subject = names match. >=20 > i know -- but proposal (a) here suggests that the root trust store > doesn't need to associate "trusted issuer name" with any field in the > current self-signed certificate. rather, it can keep that information > independent. anyway, it's one of three suggestions. I see, I misunderstood your paragraph at the end of your list began, = "Failing any of these", which I read to mean that you wanted all three = of them checked by the recipient. Now that I understand your intention, I already agreed to work on some = words to acknowledge the concern if the old and new self-signed = certificates have very different names. >>> b) RPs should retain a history of such transitions and be able to >>> display them to local operators or audit systems that inspect the >>> root store. >>=20 >> I can see where this is desirable for audit purposes, but I do not >> think the document should be too detailed about it. I think a MAY is >> sufficient, especially in cases where the old-in-new and new-in-old >> certificates in a repository provide a bit of history in themselves. >=20 > i agree that the document doesn't need to be overly detailed about it. > I'm not even sure that RFC 2119 language is necessary. but it needs > some guidance to point out the problems it creates for auditors if > something like this is not done. Okay. >>> c) require that the Subject of the replacing certificate matches the >>> Subject of the earlier root CA. (maybe we can allow some sort of >>> variance in a field in the DN, so that we permit the semi-standard >>> "G1" =E2=86=92 "G2" naming shifts? i don't have a concrete = suggestion here) >>=20 >> Again, it is not a self-signed certificate unless the issuer and >> subject names match. >=20 > both Old and New are self-signed certificates (Old.Issuer =3D=3D > Old.Subject, and New.Issuer =3D=3D New.Subject). Proposal (c) here = suggests > that we could require Old.Subject to match New.Subject (fsvo "match"), > in order for the replacement/revocation to proceed. That would require no name change at all, including the GA1 --> GA2, = which you already acknowledged is commonplace. Russ From nobody Thu Jan 10 11:50:15 2019 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 72DD8130F3F for ; Thu, 10 Jan 2019 11:50:14 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 J8ouVzoo-S5j for ; Thu, 10 Jan 2019 11:50:13 -0800 (PST) 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 9E2B2130F34 for ; Thu, 10 Jan 2019 11:50:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5E515300AA4 for ; Thu, 10 Jan 2019 14:24:04 -0500 (EST) 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 4ugirDTG1ybz for ; Thu, 10 Jan 2019 14:24:02 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 8CEB330017E; Thu, 10 Jan 2019 14:24:02 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: <771552B4-E30D-4B97-B010-32690A86285F@akamai.com> Date: Thu, 10 Jan 2019 14:42:19 -0500 Cc: Daniel Kahn Gillmor , LAMPS WG , "draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org" , IETF Content-Transfer-Encoding: quoted-printable Message-Id: <23D681CF-BE8C-43DF-892F-A4E99196D90B@vigilsec.com> References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <87va35o7pe.fsf@fifthhorseman.net> <38891959-38F6-4FA5-B7B1-ACB50921E300@vigilsec.com> <87k1jlnxnu.fsf@fifthhorseman.net> <2AB77CF4-ADD6-4EE6-ABB2-BCDAC4BF6631@vigilsec.com> <87imyxh8fy.fsf@fifthhorseman.net> <175B8CA7-17E8-48EC-BEFA-9E5D4B685B48@akamai.com> <87y37tf71a.fsf@fifthhorseman.net> <8736q0fqy8.fsf@fifthhorseman.net> <771552B4-E30D-4B97-B010-32690A86285F@akamai.com> To: Rich Salz X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 10 Jan 2019 19:50:15 -0000 > On Jan 10, 2019, at 2:15 PM, Salz, Rich wrote: >=20 >> If both checks succeed, then the potential Root CA certificate is >> added to the trust anchor store and the current Root CA certificate = is >> removed. >=20 > I suggest adding "after an appropriate amount of time (such as no old = certificate chains being in use)." >=20 > Does that solve the issue? There are two cases. In one case, there is an enterprise directory = system, and there is no concern with the discovery of the old-in-new and = the new-in-old certificates. The old certificate can be removed without = any concerns in this situation. In the second case, there is no = appropriate directory, and keeping the old certificate for some amount = of time would prevent the issue raised by DKG. Russ From nobody Thu Jan 10 13:54:39 2019 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 C0B7E131218 for ; Thu, 10 Jan 2019 13:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hl5kWu45EwVE for ; Thu, 10 Jan 2019 13:54:35 -0800 (PST) Received: from dragon.pibit.ch (dragon.pibit.ch [94.231.81.244]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 896C1130E69 for ; Thu, 10 Jan 2019 13:54:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by dragon.pibit.ch (Postfix) with ESMTP id 0D4D7171C069 for ; Thu, 10 Jan 2019 22:54:33 +0100 (CET) Received: from dragon.pibit.ch ([127.0.0.1]) by localhost (dragon.pibit.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvabR0OwogFT for ; Thu, 10 Jan 2019 22:54:31 +0100 (CET) Received: from [10.0.0.46] (77-56-100-105.dclient.hispeed.ch [77.56.100.105]) by dragon.pibit.ch (Postfix) with ESMTPSA id 12D59171C057 for ; Thu, 10 Jan 2019 22:54:31 +0100 (CET) To: spasm@ietf.org References: <87bm5hxdn0.fsf@fifthhorseman.net> <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> From: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgcHJvamVjdCk=?= Openpgp: preference=signencrypt Message-ID: Date: Thu, 10 Jan 2019 22:54:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0A8gzuggOSJepxx2VspAEwV7VcPuHtZpx" Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 10 Jan 2019 21:54:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0A8gzuggOSJepxx2VspAEwV7VcPuHtZpx Content-Type: multipart/mixed; boundary="pmX4E3FkEGu2zJwGabefOlkLaU9LMXFKF"; protected-headers="v1" From: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgcHJvamVjdCk=?= To: spasm@ietf.org Message-ID: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter References: <87bm5hxdn0.fsf@fifthhorseman.net> <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> In-Reply-To: --pmX4E3FkEGu2zJwGabefOlkLaU9LMXFKF Content-Type: multipart/mixed; boundary="------------74798393C8E8FE60D79F5EA9" Content-Language: en-US This is a multi-part message in MIME format. --------------74798393C8E8FE60D79F5EA9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10.01.19 19:21, Russ Housley wrote: > We seem to have moved on to other topics. Does that mean we have settl= ed on the text we want the IESG to add to the charter? >=20 > 7. Cryptographic protection of electronic mail headers: A > mechanism to address this in S/MIME has been standardized > in RFC 5751. The WG shall define solutions (both for > signature and encryption) to close significant privacy, > security and usability gaps in cryptographically-protected > electronic mail. For me fine. --------------74798393C8E8FE60D79F5EA9 Content-Type: application/pgp-keys; name="0xCB5738652768F7E9.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0xCB5738652768F7E9.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFWozlEBEADAIFgjylzzPH7JKRJPbiEGoSsrSaCrbWLdy4sNGD4fS7GsuZ9f o/E9iYzC7WwGhN8rB4jsLv/ZfGVbAsmpypvZdReVs/BPidR8Vo1WMOK3lww1L6j8 7UV7TwUzG72u0zMXCUWMtX3+7kWZVlohXPCzDe7xyLu5tdfPWIAxDrI3h/+a4qAR ySVo8RwzILDwjbLF8at0w52oTRIWcr9CAus8ktRKBhc3MiUsSXHGgZLujUsXKAYg Vmh53uEVsjigeHZh6XPrzQPTnQ/VDcqNSRl4n+fQ2e/sZV7CQttcqb9zfj8P6Lyk jG3pe1AUSm9A0o75bi8PUluPWyH0wdt4D29xabFFyBANyYqKiLyZvnBqGSkqswnW 00QoYtMaEBh7nyuoUCa0bTMCRn8NaXRCnuINx+E2llqJqeQ0sMJ5WSQe4RbkWRsF PJOdiouLyHEZUpyQlMFesu/mN565eZsw3a7u9hxnoFgX0tF0hoONMRSAU1y3aZeb a+DvwXDQcSaHmBARQ2v8qWdql16Zhvf7KFo5Cris9jNknInzs2L6pHVZN8AY2ESO 2UXQJ+Fyy5BEHXS4LzEnWRPLYkAE5eVi+ZDcRMQeO2L3ZenqhcRRcQUAaRObho0L WzE+EE8ZvQxlA5hn/4/lHQLk8ZiEgenl+y/mtL8TeXB1HO4DrqahXvlu2QARAQAB tDxIZXJuw6JuaSBNYXJxdWVzIChw4omhcCBmb3VuZGF0aW9uKSA8aGVybmFuaUBw ZXAuZm91bmRhdGlvbj6JAjkEEwEIACMFAlcnOjUCGyMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDLVzhlJ2j36SSQEAC7L0ZgFNXZAsXUzDIj7ZcyG41jcIaF oBz+VyIz/72zsr7tR469bq9QulnEdhr5Zxa+sZauT+tktmehpQpkwAZRXb4jHawS MVGwzssKehUe+sN9rrkIKvFbKMHcL/ZUiaFKNL0dX/tbtA/lZGwMSGlE9x1BWPKX JrqiKUpvk278jFwkOfx+mzVSuuIcIn2o25BM6n4wxQnDizcES2Z9nXyYzSBagvW0 v2LsOEatYgCFoTxuO37uPHXL3NlhipRx5dfIxKjX5zr2DOxKcS7SPio9cGJ8Z5gB jfC3ByoZfQVmrR0lfIxZVtFTzR8my+fOLDhL5U+3RVbGHHHjzJZY03a8RUpcWsMr +lsogSH4h5z8QgkwfhTyBAUIcewHU5128dRG8m+wfTTHnQFCpmd0Ql3beRbAhN/e xQx5aJq81rPD7dunQtKB7iyiDpHjLWJ22aBr75GjSfF05Gr4LgLMFkATzrpnlXyR uLtZ0TTURWw+pximLJu/Smn5CKUClJayGOgp8a6bmNlxn6li6SZVoyu/S9RCUWTB z2dsv+iDjk/La7gcLxwrtkf2wFxvauaax5BjXoEnOAsD12wF3Snr6ymARh65rZ+C /HaiRpUXoUFIWUh0gRnJHa+EOxXq2wKBJul5toTlOEiqK93vVwKLlPgjiEY5NHEU 7zpE7skkXYqKhIkCPAQTAQgAJgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheA BQJXJzpdAhkBAAoJEMtXOGUnaPfpktIP/iTLClFO8y+KN00z7cHxbistBKjkFlS+ Q4RzNmXQXgXMaB9pMvIbCP6Fm11q13GGT2MLm5gpoIBH50/fCXxWPGaeMRyKvv3p PDbSwm7J7hDP5H2yCGclkzs0NntiZXbOmLhFdZjsIhi2GnNSrUve6MOUM18p0ph3 f0+Ia3Ki3HaURLD4sGUJ12ig8tLI82nt+NaxEKCaD7b7KtV2XtMQ7RAVwax8to2m PBWzZReX4nMmqX8LNXhn1DFkCSGCl45umK7i39Em4+OYpLyWy3vMmKuGXA6uVenl WQbKuaw+Rer+MUOTM2sABfm5ffiNMGBO94JEGvgwSVUCmrqyBsZ846q+FTlJnapY /D63bIeINuX20TYxpzZSKh0U9sVKU6cd3koeH6CFYPLEICQBzDFZ7GTg9MJbAbGp y/P3klwdfHo8AcM6QIH7MIdfrkk5WljF1vz3FvWcGmoqmGRdrHt/JBsDw94p/d6G n/HWAX3gJvrF6+BTDUZ6pmhRFXrk71/M7Qz7FI2NzIv5XWmzYhxkQ58om1adBhx/ PQZmCFJeXkp0pIBSWa3vuca6LOwsvipRoMhXSm9UCYFmYtsny871dIEMWfDaYisV mBSKRw2mZnAo/sjARxjqrPUEAIbzGJL3ePnyqj0P0mLYOqiEi+wxMEUzYpCn9WZc r1I/JWQ1Bri+iQIcBBIBCAAGBQJXe+cuAAoJEH+zxRJjw92vLy8P/1xWquKLJ1E6 n0aDRPLRKV3dcdTS1CzXLbGOp1IkPrg35hAJtiqhlYDWqY7Ff/oHzYFwi1iClHwq FCTx3U2nGAU6O7/TVR99c9FTV4UdbO/et3J+rb6dRm3e+DoqCgBq/uvCrg7I8Gcw vTLOnIxXeL9N7ZIzV7Ac5rdowvzCMhGClRrT3im3fBpbe4EbHPfrTtBclZhL52rg 2EYrfwu8b3OeNgNzEfS+T0GM9O9ZeTVU6xqtqCfyYYzTSOTL0nLxabl5QjSq+Xn1 9Ye7tDGDIE47Tt1XCMQANwpfQzDYbJhYeXhX9fUw1oDIX0EbGJI/X7aHhDPn+bFY RsBUS7x/tuD6STnbDLanNjRvyBpttMkMwW9udO0QmMwApZ1PqyB+xGoKQCQhnN6y 6RQDUjMBD180J0i6f9K5zezwrAqWjQo8fU7S5Q02d91iRk3msZtbNR6nM+ulVX8s 8iKhHDBiJdzW8WT/wc2R06ch8LQ20sNscU4ZrdcC5IOL5uadCT0NTCr85vC47Qgw 2Ywe7lYwvamkU9GeM0xIs5ZaLkC9PpWOGnQbrpFDod0nL+mot+/bdtI8fX+p99aC xmHAG9GIt4V0unAVvFo6HQUKN5h49sfLQk5nZqAfhrxFgoKPeL5IvTxls+D1+/1W UHBc9FkdnBLYOQz+IXKfpjf6Gus5u2dTiQEzBBABCgAdFiEE67uJIQ52iILmzp8S zf3jCQ8RqFAFAloRcs0ACgkQzf3jCQ8RqFA0CQf+MYsDDjj4qMI+e62hhiyg24h5 cyRFtfc8wa0cpsAzfdAHjxx+vX2Nf7NT0EgfmOPhQqDdL7VOs4dqAxP0x84D+Hqc Ps/8wcH9TWsOKykohWJI3LmOoQJ9pGA/piX3HMjTDQTy2C4DfAdgJEJjeoL5kdB4 EsIRUBQsi2mZz5/Uj3MoyE8m9JIMWsfgw14F0lT1sG2VLWU5s+NRD7nCkNLnzlNZ dGKDyeppBf+QYOKYOnrlVuXFmt1lSJjocB9hnqYI3ZQca/Pyex/mRZ6ygxZsQiRO Zl0NRJW8zcwDOzZmsyJbroDkH/H0q4Noh+NvYUov1ByvIC+0sf6zk7YUlm6TC4kC MwQQAQgAHRYhBOSm1kc+nalhW5hsG137/dXwIyEQBQJbKyeMAAoJEF37/dXwIyEQ ktMQAIZof2Yb4Z5C9rbci/TD4b85tzEpOn1/t1k13Rro29AgFe1/RnHl59EyoTFw Ii1sTum7RX9DMzZGmpJcrMM5DpTGWH842qz0dD/tj32bGEUcCe4QQ3riui/F+STI MVtQmFNRhCKxKw0Kp6zSt+yphlaVwbeXD4XdgCTJ7+HiLPHq87QkWn2WuJhjGuLF L0Cz65bp58YjUCTVJJ1FpcIUjkirO1lcL3jsbdoVhaYlkhu2IuK6TialybqsomQ+ dAEEWkOKujqlS8VztQeTSEm16W2XqI0omPaJA5W5xE6efqtrq2aL+EaJ4F5eUFuo jBbtidd557PYTAtvUQikoqUA3BzugeCUY11bMhi9Yy838iEDkJZKUddrlW2JltZR l0iuTbM6li9urkfn4zMFLhK92U5VC3dsfo7Cat8jqwKHwS2+WksNPlQtyctTFpwq W1QTZnvI9BzlisCJq8PxHoWdbE5TYQh27PNKYRTvN1xsrM6OYeMhlnWaAzU4laDC J+VPSJqQfpGqNgcGCbY8ZQHP2hWPARf1tWtH75S5MeMmeMZqiO6w19OG8JgqBTzK NVbm/4Tq3WDQuIZi78G9xOWXdxkioEffvj+pvDl4cwEpSvpXHUrJsGA/lyeoYdlo dzEajN//a/RF/OiLlL5g9dAUGSzgYgHxDEUPmEy+dyIwfXI+iQIzBBABCgAdFiEE sCfaSQV5gVpBDUL9pIWg7VG4t8QFAlsFbvMACgkQpIWg7VG4t8SCXQ/9GokbY2It xw+8tP5xzuxkR7hC90XMi2pUjUoChuoK/Q99wHFiJKLPhWo/Y9IRefIx8hINxB5x pJfxO6C5HyMYcsKvza+0KWpVNjH9qTD5zHzKjANtwLc7xGnGquSzlMR7XbqwtGz+ WnZjFCJ3u2B3g5vEOIC13yojV1FKCZs/m2Ym2dKGB4+ZMHAb7dGugVc3QCVNH7L+ rW7rJiK1v92iIAoKS8OjZLMR9Iv0tlm/ng/OX0tjMzB2EeF6G9AWx5a5LV6+w/B7 ZbP8V8p/wdsz9JLdvB/qq42OXK8ACxlsnQ6ooSrXpjZllVDG48DR2JlgmvpUil6f DT+wA7KeCnmXn+RuxAfXRuolsFhYjRDk6y9UCGCcMj6x/S33JXO3mQbT3AO4Lowv +sF/YpiBBMGyFPs2JSU8QSRZgpNkcrZy3YGJUdgNglIb5ywOagz6Wfrkq4sM1jcP /86htV8w3HX5EshMvFR+/KgtLIZuq7WvGGnmJ3ucwK0J/1HgTfUgmp4jWexaDZ8V H0fCEKBbKpm2UZO2m4F0BBoZ6Jadtcuh4vulNIzJ0T7XwE7oPERA6TEYVDlwCtto HJdFHm/UdGlJfktWLPSS2N1pf4qvt/A2q2NLYn7/lwwzibyoyYqQm8vTcJYZPo4K xVYkwHu8k/a7zgN9tnSjMg/2huzRi9oV9Xq0REhlcm7Dom5pIE1hcnF1ZXMgKHDi iaFwIGZvdW5kYXRpb24pIDxoZXJuYW5pLm1hcnF1ZXNAcGVwLmZvdW5kYXRpb24+ iQI5BBMBCAAjBQJXJzpOAhsjBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQ y1c4ZSdo9+mfeA//VXef1e3yFrWO4N7XWOrTLSDWNCvUkyFk6gE6nq21KlgJ70cK gnBXK87WIYt7HpcdJ7zOta8/fxqKEWgruNAFzzHBiG3UNylMzscXJcnn89yHwE1L h2xzx6jO+b3qkE8+YUNyb6KAbp2Q7zX/2guo/z4FqDPwbnwGS1wWG+eOYuuQl+0k AlDgvI/kqVeCZQjG72X/9ZrwAyS3L594dMghutAYNMzjhr0364fAng5CMc2+86mu DhRkCF6EsDMKT6CLry4d+EfQC0rBn+/+VqDs5iV7Qpl6XEWwedUT4OF7weXIqq0I I4K+RYa3PkIEkM79X/FRBcFInEl3hDjD0bJ/SYn4uOvyK7V/JoSivry7VkaRpZvN BIXxhzHujoxZXV8DIWlQ1Szcze+mYmnCtZB014KlBpzN7Gc1yvOth0UMvHzPswwc TLzpBKaOZoNID5WAAfNXeijhHda7fBkoPCbh4UMGPw3kgHEwx+N+KeclvTVaQB5G 0Cor0p1d5Yazp47o4Gbw5KlqjZX+XDchkiIJ2jA9oQXPD3oPCYRL/NMCKzviYQ2u Gdu8OvMVUWQ05R1/ZKf3HzUUntfXdMSMQ1SEkkjztb5O2T14pRquSO0p0d9WkQyc 7cuDo0mIC/Clxh9qvN+aiuvCnWmxwtkEQUaIC4dWA3NjVjBcyKs9WdjsyfOJAhwE EgEIAAYFAld75y8ACgkQf7PFEmPD3a/2UA//YuEE5v3O2MMpI0kyfUhckr0Atiiv vAbcmtC/AkZ18pGPxvenyeUYK0WmjfaH/u3/2U3E8mY40lxzvpj5+q+Kx5E2TTmI YI4jJwvxD7Zsu/NA/XDd7G+jaKaAkaC1kVmpBHor8PvROtPBzLOlbqH6U3dmZm7g jO/al20kyHzc9m6zQDVwdBSEiMKXjr641PQFoQB0OmpwLn0RYUXA+P7MSFmBO2sB T1yFJePqzjbnhYwprcEi7L3RtarIy4m3z6YthN+ek3Fpisxf+m4LmGzVZCLQFBVd 0tGihI6BgNqKnSZeI7KpcdLRX3h+6I42rNhgGNAGSmF6itW4wNkvj1uHZzZXIA3E Bp9xlI3zaKxtAbVqeXoslFGIaboFgL4TDw5aZWQIRY4rjcbohD42XkGa/4XIigFD NpniKhH3zucLzZwsJu1owyz2JvlxNkEQgB4NoPRMeXTykIuR9Hic8sb+751MTnPF KsI/ijs4osudhNw6RT1Z2F9lX/prqIEnLe6+4UOh6gkbdm/TfuAcWyZ3zeajrGb2 qWxHJje85O3ElHGyfqafj9F6260PEnG+5s1lrHEvfdygabwZwwzcFo51mJGA85H0 TlIxSuWelozBaej+Y72K+J9b8EVJ618Y3fvAZ45ygzDBIJ+Pg4r1ZWF8kWoXB4vh K0wEJDo5ktzFZveJATMEEAEKAB0WIQTru4khDnaIgubOnxLN/eMJDxGoUAUCWhFy zQAKCRDN/eMJDxGoUD01B/94O8L8JNhYo9gWaBZRrOmo4lPeVqfkdrSMbgDoEGKg cSUBK3L0PypMKxkTDxMWgps90SQlvphAuH8+2XgqaAqud8kufqqbCy1suDREmgux OycRIZZLwlVTFpB9x7K4HIBrQMEMtUg/cwvWHr6ClQ1AILvhK4ZO0nFg6cjH16VQ jotggVp5E14txae7wj4Ndq/tDEWTeHeKBpQyjgyuHFJ3MKY8CVNk0G+P6S6IEaEP QXbHj4eEIkPJI6w9/Nftjj6Oud7g6Qca87XJt9ELkpTVs3f7DOJxXUu9ArxLcWi/ 1tACFD3bQj0VwXNFIsfbrRKXYw4aDUBMeBMXZgXFf886iQIzBBABCAAdFiEE5KbW Rz6dqWFbmGwbXfv91fAjIRAFAlsrJ40ACgkQXfv91fAjIRAibQ//RayE81NcW+Ku 4Hfnmltm+nJRUU592S6Jf3HahXOCF3U53nNRtXd4toJSFbqXfXpmnZE6ROsfrRRe Ll6cM+D7/n2FaTyw+mwOZ4bUKPvy5PbADm+LuFEfkYW8HwjNMn7e3mPdbHxodtDJ xBkVba4eyGOYvWaiTPfT95EE/adEErI5L5SjLzM60QvNMjCBVq9el9PqJBSIDj+k f6dDAdhGvWXPo9NRXBNaBpYUlIB6TPFamyBI1HayKU9MeeWDPUOR3FFnfmsU55In gjRi4ffQNbSjSfgvOwmvry8WkFOtPg9kjQ25QCxhitcqfUCqi2O3BgMg48kasmUw 9DINn/4hNqCM8mYv1nNTezOjds8D8N+19gJ6XwNyI1u5DY1sgbL5DyIMVo1Kggnt IV4z21TueIhvUm44HWayGICd3KHr/tc7J+4FyvjivZlP6OWKNj7xQhcLDIrI1vAO Ph3f9l/wFRmjPlpFSZw6IjxDx6VJuYX6tCMjy/SY5gJuhzQqW5a7uSZGTyUc+WYn 9dNcst7AI8vTyje8LryPYOlop3tkz6kHDdQjSauUtggXbLdW0CoHWDIolM4c8iDl jBR9g74cX07q0QQ0o3sCMFodpwKlOyHbNohIfFnM10DJLy/0xEePloVw2I+78dSD H0eXSLedGPO7V9D1a94cVbawAGgTbKWJAjMEEAEKAB0WIQSwJ9pJBXmBWkENQv2k haDtUbi3xAUCWwVvCQAKCRCkhaDtUbi3xJYND/9uo7/jmN4V31X10QZQtDGGwQjQ 9XoA8AbyBdkJvhWDQmThE8J3hPz8Vhj0vHNYj9zLAbSDDFYPtfeNLyU6osJQwiVR tTTZQWIfFqBhEBZ8Q1hmxRsJSZ+76Ozs33JEsNsX9HuTQcGMlHElR+bsBrIxQhN+ NPzw6/r8YT6f8RF4bRuS+uS3wr+m+hNYdhdIFvynQl0r2/Sgbjui4TH79byLHtq3 lpGWpH/C0TyUjO9W6b79D6Zjw3433UsiL+pcBGKam7EmV/lQN01K8ZoipX13tO09 tfjdnV28CTBfa8IVjzR5AERz/UBV8KwP3oy1Or5dsGirVtCKM/gOOVQVrTYqot35 2Yu6jRV8deRijZlgJhKg2UGoe0/oTvOXvZN4uRCsxzJ/6VYczfSthzT+232Wx9mq 4UmS7HjgHRK/hIedBGwFTawABl22hVawip0SNSr0ViEkc4OGBR2z1vsYXNyDIdBz VIRIpLusTZNHYUAkpI8ChIDpxOLpGXGCaGqBY1DwISATfSlfAQ3n7ZWOHfSRVyaZ 3rPO176t36vhsoJy+naTvPDyaTmbLkrfgVX0YsZzkPpTuk7X6GfmjBm/Cl0MrodC xt8B46RkkObRnzUBjdwtyhWEydGtbgz542kIoewxYgI0YXo7d/H7NJdlxVFsEfck sq7mfYvX2XikLXuTyLQ6SGVybsOibmkgTWFycXVlcyAocOKJoXAgcHJvamVjdCkg PGhlcm5hbmlAcGVwLXByb2plY3Qub3JnPokCOQQTAQgAIwUCVyc6dgIbIwcLCQgH AwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEMtXOGUnaPfpBJ4P/1WPpe8bRj3vavxc JmeGcgDyZ/4Z8A4xoT3rhILE+CIF9ttDQd1BFxQMfLQkrhmPOfOtnQvwBkHhp86D Obu65U0RRrr/dhLRNp/9i327Xusm+TEZs04HUe3D9Wjab4wjfpBKeBX5h5dVzwRc l+lixEBvmZ1AxSMh7diO3XoXTfFKICR3SH2fctyBIcD6gGKuAkZH+z/GZJNpJtiY fF444C+XbIwkCrjQJ8pLQ6cVDNzf4n7Dn6zbpRCCpQwNslt5HBi9wj49roMF4JEs pHl2gc1aKm6kXDzjvPye5lRDqC1Yz8GKvH+TRlqtlNK2yZ0Ux1+G3p2scO6wovup 2wBB049M26cehR/H3s7s8fOnVpRZ4Ks0AzpImVs3O6pf3m+6cx17kN0AtQ/s8zZ/ U0k0gwI0RaYCLj1pAG/+/1skX8KndF86op4rAO/CPhPtDDoY6UGm/4vYaEEQdi3x miPoAbWkV92kaLVzU9ROUdX6uu6/PdEo7d108wAyvQekaqTGuk9Cw3uM0tgmJw21 AY5Y7GBkeVmeytN0MdqfanwhQU7dsL8tidG+dum9MgkSDXOk1g7P0pUakrPwE2j0 mzin1VIVyPJNJNklehUgRD8CGNHFEkT0qADX7/iF44lt0QW4zZL6W1bbvfAg0mzA XnwHN1/KFba2fq4oGc3eNUAIWjqdiQIcBBIBCAAGBQJXe+cvAAoJEH+zxRJjw92v KTcP/30Jzpd/0WplsS891bNkYoIdzNZGYPjY0OPJiKpkmS88LvTEE5+9ZzlHcgZ5 JhJvm7GL4jT0IWvd8GMeItoqCyjUl8g2tXQW0JaInUJtG905HlPuWvwje69jmrkX jb3OFYFbqcWnlMhE6BVv0Z0IoW7te82ZMKk5iqJUN4Xf/9T/ZxRnHGFPxuA0FKJ7 gcwlerjiCmeNygQPL5uJ5PLgFtDzSyRzmlTPr7g4C6sf6+9N0RNWGnm7zQtyLl03 16UBwhjGv4CUKcRpqi45Sgwut5NZWAJOYAKZH49+vkTwIlmKRr6N4tBF0615cHoa kSaGAPJTbMJOy3L0hV3yroKJjLQrR+LyVDS9bIBPLaVoUA+9yvKt3B1yzyAt05NC H/u4d8XZ2QKyy0K1xFhbCKEXEAyxlZiYctAcp5frjbk8JiUU7zFH12ZNDw7vlHY2 itqw77d/IvyvQ5DmuZU9/TNMlf0V9VtvOnI15ynax0aeJQvUDfbKBbhLgs4I4kim JfsSmqCxmicL6MTQJnbri5rlYrbK4jRX/m4tT0hHwwQR6udtUPQ+bt44RmaHxrth zmswjhoWbNONUkPzj9T/Pi448cEhKRrECRXRE/O6KgKQpDMuNyBDgdA7TiCkla3R OOkAWTABgNSsrLDZFaMxCh9DVP4Bjpo85Le50vKlr2CL3CjeiQEzBBABCgAdFiEE 67uJIQ52iILmzp8Szf3jCQ8RqFAFAloRcs0ACgkQzf3jCQ8RqFBSAAf5AQA0ydPY vtKppM1eWZXp7WKUsF41JbYZ6mBivUuOExXkdQXqTI3oz3Cjod71S8xLAyBGRN05 PQlw58nMkVBs1M4B/QjhdyaEfMBnC4AW62YnEYacXwctiN5IgI2cKXw6OnPoZS+b v2o+WUgD8GYRiWo9n48qa+wQ/nw+t7aM17Dq5nmMtWhMixWhPLj8VLdwt1pw5nyZ eh7WzoAEozksgbAYoU/JtSxmn9NNxPcJL1IEtMzQfAkHGW9lUQgvVmRvbRaF3k8E Or8LlcuNBgVHJrnktcJin5A+rloEeVfQjCL5RUcPXZkYBn5Tus5VLNm+chRkRkcv O4KH+hzJu8IPhIkCMwQQAQgAHRYhBOSm1kc+nalhW5hsG137/dXwIyEQBQJbKyeM AAoJEF37/dXwIyEQ7gMP/1q57kla31Qqz3Nzf4D2MDScPfkFJ2KRaerPnvHjSwVX IEh5c4Ov75UDgzQRm1SYHPPuYb9VQ9dVFMT61BCsNgWi41Cso+zv64S1e2KEmrc0 7vpUKHv8yHhzPWpUXG46fQg0cYX58khQRteiohtYyMMGjOWqLS4OW7hIpjh9G46L cGIcNeHilVLGZOZxrLRyROw0LKSHEJDEabx0QFyyPjtV6g2oqXbKwvphHyzm6wsC WJCGkXZLZC76PzkMbsbwEjzm+RVLF5Y6VMS5PGA4ETUGcEmcpI6HQdykVcRhi3PS O+VrGLJtjcK8M7EHqrphgwp6puwiqFUx3MT2swJq8k9o3uz7PeDL07Tlfj1a38KL cLnwf5jcMjExjIvy+8IIIbi5USWOOjItSKETUng/9XtBuQMjszW8KCJvN9deQiOe U6ZmISXOXXtk06S60f3nXVFVL+mC+6wdtUskcfR8oyrb3+8RoKyvHSMOE4Xm57AO aISVOLehlVRIvelb9hw0bX8VtcF9mrNXt3rfZypcukpvYu6ps8suQnvPXY458eCf WtAAfO4ddna7qDiE/gMb4DT3doMMDGZFbWAne18DC28nv12Tf1HYm4mPHnrd52jn WjjcF4TyunD3ujcXv7ZThAMqAAoNT/g78MgGLGUXyJPOeC2jsWf5jOCYrGmEYLO0 iQIzBBABCgAdFiEEsCfaSQV5gVpBDUL9pIWg7VG4t8QFAlsFbwkACgkQpIWg7VG4 t8RiRhAAkgfigj0N7kdxfkFaf+IhyQzWRWacF4ydazr49mP2kFl6v5z6x4/sXCK8 6Pa8+CFSu86mvddFYacfnHmpqWCVfUOyZTiHKt1VNGa/e5+XKVs6hsbuFEpxnCvP jklKNht4fc5uCQE8N1AZAxf6QY3esBxoY10kOQsAXY63UZFmdwSKtEM4sTJd4LO8 2YDfMgqDoL75L26Pra7UhPlYkixk2UndcImz7VHzWotcD0hhOVEeq21xcfFfIif/ fZzDfb6snBOoePBMCEQA4bL7fYFid8Kqdj0+SZkD3ufwBc2HuXxWk2F7IWoX47KB vjNPKLaHmS2y2LwB0GPTYlxLK0oufvxW7bM5EusOyUdpbxtwogB5eDTDkA0xBPFt OUQ0X3TsgCm43hPmJtM6LbeDU0MXT0mmAqmiyaJ0LbtPZzffjKzcHssE3HxIfcJe URtdXxvPxpvpTaR0fwdxQjlGs6bEK6cHDmsD5Z+0u05AObrZv+e1mLsxAtTtBay8 CUaRcFrBDvZmDQlANJ/xxRm2tHHa1uxAO2VCmIlesJ60k5O8cCEiwdWZTobkwWhE 4aVCDEtv+qt6W9vMurfy2yB5N59vxFtvwUqLO+r49OC9Xy7Z289VQXtIdVVhtLii j7aLNd4Wvke8yJp1BiLhZiVJTN6fNWfXVhMM8J5Vz+LUVQ1Ynwa0Qkhlcm7Dom5p IE1hcnF1ZXMgKHDiiaFwIHByb2plY3QpIDxoZXJuYW5pLm1hcnF1ZXNAcGVwLXBy b2plY3Qub3JnPokCOQQTAQgAIwUCVyc6hgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMB Ah4BAheAAAoJEMtXOGUnaPfprZcQAL4wyuQHrMUb56gfvipTZNAV0YQopEeUtJlN PT3MDYTyD4AiTDmsDZwYaPI7O5m2bNSeLOmhAdqkUXhUOvEIWI0ABqkWVHL93nSE zFiI5HYIbmh0UqpYf0myXQdWE1qjN6n1xnqk1mmZ7RSuIJ/9zwliiX5Qyr/RVfxO VU3iBskn5iwGNs0N2anU6oA6EoD3VsuV650aIJN1c1e7bOd0QT4Z+FuYHPqsuZ/g nbD7AKJIrpO/DoWMG/Ayzw3M746Ff6GKlQFaCmMja6pkfX8NqylbPY+lDlznu9LY XK3z/7gcNSZL3y53d1G5DvbK33sDXpHEpQOVbl6cAR6cgN0jyjh5Pg4VXKWTntAM lK9E/f+3HmH7EILxF6x9kl/TJet94igOvAU3v6Ktd3CPhc2XLvp6oik7NbE4hOFm kgJYq1pW9hffzh9NGzF5l10r9Z4j0bvxbbqXZCsn2/WvK4FhidZhyHgceM/kbH6j ZdOEZPw+Kxxlfsy4CeNDexas2OO1coz68lBiO6uD9+QgoV207hy4D5txTRF3YnR3 TDdPbxiXnA8T/xNKOfMvWzfT4pmsuQdK9+DLmDPHDCZli3/5fLh2B2tb/r/SxLRN EaJjLEzbgPxxH53G5FOvjGR4isUbsZz0n2K2KZSxzVAEpkG1qmMhtGM4KZB2l+KT HBpxzElRiQIcBBIBCAAGBQJXe+cvAAoJEH+zxRJjw92vLwsP/RnUNo/RJim4FlBb Q9l5sbcpaCMyEKRMv0YYLT6QpoNziseauPxpQ1ITLeruwuq4C7ZkTNy+sj9NsC4R 360YR0Dl10rLmYEM49gPOO5RQXpJFQsmpwZRFqFN0Ct2lIFYD3XhMyH8/yV+DPJ9 EafZQlC9L6+Q+up9iK1JdnqisdPGHduXK9sApujb6lkS8kF3PV2BitdLTgsVk0tG rs182FkgQ68rMpubCB/IUkTuuU58VWKGfsXhrndxRb9g7l2/6S+1MWUXochI5Bl3 D/XtemP9aIL21EApXj32/rfczx/y34okbs1ePPGJDTC2Qwprkcna5VPQWOE0Aq+I c/Dy3GPWT67IfblVV3/iar7z01L8nKkCBWx3VVLOFgVpOeGKEjttHlqK+xaamIgH KRi4blqXGXIT19RQ8o/krDV3U1EOC/vLQn168vGJ3iOI/zISEG6Va0hYAV10ebhG i7S9VIrZ9qM4gA26RhP0i4JtxPo0gjdbtUMosTxBrDKLZyAqgRn2eNOaRz/aO0xt j/HrUbUVyDZANaVf69rn03yejq1/pNrDHfPwPma3TmEBM1ieZ1ciGT9uwnIQOde5 pNsYGk6B5M85ZgDgj9YaPrKobL1lDcq7KddAks/L+SHWI9o1jj799FJJwukwTUsP e4LRmxnydcdD3O0O7RzdwurQV1jjiQEzBBABCgAdFiEE67uJIQ52iILmzp8Szf3j CQ8RqFAFAloRcs0ACgkQzf3jCQ8RqFCDAggA0p9oMz9h0DODfzcKxjgJxonnyYhK E9ZP1dNB7b+NSsRShQIUL5VQwoU+ZxHFUH4dbl9NPc4fnFRtfjEkou08tpf6g5cP wK3+26nDTD71xdtDkt1LDvCtVpEDFdw/2BSJlMFX3xrv+ew2qXdW6yEUdxgtpLWv QVuGGQFx27UuqMu8RnOs9cVwBOs8E0dv8+NZG3mE1ubo3wiUmr6nUD5hQarmu5q0 Gq0A0f1ZmyQPgyRmdsVFO2VGASv7pmLvzIyaAI7Jx6fWzdJFpQpZYQ8emGCGqbyG N82n4RAsZv8b/wQM0nC58g0zTVqdIUhtt/EbTghOD8ayKyWx0ht6Rf8dh4kCMwQQ AQgAHRYhBOSm1kc+nalhW5hsG137/dXwIyEQBQJbKyeMAAoJEF37/dXwIyEQPhcP /2H+uYxE15a3Qhei1e133v/t1mCs1MBmpjA3urc2WsyPE3goKFH4p58SLxHImL8A eT74eC2MiM9q6B8TFpgYBv1R0b2tBQptzp8tOFKRxmITkZI9TlX4cft1mSFVN/Mt n3iLr9uswTeQ4Obl6SIlMJtV2tEgspy39nBO49a57INw7BuTnJajHrhznTb4txoa eXp+JNparqKbPAN16xoZb1NH+0UK2nPXRAdDWmujl67km0OzjWOdJdPxlZBnSOhh w8KC/DUBbLcEZ8XfbFMqNXXpTOGlCcBPpCfpxeDRR0Avk1A9OBbnklTJ4s9gpEVv 73BLWLOPZmFz49dOFrZLiCieJZHfBWdcWS86cizCSdDAOqIsbQcWJMDVlSyaYXhF kbvPuf06apTeuaa+MjXK9b38/ITAug5QSoqcKEbHW29++5GNGE8jayFFh90iUFGv a41T/Tl+EcKy3D2eWKCYOzVtd7GvxubdMddztZZitEO3rJD1exXSeORkFh1ezMI6 aVxzrt/wxWbNkTEetUAqWukmocAWyvCU9LkkHr3w+fFTl9mCI4F3xUwglWoP010g SEdxdahBf5QuJcbj1vFWkNg+9/Yq2ZoBgiuJPevPe1adOh/dySso3xepGmCmEHgI FurFtUVO94i46Zzw5zT371eB347ICplRFLC9YdIrbYrgiQIzBBABCgAdFiEEsCfa SQV5gVpBDUL9pIWg7VG4t8QFAlsFbwoACgkQpIWg7VG4t8QMew//R7/9Whv7E2ya i7wp34pYE9Hi4hCH/q+5ShqO5dAL7iLrFbnPCaFl//fgJB5z61Ku+QP/xrxCQocy akGZyxv5nJzktOn2xs68rK6l3VqUB8j3bUxIJC+Ftq1W7gV3klzqFDovDwqGVCbO 0KFQRrQbu/X3z6XYoftRH11aaqcRR8Nl69pZBWYXQSlGP7r4Yw8eJC1f0TX2SgDs P3XKrm5xbzlNCW2vAhjPpnI8OGlvzuZ4i0OVElrEDci6mq0aBYAoBOesxtoEJF+r bQORIVadO5fCiTnen9GNT8UIz5jDay+eYtR+q6kyIP75pXWurOzD8gkvKU3rQlM3 aZJsCH5HZ4bojPIyKebAlu7iHZRIFuwDJPf0TCRGHTWzX+y1kCm5NiJ2+PFggD4k qLTOGVy8b99O9eLEtwfmF9MZ2zIroQh248PdEVCn7SxTyhVeYGtjQ3yqGkqi8xTb v9hTvU/mLR72pB5LtAMn07gKGpPLC4Mjiex9HrXJArfIWnjD8tQDUbL736csWnDP nISrVNn7eOf7WUUUTOUZPrX4fBnSZ1TQ3bTa6zDWu/KetBPrZU9sdZduqOQqahKt BaLNh0jzornidTsVDUiDYTDB/ITDOsW1MkpVgG8+S9lhFkVWYdLIGHabxAH7KGZ/ 6D4WNsXvdV7AXT+1PLho/o3jYdW1ZYK0L0hlcm5hbmkgTWFycXVlcyAocEVwKSA8 aGVybmFuaUBwZXAtcHJvamVjdC5vcmc+iEYEExECAAYFAlXv90AACgkQe4NuQfer nOXY6ACfXZdspV/S6yD97EO/y07E7M9Ovx4An1vhAUJL8FrLDnMTcXLrnSjCSd8k iQIcBBABAgAGBQJV8JbTAAoJED2DTY0Y+Ak0aj4P/R7DmS63uEPDx0AMg+kdppId 8K77tOyR1DFSxuuD/jC+aJDmVm8UEO1uq+0EddVDU6PbG09FF2UvnC6IGp/qGmdH x1ByWCCcAtqRWLwP5zfwApAUUGkA9OtprpsJFrBJLvj6c7KtKlH+FSxheYPI69AI HEqnBLtCL85v8ml9VmkvAP7b3tn4gs0WLFtiVi4DtXzP4StB2SFKmSC0Gh4HbSBv D8WarJAq+0zS6XjeYg0mk3Ng/jK9ThiwMI0KUY5hYss8Utye9WjCaFGYw7uszR4X oV+Es4aFtvfUfxqSXY6nYLsSIy/YPwMaJm1XlC1W32v88J2X0ssSfDWSNQsDnTII PQXh5cUs8tTVLoA+ooW1K/16xIg0uOjSrVvhLl6SZQSqEExEe9EQ/AaaxaOh2nul 7VA80+pvums0A7AHHIq95dYhsvRNphs+EFDhrPtxSxaaVb0GCfTzO70mX231J2gS noFXyqTvLpWaKYwth7alJPl1mPB5vv67hJ+d+23GW3qTC76HLP9zVFf1V2+CTNon 7yL6la8fKKOaJK1BOIe0kRwpvOGAdwQN86S8UwaY2keVW4HyyRSdv0d4aF5vpBna ZGYLBmUpBAgwNgcTrE4jDxEkEeIiG9c6vveZdw5ECwG8QCQYpBGV2O25ClvZ1YRo vyjPenhMDq8j/zLiqPuZiQIcBBABCAAGBQJV7/dOAAoJEEtKJCPQQcY9yZAP/2eD Br1HyewzQJMIyKgkRtYngg2doM0Py6+c/NFP6/JSRMnMz5EK9U6gaCuYIV6o54JC F1/bQTGwA2yq2/1dATIMMjs++cCemsktJijN+lixw97s3YxLBMGI/PvS3TcvmPph 8mGigKiT3bVTT7EI1SXctfN8iRdPEwLTPvtXFKoSIeI+BAfijCqcO4SFE+179m3O 8yAJEiTwvz71RlrOXyEXiv1c8/6HwQVUlbQwHYA0gK+YdyymJV3pAl09NgdkjBnY sytvkO3VDDI2RMMq+giaBHqqJpHToYPIyGKzqXyx67oa4C05kaHZEawYY8M+jNxO LWR3K0WYYLRbYn5syhh4QyIAfginijgq8vC8QiFTVFMxaDdCjXvbDVjYUtBJAtqv mRW+Md8B2mAB5kyWI+Xv7J3OIMX4Rg/anh3qTDpo9k2gHu4PWaF2DG2zSUG5TeJF DCE5BNyusmP/YO1Q92gUahHk5NUOuZvWWh3DlZbMjwW1NnsLpnIY+OP5XsI5NIcY /hHtgtcqs8Ur7kCPHOjMr5wiC9hJmiXxl8C6zHPPmYdd5NmqkeRA118IIdYInuiD ZbltqmtSCRCfY70CoQxItBb2GkwZvMohWHpkWXqfaKz91m5tLloIf35s0moSLxV3 +kyxb0wwR614YpzVaga0MUUMzRihyC8XUKxJ8Z8wiQI5BBMBCAAjBQJVqM5RAhsj BwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQy1c4ZSdo9+nDaw//dgR+2wW/ zew8sFyWwDkcU1GvgWxfNtG/0XuCsOyqe95yAPwi3BQnQb9n/S6pcI8p5yerqY2F FmJf4C02QaIyV7rFxYjaRpwCL8vrUY/JdaiGzLt3jZ6P4Urb+XIpJxOD3v1cEBcY kIJ/IahpVTRG33OUfI44HfT3VgLiBJiQwnaLuOx2nuWqq9PAzqg+cRCRLvleWJMM p6y9h2srzsxNwXm2UE1WrTJwaakYM5jn53ke+RonKF9R4lySe8w8hw5uwfrvi/KF N6NdptCDa5SGJbI4UTPhPZfDvZd2+1eEHx4gY0k6sY/weobR+F6OjJdXubafRf21 pgH5WoWtGdP1Z6hK1owfMuEQC86AshcZ7lsM9WQTR9XpIBK8KUABO2Cyu6exgi6F DmoeZwDGh8KvQPgIDhgOGdFBt1tFoQqsc8UqR23D1bwPYc7xfTGroWbKRg24oj2T vDmg+DO4ad+0Ff/xWkoRpIA5ohfirgyt6WxvJonxSPHh9QVoYdBbazWuaYl/wGcQ Se3INKLdOrskAFJ4DQ7n8lQlL1ritIy++yx21hJIC0EPQ3zJlO12N2FoV989um/Q 8qa41uNfUWzQ04kM9YrCtKiFcNaqvfqi23lqnf/fB//m6mAo1HwAqiqMIXSGY9LY vdL4s2eqVljx6iaF/1gDWBI3j3JH7aECN7uJAjwEEwEIACYCGyMHCwkIBwMCAQYV CAIJCgsEFgIDAQIeAQIXgAUCVl+KiQIZAQAKCRDLVzhlJ2j36WtOD/0U7IpbNx5e 22TRrdydSminsBCRAL0V8T1BDMU5bhUeTVkpOUftXVCs6vNTl9p13wLvWgdt/vl9 VOWY21yX04TR+fHRPob4Uq9PIlX5b0shFuw17z6rt5FG1/8eyNB1uUQiqR1SUCFV GAKMEjor+t4xhWjPkXFIaggyN/F2zUreRAgLFL6677NGbp9/xW5YcxIRILfgjGUi 98F/e9s9idQ+G7gKfRRPEfemYeaT614nW4VaJf3wcDEOm/Rmhso1r2KZxIIqFhOp 2bz1cFc0PTVtR3jjDdEKZKqDMRChGLQmP6J6DhdKf3yU4i0gE8TamL3Y2yR1Imvs Ln77R873GvNRFmOoaIQ+aJ6Bb44y+cjpf07ZIHNdhTsYGKqmmtaxr/LRYpEnw76Q RXMZQjUGeB6q9nnZAcY32/laeGjSC8BaCICYNWfqffJ9ycj5IEkea/L4ibpMjxo1 Jfgb3FCNW6Qz+JbKOw3MDLGO12Ru44GIoA4AMOpMLf0fCwagde4ojMRkwZMXHu8D XK62iC2Dwx9SypfXwiW3ynq/520kljXgzMX1/JUh9WvzcVzQg+6/d/n37tVA9jgA 72tQ35tyOCB0pj2l4saLNxPWaxZ7DhvIgiNTf0R8LHWiN9iQMWZXp9A4w4tZPrZG AiLI5FEojQxrYuesdSo8NTqRYzvyyRUf54kCHAQSAQgABgUCV3vnLwAKCRB/s8US Y8PdrySjEACOgZ2cM2KkHLA2/2XlBbSl0p6xTBIo0DiXF8i5LAMvDtlNpuYwcfpY FmM2ZxvDuuiS+5JXn6eOuQUbWpO6bL4le2eJPt1ugSv+VeSJu7YQQHzPRA1KEzGb cJ/rwdGwZBGUDCCWeoOdkQ6S/kAZZiPGo59FEIoIgYIYdmQphUrcrwNT7T2J9oDG 5HYosm48zNjAPyahmQGXITNPkWE5vqFUIb24cF4JlxrKsyxMWE4pThjkYpM2CwTj HoVtmgYIWFPDHUwaSgK/NJw+HGZ6zmSmv8BRmDBqx4dZ+xoLleAOqOLceG7bV7oT Pg2QfdnUJQcsQfMah3GkonYSRZWLmh9LMP7X0wjcDSrBSAN0ZU0wM/ST1K/Aw+eA DmzqGG3uwP7qa1Ke4fCI0s1mTf1C3uwdRiDgBBEIjDNStC4nQ9S0UjOjH6kxBxUi BUzmvDGc1upT6JaBIF5p1zc98CvrIXeAnLxTuk3slKOIS6E1a7zdw+bfO4ghWEPC MkpDOz6s26czg+2K2FiWgSCmgbm0y1srmogYhCLF12WpdxRC2iIDeAVc7rFCN6op YkyfGn2r5wH4uEquiZkQ2WOPwzRQK3MHhQa7hQh4MYoA+xlQIePAvctOHIr70S0s f3ujP9D0iBcf1wRbgqyKxy3cwCxytrb0w8AK3bFNEpSJfM1UGWFwBokBMwQQAQoA HRYhBOu7iSEOdoiC5s6fEs394wkPEahQBQJaEXLNAAoJEM394wkPEahQ6mAH/AmU HATY4PTdnb0u7570HgcXmbnWqdKNBDkwrabsZkY+MhZ7EKoUmPMrvfib9laK8ZoQ Hgdh1tJYx9ftEu8eEpg9mUB9lcAx9Z1OK7az13MkwTfo6dztrY9eIHcHHCzb4Hc5 sulJylSAQXgS0eRIqF0kuNgWtjC113PPN9B6OzJXR63MEuMnQJXvkjodh0L5p28u 1v/2aAIFOvxceuCf07s6AxJgo0gC0H5/8BK6enAH5/DWkuEi03NfrJcENJBPyJH5 PnXUZSqz+QXv97QK03M8YZwJigYKPTl/3146PFhw/3MiUXb9Zm4DKWwyiGSFPPAs sA11Q8dEcvvX3Wdl88aJAjMEEAEIAB0WIQTkptZHPp2pYVuYbBtd+/3V8CMhEAUC WysnjAAKCRBd+/3V8CMhEOXkD/9H/AyPwJgKkUA1WwutV3v6j6Urg0f61atDxcWt 5D6+si4eLZUYfmRKWmxDCUaaxnLB2VPcRU04krj4rjxCtEmLQuDZwYagh0U7CPEZ ruf91KOSZGKQbSqkjxvxim7ok59TAuXn86i+5CBGHEf+4m2YpPIn8Y04O5arbwAg +4qBHGhUygV7Yoi8rdM+6R1olHESEGbb4fjhHZo9241qFhBNGgXtSNy7vqpL4Jt/ /bjW92liPH0TSrhFmlob6O8Y7QCQzd0YD7dYXxFQB0Nmvh6fruoUrCkbqG+SuduG NGGleRFl8LtiauV7jFwHwYxWC37kXWaGahqlcxGuA4LsbWxTQK788KDJNdBq/zHn hr+1g5Gu6d0ei/oXlTDuEG1FVc2LB17/UVhq1JWlcGB8OGFM/Amn81wAqEhFHoCs rrjzqhnwSA0TFGpZH6sMRw7VHxns8tib+4O/0MMxq0dYgngrAKGwPMU2TsiDeZr9 ttqvEtirNOH5O0Pkbs0DwBG80sPOxWvdsToZPt2dSgMSAQNDK0wrJtJT3S4m7mOn 1XAlYoMxjRBgx7TLz6rP366DpKNc0widcWfEex9C0FNVT3T/ZogtQ4IvtJob2Vj/ T//Od6jv8L0QsUz9kBp690oPCg9tuMboQchcKok2m7LZersEa0DL5wRKM/grLELL dbfcUokCMwQQAQoAHRYhBLAn2kkFeYFaQQ1C/aSFoO1RuLfEBQJbBW8KAAoJEKSF oO1RuLfEAOUP/0w5FN5SUWWqTxrQD6UcY6POmbji7u1My34eeApx3u6y/Nmyqjq2 SVnNbi9SQ5/rRHIh/Sd+v4a/MAYYiS/r90NBnTcx+9i6XK1UmFVOX+k/UEYcC1db LIm8TE402Ah/NlU0D6bfFTjgLLOFposNZUlutPWZaIeI23QbQC2bG9EzLRn2oDam +A1axTeWbmhYaCsdkTxwVOR2DGmd2H+6lbP1cVZZlOM7+hr3+CRuU1j96GFBViJd kyZiXpdthLDJNpCKHJ5FsQDjzAHsaPsikipZ+LGXE3PFJd/9nfNJZRbhnZBHYhho He6p/27S6YIC2F7GqKo4O32oXD/45B4phxvWknlauSm2n7Gpikde/4ek3Iiiu8tc gd0jmv6KlguNs/EXQUwFOptLvjGUOAbDcRRh+tMGVu0MR74UbIAsJYUm8Kh2lvZv mmP7uZ2qFS3vG1cEX7DpMzR0F4LlkXqWaniLmkl1gdzX3moK3gHL75Bd5B3ql7O9 Bxctbz0qH30FVaTjN2LiaESTV18dUmWmmxzoAxeHBQCr1aDr5BmU3lqeF0/pVRb0 yestKQ9lFH/uanGdZl7Axq9BltZn5iwsfodGWDZwv7Bqi73+6P+wjmYLjx6SBHgy hEvMjwdXNC/PSUHrRJ9OlCO4/j8OW/8bRTQQRE0m3NpoZlskmES28owYtD5IZXJu YW5pIE1hcnF1ZXMgKHBFcCBDb3VuY2lsKSA8aGVybmFuaS5tYXJxdWVzQHBlcC5m b3VuZGF0aW9uPokCOQQTAQgAIwUCVl+KfgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMB Ah4BAheAAAoJEMtXOGUnaPfpbHcP/RGtMtp9CJ3cocPEWgu7vy7vjleWtNwE4lrl der8mBV4iWlUwopXbHFwkaUkR60/OM5OHmH+srEbs5V2VHINNPZxepWo7sw5uhOu mSV5KCJxqcBHBjMeaHVHkisXGmeSEL3hFsiWoS2x3+BYELbNq/AbAoZKEhL4caIw YR0E+RWMXWDXCp6zY+t1GcPscE24P+/T1jowdeNThMDTk+K4IF0meu8PDtSbTLTB mAICNiohyMVD67hLnYiSPA711GpF/SyUU6SZ6kmnIJAv2oS/Juf/+3j64lDthUem Xg5Bqec+oOffpYq7iYTnJm46a+8AKOoVc3ZKS0/KruLrqGljP5EWshCn4ZVI9Egn Bu+dbnExPsh/RzEQQ1Ff/H4VbqC7BB56uPfyf3Fce6q9cuBHww2jfM1vCC3uL3Gc BoGw9JSOa+rXstmMr8FRCgxHtbyImq20bB2vuoWl/POUgMqKCH3aig3J+jRjNdgF QDziHtvtkOxmVegAAg/o+xll/44jWleB8Cdv0rDQRT8Nv5Q6MLB54RXb8BETsp0Z RhtxWxzBieR6zYUCVlmQzxeNIQ6biaUEVLnObszs0FKbWoPZuYH8QkDUFwrZSKSC dwnZSSYz853SB5LVev3qNsYgJ9uG9sgXogZyoxE+jhOYrMAHeAztwYwCkwWGJqg9 jjAvkAs0iQIcBBIBCAAGBQJXe+cvAAoJEH+zxRJjw92vcP4QAJzEiKzKCFYJP6O1 5cof/U0d1k0bJnMTN1Zs/iiOIcwl3XvSSvGvr62TIUh/2QQWpxT0KJbu80W4+/jH mP4OHCWQ7LhwTNfr4cI8cBT1l0QVnTWRSSM89eDxdU1Rm7GkMNq/aunIOruuKWWA Nxv7HH3EcTzLG0J1Qc9C4O39ia2r905LsL45yqZ2XNImekLiMgMFHbYfE2O8t4V2 OelcE9a67Th11xNESmg3wqMnqfK0Rv/qoYmU9Vhs6uywwCHgkeQ3ZXgmk/m1zLCt Tel5Noper143nbxjrZddiPSIKgt9LaqiTKVq0W9ShV+tJeqAjmKqwKsrGo39QRSX g5omYKcS3Hjyw/V68zR6iqyu2UVRpnO2ikr8SMlka6K2A4eNjBLcPG/5OmZF3R9s pPj2VDwzDVxlZOqOJDYVdINMS/JSKgpPjqPNtxdI02HGrH970XtTsbCjybh/iDTi TAJJmFL4v0Dis/6cnCSz2nTfz1biw/8k5HX5zz/a3I+97kKY4ME3xvDe11YJmK22 Jk9tT1lOHB6a1AFXsRATGkLWs+5N+64H6o2ciHxhc6wQFQUZpw5v/imYneEpx7yD EKguVGmRSJsX2GXIEmObKi4zSZomkyqSgXBP77LO4cmb7JsL5cU+udgjb3bWEnoQ zvxfS2QZSGaI7+UTu02pSEaUwhEUiQEzBBABCgAdFiEE67uJIQ52iILmzp8Szf3j CQ8RqFAFAloRcs0ACgkQzf3jCQ8RqFCwOAf9H/HkupX0eDhrABex2x8krTUf5KQk IwiBxiQ5xpFM09rXhNmy3U/qSYCC9IW3veWBFdH18lXrS5nwUkOqsGGWQ7uPLggS Q1NJRjjjmCa6V64SDS2qu85N3c/hu+aAzJaoD9v8ku2fV3GPD3vcmzoo4vCKtIhH OWj5ZezothKVakAYLi40F26J9NNBlX+a0pkBFlxRt1TUurxHMUd3NX56E5I08b3s m0XGIl51RFDU6a6QFSa1XvTCl3pYb7HCLF7O0v2qefQ/oFx/x7Tul1J6ysor+1FO viAMVDyzcmDrZSN4nGBqLuiF+zvKdcOgth2/3MxKFJnhNz8WYisueIjL5IkCMwQQ AQgAHRYhBOSm1kc+nalhW5hsG137/dXwIyEQBQJbKyeMAAoJEF37/dXwIyEQAmUP /1Z2EnfcGbi+bGeTsEgWj4X8FA+2ji3T3cvgZIJQCE7Sjbr1nqw3p2SvcH/8rGbI OrQ4wI9FWPZ3pJmzSRDEkqac3Le34yoOVttmiE3RzGsodskgwtAu6NKDAtA9qMUv PyQ/Q/QU4ecshuAc4Lg9l4+x0DUOnNeymIgHfJPT+lFnuUz7tLCPhznY6utGHT9A SA6rr23CR8H+pM1xtSh6tAID/lBzkmGG5Qk0nKfJYOUP2Juy8aO0gcRmUMpJgruk Z42zPKXqO7Ks7JCSGJZR01ApTxhwn1nUfr4fKpWiQ1GnQJnJuH6XEqN4r6Tdiikf bCq6efCQfw/SnYT3X8TSUy0eleLaiHy/ZIhO/eYwXC+B3D0sNYhMV9Iki415Oez4 o3hbTzeLGlqhdWe8PO9yvDD4OtBo7g0N8obFxYFsvQ0hMB/bRpUzRYQoZ1JQoH3H xcb1aqQnH5/uQQh6JAzEi0LwIS7hhcxesrW5s0C3LO79Ea9yXEPqhzZYnlBPXCWr VVNm3porafNh7XqqKiqFEWH/cl6g9rLngN8Uw3atqWWgs4rvHaHjP65z8mgDzMCv DHpjy4U/veuC2wL11ksurc8Ca5PSzyZHQGUEnx3yTF5cstcHROg+XgrQjSuZQSMB upn3OlNPM1w2htnpQxXdk6vx0iqPGoat94p0RwVLTPCHiQIzBBABCgAdFiEEsCfa SQV5gVpBDUL9pIWg7VG4t8QFAlsFbwoACgkQpIWg7VG4t8SI+A//eIFjXiwDakkc 037aq16N0gtmcKyN4RRYQh7eeM+Mph7Bx/TRbXi3GfK5GXuUDVyLJOVhN+CcBbN6 bro6UKh5RaZECGJSfuOIh3yHESvhinKGo4Xr1exwZujxlfR6guiLqhKByZ/MKAvt T5x3Luhw2+xWMZ8uJur8rrcDUVmbc0iBKpIPRNdt8ioDdvlmQv5awXoA4qAvq6i8 /NNVgg7eJRXLLvXFrB6LYYp1WaH518sLGFcfkjODetfhef6JPctMibppKON/JtjJ TYtM+Yj47DtpNUCTYQqGKUiYz4uus1aH2vRa9mKQlnvByO3jUl7Ly1cAuEUD2/hT woSQmlB/LWRjxocVYYIF9RmL8axr2OduhpMte5i9PhRgU0NAo/G6RYbLPihgRscs SURfShzq2l4zaxv5KTJAdYwlMYMMLwIrlHxIN+7BbMwGpmgH7EF7+/6nbRkTK0e/ Z55LIxmqMLgalW0NBwR3xn1oKXaijPf9lh3Cujqu2Yh9lKr15fJt7YYVpFRUUST3 Hjkw17JhLt/0f9QXVpP/pPeh/RRjFHF5Aph8TMBcZbywCT5++HRwPRERriG6+MyE KvQR0SnmTwuxWzRlzVvhZFBb3II5qehhrauSX98UJOuWHXrhQk3wW2So2n0FmE8h KmeYTHKrKLEAHtUXf4svBJGzaWZ/f2O5Ag0EVajOUQEQALy+1UBEbXWX5iE1YezJ 1qHy2DtT+0JUHiEMbY2iGO/cV4qXOwC5+w6ASp2Udoy52iHznW6AcktoQF/bf8JC xXGGISJMI0tS+1b61NuKW+vkXDiSgYn5X5V+mjqS4fFmTMoqo5ig4jqIunmEuwLl JxkP30s8tUeGMRzcWSF5MvSKqQu0yXqg7N4MhEzMt4M4dV+I59HyoORJ805VBOFh r8jCtlg4ug0HrySlLqRp20hhKL8lBUA5opyQkMNSbA+I0S5gFq9sZz31lLVC7sYm 6ckap6FBziAwcfnTfnFL4YFfTH4CIdkDFElCZ9318/cSnqbbhilRzvXh8aZfZl5w GntS6cIMJYbbKKGwdsPTkA5IR5yEVH1RbvD/m1d4cu5jqGfTeeRNMIngVirIa7W1 Z49x/tTKykUM6/mheqnzEqbbJsXLrnKN6Y+eu6mJLQgQhj/HNfk09j/wtgo1aRQg L/UVZDVTcuP0MuG9tTeZ39nt6dFaI3+IsTa4QhnDcO1dJ+eYsuCJmVY3CtuZ5Sh3 GcNGk6sX+eeEMkfZ0jN9uwIWqhva5dqvetoO0VMfQyZiAauNxB0cjo2Cpl+xv+vQ HEqPfFcYdY3QCay5Alsn3ttd6Ht+S2IB/BukcO9N+EmYT1HgJkS1c4UR6x512b0N TGRC6yMFAGSshsx3z9DInGvRABEBAAGJAh8EGAEIAAkFAlWozlECGwwACgkQy1c4 ZSdo9+kphw//Sw7Ji9eTyfJHdzRXNa1cA335dY1QYKq9/6eGhSjcyRGz4bHyHUDt 5G5dmKwmaYrPGS3Hr2H1+Z3w9BD5X/V1ZVgsKYYVM18N0CsnarJdcugdwC1difyM zo2NJGz6btuFey6ZiMZo6EQKgsH/0sLChHSLM5sjBgdmWswkWh7L8oNrFv/p091F Vj6rFeda/e7g3xK2NjPSk3+oX5aLgcCrUSeWJCZflyEL6NEf3EOAahzzoqUfN9D6 aTjZWPSmTVTO21t8s86XeSPuYBVGGODyIkCXWJxkm2WXY5AoPLYJWmmm9TwOJE0F gM/nTj04cBNW91q8tCCaCx//2dGfW+EdAMew/G8aa2cJgbF7iJs5IWpMRUxujMM7 rWJdxXjAh6Y3FiVc5UtYO87HmthC953QiJntDTa/72Oi7HrGw/wUtSRm2S9G/jdp XZ7WBaPD0R4/QcXS9590nMfFahWfQs6cdAOtLBJzCL6JMX4sHqaycwxErzd0jvto hCGJW0Ksc8GjTxWtmgBpCVzkTidkWgXICzd7EKE36z5Ir6jvN7NLe4qbPQF+uDWm xQqAK92/Iwt/NBALQ2oWAiHN5j8v2/ObJDuZH5Q4DGzzVmXYAeKjVMyH9Upsutnu 8iYrvghKyC1RKKPPjqzJvcZkDO24NIw8RM1VxPH/3UxXFg+hWD+7KMw=3D =3DbPR0 -----END PGP PUBLIC KEY BLOCK----- --------------74798393C8E8FE60D79F5EA9-- --pmX4E3FkEGu2zJwGabefOlkLaU9LMXFKF-- --0A8gzuggOSJepxx2VspAEwV7VcPuHtZpx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEMXM+DFmNOhz3CVXWy1c4ZSdo9+kFAlw3vxUACgkQy1c4ZSdo 9+mZuBAAnYtqoH6mpUqbR9d3rjsbaWAgLPyPHT53DouaZkQQCdapXe33OZjYsn2h oiXFdXq7a46NQJLydh7aofzsY0tKCMbFqQrPAwsMAT/WJIn1IRy/njUZfQo5+orE 5TMvBChWk1Lqu2aEd87sNRRBKwmcBNXIhK/pfZEu9+i7HKC/4sGQNzhiejMigIr2 aWnLHH8YM7RsL+4vPV48q8MJrIINdc3/h47oc0UW/0eoT6Lwwz8cr2PpVrz+tibO S0KyhsAVRA0gYBBqnr2TJWr3sBAoe0i+SSCljF3MzffKNCm6nsf7bVMBhFagFcxO vcurVYuE+/P2+HwjEgkjYZk2ndE1UnaQd5ygnGXoOUV2gIlt9xNb3pRfj7v6iede 3FY8Ccs3ULDHvQF8osOgf/UBRQl2TW5R1v6rA0YsPWD1QinWpV6aSscu8z2aShj9 s+lbtkEMq5dD0voHUKyVvxrIdQ9yOX2XrK4CJQ4WZhMVNNQJHJWVpkWMucOyT1II ZdsIKeRtPBO0ctWw0v5dSOGqtWVG8z3PS1uBCUbBvEDKQtmVh6PWDfS+Fa1wzO8n bL+9IjoSOYFkDQu+I37AdKtZlqcgqqI+VJ07VoNNnZ6NBbWK0ILvtl2EpqY+V2eY 5wSb09V9cQBc2ozh9486mlll8Sgz3UrmtTg5PJEpsu3zXRTNxxo= =ZF2H -----END PGP SIGNATURE----- --0A8gzuggOSJepxx2VspAEwV7VcPuHtZpx-- From nobody Thu Jan 10 15:01:16 2019 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 C5920131058 for ; Thu, 10 Jan 2019 15:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.554 X-Spam-Level: X-Spam-Status: No, score=-11.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnVoA7tBYPop for ; Thu, 10 Jan 2019 15:01:11 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2E0130EFC for ; Thu, 10 Jan 2019 15:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=H6IHAdgjqhXNQ1hLGcovdjgzaGjLLdsvgKe28StQruU=; b=0WGSUMCYlZ77Fe8MUWQDjt9mYf HelRGh2SgowuJbKFPPGnYY8ht2BwGpgGAjk047CV1VLD+lw4axDqX6ZDWSdiL+5z6YfGlzz/S9Xnm mBikeJJ7rbtWCg0LcYShupFF2LYNd1qXkcQlySkcqbsa1GFvhOpEdfn9iNOfI+gZop7A=; Received: ; Thu, 10 Jan 2019 15:01:11 -0800 To: spasm@ietf.org References: From: Jacob Hoffman-Andrews Message-ID: <0a03eb13-dd58-7635-870f-10daf5937005@eff.org> Date: Thu, 10 Jan 2019 15:01:09 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lamps] AD Review: draft-ietf-lamps-rfc6844bis-04 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, 10 Jan 2019 23:01:14 -0000 I've pushed changes to my working copy in git at https://github.com/jsha/caa-simplification/compare/draft-04...master. I'll publish a new draft once we've resolved the remaining questions. On 12/24/18 1:32 PM, Eric Rescorla wrote: > >      iodef : Specifies a URL to which an issuer MAY report > > I know that this seems nitpicky, but the rules here seem > underspecified. Specifically,  you don't say that you can't issue of > neither "issue" nor "issuewild" is present. Also, see below. Actually, if neither "issue" nor "issuewild" is present you *can* issue. I've moved the clarification of that fact from the individual tag definitions to Section 4: "If the relevant resource record set for a domain name or wildcard domain name contains no property tags that restrict issuance (for instance, if it contains only iodef property tags, or only property tags unrecognized by the CA), CAA does not restrict issuance." > S 4.1. > >   4.1.  Use of DNS Security > > > >      Use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED > but not > >      required.  An issuer MUST NOT issue certificates if doing so would > >      conflict with the relevant CAA Resource Record set, irrespective of > >      whether the corresponding DNS records are signed. > > what if I get a bogus record set which would preclude signing? A bogus resource record set would return SERVFAIL from the authoritative resolver, which the CA should treat as an error. > say we have "issuewild" for "example.com ", I know I > can issue for > "*.example.com ", but how about "*.a.example.com > " I've added a definition for "wildcard domain name" and rephrased to make this clearer: Wildcard Domain Name: A Domain Name consisting of a single asterisk character followed by a single full stop character (“*.â€) followed by a Fully-Qualified Domain Name. issuewild \[; <name>=<value> ]* : The issuewild property entry authorizes the holder of the domain name <Issuer Domain Name> or a party acting under the explicit authority of the holder of that domain name to issue certificates for wildcard domain names **where this property tag is in the wildcard domain name's relevant resource record set.** This combines with the processing rules: Given a request for a specific domain name X, or a request for a wildcard domain name *.X, the relevant resource record set RelevantCAASet(X) is determined as follows: [...] > Wait, are you saying that "issue" allows wildcard issuance? Yes, if there is just an "issue" property tag but no "issuewild" property tag, and the "issue" property tag matches a CA, that CA is allowed to issue wildcard certificates. > >      issuewild properties MUST be ignored when processing a request for a > >      domain that is not a wildcard domain. > > What's the reasoning for this? In general, it seems like a wildcard > domain is more powerful than a non-wildcard. I'm not sure; this is carried over directly from RFC6844. My guess is that it's to ensure it's possible to specify a disjoint set of issuers for wildcard vs non-wildcard domain names. > COMMENTS > S 1. > >      sufficient condition for issuance of a certificate.  Before > issuing a > >      certificate, a PKIX CA is required to validate the request according > >      to the policies set out in its Certificate Policy.  In the case of a > >      public CA that validates certificate requests as a third party, the > >      certificate will typically be issued under a public trust anchor > >      certificate embedded in one or more relevant Relying Applications. > > These two sentences don't really connect, as the Policy may just say > nothing about CAA. Deleted. > This needs to be updated to RFC 8174. Done. > >      Domain: A DNS Domain Name. > > This probably needs a cite. I replaced all instances of "domain" with "domain name" and deleted this definition. The definition of "domain name" has a cite already. > S 3. > > > >      issue [; = ]* : The issue property > >      entry authorizes the holder of the domain name > >      or a party acting under the explicit authority of the holder of that > >      domain name to issue certificates for the domain in which the > >      property is published. > > How about for subdomains? Clarified by rewriting to refer to the "relevant resource record set" for a domain, which defines the relationship with subdomains. > >      issuewild [; = ]* : The issuewild > >      property entry authorizes the holder of the domain name >      Domain Name> or a party acting under the explicit authority of the > >      holder of that domain name to issue wildcard certificates for the > >      domain in which the property is published. > > This is not entirely clear. Say the CAA is at a.example.com > , I assume > that this means I can issue wildcards for "*.x.example.com > " not > "*example.com " This comment made me realize that Section 3 and Section 5 are essentially duplicates of each other. I'll add another commit deleting Section 3 and making Section 5 canonical. > S 7.1. > >      This generally manifests as a timed-out DNS query, or a SERVFAIL > at a > >      local recursive resolver. > > > >      For deployability of CAA and future DNS record types, middleboxes > >      SHOULD block DNS packets by volume and size rather than by query > >      type. > > This sentence doesn't seem appropriate for a doc in a SEC WG. Deleted. > What is the reader supposed to do with this sxn? > I'm not sure what I'm supposed to do with this section either.. What's > the take-home? I've added a sentence to the top of "Deployment Considerations:" > A CA implementing CAA may find that they receive errors looking up CAA > records. The following are some common causes of such errors, so that > CAs may provide guidance to their subscribers on fixing the underlying > problems. > Acknowledgements >... > Is this by any chance "James Manger" Fixed. From nobody Thu Jan 10 18:26:11 2019 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 665B512D4ED; Thu, 10 Jan 2019 18:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXqbjqJcAfh5; Thu, 10 Jan 2019 18:26:07 -0800 (PST) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-dm3nam05on071c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe51::71c]) (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 E6E5112950A; Thu, 10 Jan 2019 18:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=j3SDmy7yVT2kEV9QuZvVNqcHWO43LtyogJra9kXjFuQ=; b=TRmU3YI7Rbvf0/WqeY/gPPfiBbJFiO7PffejfEx/VMhAMaQBl87cYTApLAe/JvEeh383RWY7ILqNBFqnqnyDmQfrsycQswP1KTFgiGxzYmI8FTc7kWH8g7Uaht4kFjs2dsl3corn643TRcI+10o0UvIbxYBFp00tcNsOlm7lvjE= Received: from BL0PR0102CA0056.prod.exchangelabs.com (2603:10b6:208:25::33) by DM6PR01MB5530.prod.exchangelabs.com (2603:10b6:5:153::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.14; Fri, 11 Jan 2019 02:26:05 +0000 Received: from CO1NAM03FT022.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::200) by BL0PR0102CA0056.outlook.office365.com (2603:10b6:208:25::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1516.15 via Frontend Transport; Fri, 11 Jan 2019 02:26:05 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT022.mail.protection.outlook.com (10.152.80.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Fri, 11 Jan 2019 02:26:04 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0B2Q0bP013350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Jan 2019 21:26:03 -0500 Date: Thu, 10 Jan 2019 20:26:00 -0600 From: Benjamin Kaduk To: Daniel Kahn Gillmor CC: Russ Housley , LAMPS WG , "draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org" , IETF Message-ID: <20190111022600.GF28515@kduck.mit.edu> References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <87va35o7pe.fsf@fifthhorseman.net> <38891959-38F6-4FA5-B7B1-ACB50921E300@vigilsec.com> <87k1jlnxnu.fsf@fifthhorseman.net> <2AB77CF4-ADD6-4EE6-ABB2-BCDAC4BF6631@vigilsec.com> <87imyxh8fy.fsf@fifthhorseman.net> <175B8CA7-17E8-48EC-BEFA-9E5D4B685B48@akamai.com> <87y37tf71a.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87y37tf71a.fsf@fifthhorseman.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(396003)(136003)(2980300002)(199004)(189003)(305945005)(8936002)(54906003)(33656002)(4326008)(246002)(7696005)(316002)(75432002)(53416004)(23676004)(4744005)(36906005)(106002)(8676002)(104016004)(106466001)(786003)(6246003)(476003)(2870700001)(956004)(88552002)(446003)(426003)(26005)(86362001)(229853002)(58126008)(2486003)(126002)(26826003)(76176011)(5660300001)(2906002)(336012)(186003)(478600001)(55016002)(93886005)(1076003)(486006)(6916009)(356004)(50466002)(47776003)(11346002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR01MB5530; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT022; 1:Wdc8D/L9MS5u6aGEETNxOM1AShfSHo80vcgrKa0ff4CllgbFh0kTblk4L0M1cTODiX25YOdyhJQwcIa/DbIR6l4Zr1Iq6YGHH0/Kb+OfWTVc8n4PEQLGoo4Q8osPk7F5 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6fef3b40-997f-4dfe-4d0d-08d6776c234d X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4608076)(4709027)(2017052603328)(7153060); SRVR:DM6PR01MB5530; X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB5530; 3:5JjPrkHXIsiQlg/GKQuX3A3Gih60hSnBRiy0jQ5hHBiLz8xjDCU0MGHDi3U72eLVmOUXzYS13gcE4SCPcpPwXCthG1gTlxhP2Cdk7h94zJCak1BlVBGjAziCnYGijaWVSyW9Bf2XFTwYhwX1n+nYKd72Xwk3WUEemAS9oCsIbMBPIb6hTABCXCOVsfIX0TJu8IlC4mIX6fxP5pZdzbxAiy8WDUPhsUVKwaOQ/aEw1dw447y9iL3LJ++wiIivZJlx3uLqLL72pJl5oifVkcYhHgF1o0OuZridzj19DKRanWZYQSCgfKc6cnFLfEGd2EZR0OoBXr25WeUq17RV6Pi7iWBddp7rQHvvo8s7+K1dKojI2rwMksHXt9eNJMiCLJYr; 25:DxYveEnb4gzKlFDLa7QxMlkfgx0+Vxi0Y+UHoa75vDK5R6Bst/XjmtLNDStqQiaSrdMdtDsxlLk3+FYn9ONYNLpQNdY89+wik6iTD7RLRlJ2vTRaedyAh1jMuvNdRsKt5VTWQXFneNN/irjacSppOX5+X8B2dSXIJwM2eATK3SaWwfT32loz8Fz43sV4JIVILxMq7SdF7RL9q14bG50puRjk825lj7ysfLm49z7IHK8mZwEARtSLwiw1JyXeyxAba1A0MvwLtbrcYBG+rGb/CGxeMieP8a1zNQRhNpUlVwnm579qNjwOHtocNiFDAA89AzgGL8gCjOHzdQvA96pmZA== X-MS-TrafficTypeDiagnostic: DM6PR01MB5530: X-LD-Processed: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB5530; 31:4zx2q65u0XHOJEb3KubjPzcc0ovFb7wae37X6DJXHLxapxfycpoS42BcKYI5wZJgKH47eMNqFJT4Dn0kH0y2PG1+wGxsFi0TjsUpSTRAEL+Ox01q/njuGb1E/8y2I71126/i9XNG6w+cICzTGBWlF4HAq3Zerok4oFHD8Pcc1xv6OJJvnUpSnmzr5b9yJ7QbLAMtIEaOsjLkFPlHrS3gef0wq3uwvn84BLmSyrQC4Os=; 20:vZ3Gc0ySkGknUbuNNZjkHPgaEnoVdnVPNcTIqrUcMB13NikGynJw+rUW/dIkDyFVjwJt6b0VNltAnDja5iGOWl8PiGLUjDh75309guW7QS6S68p9LmwSpa4QA1C1t8mP5IsrdWfw4EWOtO6ilOSGw44LquRntLOIkM2Q0QWQkBEWqgRbXATl20rAve3s3+8h12THo/3Fw6j/b/DUQ5sch2sjalhNqQIF19x0X5aELYy+FXak+/pqbW66+0CGEhiEUE76tNHPGcraSC0MKFMkopHtipDZ24HePsibcWsnNzgatareQyLWvtFFPVhH1mLKaOnaO/5mgQPK2icXFBHTQdqMKjbr1gss/gdGhPfEdHHpGgbm4pUvm81EmXNLIGKetk/Nma/p0W30Qw7pOvyu6K0282LdDMxksikh6XEq+u4SM5tqaVPqIZezBDUt/sPIEDAiri6xpKGnPI6EhvLffX6VVAEiUwTagkkNAhtbYz+xywFLQZCQ6CqehRoxd7nKYdBuclCKsYjbhIrE1WpikRuNkSyeV3Zj/ffcncthBfOkDxMnGA0zzbtcZqTlPNSqSw7yQELJPHF4Bye0A3VM57w0mWeFUMTPErtRRfKk//4= X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB5530; 4:tGOQPh0tChhyuTN5qepV/GAM5ke2FR7Qb4npBmTA43oGCdb3WG2sRVGXlUw6Meb9kmRsMzZj/UpMbXXsvK0pkhjm4D1zU6VAw50SIgg+w9zSFZqfdYaZhCLSSgnWN8Xn4+9MB1Gs7tN9tABME/7q1HPIi+XiT/EHkuwzzESxCUa4fgGFjUi9KB6JKk/X9tXess2hhAzZWwCfP4ahdUkv1fMQckfPB6vY3TVR69vs1tELvOyrha6NB+oPQgua7O2Kg3yESKhZiOarQ7JgzrHPmr9MfYYuHM9wxWsYRfmcw1s= X-Forefront-PRVS: 09144DB0F7 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTZQUjAxTUI1NTMwOzIzOlRCc1Y3d2hhVWZiZWVQeW9XNFFDU0pQdnJI?= =?utf-8?B?d3lrMnA5V1VFVllqV3dGMXJxWWtneWUvMktkVGd0RjEwRk1vWW5aamY5S1FN?= =?utf-8?B?Rnl6dDR3NnQ1aWRKMUE4S2JSVGVHRGlxVmt5MGFJR2FXS0swaTZpZk4zY3Ns?= =?utf-8?B?UG9Idkk0RFcraDJEempXSWU1d1g5M0l1emJudnlIQjJEK0owRWR4azZvUmFq?= =?utf-8?B?U3BqVHJlbndGWVc0bVBiQ2VMNEVBbDVQV3A0TW1nZGxpUWNBKzJYWlFpeEp4?= =?utf-8?B?NXF3SWQ5Sjh4SjFDZ1BRM0R5VFM2RHdkTWlFa2UwNXJUQVp3dkJoRnVSQUtn?= =?utf-8?B?S3lEVHN6TmNkMFBlT0dYOGZzblBaRXdhaG0yMWRZNWNKUmRscmdDelhUdCty?= =?utf-8?B?NHNMWE5WejI0aWlNd1Zwd0FMRFJIR0JIemswUTROQSs0TGE3S3J1aGFvRVgv?= =?utf-8?B?TDNDbkI2QmtsRHRWQ3prN1hqK09aK2RxWmdXS0tXeFhKL05DWVJTSHB1N3J6?= =?utf-8?B?VGRLRldLc3dnZnZhL24waGprSC8zQ2hsK1ZFbkF1bHB1L3dGRWNWVnR6Ym9C?= =?utf-8?B?dE9pYlhyb3l1MHJ1b2JPL2w1MXIwSmE1WFNybkZiYTZ4aG1kZlFTU3Z6OHRl?= =?utf-8?B?WXhNTm9KWHR0Rkpyd1J5VkdlSlVWa3VUTDFEZjc2U2ljRHFRSmR6K0k4S2R0?= =?utf-8?B?YlNNREx4QklreHVKdm5nbXNWNmk4N281dFBzejB4ckdwSmxXVStrSndObzRx?= =?utf-8?B?dUtGcmE4dDdqNTFtam5TZzJVRHlqNERHTkJtUDBTOXVCTlMxNlFmK0lNeTNl?= =?utf-8?B?Mkp5NGRJWGkxeDhrY21nWUZBdS9LYnlTWUI2NW9xOUVHN2dadVBwVkI5TjVz?= =?utf-8?B?aG56RUIwTjdJdWQ0QUZaMk9IZUdKMFkyOXFrY1o0QXZlSEI4ZmNEQ2V5bXdz?= =?utf-8?B?NWZ6dHFjTlZiZXZRdjFzTGxrZmxsYVVnS1VkNmtLVlZRZ0NxSnBZd3VuUit5?= =?utf-8?B?Ui9yb0k0UGFQQzhpME93WEcwbDlIKzhvcE5mUFJYM25uZnFNK1AwaFZzQ3BQ?= =?utf-8?B?T21ZLzNTdzltMzJ2aWh6Mno3RXBNM2JnUWM1UlkwQUJKc3BPdlRiM1Z4TlRH?= =?utf-8?B?MEpQaURVRUlVeHVNLytLV0RJaVNtVlhwbFAvUHY0MllKclpmRHJiVWlCdGN6?= =?utf-8?B?dDIrTnRubk5xbGFWQ3RjVHhPejdZNGlrMDJtNkhPdXZmYXRpYW5YWHFMZXVE?= =?utf-8?B?NTY2b014QnluMjZpdEYxOHBVaTdtd1ZZZ0NuUkkrOTg4Y3BoVllyZHR4a3Bp?= =?utf-8?B?dnNkMWM1MkpLbHVKdE8xNTJBY3VQNzNRTXVpSXBNMnRJandleFdTUmhoNE5y?= =?utf-8?B?UTdSVHpNZGljbC8zVjdKZmlWdUdhTU1XQUFMdWRVdlA0VEUzd0NFeTQ0VG44?= =?utf-8?B?OFJkbHFBWkxuVlk4RThPbnhodmtTcjdSdU1hZnRrSGU4SWtENjhpZkNQVEgv?= =?utf-8?B?ZWhqT282cnhOTnk4b1cxWHJheU5hZnRBYXJYRWFDV2kyWndieGNvUDVlald0?= =?utf-8?B?SmhkMlZIamFJeVVnMTdDYUpGREpkV0FmT0ZlR1pQajVESStPdnZWcEtqRXZV?= =?utf-8?B?RUVsSllIOUE0VU9ONndrR0FHRm13V0NXMU1ubk91N0xuMWR3K1VpbUtRPT0=?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: TbFI3pa31eI0l+4cKWGyBIe5nBZ4mRD8GFiVvSgmndqj2P1nRy5j42H5l9Y8LqOTSxxHdQbIsbFLZRYCbeQcBRAhSrIqvLTqk6gbK2pxjEKer8DRyzNCA+lSwZcxxYbUv8V+K3ltTW7dB9uQJhYP0CwyyePAlUanpRZDkIPnYHAguYms0QYCBu2Dmcu+b+VfNCtPttVDDt48J8qwvCFTZJIO9RknR5gvYPMUGNGheIM/IOb5vSmoXsLYKJY0j/7a1pyoOW0IAM8UEceMGLkhKkotG6h7BCWJfaX7bqnkPeuCeVVJfN6qaT2nolE0XwOxJNlgFGjdnRVIgGNqFDl8IsmHY+Ss6hFeEQx8eDL8NrdI7eStK6hzgsNEAI5fUdK267Th0FYPxcmFY6fJLzsVkUYimxA8igdcxrNTs8iwpDw= X-Microsoft-Exchange-Diagnostics: 1; DM6PR01MB5530; 6:BN8pLpZoi/UmKj5drfEGxKspjr06c2HQ31OjA4pHJJZX2F6CIsX3bkAtpI60kDcv/dCJcGvpPiNlwzOdVEz9PgpAHJ+rHzCRkySU2QC1swnfLpuaEgR2Z7YHSVaMvXzrwOwqpd0RGosybYr588WwKoxPFqv67GsCyyDalwPBzQmZ48T7LcMVgxEtYzOBRHGXZ0jsT1BhzVV4ht3toSFct6g6kNmI2ZmuRWAyBZWDkmDZu/TzYjTQGKyjMEh/jh514t7RGlaz+0UTy4BBtZ2UzCtcGa1Sb+gxejfeopaI/fSuJnOUkAVMFSC+zd/0m1e4EJoA7ov5MuuaFr2EfWqpHSSj8SGA1O5QAAzvGi8nSnrtMgMTAmYjnbn4DsgMSh0DZx5e/SFYswiQD4k66G5JpuIwv2jErfvDaiDDlyELn2nlt/6VxD0vTkmzQygYNWlzcgI94WLZIXWQnKU2s1Q2DQ==; 5:nhpfvGYw2mRC0nvHwunL6sn982MQv5eZJtJ4X6QzyS0Dyi9tAJDK5WdY3bgG4yHi7P7SVO+F5ReeFgxD1Noo3wY8FhKPsEQt/DyC+08eUuhiewr8pf4tsR88Nx01abvdSh64cq6QzgA5bRtDzd0vuz49BXfAH0XPaH+FaMD9WCrSUNwNzEPkvcvFb/ke+AZM8SK+LKkqRJugDKUYYSAxBA==; 7:nwXIMEpvLTE5hJ+80bA6EUEtl0A3IAIqFMz987iMLMLmtytjnypTMsCuOjHTqSH67BnTWmQeyIJOMD0ia4ekE0eVPC5VQ1LswImycp/+ki/UZ4KddJKQqkiIicMJuBSdTfxhwUhLnu34KD4yn9tThA== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2019 02:26:04.7258 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6fef3b40-997f-4dfe-4d0d-08d6776c234d X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR01MB5530 Archived-At: Subject: Re: [lamps] Last Call: (Hash Of Root Key Certificate Extension) to Informational RFC 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, 11 Jan 2019 02:26:09 -0000 On Wed, Jan 09, 2019 at 11:52:49PM -0500, Daniel Kahn Gillmor wrote: > > Does no one else see this as a problem? if not, i'll just shut up about > it and let things break, i guess. it's not like the ecosystem has never > run into transvalidity problems and unreliable root stores before, this > is just new and interesting automated ways to arrive there… I am late to the party, but I am happy that you are continuing to drive the discussion, and it seems to be making good progress. Thanks to both of you for keeping talking it through! -Ben From nobody Fri Jan 11 01:17:11 2019 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 A45C812D4E9 for ; Fri, 11 Jan 2019 01:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDs7uq5MhYYw for ; Fri, 11 Jan 2019 01:17:07 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF6AA128CB7 for ; Fri, 11 Jan 2019 01:17:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4F65ABE2D; Fri, 11 Jan 2019 09:17:05 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8ho68gtRo6d; Fri, 11 Jan 2019 09:17:03 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B3F40BE2F; Fri, 11 Jan 2019 09:17:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1547198223; bh=vOSjsV+IY7G0cujiuVdD8qOt5O92uzsVbWZlvx/3us0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=CFuuyEnIhIfoYab5Humkf4X3R1P8mv0qTeJFJ3otcueAKGW+0ZuzKTkUhcl1AiAb3 mFZ5OD+yowKlBUG1Zw8GK6TsFPcTzXHc9WODauQcViLskzXuB/gGunpzyHNfNmSNhk r4dSMRm2RIrY/KLPvfYoLvlYDFSfWKI8F6jpzTnY= To: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgcHJvamVjdCk=?= , spasm@ietf.org References: <87bm5hxdn0.fsf@fifthhorseman.net> <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <3d2b0b40-10cb-3019-bc11-53450c529573@cs.tcd.ie> Date: Fri, 11 Jan 2019 09:17:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xIl6SRBTeKZIx8nupeNwzPeFXK7p0Q1qL" Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 11 Jan 2019 09:17:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xIl6SRBTeKZIx8nupeNwzPeFXK7p0Q1qL Content-Type: multipart/mixed; boundary="AdtL8RmuokHODpieGYvUdVu7NVMa3HvGd"; protected-headers="v1" From: Stephen Farrell To: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgcHJvamVjdCk=?= , spasm@ietf.org Message-ID: <3d2b0b40-10cb-3019-bc11-53450c529573@cs.tcd.ie> Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter References: <87bm5hxdn0.fsf@fifthhorseman.net> <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> In-Reply-To: --AdtL8RmuokHODpieGYvUdVu7NVMa3HvGd Content-Type: multipart/mixed; boundary="------------28593BC0C5FCBC6774E76C5F" Content-Language: en-GB This is a multi-part message in MIME format. --------------28593BC0C5FCBC6774E76C5F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/01/2019 21:54, Hern=C3=A2ni Marques (p=E2=89=A1p project) wrote: > On 10.01.19 19:21, Russ Housley wrote: >=20 >> We seem to have moved on to other topics. Does that mean we have sett= led on the text we want the IESG to add to the charter? >> >> 7. Cryptographic protection of electronic mail headers: A >> mechanism to address this in S/MIME has been standardized >> in RFC 5751. The WG shall define solutions (both for >> signature and encryption) to close significant privacy, >> security and usability gaps in cryptographically-protected >> electronic mail. >=20 > For me fine. Also seems fine to me. I'd say shoot it on. S >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 --------------28593BC0C5FCBC6774E76C5F Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------28593BC0C5FCBC6774E76C5F-- --AdtL8RmuokHODpieGYvUdVu7NVMa3HvGd-- --xIl6SRBTeKZIx8nupeNwzPeFXK7p0Q1qL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlw4Xw8ACgkQWrL68XsX K+pHTg/6AvfBDyKrwhFWNeSNnVC+TLUHICACA1KTwnjPt5TSeZDOcvg2FXpEAO1/ kcAQoqDYXB37zKmMHPgCWqkkEOEqmx4ltvOHveD5dQCFGwlEzToRCGb8rEUoZDeF fZ7AQzKF2AaOsE9otvtp9gTGOBznYeYFgGUKGQ6L5Skg1pALxbm4S7PgFz7nJ1A0 YsS5Oi4lEmUT10pLibmB3vvTIM9vDa3IMaT5Aly9IjzRoM3Bg51hQ3qjVQsFdGol yShe99WxK1UwRsckuznwgCmt8zk0/2OM0K88qGWmmOqcd7zL4l8ti7O+EfwbQ2fW eTdJB4cNBxFV5nJTDKo1+2OaUuxo+6Bty5A28XjGpovUacZrvWne8CYDQ/R3PnBO jBs73jDvYWABbwTzovoYuyQAiOWU8NLc4qmQJFFv+u2mMXGz9PKRFFZ+0Fdb+q2x 3eJxtPgsRpRlGj1bmncJYXLRMjR2vvDrRAtzatCBAhl40WPPCHXbbtP7ZJ5ztrAy 0tRx7nrNxiCsMnrhvmrMmA4CcMbasylMgdccjqX4aILYa8eRnQ5osC80IwneZlen 04LXjgm//WrAcrJkbpr+714YAhUY/NMBwaYH1FTJThPFRzXfooQ1hxv6iCrpFMOu 4vfzV1/joYnCCdkQZRM4nU4rB2bay58FiZVSqa47YFKaAAhzMz0= =JmZN -----END PGP SIGNATURE----- --xIl6SRBTeKZIx8nupeNwzPeFXK7p0Q1qL-- From nobody Fri Jan 11 10:17:56 2019 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 8CAEE127AC2 for ; Fri, 11 Jan 2019 10:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jt4tyHyqIc4 for ; Fri, 11 Jan 2019 10:17:54 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27EE21277CC for ; Fri, 11 Jan 2019 10:17:54 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 20800F99A; Fri, 11 Jan 2019 13:17:52 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 120B621274; Fri, 11 Jan 2019 13:17:50 -0500 (EST) From: Daniel Kahn Gillmor To: Russ Housley , LAMPS WG In-Reply-To: References: <87bm5hxdn0.fsf@fifthhorseman.net> <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> Date: Fri, 11 Jan 2019 13:17:49 -0500 Message-ID: <87imyvcb3m.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 11 Jan 2019 18:17:55 -0000 On Thu 2019-01-10 13:21:45 -0500, Russ Housley wrote: > We seem to have moved on to other topics. Does that mean we have settled on the text we want the IESG to add to the charter? > > 7. Cryptographic protection of electronic mail headers: A > mechanism to address this in S/MIME has been standardized > in RFC 5751. The WG shall define solutions (both for > signature and encryption) to close significant privacy, > security and usability gaps in cryptographically-protected > electronic mail. I like the push and am happy to move forward with a charter that includes e-mail header protection. But I'm a bit concerned about this text for mainly stylistic reasons -- the above text only mentions headers explicitly in the part before the colon, and it doesn't match the form of the other bullet points that are currently in the charter (no other bullet point starts with a set-off title like this; no other bullet point says "The WG shall…", etc). I propose the following revision that matches the style of the existing charter elements (using Bernie's notation, i'll call this DKG-2): --- BEGIN DKG-2 --- 7. Update the specification for the cryptographic protection of e-mail headers - both for signatures and encryption - to improve the implementation situation with respect to privacy, security and usability in cryptographically-protected electronic mail. Most current implementations of cryptographically-protected electronic mail protect only the body of the message, which leaves significant room for attacks against otherwise-protected messages. --- END DKG-2 --- if the group prefers the text Russ cited, i can live with it too. i'd like to move on to the actual specification work. Regards, --dkg From nobody Fri Jan 11 10:56:50 2019 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 69D6F1286D9 for ; Fri, 11 Jan 2019 10:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFS9v0gMy9st for ; Fri, 11 Jan 2019 10:56:47 -0800 (PST) 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 BBFCA127AC2 for ; Fri, 11 Jan 2019 10:56:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C5A4F300A01 for ; Fri, 11 Jan 2019 13:38:29 -0500 (EST) 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 g02KVfL8WrVB for ; Fri, 11 Jan 2019 13:38:28 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 67D3C300064; Fri, 11 Jan 2019 13:38:28 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: <87imyvcb3m.fsf@fifthhorseman.net> Date: Fri, 11 Jan 2019 13:56:45 -0500 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <7DC69A08-3A4E-4D57-B490-179B8E4A411E@vigilsec.com> References: <87bm5hxdn0.fsf@fifthhorseman.net> <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> <87imyvcb3m.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 11 Jan 2019 18:56:50 -0000 I prefer this wording as well. Russ > On Jan 11, 2019, at 1:17 PM, Daniel Kahn Gillmor = wrote: >=20 > On Thu 2019-01-10 13:21:45 -0500, Russ Housley wrote: >> We seem to have moved on to other topics. Does that mean we have = settled on the text we want the IESG to add to the charter? >>=20 >> 7. Cryptographic protection of electronic mail headers: A >> mechanism to address this in S/MIME has been standardized >> in RFC 5751. The WG shall define solutions (both for >> signature and encryption) to close significant privacy, >> security and usability gaps in cryptographically-protected >> electronic mail. >=20 > I like the push and am happy to move forward with a charter that > includes e-mail header protection. But I'm a bit concerned about this > text for mainly stylistic reasons -- the above text only mentions > headers explicitly in the part before the colon, and it doesn't match > the form of the other bullet points that are currently in the charter > (no other bullet point starts with a set-off title like this; no other > bullet point says "The WG shall=E2=80=A6", etc). >=20 > I propose the following revision that matches the style of the = existing > charter elements (using Bernie's notation, i'll call this DKG-2): >=20 > --- BEGIN DKG-2 --- >=20 > 7. Update the specification for the cryptographic protection of e-mail > headers - both for signatures and encryption - to improve the > implementation situation with respect to privacy, security and = usability > in cryptographically-protected electronic mail. Most current > implementations of cryptographically-protected electronic mail protect > only the body of the message, which leaves significant room for = attacks > against otherwise-protected messages. >=20 > --- END DKG-2 --- >=20 > if the group prefers the text Russ cited, i can live with it too. i'd > like to move on to the actual specification work. >=20 > Regards, >=20 > --dkg From nobody Fri Jan 11 11:39:56 2019 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 7F56912870E for ; Fri, 11 Jan 2019 11:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuQM0o6ALvM0 for ; Fri, 11 Jan 2019 11:39:53 -0800 (PST) Received: from dragon.pibit.ch (dragon.pibit.ch [94.231.81.244]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3C6127AC2 for ; Fri, 11 Jan 2019 11:39:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by dragon.pibit.ch (Postfix) with ESMTP id B0DD8171C069; Fri, 11 Jan 2019 20:39:49 +0100 (CET) Received: from dragon.pibit.ch ([127.0.0.1]) by localhost (dragon.pibit.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4GzPRRikxav; Fri, 11 Jan 2019 20:39:47 +0100 (CET) Received: from [192.168.43.199] (0.229.197.178.dynamic.wless.zhbmb00p-cgnat.res.cust.swisscom.ch [178.197.229.0]) by dragon.pibit.ch (Postfix) with ESMTPSA id 62CF7171C05E; Fri, 11 Jan 2019 20:39:47 +0100 (CET) To: spasm@ietf.org, Daniel Kahn Gillmor , Russ Housley References: <87bm5hxdn0.fsf@fifthhorseman.net> <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> <87imyvcb3m.fsf@fifthhorseman.net> <7DC69A08-3A4E-4D57-B490-179B8E4A411E@vigilsec.com> From: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgcHJvamVjdCk=?= Openpgp: preference=signencrypt Message-ID: <0319e3b2-81b7-13af-df9e-436a15ee1074@pep-project.org> Date: Fri, 11 Jan 2019 20:39:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <7DC69A08-3A4E-4D57-B490-179B8E4A411E@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xa99I1ZUa8pPV2W78rGnnFIwmlrSdFiZl" Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 11 Jan 2019 19:39:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xa99I1ZUa8pPV2W78rGnnFIwmlrSdFiZl Content-Type: multipart/mixed; boundary="pRZow2qSeczAvcarTt4kicmrg0ppja6di"; protected-headers="v1" From: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgcHJvamVjdCk=?= To: spasm@ietf.org, Daniel Kahn Gillmor , Russ Housley Message-ID: <0319e3b2-81b7-13af-df9e-436a15ee1074@pep-project.org> Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter References: <87bm5hxdn0.fsf@fifthhorseman.net> <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> <87imyvcb3m.fsf@fifthhorseman.net> <7DC69A08-3A4E-4D57-B490-179B8E4A411E@vigilsec.com> In-Reply-To: <7DC69A08-3A4E-4D57-B490-179B8E4A411E@vigilsec.com> --pRZow2qSeczAvcarTt4kicmrg0ppja6di Content-Type: multipart/mixed; boundary="------------16E340BD4169D98D4EA9DE40" Content-Language: en-US This is a multi-part message in MIME format. --------------16E340BD4169D98D4EA9DE40 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello dkg & Russ & list On 11.01.19 19:56, Russ Housley wrote: > --- BEGIN DKG-2 --- >=20 > 7. Update the specification for the cryptographic protection of e-mail > headers - both for signatures and encryption - to improve the > implementation situation with respect to privacy, security and usabilit= y > in cryptographically-protected electronic mail. Most current > implementations of cryptographically-protected electronic mail protect > only the body of the message, which leaves significant room for attacks= > against otherwise-protected messages. >=20 > --- END DKG-2 --- Thanks for the new suggestion! Despite *email, I can live with that, but if there's no objection I would also add interoperability to the list, such as to have the following text: --- BEGIN HM-1 --- 7. Update the specification for the cryptographic protection of email headers -- both for signatures and encryption -- to improve the implementation situation with respect to privacy, security, usability and interoperability in cryptographically-protected electronic mail. Most current implementations of cryptographically-protected electronic mail protect only the body of the message, which leaves significant room for attacks against otherwise-protected messages. --- END HM-1 --- Greets! --------------16E340BD4169D98D4EA9DE40 Content-Type: application/pgp-keys; name="0xCB5738652768F7E9.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0xCB5738652768F7E9.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFWozlEBEADAIFgjylzzPH7JKRJPbiEGoSsrSaCrbWLdy4sNGD4fS7GsuZ9f o/E9iYzC7WwGhN8rB4jsLv/ZfGVbAsmpypvZdReVs/BPidR8Vo1WMOK3lww1L6j8 7UV7TwUzG72u0zMXCUWMtX3+7kWZVlohXPCzDe7xyLu5tdfPWIAxDrI3h/+a4qAR ySVo8RwzILDwjbLF8at0w52oTRIWcr9CAus8ktRKBhc3MiUsSXHGgZLujUsXKAYg Vmh53uEVsjigeHZh6XPrzQPTnQ/VDcqNSRl4n+fQ2e/sZV7CQttcqb9zfj8P6Lyk jG3pe1AUSm9A0o75bi8PUluPWyH0wdt4D29xabFFyBANyYqKiLyZvnBqGSkqswnW 00QoYtMaEBh7nyuoUCa0bTMCRn8NaXRCnuINx+E2llqJqeQ0sMJ5WSQe4RbkWRsF PJOdiouLyHEZUpyQlMFesu/mN565eZsw3a7u9hxnoFgX0tF0hoONMRSAU1y3aZeb a+DvwXDQcSaHmBARQ2v8qWdql16Zhvf7KFo5Cris9jNknInzs2L6pHVZN8AY2ESO 2UXQJ+Fyy5BEHXS4LzEnWRPLYkAE5eVi+ZDcRMQeO2L3ZenqhcRRcQUAaRObho0L WzE+EE8ZvQxlA5hn/4/lHQLk8ZiEgenl+y/mtL8TeXB1HO4DrqahXvlu2QARAQAB tDxIZXJuw6JuaSBNYXJxdWVzIChw4omhcCBmb3VuZGF0aW9uKSA8aGVybmFuaUBw ZXAuZm91bmRhdGlvbj6JAjkEEwEIACMFAlcnOjUCGyMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDLVzhlJ2j36SSQEAC7L0ZgFNXZAsXUzDIj7ZcyG41jcIaF oBz+VyIz/72zsr7tR469bq9QulnEdhr5Zxa+sZauT+tktmehpQpkwAZRXb4jHawS MVGwzssKehUe+sN9rrkIKvFbKMHcL/ZUiaFKNL0dX/tbtA/lZGwMSGlE9x1BWPKX JrqiKUpvk278jFwkOfx+mzVSuuIcIn2o25BM6n4wxQnDizcES2Z9nXyYzSBagvW0 v2LsOEatYgCFoTxuO37uPHXL3NlhipRx5dfIxKjX5zr2DOxKcS7SPio9cGJ8Z5gB jfC3ByoZfQVmrR0lfIxZVtFTzR8my+fOLDhL5U+3RVbGHHHjzJZY03a8RUpcWsMr +lsogSH4h5z8QgkwfhTyBAUIcewHU5128dRG8m+wfTTHnQFCpmd0Ql3beRbAhN/e xQx5aJq81rPD7dunQtKB7iyiDpHjLWJ22aBr75GjSfF05Gr4LgLMFkATzrpnlXyR uLtZ0TTURWw+pximLJu/Smn5CKUClJayGOgp8a6bmNlxn6li6SZVoyu/S9RCUWTB z2dsv+iDjk/La7gcLxwrtkf2wFxvauaax5BjXoEnOAsD12wF3Snr6ymARh65rZ+C /HaiRpUXoUFIWUh0gRnJHa+EOxXq2wKBJul5toTlOEiqK93vVwKLlPgjiEY5NHEU 7zpE7skkXYqKhIkCPAQTAQgAJgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheA BQJXJzpdAhkBAAoJEMtXOGUnaPfpktIP/iTLClFO8y+KN00z7cHxbistBKjkFlS+ Q4RzNmXQXgXMaB9pMvIbCP6Fm11q13GGT2MLm5gpoIBH50/fCXxWPGaeMRyKvv3p PDbSwm7J7hDP5H2yCGclkzs0NntiZXbOmLhFdZjsIhi2GnNSrUve6MOUM18p0ph3 f0+Ia3Ki3HaURLD4sGUJ12ig8tLI82nt+NaxEKCaD7b7KtV2XtMQ7RAVwax8to2m PBWzZReX4nMmqX8LNXhn1DFkCSGCl45umK7i39Em4+OYpLyWy3vMmKuGXA6uVenl WQbKuaw+Rer+MUOTM2sABfm5ffiNMGBO94JEGvgwSVUCmrqyBsZ846q+FTlJnapY /D63bIeINuX20TYxpzZSKh0U9sVKU6cd3koeH6CFYPLEICQBzDFZ7GTg9MJbAbGp y/P3klwdfHo8AcM6QIH7MIdfrkk5WljF1vz3FvWcGmoqmGRdrHt/JBsDw94p/d6G n/HWAX3gJvrF6+BTDUZ6pmhRFXrk71/M7Qz7FI2NzIv5XWmzYhxkQ58om1adBhx/ PQZmCFJeXkp0pIBSWa3vuca6LOwsvipRoMhXSm9UCYFmYtsny871dIEMWfDaYisV mBSKRw2mZnAo/sjARxjqrPUEAIbzGJL3ePnyqj0P0mLYOqiEi+wxMEUzYpCn9WZc r1I/JWQ1Bri+iQIcBBIBCAAGBQJXe+cuAAoJEH+zxRJjw92vLy8P/1xWquKLJ1E6 n0aDRPLRKV3dcdTS1CzXLbGOp1IkPrg35hAJtiqhlYDWqY7Ff/oHzYFwi1iClHwq FCTx3U2nGAU6O7/TVR99c9FTV4UdbO/et3J+rb6dRm3e+DoqCgBq/uvCrg7I8Gcw vTLOnIxXeL9N7ZIzV7Ac5rdowvzCMhGClRrT3im3fBpbe4EbHPfrTtBclZhL52rg 2EYrfwu8b3OeNgNzEfS+T0GM9O9ZeTVU6xqtqCfyYYzTSOTL0nLxabl5QjSq+Xn1 9Ye7tDGDIE47Tt1XCMQANwpfQzDYbJhYeXhX9fUw1oDIX0EbGJI/X7aHhDPn+bFY RsBUS7x/tuD6STnbDLanNjRvyBpttMkMwW9udO0QmMwApZ1PqyB+xGoKQCQhnN6y 6RQDUjMBD180J0i6f9K5zezwrAqWjQo8fU7S5Q02d91iRk3msZtbNR6nM+ulVX8s 8iKhHDBiJdzW8WT/wc2R06ch8LQ20sNscU4ZrdcC5IOL5uadCT0NTCr85vC47Qgw 2Ywe7lYwvamkU9GeM0xIs5ZaLkC9PpWOGnQbrpFDod0nL+mot+/bdtI8fX+p99aC xmHAG9GIt4V0unAVvFo6HQUKN5h49sfLQk5nZqAfhrxFgoKPeL5IvTxls+D1+/1W UHBc9FkdnBLYOQz+IXKfpjf6Gus5u2dTiQEzBBABCgAdFiEE67uJIQ52iILmzp8S zf3jCQ8RqFAFAloRcs0ACgkQzf3jCQ8RqFA0CQf+MYsDDjj4qMI+e62hhiyg24h5 cyRFtfc8wa0cpsAzfdAHjxx+vX2Nf7NT0EgfmOPhQqDdL7VOs4dqAxP0x84D+Hqc Ps/8wcH9TWsOKykohWJI3LmOoQJ9pGA/piX3HMjTDQTy2C4DfAdgJEJjeoL5kdB4 EsIRUBQsi2mZz5/Uj3MoyE8m9JIMWsfgw14F0lT1sG2VLWU5s+NRD7nCkNLnzlNZ dGKDyeppBf+QYOKYOnrlVuXFmt1lSJjocB9hnqYI3ZQca/Pyex/mRZ6ygxZsQiRO Zl0NRJW8zcwDOzZmsyJbroDkH/H0q4Noh+NvYUov1ByvIC+0sf6zk7YUlm6TC4kC MwQQAQgAHRYhBOSm1kc+nalhW5hsG137/dXwIyEQBQJbKyeMAAoJEF37/dXwIyEQ ktMQAIZof2Yb4Z5C9rbci/TD4b85tzEpOn1/t1k13Rro29AgFe1/RnHl59EyoTFw Ii1sTum7RX9DMzZGmpJcrMM5DpTGWH842qz0dD/tj32bGEUcCe4QQ3riui/F+STI MVtQmFNRhCKxKw0Kp6zSt+yphlaVwbeXD4XdgCTJ7+HiLPHq87QkWn2WuJhjGuLF L0Cz65bp58YjUCTVJJ1FpcIUjkirO1lcL3jsbdoVhaYlkhu2IuK6TialybqsomQ+ dAEEWkOKujqlS8VztQeTSEm16W2XqI0omPaJA5W5xE6efqtrq2aL+EaJ4F5eUFuo jBbtidd557PYTAtvUQikoqUA3BzugeCUY11bMhi9Yy838iEDkJZKUddrlW2JltZR l0iuTbM6li9urkfn4zMFLhK92U5VC3dsfo7Cat8jqwKHwS2+WksNPlQtyctTFpwq W1QTZnvI9BzlisCJq8PxHoWdbE5TYQh27PNKYRTvN1xsrM6OYeMhlnWaAzU4laDC J+VPSJqQfpGqNgcGCbY8ZQHP2hWPARf1tWtH75S5MeMmeMZqiO6w19OG8JgqBTzK NVbm/4Tq3WDQuIZi78G9xOWXdxkioEffvj+pvDl4cwEpSvpXHUrJsGA/lyeoYdlo dzEajN//a/RF/OiLlL5g9dAUGSzgYgHxDEUPmEy+dyIwfXI+iQIzBBABCgAdFiEE sCfaSQV5gVpBDUL9pIWg7VG4t8QFAlsFbvMACgkQpIWg7VG4t8SCXQ/9GokbY2It xw+8tP5xzuxkR7hC90XMi2pUjUoChuoK/Q99wHFiJKLPhWo/Y9IRefIx8hINxB5x pJfxO6C5HyMYcsKvza+0KWpVNjH9qTD5zHzKjANtwLc7xGnGquSzlMR7XbqwtGz+ WnZjFCJ3u2B3g5vEOIC13yojV1FKCZs/m2Ym2dKGB4+ZMHAb7dGugVc3QCVNH7L+ rW7rJiK1v92iIAoKS8OjZLMR9Iv0tlm/ng/OX0tjMzB2EeF6G9AWx5a5LV6+w/B7 ZbP8V8p/wdsz9JLdvB/qq42OXK8ACxlsnQ6ooSrXpjZllVDG48DR2JlgmvpUil6f DT+wA7KeCnmXn+RuxAfXRuolsFhYjRDk6y9UCGCcMj6x/S33JXO3mQbT3AO4Lowv +sF/YpiBBMGyFPs2JSU8QSRZgpNkcrZy3YGJUdgNglIb5ywOagz6Wfrkq4sM1jcP /86htV8w3HX5EshMvFR+/KgtLIZuq7WvGGnmJ3ucwK0J/1HgTfUgmp4jWexaDZ8V H0fCEKBbKpm2UZO2m4F0BBoZ6Jadtcuh4vulNIzJ0T7XwE7oPERA6TEYVDlwCtto HJdFHm/UdGlJfktWLPSS2N1pf4qvt/A2q2NLYn7/lwwzibyoyYqQm8vTcJYZPo4K xVYkwHu8k/a7zgN9tnSjMg/2huzRi9oV9Xq0REhlcm7Dom5pIE1hcnF1ZXMgKHDi iaFwIGZvdW5kYXRpb24pIDxoZXJuYW5pLm1hcnF1ZXNAcGVwLmZvdW5kYXRpb24+ iQI5BBMBCAAjBQJXJzpOAhsjBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQ y1c4ZSdo9+mfeA//VXef1e3yFrWO4N7XWOrTLSDWNCvUkyFk6gE6nq21KlgJ70cK gnBXK87WIYt7HpcdJ7zOta8/fxqKEWgruNAFzzHBiG3UNylMzscXJcnn89yHwE1L h2xzx6jO+b3qkE8+YUNyb6KAbp2Q7zX/2guo/z4FqDPwbnwGS1wWG+eOYuuQl+0k AlDgvI/kqVeCZQjG72X/9ZrwAyS3L594dMghutAYNMzjhr0364fAng5CMc2+86mu DhRkCF6EsDMKT6CLry4d+EfQC0rBn+/+VqDs5iV7Qpl6XEWwedUT4OF7weXIqq0I I4K+RYa3PkIEkM79X/FRBcFInEl3hDjD0bJ/SYn4uOvyK7V/JoSivry7VkaRpZvN BIXxhzHujoxZXV8DIWlQ1Szcze+mYmnCtZB014KlBpzN7Gc1yvOth0UMvHzPswwc TLzpBKaOZoNID5WAAfNXeijhHda7fBkoPCbh4UMGPw3kgHEwx+N+KeclvTVaQB5G 0Cor0p1d5Yazp47o4Gbw5KlqjZX+XDchkiIJ2jA9oQXPD3oPCYRL/NMCKzviYQ2u Gdu8OvMVUWQ05R1/ZKf3HzUUntfXdMSMQ1SEkkjztb5O2T14pRquSO0p0d9WkQyc 7cuDo0mIC/Clxh9qvN+aiuvCnWmxwtkEQUaIC4dWA3NjVjBcyKs9WdjsyfOJAhwE EgEIAAYFAld75y8ACgkQf7PFEmPD3a/2UA//YuEE5v3O2MMpI0kyfUhckr0Atiiv vAbcmtC/AkZ18pGPxvenyeUYK0WmjfaH/u3/2U3E8mY40lxzvpj5+q+Kx5E2TTmI YI4jJwvxD7Zsu/NA/XDd7G+jaKaAkaC1kVmpBHor8PvROtPBzLOlbqH6U3dmZm7g jO/al20kyHzc9m6zQDVwdBSEiMKXjr641PQFoQB0OmpwLn0RYUXA+P7MSFmBO2sB T1yFJePqzjbnhYwprcEi7L3RtarIy4m3z6YthN+ek3Fpisxf+m4LmGzVZCLQFBVd 0tGihI6BgNqKnSZeI7KpcdLRX3h+6I42rNhgGNAGSmF6itW4wNkvj1uHZzZXIA3E Bp9xlI3zaKxtAbVqeXoslFGIaboFgL4TDw5aZWQIRY4rjcbohD42XkGa/4XIigFD NpniKhH3zucLzZwsJu1owyz2JvlxNkEQgB4NoPRMeXTykIuR9Hic8sb+751MTnPF KsI/ijs4osudhNw6RT1Z2F9lX/prqIEnLe6+4UOh6gkbdm/TfuAcWyZ3zeajrGb2 qWxHJje85O3ElHGyfqafj9F6260PEnG+5s1lrHEvfdygabwZwwzcFo51mJGA85H0 TlIxSuWelozBaej+Y72K+J9b8EVJ618Y3fvAZ45ygzDBIJ+Pg4r1ZWF8kWoXB4vh K0wEJDo5ktzFZveJATMEEAEKAB0WIQTru4khDnaIgubOnxLN/eMJDxGoUAUCWhFy zQAKCRDN/eMJDxGoUD01B/94O8L8JNhYo9gWaBZRrOmo4lPeVqfkdrSMbgDoEGKg cSUBK3L0PypMKxkTDxMWgps90SQlvphAuH8+2XgqaAqud8kufqqbCy1suDREmgux OycRIZZLwlVTFpB9x7K4HIBrQMEMtUg/cwvWHr6ClQ1AILvhK4ZO0nFg6cjH16VQ jotggVp5E14txae7wj4Ndq/tDEWTeHeKBpQyjgyuHFJ3MKY8CVNk0G+P6S6IEaEP QXbHj4eEIkPJI6w9/Nftjj6Oud7g6Qca87XJt9ELkpTVs3f7DOJxXUu9ArxLcWi/ 1tACFD3bQj0VwXNFIsfbrRKXYw4aDUBMeBMXZgXFf886iQIzBBABCAAdFiEE5KbW Rz6dqWFbmGwbXfv91fAjIRAFAlsrJ40ACgkQXfv91fAjIRAibQ//RayE81NcW+Ku 4Hfnmltm+nJRUU592S6Jf3HahXOCF3U53nNRtXd4toJSFbqXfXpmnZE6ROsfrRRe Ll6cM+D7/n2FaTyw+mwOZ4bUKPvy5PbADm+LuFEfkYW8HwjNMn7e3mPdbHxodtDJ xBkVba4eyGOYvWaiTPfT95EE/adEErI5L5SjLzM60QvNMjCBVq9el9PqJBSIDj+k f6dDAdhGvWXPo9NRXBNaBpYUlIB6TPFamyBI1HayKU9MeeWDPUOR3FFnfmsU55In gjRi4ffQNbSjSfgvOwmvry8WkFOtPg9kjQ25QCxhitcqfUCqi2O3BgMg48kasmUw 9DINn/4hNqCM8mYv1nNTezOjds8D8N+19gJ6XwNyI1u5DY1sgbL5DyIMVo1Kggnt IV4z21TueIhvUm44HWayGICd3KHr/tc7J+4FyvjivZlP6OWKNj7xQhcLDIrI1vAO Ph3f9l/wFRmjPlpFSZw6IjxDx6VJuYX6tCMjy/SY5gJuhzQqW5a7uSZGTyUc+WYn 9dNcst7AI8vTyje8LryPYOlop3tkz6kHDdQjSauUtggXbLdW0CoHWDIolM4c8iDl jBR9g74cX07q0QQ0o3sCMFodpwKlOyHbNohIfFnM10DJLy/0xEePloVw2I+78dSD H0eXSLedGPO7V9D1a94cVbawAGgTbKWJAjMEEAEKAB0WIQSwJ9pJBXmBWkENQv2k haDtUbi3xAUCWwVvCQAKCRCkhaDtUbi3xJYND/9uo7/jmN4V31X10QZQtDGGwQjQ 9XoA8AbyBdkJvhWDQmThE8J3hPz8Vhj0vHNYj9zLAbSDDFYPtfeNLyU6osJQwiVR tTTZQWIfFqBhEBZ8Q1hmxRsJSZ+76Ozs33JEsNsX9HuTQcGMlHElR+bsBrIxQhN+ NPzw6/r8YT6f8RF4bRuS+uS3wr+m+hNYdhdIFvynQl0r2/Sgbjui4TH79byLHtq3 lpGWpH/C0TyUjO9W6b79D6Zjw3433UsiL+pcBGKam7EmV/lQN01K8ZoipX13tO09 tfjdnV28CTBfa8IVjzR5AERz/UBV8KwP3oy1Or5dsGirVtCKM/gOOVQVrTYqot35 2Yu6jRV8deRijZlgJhKg2UGoe0/oTvOXvZN4uRCsxzJ/6VYczfSthzT+232Wx9mq 4UmS7HjgHRK/hIedBGwFTawABl22hVawip0SNSr0ViEkc4OGBR2z1vsYXNyDIdBz VIRIpLusTZNHYUAkpI8ChIDpxOLpGXGCaGqBY1DwISATfSlfAQ3n7ZWOHfSRVyaZ 3rPO176t36vhsoJy+naTvPDyaTmbLkrfgVX0YsZzkPpTuk7X6GfmjBm/Cl0MrodC xt8B46RkkObRnzUBjdwtyhWEydGtbgz542kIoewxYgI0YXo7d/H7NJdlxVFsEfck sq7mfYvX2XikLXuTyLQ6SGVybsOibmkgTWFycXVlcyAocOKJoXAgcHJvamVjdCkg PGhlcm5hbmlAcGVwLXByb2plY3Qub3JnPokCOQQTAQgAIwUCVyc6dgIbIwcLCQgH AwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEMtXOGUnaPfpBJ4P/1WPpe8bRj3vavxc JmeGcgDyZ/4Z8A4xoT3rhILE+CIF9ttDQd1BFxQMfLQkrhmPOfOtnQvwBkHhp86D Obu65U0RRrr/dhLRNp/9i327Xusm+TEZs04HUe3D9Wjab4wjfpBKeBX5h5dVzwRc l+lixEBvmZ1AxSMh7diO3XoXTfFKICR3SH2fctyBIcD6gGKuAkZH+z/GZJNpJtiY fF444C+XbIwkCrjQJ8pLQ6cVDNzf4n7Dn6zbpRCCpQwNslt5HBi9wj49roMF4JEs pHl2gc1aKm6kXDzjvPye5lRDqC1Yz8GKvH+TRlqtlNK2yZ0Ux1+G3p2scO6wovup 2wBB049M26cehR/H3s7s8fOnVpRZ4Ks0AzpImVs3O6pf3m+6cx17kN0AtQ/s8zZ/ U0k0gwI0RaYCLj1pAG/+/1skX8KndF86op4rAO/CPhPtDDoY6UGm/4vYaEEQdi3x miPoAbWkV92kaLVzU9ROUdX6uu6/PdEo7d108wAyvQekaqTGuk9Cw3uM0tgmJw21 AY5Y7GBkeVmeytN0MdqfanwhQU7dsL8tidG+dum9MgkSDXOk1g7P0pUakrPwE2j0 mzin1VIVyPJNJNklehUgRD8CGNHFEkT0qADX7/iF44lt0QW4zZL6W1bbvfAg0mzA XnwHN1/KFba2fq4oGc3eNUAIWjqdiQIcBBIBCAAGBQJXe+cvAAoJEH+zxRJjw92v KTcP/30Jzpd/0WplsS891bNkYoIdzNZGYPjY0OPJiKpkmS88LvTEE5+9ZzlHcgZ5 JhJvm7GL4jT0IWvd8GMeItoqCyjUl8g2tXQW0JaInUJtG905HlPuWvwje69jmrkX jb3OFYFbqcWnlMhE6BVv0Z0IoW7te82ZMKk5iqJUN4Xf/9T/ZxRnHGFPxuA0FKJ7 gcwlerjiCmeNygQPL5uJ5PLgFtDzSyRzmlTPr7g4C6sf6+9N0RNWGnm7zQtyLl03 16UBwhjGv4CUKcRpqi45Sgwut5NZWAJOYAKZH49+vkTwIlmKRr6N4tBF0615cHoa kSaGAPJTbMJOy3L0hV3yroKJjLQrR+LyVDS9bIBPLaVoUA+9yvKt3B1yzyAt05NC H/u4d8XZ2QKyy0K1xFhbCKEXEAyxlZiYctAcp5frjbk8JiUU7zFH12ZNDw7vlHY2 itqw77d/IvyvQ5DmuZU9/TNMlf0V9VtvOnI15ynax0aeJQvUDfbKBbhLgs4I4kim JfsSmqCxmicL6MTQJnbri5rlYrbK4jRX/m4tT0hHwwQR6udtUPQ+bt44RmaHxrth zmswjhoWbNONUkPzj9T/Pi448cEhKRrECRXRE/O6KgKQpDMuNyBDgdA7TiCkla3R OOkAWTABgNSsrLDZFaMxCh9DVP4Bjpo85Le50vKlr2CL3CjeiQEzBBABCgAdFiEE 67uJIQ52iILmzp8Szf3jCQ8RqFAFAloRcs0ACgkQzf3jCQ8RqFBSAAf5AQA0ydPY vtKppM1eWZXp7WKUsF41JbYZ6mBivUuOExXkdQXqTI3oz3Cjod71S8xLAyBGRN05 PQlw58nMkVBs1M4B/QjhdyaEfMBnC4AW62YnEYacXwctiN5IgI2cKXw6OnPoZS+b v2o+WUgD8GYRiWo9n48qa+wQ/nw+t7aM17Dq5nmMtWhMixWhPLj8VLdwt1pw5nyZ eh7WzoAEozksgbAYoU/JtSxmn9NNxPcJL1IEtMzQfAkHGW9lUQgvVmRvbRaF3k8E Or8LlcuNBgVHJrnktcJin5A+rloEeVfQjCL5RUcPXZkYBn5Tus5VLNm+chRkRkcv O4KH+hzJu8IPhIkCMwQQAQgAHRYhBOSm1kc+nalhW5hsG137/dXwIyEQBQJbKyeM AAoJEF37/dXwIyEQ7gMP/1q57kla31Qqz3Nzf4D2MDScPfkFJ2KRaerPnvHjSwVX IEh5c4Ov75UDgzQRm1SYHPPuYb9VQ9dVFMT61BCsNgWi41Cso+zv64S1e2KEmrc0 7vpUKHv8yHhzPWpUXG46fQg0cYX58khQRteiohtYyMMGjOWqLS4OW7hIpjh9G46L cGIcNeHilVLGZOZxrLRyROw0LKSHEJDEabx0QFyyPjtV6g2oqXbKwvphHyzm6wsC WJCGkXZLZC76PzkMbsbwEjzm+RVLF5Y6VMS5PGA4ETUGcEmcpI6HQdykVcRhi3PS O+VrGLJtjcK8M7EHqrphgwp6puwiqFUx3MT2swJq8k9o3uz7PeDL07Tlfj1a38KL cLnwf5jcMjExjIvy+8IIIbi5USWOOjItSKETUng/9XtBuQMjszW8KCJvN9deQiOe U6ZmISXOXXtk06S60f3nXVFVL+mC+6wdtUskcfR8oyrb3+8RoKyvHSMOE4Xm57AO aISVOLehlVRIvelb9hw0bX8VtcF9mrNXt3rfZypcukpvYu6ps8suQnvPXY458eCf WtAAfO4ddna7qDiE/gMb4DT3doMMDGZFbWAne18DC28nv12Tf1HYm4mPHnrd52jn WjjcF4TyunD3ujcXv7ZThAMqAAoNT/g78MgGLGUXyJPOeC2jsWf5jOCYrGmEYLO0 iQIzBBABCgAdFiEEsCfaSQV5gVpBDUL9pIWg7VG4t8QFAlsFbwkACgkQpIWg7VG4 t8RiRhAAkgfigj0N7kdxfkFaf+IhyQzWRWacF4ydazr49mP2kFl6v5z6x4/sXCK8 6Pa8+CFSu86mvddFYacfnHmpqWCVfUOyZTiHKt1VNGa/e5+XKVs6hsbuFEpxnCvP jklKNht4fc5uCQE8N1AZAxf6QY3esBxoY10kOQsAXY63UZFmdwSKtEM4sTJd4LO8 2YDfMgqDoL75L26Pra7UhPlYkixk2UndcImz7VHzWotcD0hhOVEeq21xcfFfIif/ fZzDfb6snBOoePBMCEQA4bL7fYFid8Kqdj0+SZkD3ufwBc2HuXxWk2F7IWoX47KB vjNPKLaHmS2y2LwB0GPTYlxLK0oufvxW7bM5EusOyUdpbxtwogB5eDTDkA0xBPFt OUQ0X3TsgCm43hPmJtM6LbeDU0MXT0mmAqmiyaJ0LbtPZzffjKzcHssE3HxIfcJe URtdXxvPxpvpTaR0fwdxQjlGs6bEK6cHDmsD5Z+0u05AObrZv+e1mLsxAtTtBay8 CUaRcFrBDvZmDQlANJ/xxRm2tHHa1uxAO2VCmIlesJ60k5O8cCEiwdWZTobkwWhE 4aVCDEtv+qt6W9vMurfy2yB5N59vxFtvwUqLO+r49OC9Xy7Z289VQXtIdVVhtLii j7aLNd4Wvke8yJp1BiLhZiVJTN6fNWfXVhMM8J5Vz+LUVQ1Ynwa0Qkhlcm7Dom5p IE1hcnF1ZXMgKHDiiaFwIHByb2plY3QpIDxoZXJuYW5pLm1hcnF1ZXNAcGVwLXBy b2plY3Qub3JnPokCOQQTAQgAIwUCVyc6hgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMB Ah4BAheAAAoJEMtXOGUnaPfprZcQAL4wyuQHrMUb56gfvipTZNAV0YQopEeUtJlN PT3MDYTyD4AiTDmsDZwYaPI7O5m2bNSeLOmhAdqkUXhUOvEIWI0ABqkWVHL93nSE zFiI5HYIbmh0UqpYf0myXQdWE1qjN6n1xnqk1mmZ7RSuIJ/9zwliiX5Qyr/RVfxO VU3iBskn5iwGNs0N2anU6oA6EoD3VsuV650aIJN1c1e7bOd0QT4Z+FuYHPqsuZ/g nbD7AKJIrpO/DoWMG/Ayzw3M746Ff6GKlQFaCmMja6pkfX8NqylbPY+lDlznu9LY XK3z/7gcNSZL3y53d1G5DvbK33sDXpHEpQOVbl6cAR6cgN0jyjh5Pg4VXKWTntAM lK9E/f+3HmH7EILxF6x9kl/TJet94igOvAU3v6Ktd3CPhc2XLvp6oik7NbE4hOFm kgJYq1pW9hffzh9NGzF5l10r9Z4j0bvxbbqXZCsn2/WvK4FhidZhyHgceM/kbH6j ZdOEZPw+Kxxlfsy4CeNDexas2OO1coz68lBiO6uD9+QgoV207hy4D5txTRF3YnR3 TDdPbxiXnA8T/xNKOfMvWzfT4pmsuQdK9+DLmDPHDCZli3/5fLh2B2tb/r/SxLRN EaJjLEzbgPxxH53G5FOvjGR4isUbsZz0n2K2KZSxzVAEpkG1qmMhtGM4KZB2l+KT HBpxzElRiQIcBBIBCAAGBQJXe+cvAAoJEH+zxRJjw92vLwsP/RnUNo/RJim4FlBb Q9l5sbcpaCMyEKRMv0YYLT6QpoNziseauPxpQ1ITLeruwuq4C7ZkTNy+sj9NsC4R 360YR0Dl10rLmYEM49gPOO5RQXpJFQsmpwZRFqFN0Ct2lIFYD3XhMyH8/yV+DPJ9 EafZQlC9L6+Q+up9iK1JdnqisdPGHduXK9sApujb6lkS8kF3PV2BitdLTgsVk0tG rs182FkgQ68rMpubCB/IUkTuuU58VWKGfsXhrndxRb9g7l2/6S+1MWUXochI5Bl3 D/XtemP9aIL21EApXj32/rfczx/y34okbs1ePPGJDTC2Qwprkcna5VPQWOE0Aq+I c/Dy3GPWT67IfblVV3/iar7z01L8nKkCBWx3VVLOFgVpOeGKEjttHlqK+xaamIgH KRi4blqXGXIT19RQ8o/krDV3U1EOC/vLQn168vGJ3iOI/zISEG6Va0hYAV10ebhG i7S9VIrZ9qM4gA26RhP0i4JtxPo0gjdbtUMosTxBrDKLZyAqgRn2eNOaRz/aO0xt j/HrUbUVyDZANaVf69rn03yejq1/pNrDHfPwPma3TmEBM1ieZ1ciGT9uwnIQOde5 pNsYGk6B5M85ZgDgj9YaPrKobL1lDcq7KddAks/L+SHWI9o1jj799FJJwukwTUsP e4LRmxnydcdD3O0O7RzdwurQV1jjiQEzBBABCgAdFiEE67uJIQ52iILmzp8Szf3j CQ8RqFAFAloRcs0ACgkQzf3jCQ8RqFCDAggA0p9oMz9h0DODfzcKxjgJxonnyYhK E9ZP1dNB7b+NSsRShQIUL5VQwoU+ZxHFUH4dbl9NPc4fnFRtfjEkou08tpf6g5cP wK3+26nDTD71xdtDkt1LDvCtVpEDFdw/2BSJlMFX3xrv+ew2qXdW6yEUdxgtpLWv QVuGGQFx27UuqMu8RnOs9cVwBOs8E0dv8+NZG3mE1ubo3wiUmr6nUD5hQarmu5q0 Gq0A0f1ZmyQPgyRmdsVFO2VGASv7pmLvzIyaAI7Jx6fWzdJFpQpZYQ8emGCGqbyG N82n4RAsZv8b/wQM0nC58g0zTVqdIUhtt/EbTghOD8ayKyWx0ht6Rf8dh4kCMwQQ AQgAHRYhBOSm1kc+nalhW5hsG137/dXwIyEQBQJbKyeMAAoJEF37/dXwIyEQPhcP /2H+uYxE15a3Qhei1e133v/t1mCs1MBmpjA3urc2WsyPE3goKFH4p58SLxHImL8A eT74eC2MiM9q6B8TFpgYBv1R0b2tBQptzp8tOFKRxmITkZI9TlX4cft1mSFVN/Mt n3iLr9uswTeQ4Obl6SIlMJtV2tEgspy39nBO49a57INw7BuTnJajHrhznTb4txoa eXp+JNparqKbPAN16xoZb1NH+0UK2nPXRAdDWmujl67km0OzjWOdJdPxlZBnSOhh w8KC/DUBbLcEZ8XfbFMqNXXpTOGlCcBPpCfpxeDRR0Avk1A9OBbnklTJ4s9gpEVv 73BLWLOPZmFz49dOFrZLiCieJZHfBWdcWS86cizCSdDAOqIsbQcWJMDVlSyaYXhF kbvPuf06apTeuaa+MjXK9b38/ITAug5QSoqcKEbHW29++5GNGE8jayFFh90iUFGv a41T/Tl+EcKy3D2eWKCYOzVtd7GvxubdMddztZZitEO3rJD1exXSeORkFh1ezMI6 aVxzrt/wxWbNkTEetUAqWukmocAWyvCU9LkkHr3w+fFTl9mCI4F3xUwglWoP010g SEdxdahBf5QuJcbj1vFWkNg+9/Yq2ZoBgiuJPevPe1adOh/dySso3xepGmCmEHgI FurFtUVO94i46Zzw5zT371eB347ICplRFLC9YdIrbYrgiQIzBBABCgAdFiEEsCfa SQV5gVpBDUL9pIWg7VG4t8QFAlsFbwoACgkQpIWg7VG4t8QMew//R7/9Whv7E2ya i7wp34pYE9Hi4hCH/q+5ShqO5dAL7iLrFbnPCaFl//fgJB5z61Ku+QP/xrxCQocy akGZyxv5nJzktOn2xs68rK6l3VqUB8j3bUxIJC+Ftq1W7gV3klzqFDovDwqGVCbO 0KFQRrQbu/X3z6XYoftRH11aaqcRR8Nl69pZBWYXQSlGP7r4Yw8eJC1f0TX2SgDs P3XKrm5xbzlNCW2vAhjPpnI8OGlvzuZ4i0OVElrEDci6mq0aBYAoBOesxtoEJF+r bQORIVadO5fCiTnen9GNT8UIz5jDay+eYtR+q6kyIP75pXWurOzD8gkvKU3rQlM3 aZJsCH5HZ4bojPIyKebAlu7iHZRIFuwDJPf0TCRGHTWzX+y1kCm5NiJ2+PFggD4k qLTOGVy8b99O9eLEtwfmF9MZ2zIroQh248PdEVCn7SxTyhVeYGtjQ3yqGkqi8xTb v9hTvU/mLR72pB5LtAMn07gKGpPLC4Mjiex9HrXJArfIWnjD8tQDUbL736csWnDP nISrVNn7eOf7WUUUTOUZPrX4fBnSZ1TQ3bTa6zDWu/KetBPrZU9sdZduqOQqahKt BaLNh0jzornidTsVDUiDYTDB/ITDOsW1MkpVgG8+S9lhFkVWYdLIGHabxAH7KGZ/ 6D4WNsXvdV7AXT+1PLho/o3jYdW1ZYK0L0hlcm5hbmkgTWFycXVlcyAocEVwKSA8 aGVybmFuaUBwZXAtcHJvamVjdC5vcmc+iEYEExECAAYFAlXv90AACgkQe4NuQfer nOXY6ACfXZdspV/S6yD97EO/y07E7M9Ovx4An1vhAUJL8FrLDnMTcXLrnSjCSd8k iQIcBBABAgAGBQJV8JbTAAoJED2DTY0Y+Ak0aj4P/R7DmS63uEPDx0AMg+kdppId 8K77tOyR1DFSxuuD/jC+aJDmVm8UEO1uq+0EddVDU6PbG09FF2UvnC6IGp/qGmdH x1ByWCCcAtqRWLwP5zfwApAUUGkA9OtprpsJFrBJLvj6c7KtKlH+FSxheYPI69AI HEqnBLtCL85v8ml9VmkvAP7b3tn4gs0WLFtiVi4DtXzP4StB2SFKmSC0Gh4HbSBv D8WarJAq+0zS6XjeYg0mk3Ng/jK9ThiwMI0KUY5hYss8Utye9WjCaFGYw7uszR4X oV+Es4aFtvfUfxqSXY6nYLsSIy/YPwMaJm1XlC1W32v88J2X0ssSfDWSNQsDnTII PQXh5cUs8tTVLoA+ooW1K/16xIg0uOjSrVvhLl6SZQSqEExEe9EQ/AaaxaOh2nul 7VA80+pvums0A7AHHIq95dYhsvRNphs+EFDhrPtxSxaaVb0GCfTzO70mX231J2gS noFXyqTvLpWaKYwth7alJPl1mPB5vv67hJ+d+23GW3qTC76HLP9zVFf1V2+CTNon 7yL6la8fKKOaJK1BOIe0kRwpvOGAdwQN86S8UwaY2keVW4HyyRSdv0d4aF5vpBna ZGYLBmUpBAgwNgcTrE4jDxEkEeIiG9c6vveZdw5ECwG8QCQYpBGV2O25ClvZ1YRo vyjPenhMDq8j/zLiqPuZiQIcBBABCAAGBQJV7/dOAAoJEEtKJCPQQcY9yZAP/2eD Br1HyewzQJMIyKgkRtYngg2doM0Py6+c/NFP6/JSRMnMz5EK9U6gaCuYIV6o54JC F1/bQTGwA2yq2/1dATIMMjs++cCemsktJijN+lixw97s3YxLBMGI/PvS3TcvmPph 8mGigKiT3bVTT7EI1SXctfN8iRdPEwLTPvtXFKoSIeI+BAfijCqcO4SFE+179m3O 8yAJEiTwvz71RlrOXyEXiv1c8/6HwQVUlbQwHYA0gK+YdyymJV3pAl09NgdkjBnY sytvkO3VDDI2RMMq+giaBHqqJpHToYPIyGKzqXyx67oa4C05kaHZEawYY8M+jNxO LWR3K0WYYLRbYn5syhh4QyIAfginijgq8vC8QiFTVFMxaDdCjXvbDVjYUtBJAtqv mRW+Md8B2mAB5kyWI+Xv7J3OIMX4Rg/anh3qTDpo9k2gHu4PWaF2DG2zSUG5TeJF DCE5BNyusmP/YO1Q92gUahHk5NUOuZvWWh3DlZbMjwW1NnsLpnIY+OP5XsI5NIcY /hHtgtcqs8Ur7kCPHOjMr5wiC9hJmiXxl8C6zHPPmYdd5NmqkeRA118IIdYInuiD ZbltqmtSCRCfY70CoQxItBb2GkwZvMohWHpkWXqfaKz91m5tLloIf35s0moSLxV3 +kyxb0wwR614YpzVaga0MUUMzRihyC8XUKxJ8Z8wiQI5BBMBCAAjBQJVqM5RAhsj BwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQy1c4ZSdo9+nDaw//dgR+2wW/ zew8sFyWwDkcU1GvgWxfNtG/0XuCsOyqe95yAPwi3BQnQb9n/S6pcI8p5yerqY2F FmJf4C02QaIyV7rFxYjaRpwCL8vrUY/JdaiGzLt3jZ6P4Urb+XIpJxOD3v1cEBcY kIJ/IahpVTRG33OUfI44HfT3VgLiBJiQwnaLuOx2nuWqq9PAzqg+cRCRLvleWJMM p6y9h2srzsxNwXm2UE1WrTJwaakYM5jn53ke+RonKF9R4lySe8w8hw5uwfrvi/KF N6NdptCDa5SGJbI4UTPhPZfDvZd2+1eEHx4gY0k6sY/weobR+F6OjJdXubafRf21 pgH5WoWtGdP1Z6hK1owfMuEQC86AshcZ7lsM9WQTR9XpIBK8KUABO2Cyu6exgi6F DmoeZwDGh8KvQPgIDhgOGdFBt1tFoQqsc8UqR23D1bwPYc7xfTGroWbKRg24oj2T vDmg+DO4ad+0Ff/xWkoRpIA5ohfirgyt6WxvJonxSPHh9QVoYdBbazWuaYl/wGcQ Se3INKLdOrskAFJ4DQ7n8lQlL1ritIy++yx21hJIC0EPQ3zJlO12N2FoV989um/Q 8qa41uNfUWzQ04kM9YrCtKiFcNaqvfqi23lqnf/fB//m6mAo1HwAqiqMIXSGY9LY vdL4s2eqVljx6iaF/1gDWBI3j3JH7aECN7uJAjwEEwEIACYCGyMHCwkIBwMCAQYV CAIJCgsEFgIDAQIeAQIXgAUCVl+KiQIZAQAKCRDLVzhlJ2j36WtOD/0U7IpbNx5e 22TRrdydSminsBCRAL0V8T1BDMU5bhUeTVkpOUftXVCs6vNTl9p13wLvWgdt/vl9 VOWY21yX04TR+fHRPob4Uq9PIlX5b0shFuw17z6rt5FG1/8eyNB1uUQiqR1SUCFV GAKMEjor+t4xhWjPkXFIaggyN/F2zUreRAgLFL6677NGbp9/xW5YcxIRILfgjGUi 98F/e9s9idQ+G7gKfRRPEfemYeaT614nW4VaJf3wcDEOm/Rmhso1r2KZxIIqFhOp 2bz1cFc0PTVtR3jjDdEKZKqDMRChGLQmP6J6DhdKf3yU4i0gE8TamL3Y2yR1Imvs Ln77R873GvNRFmOoaIQ+aJ6Bb44y+cjpf07ZIHNdhTsYGKqmmtaxr/LRYpEnw76Q RXMZQjUGeB6q9nnZAcY32/laeGjSC8BaCICYNWfqffJ9ycj5IEkea/L4ibpMjxo1 Jfgb3FCNW6Qz+JbKOw3MDLGO12Ru44GIoA4AMOpMLf0fCwagde4ojMRkwZMXHu8D XK62iC2Dwx9SypfXwiW3ynq/520kljXgzMX1/JUh9WvzcVzQg+6/d/n37tVA9jgA 72tQ35tyOCB0pj2l4saLNxPWaxZ7DhvIgiNTf0R8LHWiN9iQMWZXp9A4w4tZPrZG AiLI5FEojQxrYuesdSo8NTqRYzvyyRUf54kCHAQSAQgABgUCV3vnLwAKCRB/s8US Y8PdrySjEACOgZ2cM2KkHLA2/2XlBbSl0p6xTBIo0DiXF8i5LAMvDtlNpuYwcfpY FmM2ZxvDuuiS+5JXn6eOuQUbWpO6bL4le2eJPt1ugSv+VeSJu7YQQHzPRA1KEzGb cJ/rwdGwZBGUDCCWeoOdkQ6S/kAZZiPGo59FEIoIgYIYdmQphUrcrwNT7T2J9oDG 5HYosm48zNjAPyahmQGXITNPkWE5vqFUIb24cF4JlxrKsyxMWE4pThjkYpM2CwTj HoVtmgYIWFPDHUwaSgK/NJw+HGZ6zmSmv8BRmDBqx4dZ+xoLleAOqOLceG7bV7oT Pg2QfdnUJQcsQfMah3GkonYSRZWLmh9LMP7X0wjcDSrBSAN0ZU0wM/ST1K/Aw+eA DmzqGG3uwP7qa1Ke4fCI0s1mTf1C3uwdRiDgBBEIjDNStC4nQ9S0UjOjH6kxBxUi BUzmvDGc1upT6JaBIF5p1zc98CvrIXeAnLxTuk3slKOIS6E1a7zdw+bfO4ghWEPC MkpDOz6s26czg+2K2FiWgSCmgbm0y1srmogYhCLF12WpdxRC2iIDeAVc7rFCN6op YkyfGn2r5wH4uEquiZkQ2WOPwzRQK3MHhQa7hQh4MYoA+xlQIePAvctOHIr70S0s f3ujP9D0iBcf1wRbgqyKxy3cwCxytrb0w8AK3bFNEpSJfM1UGWFwBokBMwQQAQoA HRYhBOu7iSEOdoiC5s6fEs394wkPEahQBQJaEXLNAAoJEM394wkPEahQ6mAH/AmU HATY4PTdnb0u7570HgcXmbnWqdKNBDkwrabsZkY+MhZ7EKoUmPMrvfib9laK8ZoQ Hgdh1tJYx9ftEu8eEpg9mUB9lcAx9Z1OK7az13MkwTfo6dztrY9eIHcHHCzb4Hc5 sulJylSAQXgS0eRIqF0kuNgWtjC113PPN9B6OzJXR63MEuMnQJXvkjodh0L5p28u 1v/2aAIFOvxceuCf07s6AxJgo0gC0H5/8BK6enAH5/DWkuEi03NfrJcENJBPyJH5 PnXUZSqz+QXv97QK03M8YZwJigYKPTl/3146PFhw/3MiUXb9Zm4DKWwyiGSFPPAs sA11Q8dEcvvX3Wdl88aJAjMEEAEIAB0WIQTkptZHPp2pYVuYbBtd+/3V8CMhEAUC WysnjAAKCRBd+/3V8CMhEOXkD/9H/AyPwJgKkUA1WwutV3v6j6Urg0f61atDxcWt 5D6+si4eLZUYfmRKWmxDCUaaxnLB2VPcRU04krj4rjxCtEmLQuDZwYagh0U7CPEZ ruf91KOSZGKQbSqkjxvxim7ok59TAuXn86i+5CBGHEf+4m2YpPIn8Y04O5arbwAg +4qBHGhUygV7Yoi8rdM+6R1olHESEGbb4fjhHZo9241qFhBNGgXtSNy7vqpL4Jt/ /bjW92liPH0TSrhFmlob6O8Y7QCQzd0YD7dYXxFQB0Nmvh6fruoUrCkbqG+SuduG NGGleRFl8LtiauV7jFwHwYxWC37kXWaGahqlcxGuA4LsbWxTQK788KDJNdBq/zHn hr+1g5Gu6d0ei/oXlTDuEG1FVc2LB17/UVhq1JWlcGB8OGFM/Amn81wAqEhFHoCs rrjzqhnwSA0TFGpZH6sMRw7VHxns8tib+4O/0MMxq0dYgngrAKGwPMU2TsiDeZr9 ttqvEtirNOH5O0Pkbs0DwBG80sPOxWvdsToZPt2dSgMSAQNDK0wrJtJT3S4m7mOn 1XAlYoMxjRBgx7TLz6rP366DpKNc0widcWfEex9C0FNVT3T/ZogtQ4IvtJob2Vj/ T//Od6jv8L0QsUz9kBp690oPCg9tuMboQchcKok2m7LZersEa0DL5wRKM/grLELL dbfcUokCMwQQAQoAHRYhBLAn2kkFeYFaQQ1C/aSFoO1RuLfEBQJbBW8KAAoJEKSF oO1RuLfEAOUP/0w5FN5SUWWqTxrQD6UcY6POmbji7u1My34eeApx3u6y/Nmyqjq2 SVnNbi9SQ5/rRHIh/Sd+v4a/MAYYiS/r90NBnTcx+9i6XK1UmFVOX+k/UEYcC1db LIm8TE402Ah/NlU0D6bfFTjgLLOFposNZUlutPWZaIeI23QbQC2bG9EzLRn2oDam +A1axTeWbmhYaCsdkTxwVOR2DGmd2H+6lbP1cVZZlOM7+hr3+CRuU1j96GFBViJd kyZiXpdthLDJNpCKHJ5FsQDjzAHsaPsikipZ+LGXE3PFJd/9nfNJZRbhnZBHYhho He6p/27S6YIC2F7GqKo4O32oXD/45B4phxvWknlauSm2n7Gpikde/4ek3Iiiu8tc gd0jmv6KlguNs/EXQUwFOptLvjGUOAbDcRRh+tMGVu0MR74UbIAsJYUm8Kh2lvZv mmP7uZ2qFS3vG1cEX7DpMzR0F4LlkXqWaniLmkl1gdzX3moK3gHL75Bd5B3ql7O9 Bxctbz0qH30FVaTjN2LiaESTV18dUmWmmxzoAxeHBQCr1aDr5BmU3lqeF0/pVRb0 yestKQ9lFH/uanGdZl7Axq9BltZn5iwsfodGWDZwv7Bqi73+6P+wjmYLjx6SBHgy hEvMjwdXNC/PSUHrRJ9OlCO4/j8OW/8bRTQQRE0m3NpoZlskmES28owYtD5IZXJu YW5pIE1hcnF1ZXMgKHBFcCBDb3VuY2lsKSA8aGVybmFuaS5tYXJxdWVzQHBlcC5m b3VuZGF0aW9uPokCOQQTAQgAIwUCVl+KfgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMB Ah4BAheAAAoJEMtXOGUnaPfpbHcP/RGtMtp9CJ3cocPEWgu7vy7vjleWtNwE4lrl der8mBV4iWlUwopXbHFwkaUkR60/OM5OHmH+srEbs5V2VHINNPZxepWo7sw5uhOu mSV5KCJxqcBHBjMeaHVHkisXGmeSEL3hFsiWoS2x3+BYELbNq/AbAoZKEhL4caIw YR0E+RWMXWDXCp6zY+t1GcPscE24P+/T1jowdeNThMDTk+K4IF0meu8PDtSbTLTB mAICNiohyMVD67hLnYiSPA711GpF/SyUU6SZ6kmnIJAv2oS/Juf/+3j64lDthUem Xg5Bqec+oOffpYq7iYTnJm46a+8AKOoVc3ZKS0/KruLrqGljP5EWshCn4ZVI9Egn Bu+dbnExPsh/RzEQQ1Ff/H4VbqC7BB56uPfyf3Fce6q9cuBHww2jfM1vCC3uL3Gc BoGw9JSOa+rXstmMr8FRCgxHtbyImq20bB2vuoWl/POUgMqKCH3aig3J+jRjNdgF QDziHtvtkOxmVegAAg/o+xll/44jWleB8Cdv0rDQRT8Nv5Q6MLB54RXb8BETsp0Z RhtxWxzBieR6zYUCVlmQzxeNIQ6biaUEVLnObszs0FKbWoPZuYH8QkDUFwrZSKSC dwnZSSYz853SB5LVev3qNsYgJ9uG9sgXogZyoxE+jhOYrMAHeAztwYwCkwWGJqg9 jjAvkAs0iQIcBBIBCAAGBQJXe+cvAAoJEH+zxRJjw92vcP4QAJzEiKzKCFYJP6O1 5cof/U0d1k0bJnMTN1Zs/iiOIcwl3XvSSvGvr62TIUh/2QQWpxT0KJbu80W4+/jH mP4OHCWQ7LhwTNfr4cI8cBT1l0QVnTWRSSM89eDxdU1Rm7GkMNq/aunIOruuKWWA Nxv7HH3EcTzLG0J1Qc9C4O39ia2r905LsL45yqZ2XNImekLiMgMFHbYfE2O8t4V2 OelcE9a67Th11xNESmg3wqMnqfK0Rv/qoYmU9Vhs6uywwCHgkeQ3ZXgmk/m1zLCt Tel5Noper143nbxjrZddiPSIKgt9LaqiTKVq0W9ShV+tJeqAjmKqwKsrGo39QRSX g5omYKcS3Hjyw/V68zR6iqyu2UVRpnO2ikr8SMlka6K2A4eNjBLcPG/5OmZF3R9s pPj2VDwzDVxlZOqOJDYVdINMS/JSKgpPjqPNtxdI02HGrH970XtTsbCjybh/iDTi TAJJmFL4v0Dis/6cnCSz2nTfz1biw/8k5HX5zz/a3I+97kKY4ME3xvDe11YJmK22 Jk9tT1lOHB6a1AFXsRATGkLWs+5N+64H6o2ciHxhc6wQFQUZpw5v/imYneEpx7yD EKguVGmRSJsX2GXIEmObKi4zSZomkyqSgXBP77LO4cmb7JsL5cU+udgjb3bWEnoQ zvxfS2QZSGaI7+UTu02pSEaUwhEUiQEzBBABCgAdFiEE67uJIQ52iILmzp8Szf3j CQ8RqFAFAloRcs0ACgkQzf3jCQ8RqFCwOAf9H/HkupX0eDhrABex2x8krTUf5KQk IwiBxiQ5xpFM09rXhNmy3U/qSYCC9IW3veWBFdH18lXrS5nwUkOqsGGWQ7uPLggS Q1NJRjjjmCa6V64SDS2qu85N3c/hu+aAzJaoD9v8ku2fV3GPD3vcmzoo4vCKtIhH OWj5ZezothKVakAYLi40F26J9NNBlX+a0pkBFlxRt1TUurxHMUd3NX56E5I08b3s m0XGIl51RFDU6a6QFSa1XvTCl3pYb7HCLF7O0v2qefQ/oFx/x7Tul1J6ysor+1FO viAMVDyzcmDrZSN4nGBqLuiF+zvKdcOgth2/3MxKFJnhNz8WYisueIjL5IkCMwQQ AQgAHRYhBOSm1kc+nalhW5hsG137/dXwIyEQBQJbKyeMAAoJEF37/dXwIyEQAmUP /1Z2EnfcGbi+bGeTsEgWj4X8FA+2ji3T3cvgZIJQCE7Sjbr1nqw3p2SvcH/8rGbI OrQ4wI9FWPZ3pJmzSRDEkqac3Le34yoOVttmiE3RzGsodskgwtAu6NKDAtA9qMUv PyQ/Q/QU4ecshuAc4Lg9l4+x0DUOnNeymIgHfJPT+lFnuUz7tLCPhznY6utGHT9A SA6rr23CR8H+pM1xtSh6tAID/lBzkmGG5Qk0nKfJYOUP2Juy8aO0gcRmUMpJgruk Z42zPKXqO7Ks7JCSGJZR01ApTxhwn1nUfr4fKpWiQ1GnQJnJuH6XEqN4r6Tdiikf bCq6efCQfw/SnYT3X8TSUy0eleLaiHy/ZIhO/eYwXC+B3D0sNYhMV9Iki415Oez4 o3hbTzeLGlqhdWe8PO9yvDD4OtBo7g0N8obFxYFsvQ0hMB/bRpUzRYQoZ1JQoH3H xcb1aqQnH5/uQQh6JAzEi0LwIS7hhcxesrW5s0C3LO79Ea9yXEPqhzZYnlBPXCWr VVNm3porafNh7XqqKiqFEWH/cl6g9rLngN8Uw3atqWWgs4rvHaHjP65z8mgDzMCv DHpjy4U/veuC2wL11ksurc8Ca5PSzyZHQGUEnx3yTF5cstcHROg+XgrQjSuZQSMB upn3OlNPM1w2htnpQxXdk6vx0iqPGoat94p0RwVLTPCHiQIzBBABCgAdFiEEsCfa SQV5gVpBDUL9pIWg7VG4t8QFAlsFbwoACgkQpIWg7VG4t8SI+A//eIFjXiwDakkc 037aq16N0gtmcKyN4RRYQh7eeM+Mph7Bx/TRbXi3GfK5GXuUDVyLJOVhN+CcBbN6 bro6UKh5RaZECGJSfuOIh3yHESvhinKGo4Xr1exwZujxlfR6guiLqhKByZ/MKAvt T5x3Luhw2+xWMZ8uJur8rrcDUVmbc0iBKpIPRNdt8ioDdvlmQv5awXoA4qAvq6i8 /NNVgg7eJRXLLvXFrB6LYYp1WaH518sLGFcfkjODetfhef6JPctMibppKON/JtjJ TYtM+Yj47DtpNUCTYQqGKUiYz4uus1aH2vRa9mKQlnvByO3jUl7Ly1cAuEUD2/hT woSQmlB/LWRjxocVYYIF9RmL8axr2OduhpMte5i9PhRgU0NAo/G6RYbLPihgRscs SURfShzq2l4zaxv5KTJAdYwlMYMMLwIrlHxIN+7BbMwGpmgH7EF7+/6nbRkTK0e/ Z55LIxmqMLgalW0NBwR3xn1oKXaijPf9lh3Cujqu2Yh9lKr15fJt7YYVpFRUUST3 Hjkw17JhLt/0f9QXVpP/pPeh/RRjFHF5Aph8TMBcZbywCT5++HRwPRERriG6+MyE KvQR0SnmTwuxWzRlzVvhZFBb3II5qehhrauSX98UJOuWHXrhQk3wW2So2n0FmE8h KmeYTHKrKLEAHtUXf4svBJGzaWZ/f2O5Ag0EVajOUQEQALy+1UBEbXWX5iE1YezJ 1qHy2DtT+0JUHiEMbY2iGO/cV4qXOwC5+w6ASp2Udoy52iHznW6AcktoQF/bf8JC xXGGISJMI0tS+1b61NuKW+vkXDiSgYn5X5V+mjqS4fFmTMoqo5ig4jqIunmEuwLl JxkP30s8tUeGMRzcWSF5MvSKqQu0yXqg7N4MhEzMt4M4dV+I59HyoORJ805VBOFh r8jCtlg4ug0HrySlLqRp20hhKL8lBUA5opyQkMNSbA+I0S5gFq9sZz31lLVC7sYm 6ckap6FBziAwcfnTfnFL4YFfTH4CIdkDFElCZ9318/cSnqbbhilRzvXh8aZfZl5w GntS6cIMJYbbKKGwdsPTkA5IR5yEVH1RbvD/m1d4cu5jqGfTeeRNMIngVirIa7W1 Z49x/tTKykUM6/mheqnzEqbbJsXLrnKN6Y+eu6mJLQgQhj/HNfk09j/wtgo1aRQg L/UVZDVTcuP0MuG9tTeZ39nt6dFaI3+IsTa4QhnDcO1dJ+eYsuCJmVY3CtuZ5Sh3 GcNGk6sX+eeEMkfZ0jN9uwIWqhva5dqvetoO0VMfQyZiAauNxB0cjo2Cpl+xv+vQ HEqPfFcYdY3QCay5Alsn3ttd6Ht+S2IB/BukcO9N+EmYT1HgJkS1c4UR6x512b0N TGRC6yMFAGSshsx3z9DInGvRABEBAAGJAh8EGAEIAAkFAlWozlECGwwACgkQy1c4 ZSdo9+kphw//Sw7Ji9eTyfJHdzRXNa1cA335dY1QYKq9/6eGhSjcyRGz4bHyHUDt 5G5dmKwmaYrPGS3Hr2H1+Z3w9BD5X/V1ZVgsKYYVM18N0CsnarJdcugdwC1difyM zo2NJGz6btuFey6ZiMZo6EQKgsH/0sLChHSLM5sjBgdmWswkWh7L8oNrFv/p091F Vj6rFeda/e7g3xK2NjPSk3+oX5aLgcCrUSeWJCZflyEL6NEf3EOAahzzoqUfN9D6 aTjZWPSmTVTO21t8s86XeSPuYBVGGODyIkCXWJxkm2WXY5AoPLYJWmmm9TwOJE0F gM/nTj04cBNW91q8tCCaCx//2dGfW+EdAMew/G8aa2cJgbF7iJs5IWpMRUxujMM7 rWJdxXjAh6Y3FiVc5UtYO87HmthC953QiJntDTa/72Oi7HrGw/wUtSRm2S9G/jdp XZ7WBaPD0R4/QcXS9590nMfFahWfQs6cdAOtLBJzCL6JMX4sHqaycwxErzd0jvto hCGJW0Ksc8GjTxWtmgBpCVzkTidkWgXICzd7EKE36z5Ir6jvN7NLe4qbPQF+uDWm xQqAK92/Iwt/NBALQ2oWAiHN5j8v2/ObJDuZH5Q4DGzzVmXYAeKjVMyH9Upsutnu 8iYrvghKyC1RKKPPjqzJvcZkDO24NIw8RM1VxPH/3UxXFg+hWD+7KMw=3D =3DbPR0 -----END PGP PUBLIC KEY BLOCK----- --------------16E340BD4169D98D4EA9DE40-- --pRZow2qSeczAvcarTt4kicmrg0ppja6di-- --xa99I1ZUa8pPV2W78rGnnFIwmlrSdFiZl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEMXM+DFmNOhz3CVXWy1c4ZSdo9+kFAlw48QIACgkQy1c4ZSdo 9+ly5Q/+MyIc4YHNDyWKIQyGOPkiF7wwac22lelRtdY/PAHnG5UbzxpSNXxO6Nb/ GBnstAQVMGrRpmsuG8DfvA/qM/0AoO246jfxquvrbeUiHAd3/7UDYd5IrCySBG90 g97pigUJcKVFgIw5xVIXB4Isx4jhNct/b9b3cFm5KlT0A7fGN9NEmQEADEPfHl8Q mAqASAAcBrbJqr9clkdTs+gcQF4/pyZpPCq+Gd+GHmFA0mRCP7RFu1KFjX85B6IZ 9ZUvyJIy+jsxI62kXN1VFy5wpVIuf+AaaM8RMGCxm5wPrGU4wUMkIM7zxLw9RUI7 ImmetOI3DQJvbC9EeT36PO9j3/oWyDr1vuK9riqPDqf+eD6h21Domf1+yf+ELnJH tNKuErE/wQy+6Va+0kHMhVFOJzEKbFy00SYC8R4V3xiCTGLplYbqAjZUrFwYGhAp sLhIRWldddAI50K25ZAxk4WC4XHHJot/p0ELoSa/sWThecD3YzFTI2DHqLY6Qkhc n9Q3jZvxVCJsXHZKZxw5+ZZtqq1V93pjurXvTtjq59tn3srgC/QbI875qnlYbvM5 hzp6fQRi9/BMy38pE7PnZFPhCoKQwTQv7hyG5VYlGKtcWB/fHym0MpTj+XgRJNxK f+dc9ZyQP+7zcZd/70CyZI1TF4Aw8VT0s0d28BNLtCJgf6ifdyU= =H6d1 -----END PGP SIGNATURE----- --xa99I1ZUa8pPV2W78rGnnFIwmlrSdFiZl-- From nobody Fri Jan 11 12:05:53 2019 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 98324128B14 for ; Fri, 11 Jan 2019 12:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWlu6sG1CpUU for ; Fri, 11 Jan 2019 12:05:49 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 78C9E128AFB for ; Fri, 11 Jan 2019 12:05:49 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1gi33p-000183-Kn; Fri, 11 Jan 2019 21:05:45 +0100 Date: Fri, 11 Jan 2019 21:05:45 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Daniel Kahn Gillmor cc: Russ Housley , LAMPS WG In-Reply-To: <87imyvcb3m.fsf@fifthhorseman.net> Message-ID: References: <87bm5hxdn0.fsf@fifthhorseman.net> <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> <87imyvcb3m.fsf@fifthhorseman.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="37663318-23106365-1547237145=:28417" 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] Draft addition of header protection to the LAMPS charter 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, 11 Jan 2019 20:05:52 -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. --37663318-23106365-1547237145=:28417 Content-Type: text/plain; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT Hi Daniel Thanks for your input. Your latest proposal (DKG-2) works for me. As you say, it even fits better to the existing charter text and probably allays the concerns raised by John and Stephen about explit references to (legacy) RFCs. Hernani's small amendment (HM-1) looks even better. I suggest to go forward with the wording HM-1, though DKG-2 is also a viable option for me. cheers, Bernie -- http://ucom.ch/ Modern Telephony Solutions and Tech Consulting for Internet Technology * * * On Fri, 11 Jan 2019, Hernâni Marques (p≡p project) wrote: > --- BEGIN HM-1 --- > > 7. Update the specification for the cryptographic protection of email > headers -- both for signatures and encryption -- to improve the > implementation situation with respect to privacy, security, usability > and interoperability in cryptographically-protected electronic mail. > Most current implementations of cryptographically-protected electronic > mail protect only the body of the message, which leaves significant room > for attacks against otherwise-protected messages. > > --- END HM-1 --- * * * On Fri, 11 Jan 2019, Daniel Kahn Gillmor wrote: > --- BEGIN DKG-2 --- > > 7. Update the specification for the cryptographic protection of e-mail > headers - both for signatures and encryption - to improve the > implementation situation with respect to privacy, security and usability > in cryptographically-protected electronic mail. Most current > implementations of cryptographically-protected electronic mail protect > only the body of the message, which leaves significant room for attacks > against otherwise-protected messages. > > --- END DKG-2 --- --37663318-23106365-1547237145=:28417-- From nobody Fri Jan 11 17:05:51 2019 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 8F85F130E0A for ; Fri, 11 Jan 2019 17:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.554 X-Spam-Level: X-Spam-Status: No, score=-11.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZ6M19qytq0v for ; Fri, 11 Jan 2019 17:05:49 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B801129508 for ; Fri, 11 Jan 2019 17:05:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=rj0vSlpKmzHaxL3sNyc/AFu/8JsuvZhZbqkFv9dTVAU=; b=U/YInj7OAo0XcyTV+OPiN+UIPO Y8aM0oUK/KHX/lMkcM9mg6s98Ylq2sNUYkdTSffAATJ0t5ppUXxRhFCX1/VHKcj7PhmzuL1RtIwWu vLXgoDdkx++eoYZVnrrgYj03JY7cUztosr0/lUliKpSirhEmhIMygANeruPeKPm0x7/A=; Received: ; Fri, 11 Jan 2019 17:05:49 -0800 To: SPASM From: Jacob Hoffman-Andrews Message-ID: <026b92e4-055d-42b4-1448-883a01ddad50@eff.org> Date: Fri, 11 Jan 2019 17:05:48 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [lamps] 6844bis: Merging sections 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, 12 Jan 2019 01:05:51 -0000 In reviewing ekr's AD review for 6844bis, I realized a lot of information was duplicated between Section 3 "The CA RR Type" and Section 5 "Mechanism." I don't see a reason for these to be separate sections, and I think they were behind a number of inconsistencies. I wrote up a change to merge the two. I think this fixes a lot of problems in the spec, but it's a fairly significant change, so I wanted to present this for review before merging into my working copy. Please take a look: https://github.com/jsha/caa-simplification/pull/5 Thanks, Jacob From nobody Sat Jan 12 05:57:33 2019 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 89951130F80 for ; Sat, 12 Jan 2019 05:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OA_K0g4LmEQC for ; Sat, 12 Jan 2019 05:57:30 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06C43130F91 for ; Sat, 12 Jan 2019 05:57:29 -0800 (PST) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 3CB1DF99A; Sat, 12 Jan 2019 08:56:57 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 145E8201EE; Fri, 11 Jan 2019 15:29:50 -0500 (EST) From: Daniel Kahn Gillmor To: =?utf-8?Q?Hern=C3=A2ni_Marques_=28p=E2=89=A1p_project=29?= , spasm@ietf.org, Russ Housley In-Reply-To: <0319e3b2-81b7-13af-df9e-436a15ee1074@pep-project.org> References: <87bm5hxdn0.fsf@fifthhorseman.net> <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> <87imyvcb3m.fsf@fifthhorseman.net> <7DC69A08-3A4E-4D57-B490-179B8E4A411E@vigilsec.com> <0319e3b2-81b7-13af-df9e-436a15ee1074@pep-project.org> Date: Fri, 11 Jan 2019 15:29:49 -0500 Message-ID: <875zuvc4zm.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 12 Jan 2019 13:57:32 -0000 On Fri 2019-01-11 20:39:46 +0100, Hernâni Marques (p≡p project) wrote: > --- BEGIN HM-1 --- > > 7. Update the specification for the cryptographic protection of email > headers -- both for signatures and encryption -- to improve the > implementation situation with respect to privacy, security, usability > and interoperability in cryptographically-protected electronic mail. > Most current implementations of cryptographically-protected electronic > mail protect only the body of the message, which leaves significant room > for attacks against otherwise-protected messages. > > --- END HM-1 --- I'm fine with this text too. Does anyone have an objection to HM-1? can we move forward with working on the actual draft? :) --dkg From nobody Sat Jan 12 08:43:33 2019 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 3A6EE124BAA for ; Sat, 12 Jan 2019 08:43:32 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqdLQ6ivd626 for ; Sat, 12 Jan 2019 08:43:30 -0800 (PST) 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 5982212426E for ; Sat, 12 Jan 2019 08:43:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2DCAA300A81 for ; Sat, 12 Jan 2019 11:25:12 -0500 (EST) 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 NN-4skgYknDA for ; Sat, 12 Jan 2019 11:25:10 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 932B730017E; Sat, 12 Jan 2019 11:25:10 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: <875zuvc4zm.fsf@fifthhorseman.net> Date: Sat, 12 Jan 2019 11:43:27 -0500 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <82ADF5CE-DEE4-4BEB-908E-70D8EB5644FA@vigilsec.com> References: <87bm5hxdn0.fsf@fifthhorseman.net> <1194C123-1234-4B86-8EC1-26CE577CAFDA@vigilsec.com> <87imyvcb3m.fsf@fifthhorseman.net> <7DC69A08-3A4E-4D57-B490-179B8E4A411E@vigilsec.com> <0319e3b2-81b7-13af-df9e-436a15ee1074@pep-project.org> <875zuvc4zm.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Draft addition of header protection to the LAMPS charter 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, 12 Jan 2019 16:43:32 -0000 > On Jan 11, 2019, at 3:29 PM, Daniel Kahn Gillmor = wrote: >=20 > On Fri 2019-01-11 20:39:46 +0100, Hern=C3=A2ni Marques (p=E2=89=A1p = project) wrote: >> --- BEGIN HM-1 --- >>=20 >> 7. Update the specification for the cryptographic protection of email >> headers -- both for signatures and encryption -- to improve the >> implementation situation with respect to privacy, security, usability >> and interoperability in cryptographically-protected electronic mail. >> Most current implementations of cryptographically-protected = electronic >> mail protect only the body of the message, which leaves significant = room >> for attacks against otherwise-protected messages. >>=20 >> --- END HM-1 --- >=20 > I'm fine with this text too. Does anyone have an objection to HM-1? > can we move forward with working on the actual draft? :) The next step is IESG approval of the revised charter. We have an individual draft, and we can continue to work on that, = including discussing issues on this list, while the IESG does the = re-charter process. Russ From nobody Mon Jan 14 07:43:24 2019 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 8AA3C1310DB; Mon, 14 Jan 2019 07:43:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <154748059551.4662.3464847439174630766@ietfa.amsl.com> Date: Mon, 14 Jan 2019 07:43:15 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-07.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, 14 Jan 2019 15:43:16 -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 : Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA using SHAKEs Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-pkix-shake-07.txt Pages : 15 Date : 2019-01-14 Abstract: Digital signatures are used to sign messages, X.509 certificates and CRLs (Certificate Revocation Lists). This document describes the conventions for using the SHAKE function family in Internet X.509 certificates and CRLs as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms. The conventions for the associated subject public keys are also described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-pkix-shake/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-pkix-shake-07 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pkix-shake-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-pkix-shake-07 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 Jan 14 07:43:44 2019 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 D1D67131129; Mon, 14 Jan 2019 07:43:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <154748060882.4799.6385460550778062312@ietfa.amsl.com> Date: Mon, 14 Jan 2019 07:43:28 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-06.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, 14 Jan 2019 15:43:36 -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 : Use of the SHAKE One-way Hash Functions in the Cryptographic Message Syntax (CMS) Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-cms-shakes-06.txt Pages : 16 Date : 2019-01-14 Abstract: This document describes the conventions for using the SHAKE family of hash functions with the Cryptographic Message Syntax (CMS) as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms, as message digests and message authentication codes. The conventions for the associated signer public keys in CMS are also described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-shakes-06 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-shakes-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-shakes-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 14 07:51:58 2019 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 568521310E5; Mon, 14 Jan 2019 07:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.053 X-Spam-Level: X-Spam-Status: No, score=-19.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6x70mGxr5jm; Mon, 14 Jan 2019 07:51:54 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9A721310DC; Mon, 14 Jan 2019 07:51:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2136; q=dns/txt; s=iport; t=1547481114; x=1548690714; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=7HyaoPSX0PnEty3F6AZSai9wqDZzMoMOGOLJX3+1vMM=; b=geHr971Cpz3uZZ5lbMgaFVgPXHlxy70l8TZu4jYgxBt3QWwWOI1Dc4cw Q381IQHGhm+vVL+nZE1CjDpgmK4ic+0UYExCe37S3KNthhqxxne5ggbGP W7RRwhC0nfub0PyHCAfweVgve8M8XmKcEPdTZ6XAJ7aPiuiAu/U1IVofY 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAC9rzxc/5hdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggNmgQInCowRi22CDZd8gXsLAQEYC4R?= =?us-ascii?q?JAoI/IjQJDQEDAQECAQECbRwMhUoBAQEBAwEBODQXBAIBCBEEAQEfECcLHQg?= =?us-ascii?q?CBAESCIMbggEPrn+EMgIOQIUijD8XgUA/gRGDEoMeAQECAQEWgSCGBwKiBAk?= =?us-ascii?q?ChxqKZCCBZE2EWYp1iXWFEYgtgxICERSBJx84gVZwFRohgmwJgh0YiF+FP0E?= =?us-ascii?q?xiBKBLoEfAQE?= X-IronPort-AV: E=Sophos;i="5.56,478,1539648000"; d="scan'208";a="505266601" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jan 2019 15:51:53 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x0EFpr1Y016524 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Jan 2019 15:51:53 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 14 Jan 2019 09:51:52 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1395.000; Mon, 14 Jan 2019 09:51:52 -0600 From: "Panos Kampanakis (pkampana)" To: "spasm@ietf.org" , "lamps-chairs@ietf.org" Thread-Topic: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-06.txt Thread-Index: AQHUrCAt9ndrKNqYTEahXxESumFvCaWu6PgQ Date: Mon, 14 Jan 2019 15:51:52 +0000 Message-ID: <01c8c6823c4a4d6eb12cc29b854ce36b@XCH-ALN-010.cisco.com> References: <154748060882.4799.6385460550778062312@ietfa.amsl.com> In-Reply-To: <154748060882.4799.6385460550778062312@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.249.238] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-06.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: Mon, 14 Jan 2019 15:51:57 -0000 This draft incorporates Eric's AD Review comments for draft-ietf-lamps-pkix= -shake that apply to draft-ietf-lamps-cms-shakes while being under IESG Rev= iew.=20 Thanks, Panos -----Original Message----- From: Spasm On Behalf Of internet-drafts@ietf.org Sent: Monday, January 14, 2019 10:43 AM To: i-d-announce@ietf.org Cc: spasm@ietf.org Subject: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Limited Additional Mechanisms for PKIX and= SMIME WG of the IETF. Title : Use of the SHAKE One-way Hash Functions in the Cr= yptographic Message Syntax (CMS) Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-cms-shakes-06.txt Pages : 16 Date : 2019-01-14 Abstract: This document describes the conventions for using the SHAKE family of hash functions with the Cryptographic Message Syntax (CMS) as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms, as message digests and message authentication codes. The conventions for the associated signer public keys in CMS are also described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-shakes-06 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-shakes-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-shakes-06 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Jan 14 07:52:07 2019 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 DD76A13110B; Mon, 14 Jan 2019 07:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.642 X-Spam-Level: X-Spam-Status: No, score=-14.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR7YB4XqcvYL; Mon, 14 Jan 2019 07:51:58 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C80641310E5; Mon, 14 Jan 2019 07:51:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2157; q=dns/txt; s=iport; t=1547481117; x=1548690717; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=dgjAVELgOxSeOMtsZRRazzCg0HDsJggcYBeY4m5a1MU=; b=PWgYsQhQjH/Lxd2bzK6U8PZ23bwA8lYbyhcCMJhMK9K9lH0Tg6eqTEqv JRvfOkrix5s/KQniLMAvOCe9A5w/7Pkoxvn7ezy4Sp8f5ownRSzyFxxjC JAsv2VZPfpVQ8Yx9+tHDboNFn3F2bUVfRTfMSdEb8K4QNlHFoHTAAb9nw o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAC9rzxc/5JdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggNmgQInCowRi22CDZd8gXsLAQEYC4R?= =?us-ascii?q?JAoI/IjQJDQEDAQECAQECbRwMhUoBAQEBAwEBODQXBAIBCBEEAQEfECcLHQg?= =?us-ascii?q?CBAESCIMbggEPrn+EMgIOQIUijD8XgUA/gRGDEoMeAQECAQEWgSCGBwKiBAk?= =?us-ascii?q?ChxqKZCCBZE2EWYp1iXWFEYgtgxICERSBJx84gVZwFRohgmwJgh0YiF+FP0E?= =?us-ascii?q?xiBKBLoEfAQE?= X-IronPort-AV: E=Sophos;i="5.56,478,1539648000"; d="scan'208";a="225261643" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jan 2019 15:51:53 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x0EFpqv3020133 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Jan 2019 15:51:53 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 14 Jan 2019 09:51:52 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1395.000; Mon, 14 Jan 2019 09:51:52 -0600 From: "Panos Kampanakis (pkampana)" To: "spasm@ietf.org" , "lamps-chairs@ietf.org" Thread-Topic: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-07.txt Thread-Index: AQHUrB/98sVkzK2xFUa5TqQLEZSRG6Wu6CPQ Date: Mon, 14 Jan 2019 15:51:52 +0000 Message-ID: <597fee4e75874e1d84af8bf894b6eb6f@XCH-ALN-010.cisco.com> References: <154748059551.4662.3464847439174630766@ietfa.amsl.com> In-Reply-To: <154748059551.4662.3464847439174630766@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.249.238] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-07.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: Mon, 14 Jan 2019 15:52:05 -0000 This version addresses Eric's AD Review comments while draft-ietf-lamps-pki= x-shake has been under IESG review.=20 Thanks, Panos -----Original Message----- From: Spasm On Behalf Of internet-drafts@ietf.org Sent: Monday, January 14, 2019 10:43 AM To: i-d-announce@ietf.org Cc: spasm@ietf.org Subject: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-07.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Limited Additional Mechanisms for PKIX and= SMIME WG of the IETF. Title : Internet X.509 Public Key Infrastructure: Additio= nal Algorithm Identifiers for RSASSA-PSS and ECDSA using SHAKEs Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-pkix-shake-07.txt Pages : 15 Date : 2019-01-14 Abstract: Digital signatures are used to sign messages, X.509 certificates and CRLs (Certificate Revocation Lists). This document describes the conventions for using the SHAKE function family in Internet X.509 certificates and CRLs as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms. The conventions for the associated subject public keys are also described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-pkix-shake/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-pkix-shake-07 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pkix-shake-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-pkix-shake-07 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Jan 14 09:47:36 2019 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 52CC5131216 for ; Mon, 14 Jan 2019 09:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.554 X-Spam-Level: X-Spam-Status: No, score=-11.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIwth17HtmnT for ; Mon, 14 Jan 2019 09:47:26 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ED9513121C for ; Mon, 14 Jan 2019 09:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:References:To:From:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=9FTiVzemq1l0xsJqFZdVYHZNma9x+tcC7FCExHqeA1g=; b=fkMlzFS+5Juy9AmumEgK9dSmdR m3ftZco6a6O9MHma+xnLrzo544fH0RPOWjkBkRyk7rXFwRBKBx7KyN2oTcyCPK9x/UfCSjrUdlpip Ln8XTzT7kx91FFvBUyX2KV1glvY5a/cX5WZCCHv9Yffk2y6ZIWTKP4nYcqaxfisyhEf0=; Received: ; Mon, 14 Jan 2019 09:47:26 -0800 From: Jacob Hoffman-Andrews To: SPASM References: <026b92e4-055d-42b4-1448-883a01ddad50@eff.org> Message-ID: Date: Mon, 14 Jan 2019 09:47:25 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <026b92e4-055d-42b4-1448-883a01ddad50@eff.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [lamps] 6844bis: Merging sections 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, 14 Jan 2019 17:47:35 -0000 Consider this a Monday reminder to take a look at this change if you missed it last week. Thanks! On 1/11/19 5:05 PM, Jacob Hoffman-Andrews wrote: > In reviewing ekr's AD review for 6844bis, I realized a lot of > information was duplicated between Section 3 "The CA RR Type" and > Section 5 "Mechanism." I don't see a reason for these to be separate > sections, and I think they were behind a number of inconsistencies. > > I wrote up a change to merge the two. I think this fixes a lot of > problems in the spec, but it's a fairly significant change, so I > wanted to present this for review before merging into my working copy. > > Please take a look: > > https://github.com/jsha/caa-simplification/pull/5 > > Thanks, > Jacob From nobody Mon Jan 14 11:16:03 2019 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 CDD2513102B for ; Mon, 14 Jan 2019 11:16:01 -0800 (PST) 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_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZNu708PF5km for ; Mon, 14 Jan 2019 11:15:59 -0800 (PST) Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) (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 BA6EA130FF5 for ; Mon, 14 Jan 2019 11:15:59 -0800 (PST) Received: by mail-oi1-f169.google.com with SMTP id u18so102667oie.10 for ; Mon, 14 Jan 2019 11:15:59 -0800 (PST) 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=nPzL05PhnFtSVDqNtgATbkSqPtUTZFhfAGIcNITH8Tc=; b=M5LEkOarrmE3laG86yie0JDCTlj0MJf0GCV4+WdcraJlcIXhf3X6eUH3jK4J2MEkAV vRjrXuCvqB1Zq58IpVW3+4RImOOAC0Wyh1YB2R3FCi2hAgepwEJalHXc3xXUapPeJk0f +Qs/GXAjVF2TXFXJPF2SkBc2Yq0tn+ACA/eSOuiZxqzJD0K8vpWLJVQ63UXn6SW5v0XD 1hGIyaTOgV3QxBbZ6S/bhW47HjkotLhFRpWSMZg7Yj9aD+qRLpR7zTeXdMmotazNb/ev doLOhrh33IxRU9T6AiB8oBVuakw4Cs+up4/d59jkCca6EHbvOKsaaXaLoe4kKic3c3e+ Ov1w== X-Gm-Message-State: AJcUukdpi/m9xqT1+OEDjp0ZFeuKRSUW360adDb06AuQx+Nx1K0I8yBj w2kHUFERRVsmeLqrN6n+IqbXmgoQTw0ii+Cr4Gs= X-Google-Smtp-Source: ALg8bN7rXEJkoJmDZ3JkUWe1lRJv4hjTorvSiAhulb9yR2WU64yB+Dx0qVr49g0RNnoEKc0uyzlJhv3lSse0JNuKKkk= X-Received: by 2002:aca:1e08:: with SMTP id m8mr16117151oic.347.1547493358900; Mon, 14 Jan 2019 11:15:58 -0800 (PST) MIME-Version: 1.0 References: <026b92e4-055d-42b4-1448-883a01ddad50@eff.org> In-Reply-To: From: Phillip Hallam-Baker Date: Mon, 14 Jan 2019 14:15:49 -0500 Message-ID: To: Jacob Hoffman-Andrews Cc: SPASM Content-Type: multipart/alternative; boundary="000000000000f31da4057f6fdfdf" Archived-At: Subject: Re: [lamps] 6844bis: Merging sections 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, 14 Jan 2019 19:16:02 -0000 --000000000000f31da4057f6fdfdf Content-Type: text/plain; charset="UTF-8" I am reviewing it now. I will just point out that one of the comments I received when writing 6844 was that the sections should be split. On Mon, Jan 14, 2019 at 12:48 PM Jacob Hoffman-Andrews wrote: > Consider this a Monday reminder to take a look at this change if you > missed it last week. Thanks! > > On 1/11/19 5:05 PM, Jacob Hoffman-Andrews wrote: > > In reviewing ekr's AD review for 6844bis, I realized a lot of > > information was duplicated between Section 3 "The CA RR Type" and > > Section 5 "Mechanism." I don't see a reason for these to be separate > > sections, and I think they were behind a number of inconsistencies. > > > > I wrote up a change to merge the two. I think this fixes a lot of > > problems in the spec, but it's a fairly significant change, so I > > wanted to present this for review before merging into my working copy. > > > > Please take a look: > > > > https://github.com/jsha/caa-simplification/pull/5 > > > > Thanks, > > Jacob > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --000000000000f31da4057f6fdfdf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I a= m reviewing it now. I will just point out that one of the comments I receiv= ed when writing 6844 was that the sections should be split.

=
On Mon, Jan 14, 2019 at 12:48 P= M Jacob Hoffman-Andrews <jsha@eff.org> wrote:
Con= sider this a Monday reminder to take a look at this change if you
missed it last week. Thanks!

On 1/11/19 5:05 PM, Jacob Hoffman-Andrews wrote:
> In reviewing ekr's AD review for 6844bis, I realized a lot of
> information was duplicated between Section 3 "The CA RR Type"= ; and
> Section 5 "Mechanism." I don't see a reason for these to= be separate
> sections, and I think they were behind a number of inconsistencies. >
> I wrote up a change to merge the two. I think this fixes a lot of
> problems in the spec, but it's a fairly significant change, so I <= br> > wanted to present this for review before merging into my working copy.=
>
> Please take a look:
>
> https://github.com/jsha/caa-simplification/pul= l/5
>
> Thanks,
> Jacob

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--000000000000f31da4057f6fdfdf-- From nobody Mon Jan 14 11:31:15 2019 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 A0CCC130FD3 for ; Mon, 14 Jan 2019 11:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=comodoca.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 7j10TzFLv3hd for ; Mon, 14 Jan 2019 11:31:10 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740053.outbound.protection.outlook.com [40.107.74.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48E3131257 for ; Mon, 14 Jan 2019 11:31:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector1-sectigo-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c6NrfpJicTfTHAIEqiDQrjsQU5+r1m62fFAySn7lhEM=; b=bOAlN+loUYu6ZjqgFgO4r6SQQOHSk4P80AkWp+wsFBTOsAHo0y/0/C3KlxleT38DwTYCAeoJ+/HDiVaTAU4kwbTzEPDUpjmienAhg0xWeHK77OYJ7Bys9dnFngjYthCinwONuxNj8Ygxl/VZe/zuEMKac1/bnxEB0H5t8lMVZy0= Received: from DM6PR17MB2716.namprd17.prod.outlook.com (20.178.224.155) by DM6PR17MB2282.namprd17.prod.outlook.com (20.176.92.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.18; Mon, 14 Jan 2019 19:31:05 +0000 Received: from DM6PR17MB2716.namprd17.prod.outlook.com ([fe80::600a:76ca:af6f:9a10]) by DM6PR17MB2716.namprd17.prod.outlook.com ([fe80::600a:76ca:af6f:9a10%3]) with mapi id 15.20.1516.019; Mon, 14 Jan 2019 19:31:05 +0000 From: Rob Stradling To: Phillip Hallam-Baker CC: Jacob Hoffman-Andrews , SPASM Thread-Topic: [lamps] 6844bis: Merging sections Thread-Index: AQHUqhL5ib9P35WXpkCU0lqSsNR+2qWvDkSAgAAYs4CAAAQ8AA== Date: Mon, 14 Jan 2019 19:31:05 +0000 Message-ID: <1598a7ed-f3ee-2673-7d32-80993389f372@sectigo.com> References: <026b92e4-055d-42b4-1448-883a01ddad50@eff.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LNXP265CA0080.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:76::20) To DM6PR17MB2716.namprd17.prod.outlook.com (2603:10b6:5:122::27) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rob@sectigo.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [85.255.236.146] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR17MB2282; 6:hBQA384cRCSFuR60qPVKXgh0QFWhprhr1clHOvO0/67hvkDEvwtwDKzUgq/CPfNSrD9hpA3+1L9qdcu/q6g8TQEgZMQUSWXd83N8rysSAi+2OzonpFlqPKkKBtb1K1/KJJO0mJJNsLeLJ8/xqR529zeVBpeZxZDE5EbXYOQUHL4/H5aqSCgEXlTYdrv07ZgiMG9rGxKcEXzAD0v9955SjVqwBTkj2+t/yN7eScX7ftqsZwxBUsTnmbcer+NzbHhYMf0qSVdf0Ph4BXr+IjeIEyY87ChwzCa+Fb3hvdNkaR8gPaQpVHrXsVS0csyxt/W2NFEc0F5NjApcRonD9jL2C4tB3aOstmrsUvxkSN2eRBXIafhovpW6nmfzx1RoqHU4f5p9eadXVvNzwJlInJJ0LC0Xid1ERbLL5Usz0V7pPU6KrZQu/vo2eJRCzZG15E5S7AdLDWiRZGf9J1I1+LM5og==; 5:tNGAUhkfGUTbHkQkFDYlLMm4Xv9w5jTWFM6Le9nwlklYd0Rt1MKloUUdfNb7aql5ZztMeZ5CR6oqwvb/DjQeAtCy0+y6apfo3QFY99oXBaIgrq2bhHDiyLOYo11Wkp62tIMx6dTtJ58ThT0rNsYM50GZjZ2BrkEwxmiL18amW1Hq/sZZqJ863hrN5mqyfIa8O4ZV766SEHbermQxdkGFiw==; 7:UquDJ8b+UOPMMSS70oA2l1y0cblyVyU+nxhqXZ6kjW53aGxdgxnuupxrQJTUKfpmR1jWSp7FjXFtx3tzW00jy+h/7QjY3Q7nn4RQ6CpaonXGKHgfNdYQ8h4CmCC3rYtHG5u+EBdLur5LHa+7PCfviw== x-ms-office365-filtering-correlation-id: ad21d19b-02aa-4d3f-f1dd-08d67a56d373 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM6PR17MB2282; x-ms-traffictypediagnostic: DM6PR17MB2282: x-microsoft-antispam-prvs: x-forefront-prvs: 0917DFAC67 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(346002)(136003)(39850400004)(396003)(189003)(199004)(76176011)(386003)(6506007)(105586002)(53546011)(2906002)(26005)(102836004)(68736007)(97736004)(52116002)(446003)(14454004)(2616005)(8936002)(36756003)(106356001)(478600001)(486006)(476003)(11346002)(6486002)(31686004)(99286004)(5660300001)(229853002)(54906003)(6436002)(6916009)(6306002)(53936002)(25786009)(6512007)(7736002)(86362001)(4326008)(81166006)(81156014)(316002)(71190400001)(71200400001)(6246003)(6116002)(14444005)(3846002)(186003)(256004)(31696002)(966005)(66066001)(305945005)(8676002)(19400905002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB2282; H:DM6PR17MB2716.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: sectigo.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Jw5toHOitcG4UQbow4PRQQdAk+/uLM7TdyprrJFKCsVa/X1KKXC86rLMUvw6nHf3KMOGTFBz2CTDBZIgbQyF101W7MlfOl5VyhPpFEha+Q3Q8nxWfRFTpaUwpK6OYnmlksqLWuQc9ApDRkoPF9nzKag1ug7CQPguyfof+ZysA54aaNcqFljnK5vQp1+l8zrMByvUkBnnXK53Dvesw0RAlEPQ8F2VCw3fcHuHwIRpvJB9OOqkGWD9c+jp2uswuBGROYHulfOfqfKb7aznDR+HhZf3Y5YvsxB7XkQa1x4h6jyNRnalnMbdwxgdtzhn/tTjbljZfexYAMxI0tLis1/5Ak63ChIza5pbRDO68aNG17+8swS8ImbrBPDUvBR8EIsJP1vDPb0+VsKUsbasJmkvS922fCC2hzyZ/Ws9+kGWSbs= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <13BB21C4EBE718449DB045B876FC178B@namprd17.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: ad21d19b-02aa-4d3f-f1dd-08d67a56d373 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2019 19:31:05.4952 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0e9c4894-6caa-465d-9660-4b6968b49fb7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB2282 Archived-At: Subject: Re: [lamps] 6844bis: Merging sections 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, 14 Jan 2019 19:31:14 -0000 UGhpbGwsIGRvIHlvdSByZWNhbGwgd2hvIHJlcXVlc3RlZCB0aGF0IHRoZXNlIHNlY3Rpb25zIHNo b3VsZCBiZSBzcGxpdD8gDQpBbmQgd2h5Pw0KDQpPbiAxNC8wMS8yMDE5IDE5OjE1LCBQaGlsbGlw IEhhbGxhbS1CYWtlciB3cm90ZToNCj4gSSBhbSByZXZpZXdpbmcgaXQgbm93LiBJIHdpbGwganVz dCBwb2ludCBvdXQgdGhhdCBvbmUgb2YgdGhlIGNvbW1lbnRzIEkgDQo+IHJlY2VpdmVkIHdoZW4g d3JpdGluZyA2ODQ0IHdhcyB0aGF0IHRoZSBzZWN0aW9ucyBzaG91bGQgYmUgc3BsaXQuDQo+IA0K PiBPbiBNb24sIEphbiAxNCwgMjAxOSBhdCAxMjo0OCBQTSBKYWNvYiBIb2ZmbWFuLUFuZHJld3Mg PGpzaGFAZWZmLm9yZyANCj4gPG1haWx0bzpqc2hhQGVmZi5vcmc+PiB3cm90ZToNCj4gDQo+ICAg ICBDb25zaWRlciB0aGlzIGEgTW9uZGF5IHJlbWluZGVyIHRvIHRha2UgYSBsb29rIGF0IHRoaXMg Y2hhbmdlIGlmIHlvdQ0KPiAgICAgbWlzc2VkIGl0IGxhc3Qgd2Vlay4gVGhhbmtzIQ0KPiANCj4g ICAgIE9uIDEvMTEvMTkgNTowNSBQTSwgSmFjb2IgSG9mZm1hbi1BbmRyZXdzIHdyb3RlOg0KPiAg ICAgID4gSW4gcmV2aWV3aW5nIGVrcidzIEFEIHJldmlldyBmb3IgNjg0NGJpcywgSSByZWFsaXpl ZCBhIGxvdCBvZg0KPiAgICAgID4gaW5mb3JtYXRpb24gd2FzIGR1cGxpY2F0ZWQgYmV0d2VlbiBT ZWN0aW9uIDMgIlRoZSBDQSBSUiBUeXBlIiBhbmQNCj4gICAgICA+IFNlY3Rpb24gNSAiTWVjaGFu aXNtLiIgSSBkb24ndCBzZWUgYSByZWFzb24gZm9yIHRoZXNlIHRvIGJlIHNlcGFyYXRlDQo+ICAg ICAgPiBzZWN0aW9ucywgYW5kIEkgdGhpbmsgdGhleSB3ZXJlIGJlaGluZCBhIG51bWJlciBvZiBp bmNvbnNpc3RlbmNpZXMuDQo+ICAgICAgPg0KPiAgICAgID4gSSB3cm90ZSB1cCBhIGNoYW5nZSB0 byBtZXJnZSB0aGUgdHdvLiBJIHRoaW5rIHRoaXMgZml4ZXMgYSBsb3Qgb2YNCj4gICAgICA+IHBy b2JsZW1zIGluIHRoZSBzcGVjLCBidXQgaXQncyBhIGZhaXJseSBzaWduaWZpY2FudCBjaGFuZ2Us IHNvIEkNCj4gICAgICA+IHdhbnRlZCB0byBwcmVzZW50IHRoaXMgZm9yIHJldmlldyBiZWZvcmUg bWVyZ2luZyBpbnRvIG15IHdvcmtpbmcNCj4gICAgIGNvcHkuDQo+ICAgICAgPg0KPiAgICAgID4g UGxlYXNlIHRha2UgYSBsb29rOg0KPiAgICAgID4NCj4gICAgICA+IGh0dHBzOi8vZ2l0aHViLmNv bS9qc2hhL2NhYS1zaW1wbGlmaWNhdGlvbi9wdWxsLzUNCj4gICAgICA+DQo+ICAgICAgPiBUaGFu a3MsDQo+ICAgICAgPiBKYWNvYg0KDQotLSANClJvYiBTdHJhZGxpbmcNClNlbmlvciBSZXNlYXJj aCAmIERldmVsb3BtZW50IFNjaWVudGlzdA0KU2VjdGlnbyBMaW1pdGVkDQoNCg== From nobody Mon Jan 14 13:34:23 2019 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 CCC2E131312 for ; Mon, 14 Jan 2019 13:34:20 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 PkZBVKDPIq5Q for ; Mon, 14 Jan 2019 13:34:17 -0800 (PST) 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 00494131363 for ; Mon, 14 Jan 2019 13:34:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 61D453005DF for ; Mon, 14 Jan 2019 16:15:59 -0500 (EST) 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 y5rqstKV7K3y for ; Mon, 14 Jan 2019 16:15:57 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 862293001FD; Mon, 14 Jan 2019 16:15:57 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: <597fee4e75874e1d84af8bf894b6eb6f@XCH-ALN-010.cisco.com> Date: Mon, 14 Jan 2019 16:34:14 -0500 Cc: "spasm@ietf.org" , "lamps-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <72F0BDFD-1C82-4E6D-8736-DA5F39636F4F@vigilsec.com> References: <154748059551.4662.3464847439174630766@ietfa.amsl.com> <597fee4e75874e1d84af8bf894b6eb6f@XCH-ALN-010.cisco.com> To: Panos Kampanakis X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-07.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: Mon, 14 Jan 2019 21:34:21 -0000 Panos: Something got messed up in Section 5.1: The identifiers defined in Section 4 can be used as the AlgorithmIdentifier in the signatureAlgorithm field in the sequence Certificate and the signature field in the sequence tbsCertificate in X.509. The parameters of these signature algorithms are absent as explained in Section 4. [RFC5280]. I think this should say: The identifiers defined in Section 4 can be used as the AlgorithmIdentifier in the signatureAlgorithm field in the sequence Certificate and the signature field in the sequence tbsCertificate in X.509 [RFC5280]. The parameters of these signature algorithms are absent as explained in Section 4. Also, a small nit. Please spell out "OID" the first time it is used. Russ > On Jan 14, 2019, at 10:51 AM, Panos Kampanakis (pkampana) = wrote: >=20 > This version addresses Eric's AD Review comments while = draft-ietf-lamps-pkix-shake has been under IESG review.=20 > Thanks, > Panos >=20 > -----Original Message----- > From: Spasm On Behalf Of = internet-drafts@ietf.org > Sent: Monday, January 14, 2019 10:43 AM > To: i-d-announce@ietf.org > Cc: spasm@ietf.org > Subject: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-07.txt >=20 >=20 > 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. >=20 > Title : Internet X.509 Public Key Infrastructure: = Additional Algorithm Identifiers for RSASSA-PSS and ECDSA using SHAKEs > Authors : Panos Kampanakis > Quynh Dang > Filename : draft-ietf-lamps-pkix-shake-07.txt > Pages : 15 > Date : 2019-01-14 >=20 > Abstract: > Digital signatures are used to sign messages, X.509 certificates and > CRLs (Certificate Revocation Lists). This document describes the > conventions for using the SHAKE function family in Internet X.509 > certificates and CRLs as one-way hash functions with the RSA > Probabilistic signature and ECDSA signature algorithms. The > conventions for the associated subject public keys are also > described. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lamps-pkix-shake/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lamps-pkix-shake-07 > https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pkix-shake-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-pkix-shake-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Jan 14 13:36:51 2019 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 E26F5131363 for ; Mon, 14 Jan 2019 13:36:49 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mde3uWPEKdOQ for ; Mon, 14 Jan 2019 13:36:48 -0800 (PST) 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 3225313135D for ; Mon, 14 Jan 2019 13:36:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 88866300A4E for ; Mon, 14 Jan 2019 16:18:30 -0500 (EST) 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 35ALGy2znkUr for ; Mon, 14 Jan 2019 16:18:28 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id A582F3001FD; Mon, 14 Jan 2019 16:18:28 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: <01c8c6823c4a4d6eb12cc29b854ce36b@XCH-ALN-010.cisco.com> Date: Mon, 14 Jan 2019 16:36:45 -0500 Cc: "spasm@ietf.org" , "lamps-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3BB89F0A-0FB2-4645-B9B6-FF11AD2AC39D@vigilsec.com> References: <154748060882.4799.6385460550778062312@ietfa.amsl.com> <01c8c6823c4a4d6eb12cc29b854ce36b@XCH-ALN-010.cisco.com> To: Panos Kampanakis X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-06.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: Mon, 14 Jan 2019 21:36:50 -0000 These changes look fine to me. Russ > On Jan 14, 2019, at 10:51 AM, Panos Kampanakis (pkampana) = wrote: >=20 > This draft incorporates Eric's AD Review comments for = draft-ietf-lamps-pkix-shake that apply to draft-ietf-lamps-cms-shakes = while being under IESG Review.=20 > Thanks, > Panos >=20 >=20 > -----Original Message----- > From: Spasm On Behalf Of = internet-drafts@ietf.org > Sent: Monday, January 14, 2019 10:43 AM > To: i-d-announce@ietf.org > Cc: spasm@ietf.org > Subject: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-06.txt >=20 >=20 > 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. >=20 > Title : Use of the SHAKE One-way Hash Functions in = the Cryptographic Message Syntax (CMS) > Authors : Panos Kampanakis > Quynh Dang > Filename : draft-ietf-lamps-cms-shakes-06.txt > Pages : 16 > Date : 2019-01-14 >=20 > Abstract: > This document describes the conventions for using the SHAKE family = of > hash functions with the Cryptographic Message Syntax (CMS) as = one-way > hash functions with the RSA Probabilistic signature and ECDSA > signature algorithms, as message digests and message authentication > codes. The conventions for the associated signer public keys in CMS > are also described. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lamps-cms-shakes-06 > https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-shakes-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-shakes-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Jan 15 14:29:03 2019 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 51664127598; Tue, 15 Jan 2019 14:28:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <154759132229.10674.3677145629770514716@ietfa.amsl.com> Date: Tue, 15 Jan 2019 14:28:42 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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, 15 Jan 2019 22:28:42 -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 : Hash Of Root Key Certificate Extension Author : Russ Housley Filename : draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt Pages : 10 Date : 2019-01-15 Abstract: This document specifies the Hash Of Root Key certificate extension. This certificate extension is carried in the self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate. This certificate extension unambiguously identifies the next public key that will be used at some point in the future as the next Root CA certificate, eventually replacing the current one. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-extn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-hash-of-root-key-cert-extn-04 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-hash-of-root-key-cert-extn-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-hash-of-root-key-cert-extn-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 15 14:50:04 2019 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 B58BB130F1F for ; Tue, 15 Jan 2019 14:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gILCP2HLiqX for ; Tue, 15 Jan 2019 14:49:59 -0800 (PST) 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 2EBEA127598 for ; Tue, 15 Jan 2019 14:49:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5D08E3004AD for ; Tue, 15 Jan 2019 17:31:41 -0500 (EST) 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 RrekmjYcX9l4 for ; Tue, 15 Jan 2019 17:31:40 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 0EEEA3002B3 for ; Tue, 15 Jan 2019 17:31:40 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 15 Jan 2019 17:49:56 -0500 References: <154759132229.10674.3677145629770514716@ietfa.amsl.com> To: LAMPS WG In-Reply-To: <154759132229.10674.3677145629770514716@ietfa.amsl.com> Message-Id: <6248C23D-646A-4ACF-A786-D8765870E885@vigilsec.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Tue, 15 Jan 2019 22:50:02 -0000 This update covers the very long discussion that took place during IETF = Last Call. I believe that all of the comments were completely resolved, = except one. On that point, there is a disagreement between myself and = DKG regarding the amount of guidance that should be given to the Root CA = and the recipient. First, DKG would like to say that if a certificate repository is = available, then the oldWithNew certificate MUST be made available in = that repository before the new self-signed certificate is published. I think that the first and third paragraphs of the Operational = Considerations already covers this point pretty well. Second, DKG would like to include guidance to the relying party about = which certificates to cache from the repository, if one exists. As best = I can tell, this is protection against future unavailable of the = repository. While I find the criteria that DKG suggests to be quite clever, I do not = think that we should include actions to protect against repository = unavailability in the description of the certificate extension. Third, DKG suggests that the lack of a oldWithNew certificate in the = repository can be a trigger to remove the previous Root CA self-signed = certificate. I think that the third paragraph of the Operational Considerations = already covets this point pretty well. I would like to continue the discussion on the WG mail list (without = copying the IETF-wide mail list). Of course, Tim will make any = consensus calls relate to this document. Russ > On Jan 15, 2019, at 5:28 PM, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : Hash Of Root Key Certificate Extension > Author : Russ Housley > Filename : = draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt > Pages : 10 > Date : 2019-01-15 >=20 > Abstract: > This document specifies the Hash Of Root Key certificate extension. > This certificate extension is carried in the self-signed certificate > for a trust anchor, which is often called a Root Certification > Authority (CA) certificate. This certificate extension = unambiguously > identifies the next public key that will be used at some point in = the > future as the next Root CA certificate, eventually replacing the > current one. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-ex= tn/ >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-lamps-hash-of-root-key-cert-extn-04= > = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-hash-of-root-key-ce= rt-extn-04 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-hash-of-root-key-cert= -extn-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 16 15:22:05 2019 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 2624D131208 for ; Wed, 16 Jan 2019 15:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvma5GUjdI1p for ; Wed, 16 Jan 2019 15:22:01 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2710D13120A for ; Wed, 16 Jan 2019 15:22:01 -0800 (PST) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id DD7CCF99D for ; Wed, 16 Jan 2019 18:21:28 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id C85DA1FE37; Wed, 16 Jan 2019 15:01:04 -0500 (EST) From: Daniel Kahn Gillmor To: Russ Housley , LAMPS WG In-Reply-To: <6248C23D-646A-4ACF-A786-D8765870E885@vigilsec.com> References: <154759132229.10674.3677145629770514716@ietfa.amsl.com> <6248C23D-646A-4ACF-A786-D8765870E885@vigilsec.com> Date: Wed, 16 Jan 2019 15:01:01 -0500 Message-ID: <87won4e5j6.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Wed, 16 Jan 2019 23:22:03 -0000 --=-=-= Content-Type: text/plain Thanks for the summary of our off-list discussion, Russ, and for accurately describing the three concrete changes i think should be made so that the document provides robust guidance for the "cert repository expected" use case. However, the larger point of disagreement on this draft is about the "no cert repository expected" use case. The document currently doesn't provide much concrete guidance for those use cases, using terms like "some amount of time" or "an appropriate amount of time" for when the revocation for C1 should trigger. As an implementer, i would want to know how to choose those times. The draft provides me with no guidance on how to make that decision. (the guidance "until all of the certificates in the local cache that are subordinate to it have expired." is insufficient, because it fails to protect those certificates not yet in the local cache from failing due to accidentally-induced transvalidity) If the times selected are too short, then there remains the risk of very hard-to-track-down transvalidity of some certificates, potentially introduced by parties who know nothing about the other parties that they are inconveniencing. I can see two general ways to move forward if the group thinks these concerns are important (as i do): a) declare this draft as only useful in the "cert repository expected" use case, and explicitly discourage its use when no certificate repository is systemically available. b) provide some mechanism for advising relying parties about how to set those timeouts/delays for the revocation, and provide guidance for the relying parties about how to interpret that mechanism safely. Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCXD+NfQAKCRBsHx7ezFD6 UxZIAQCZC40L4ZDI1+ajsOHFeGOXSOlrrHcGcdNKgtI4hBEN5AEAw9aFSdyjwd5Y UTu+Ucm201emCUy18tFq9jUisBo/5Qo= =YOun -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 16 15:26:19 2019 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 124F0130F11 for ; Wed, 16 Jan 2019 15:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.254 X-Spam-Level: X-Spam-Status: No, score=-5.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 wZBMTQI6q70a for ; Wed, 16 Jan 2019 15:26:15 -0800 (PST) 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 9D53812870E for ; Wed, 16 Jan 2019 15:26:15 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x0GNMK1o014884; Wed, 16 Jan 2019 23:26:14 GMT 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=Eq82obGqEfCZP185hPrLKUYOgEJX2yC78e4VCaqgUFA=; b=RUJgI7Dkwc/AHPP3+37YdFCOq1KqNe2H6DsvOa37BVauG9e1RsZ2FJTCf5Q+g9OCTv/j 2jvEwYZNXC7FVkpj885exowvVoQ4jYqEpU3OKtXJ+35MLR61OsOwT1ndmXErONemoeIv TaJosBWKQZRUTc/lwsfgMc+CiDPGEBQBVGss6tGnoRckSDCqULNQA1DXnCgT2eZPcqk8 8B9d6A1UCnV5i2rBLqinZymuuyCJhCxRHNC1QdN5Y5Dm/gVCS/DELfur+wwE5iGTGORv 6KnfFIkmuZozOcT9QhHfFdVTWubzvVofQMM7ocSLKySiQseVVJnJToy+wv8qXxw2zChw qA== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2q1h4pn0j4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Jan 2019 23:26:13 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x0GNGwei025688; Wed, 16 Jan 2019 18:26:13 -0500 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint3.akamai.com with ESMTP id 2pycf324q0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 16 Jan 2019 18:26:12 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 16 Jan 2019 17:26:07 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Wed, 16 Jan 2019 17:26:07 -0600 From: "Salz, Rich" To: Daniel Kahn Gillmor , Russ Housley , LAMPS WG Thread-Topic: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt] Thread-Index: AQHUrfJRb465P3pybE6BGW6+84BbnaWympMA Date: Wed, 16 Jan 2019 23:26:06 +0000 Message-ID: References: <154759132229.10674.3677145629770514716@ietfa.amsl.com> <6248C23D-646A-4ACF-A786-D8765870E885@vigilsec.com> <87won4e5j6.fsf@fifthhorseman.net> In-Reply-To: <87won4e5j6.fsf@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190115 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.103] Content-Type: text/plain; charset="utf-8" Content-ID: <1B5EAFA735A43645A3EB8B7F0B1DB19B@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-16_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901160185 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-16_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901160186 Archived-At: Subject: Re: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Wed, 16 Jan 2019 23:26:17 -0000 PiAgICAgYSkgZGVjbGFyZSB0aGlzIGRyYWZ0IGFzIG9ubHkgdXNlZnVsIGluIHRoZSAiY2VydCBy ZXBvc2l0b3J5IGV4cGVjdGVkIg0KDQpEb2VzIGFuIGFwcGxpY2F0aW9uIChzbWFydCBob21lIElv VCBkZXZpY2U/KSB0aGF0IG9ubHkgaG9sZHMgb25lIGNlcnQgZmFsbCBpbnRvIHRoaXMgZ3JvdXA/ DQoNCg== From nobody Thu Jan 17 19:01:50 2019 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 7217013108E for ; Thu, 17 Jan 2019 19:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoq5xWAVH_6v for ; Thu, 17 Jan 2019 19:01:47 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A496F13108C for ; Thu, 17 Jan 2019 19:01:46 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 17 Jan 2019 19:01:20 -0800 From: Jim Schaad To: 'SPASM' Date: Thu, 17 Jan 2019 19:01:17 -0800 Message-ID: <05ae01d4aeda$15cf07a0$416d16e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdSu2dfps/UKMcQAQ9qW/96Y8vcAkA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [lamps] ASN.1 module in draft-ietf-lamps-rfc5751-bis 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, 18 Jan 2019 03:01:49 -0000 I don't remember that I ever raised the issue while dealing with updates to this document, however one question is should we have updated the ASN.1 module from the current 1988 module to one which is derived from RFC 5911 which is using current ASN.1. We are currently in AUTH48 so this is the last chance to update this is desired. Jim From nobody Thu Jan 17 19:29:45 2019 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 C7DCC1310D1 for ; Thu, 17 Jan 2019 19:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdYH2XEL-c_B for ; Thu, 17 Jan 2019 19:29:42 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FDB91310CD for ; Thu, 17 Jan 2019 19:29:42 -0800 (PST) Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:5407:1cff:fe30:9bdf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 5F37EF99F; Thu, 17 Jan 2019 22:29:10 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 0B24F20E9F; Thu, 17 Jan 2019 21:25:22 -0500 (EST) From: Daniel Kahn Gillmor To: "Salz\, Rich" , Russ Housley , LAMPS WG In-Reply-To: References: <154759132229.10674.3677145629770514716@ietfa.amsl.com> <6248C23D-646A-4ACF-A786-D8765870E885@vigilsec.com> <87won4e5j6.fsf@fifthhorseman.net> Date: Thu, 17 Jan 2019 21:25:18 -0500 Message-ID: <87va2md7n5.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Fri, 18 Jan 2019 03:29:44 -0000 --=-=-= Content-Type: text/plain On Wed 2019-01-16 23:26:06 +0000, Salz, Rich wrote: >> a) declare this draft as only useful in the "cert repository expected" > > Does an application (smart home IoT device?) that only holds one cert fall into this group? I should probably clarify that the subscriber (the entity that holds the cert) probably *doesn't* need to know anything about the certificate repository. The certificate repository, if i'm understanding Russ's model correctly, is something published by the Root CA (or the enterprise network operations team, or whatever), and consumed by the relying parties. So if your smarthome IoT device acts as a relying party and talks to more than one other entity that is certified by the same Root CA, then *yes*, it does need to have access to a cert repository to use this extension safely. But if your smarthome IoT device never acts as a relying party (e.g. it's a TLS server but it never does outbound TLS connections, and doesn't do client certificate validation) or it only ever validates a single entity (e.g. same as above but it also looks for software updates over cleartext HTTP, and might discover X.509 certificate chains in the process of checking CMS signatures over the packages, signatures, and certs it finds during the update process), then it's probably safe to use this extension without a cert repository *from the perspective of the IoT device*. But if you're a client and you're connecting to more than one such IoT device, and you want to be sure that one such IoT device can't break your ability to connect to the other comparable IoT devices, then as a relying party, *you* need to have access to the certificate repository. does that make sense? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCXEE5DgAKCRBsHx7ezFD6 U+fyAQCfWBCv69e+qinT7i7AtA+36eZEZPMY3Xmt2dque0tSsAD9Hwmyy3e9DTbY y7tVtA+eZZ19PdbDftDlJc5Ugc9uuAU= =tXbk -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 17 19:37:28 2019 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 984061310D9 for ; Thu, 17 Jan 2019 19:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.254 X-Spam-Level: X-Spam-Status: No, score=-5.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 HSve-_mUeXmu for ; Thu, 17 Jan 2019 19:37:24 -0800 (PST) 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 CB1681310D5 for ; Thu, 17 Jan 2019 19:37:24 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x0I3WJLh006289; Fri, 18 Jan 2019 03:37:23 GMT 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=DgAmi8miUQUqGlmPJjo0mV33T6DFWN4wkIRosK8NjWU=; b=aJxmG8n3nKdI9dvti+BcMZLeVWHH5yDGduieVT0MIeIcfjUmZtfjGKHnYwu3A0OnlaAi hKpdSIL5K7yM0NkpWNR+u0+SbGsLb0+uCriPCt6/zF2REXgNviCYpaQ96u5STp/pozMv 12Q30t6d93JcchmFGm+qma0AHj206AnfHiOh9j7fHm5XI0uKB2Gs5G19rFCDWHmqxGvq 2Y6ji7VqxZiotBZwpAbzQv7mwbDBVp051tC5gffIJTWjBZz7/ZgnVLXAmL0yL5HSYZDq xPK8RRKB7YRitGouQGvc+JFt2iy1P7xIVLMLf9SLYFjFjR7Wg/VHwvWqFVvS5fYjX6fI ng== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2q2b61chvp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Jan 2019 03:37:22 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x0I3WUPP009961; Thu, 17 Jan 2019 22:37:22 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint3.akamai.com with ESMTP id 2pycf371pf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 17 Jan 2019 22:37:22 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 17 Jan 2019 21:37:21 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Thu, 17 Jan 2019 21:37:21 -0600 From: "Salz, Rich" To: Daniel Kahn Gillmor , Russ Housley , LAMPS WG Thread-Topic: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt] Thread-Index: AQHUrfJRb465P3pybE6BGW6+84BbnaWympMAgAIYOAD//8BPAA== Date: Fri, 18 Jan 2019 03:37:21 +0000 Message-ID: <78AB2172-3C9F-4776-A9F5-9DEE0BF29DC5@akamai.com> References: <154759132229.10674.3677145629770514716@ietfa.amsl.com> <6248C23D-646A-4ACF-A786-D8765870E885@vigilsec.com> <87won4e5j6.fsf@fifthhorseman.net> <87va2md7n5.fsf@fifthhorseman.net> In-Reply-To: <87va2md7n5.fsf@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190115 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.192] Content-Type: text/plain; charset="utf-8" Content-ID: <9F0F6B2AD339D84D8BF3B5017A73231C@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-18_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901180025 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-18_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=989 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901180025 Archived-At: Subject: Re: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Fri, 18 Jan 2019 03:37:27 -0000 PiAgICBUaGUgY2VydGlmaWNhdGUgcmVwb3NpdG9yeSwgaWYgaSdtIHVuZGVyc3RhbmRpbmcgUnVz cydzIG1vZGVsIGNvcnJlY3RseSwNCiAgICBpcyBzb21ldGhpbmcgcHVibGlzaGVkIGJ5IHRoZSBS b290IENBIChvciB0aGUgZW50ZXJwcmlzZSBuZXR3b3JrDQogICAgb3BlcmF0aW9ucyB0ZWFtLCBv ciB3aGF0ZXZlciksIGFuZCBjb25zdW1lZCBieSB0aGUgcmVseWluZyBwYXJ0aWVzLg0KICANCkkg ZGlzYWdyZWUgd2l0aCB0aGF0LiAgSSBhbSB0aGlua2luZyBvZiB0aGUgdHJ1c3QgcmVwb3NpdG9y eSBhcyBzb21ldGhpbmcgdGhhdCBpcyBsaWtlIGJyb3dzZXIgcm9vdCBzdG9yZXMuDQoNCg0KDQo= From nobody Thu Jan 17 20:13:55 2019 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 5D1C41310FD for ; Thu, 17 Jan 2019 20:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eu1lDchlRVBw for ; Thu, 17 Jan 2019 20:13:52 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDF5E1310FA for ; Thu, 17 Jan 2019 20:13:51 -0800 (PST) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 82D9CF99A; Thu, 17 Jan 2019 23:13:49 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 75142203B5; Thu, 17 Jan 2019 22:55:46 -0500 (EST) From: Daniel Kahn Gillmor To: "Salz\, Rich" , Russ Housley , LAMPS WG In-Reply-To: <78AB2172-3C9F-4776-A9F5-9DEE0BF29DC5@akamai.com> References: <154759132229.10674.3677145629770514716@ietfa.amsl.com> <6248C23D-646A-4ACF-A786-D8765870E885@vigilsec.com> <87won4e5j6.fsf@fifthhorseman.net> <87va2md7n5.fsf@fifthhorseman.net> <78AB2172-3C9F-4776-A9F5-9DEE0BF29DC5@akamai.com> Date: Thu, 17 Jan 2019 22:55:42 -0500 Message-ID: <87pnsud3gh.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Fri, 18 Jan 2019 04:13:53 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri 2019-01-18 03:37:21 +0000, Salz, Rich wrote: >> The certificate repository, if i'm understanding Russ's model correct= ly, >> is something published by the Root CA (or the enterprise network >> operations team, or whatever), and consumed by the relying parties. >=20=20=20 > I disagree with that. I am thinking of the trust repository as > something that is like browser root stores. You say "trust repository" here -- but we are talking about a "certificate repository", right? I agree that the terminology is confusing! In https://tools.ietf.org/html/draft-ietf-lamps-hash-of-root-key-cert-extn-04, it says: In enterprise and application-specific environments where a directory service or certificate repository is available, the oldWithNew and newWithOld certificates SHOULD be published before the successor to the current Root CA self-signed certificate is released. In environments without such a directory service or repository, recipients SHOULD keep both the old and replacement Root CA self- signed certificate in the trust anchor store for some amount of time to ensure that all end-entity certificates can be validated until they expire. The fact the draft contemplates a scenario "without such a directory service or [certificate] repository" but where the relying party still has access to a "trust anchor store" suggests that these can't be the same thing. That said, i agree that the specification of a certificate repository is unclear in the document, and it doesn't point to any other documentation or specific examples of how to operate such a repository, or even what capabilities such a repository should offer. I've proposed text to Russ about how a relying party with access to a cert repo (or what i imagine a certificate repository to be) could minimize the risk of accidental transvalidity due to cert repo unavailability, but as Russ said at the top of this thread, he thinks that guidance is overkill for the draft. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCXEFOPwAKCRBsHx7ezFD6 UwleAQD1czHQ5+xMoZcjJhy3LysrgEZvkb1Hq23qp34zb32L8wD9GMiYdqmDlIBY NtYjKZxPfetXGuISUedhxbu3R+A92QI= =sf5t -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 18 08:06:53 2019 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 C8BAC130F59 for ; Fri, 18 Jan 2019 08:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.254 X-Spam-Level: X-Spam-Status: No, score=-5.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 6E2NodDK7BmF for ; Fri, 18 Jan 2019 08:06:50 -0800 (PST) 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 3BD25130F56 for ; Fri, 18 Jan 2019 08:06:50 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x0IG6Xcb030173; Fri, 18 Jan 2019 16:06:48 GMT 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=/n9FeNTNPVBYNOXLATXoXY9BqwkhiX+eQHJW7vlJSMw=; b=IjbJrZaY+hdiQ+qTyoalF9ppg5ygiPL8W/4drNpzuiQLLL/qTZJSETwuVlQwfHBBBHQE b9fgPpJPqgepXKat0mi708Yv3cOa254FNJzAmGQ9RzjyfGknNtlXz+wyM3hFdo1k+Bvv OI6/UEkG1r97t1ovJTnXzz6BuyyCIYnPgq+fm1aAAEZGctrV8Zkfnc6Dg0Fy1Dwz1tyH wZLt9RRwuqiLIEHQlvcvi6ZL1FWNhWmqQy7uxp4HA9C8F7p1YjcKT/+01CyTV9d+Jn/V tAI4MpiSSGjiw75Mj/jPAL9B96LMuVxkjXAyJySHE0YrZI9eauRVH6jjvVFM8rIeUKeP Ig== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2q2b61emdn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Jan 2019 16:06:48 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x0IG1fqT028887; Fri, 18 Jan 2019 11:06:47 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2pycf17g24-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 18 Jan 2019 11:06:46 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 18 Jan 2019 08:06:37 -0800 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Fri, 18 Jan 2019 10:06:37 -0600 From: "Salz, Rich" To: Daniel Kahn Gillmor , Russ Housley , LAMPS WG Thread-Topic: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt] Thread-Index: AQHUrfJRb465P3pybE6BGW6+84BbnaWympMAgAIYOAD//8BPAIAAWPMAgAB4ZoA= Date: Fri, 18 Jan 2019 16:06:37 +0000 Message-ID: <18E23E26-73DE-4489-ACB3-A9E68569B883@akamai.com> References: <154759132229.10674.3677145629770514716@ietfa.amsl.com> <6248C23D-646A-4ACF-A786-D8765870E885@vigilsec.com> <87won4e5j6.fsf@fifthhorseman.net> <87va2md7n5.fsf@fifthhorseman.net> <78AB2172-3C9F-4776-A9F5-9DEE0BF29DC5@akamai.com> <87pnsud3gh.fsf@fifthhorseman.net> In-Reply-To: <87pnsud3gh.fsf@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190115 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.4] Content-Type: text/plain; charset="utf-8" Content-ID: <6B0F66A1C810864FA363342DF601886E@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-18_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901180114 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-18_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901180116 Archived-At: Subject: Re: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Fri, 18 Jan 2019 16:06:52 -0000 PiAgICBUaGF0IHNhaWQsIGkgYWdyZWUgdGhhdCB0aGUgc3BlY2lmaWNhdGlvbiBvZiBhIGNlcnRp ZmljYXRlIHJlcG9zaXRvcnkgaXMNCiAgICB1bmNsZWFyIGluIHRoZSBkb2N1bWVudCwgYW5kIGl0 IGRvZXNuJ3QgcG9pbnQgdG8gYW55IG90aGVyIGRvY3VtZW50YXRpb24NCiAgICBvciBzcGVjaWZp YyBleGFtcGxlcyBvZiBob3cgdG8gb3BlcmF0ZSBzdWNoIGEgcmVwb3NpdG9yeSwgb3IgZXZlbiB3 aGF0DQogICAgY2FwYWJpbGl0aWVzIHN1Y2ggYSByZXBvc2l0b3J5IHNob3VsZCBvZmZlci4NCiAg DQoNCkp1c3QgZ29lcyB0byBzaG93IHdlIGFsbCBicmluZyBvdXIgcHJlY29uY2VwdGlvbnMgd2hl biB3ZSByZWFkLiA6KSAgTG9va2luZyBmb3J3YXJkIHRvIGNsYXJpZmljYXRpb24uDQoNCg== From nobody Fri Jan 18 08:15:17 2019 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 C52BC130E79 for ; Fri, 18 Jan 2019 08:15:07 -0800 (PST) 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_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTM9xx_H_FND for ; Fri, 18 Jan 2019 08:15:04 -0800 (PST) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (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 A751B130E71 for ; Fri, 18 Jan 2019 08:15:04 -0800 (PST) Received: by mail-io1-f43.google.com with SMTP id t24so11164017ioi.0 for ; Fri, 18 Jan 2019 08:15:04 -0800 (PST) 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=Gtp8Ml031QxVYxeZZQiljwV7gVTiq9GNd7pSIwLfe9w=; b=FzTvIOvY9IAlk9lGnZHptGI2K3kn1Mp4hP1VmmhmXSJycgT+sd3J1Pk6PxPY/SKSoe aqWTVK6Mn0QnFutDSa0e+RvcGE1U5/Skpcpy2bL1Q0e//JqfCqUdOEY7NvDX3PmcFwTQ QFv+8NUbpot+iC48SPwsymBVdw7Zyt0hbK3xGjUqqyfFpnoAkUOCCVQWfSSNRo7OuqDK vPddRDxTxPb/1s+tHf1kT7tNoVYlcZ04QDVgGqXFCOGZfMxsljwNg7TlbtcukakFi1vb sYgeLQ42/vXswHSW/uRRfoIfrcr2a+AeSxXT8Q3HhM4yuBxECLiaHl8gR6Y8wn/gaoGa grFw== X-Gm-Message-State: AJcUukeiU1If4Hkr6lPfHLaa1TNFcRL9e8XFQKCPBczHLKzHPkPDk38z KseIT1ldMHtm5Bieg6jUm20JGOjf X-Google-Smtp-Source: ALg8bN5PwmCwBzjZmNFX3Zckv92ves8dMoogtrIIx9hY2v9SCSsUeIjCtIvwqqbpbNNXzV/er6HnAA== X-Received: by 2002:a6b:310b:: with SMTP id j11mr9467760ioa.141.1547828103621; Fri, 18 Jan 2019 08:15:03 -0800 (PST) Received: from mail-it1-f174.google.com (mail-it1-f174.google.com. [209.85.166.174]) by smtp.gmail.com with ESMTPSA id f142sm1920289itc.15.2019.01.18.08.15.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Jan 2019 08:15:03 -0800 (PST) Received: by mail-it1-f174.google.com with SMTP id i145so7426167ita.4 for ; Fri, 18 Jan 2019 08:15:02 -0800 (PST) X-Received: by 2002:a24:d843:: with SMTP id b64mr10606232itg.39.1547828102807; Fri, 18 Jan 2019 08:15:02 -0800 (PST) MIME-Version: 1.0 References: <154759132229.10674.3677145629770514716@ietfa.amsl.com> <6248C23D-646A-4ACF-A786-D8765870E885@vigilsec.com> <87won4e5j6.fsf@fifthhorseman.net> <87va2md7n5.fsf@fifthhorseman.net> <78AB2172-3C9F-4776-A9F5-9DEE0BF29DC5@akamai.com> <87pnsud3gh.fsf@fifthhorseman.net> In-Reply-To: <87pnsud3gh.fsf@fifthhorseman.net> From: Ryan Sleevi Date: Fri, 18 Jan 2019 11:14:51 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Daniel Kahn Gillmor Cc: "Salz, Rich" , Russ Housley , LAMPS WG Content-Type: multipart/alternative; boundary="0000000000003dc780057fbdd0f6" Archived-At: Subject: Re: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Fri, 18 Jan 2019 16:15:08 -0000 --0000000000003dc780057fbdd0f6 Content-Type: text/plain; charset="UTF-8" Forgive what is probably a very stupid question, but isn't this term suitably addressed in RFC 5280? Specifically, Sections 3, 3.3, and 4.2.2.2? The notion of a repository was, I thought, one of those fundamental givens about dealing with PKI, much in the same way that this term has been an integral part of most of the standards for publication and auditing of certificates. On Thu, Jan 17, 2019 at 11:14 PM Daniel Kahn Gillmor wrote: > On Fri 2019-01-18 03:37:21 +0000, Salz, Rich wrote: > >> The certificate repository, if i'm understanding Russ's model > correctly, > >> is something published by the Root CA (or the enterprise network > >> operations team, or whatever), and consumed by the relying parties. > > > > I disagree with that. I am thinking of the trust repository as > > something that is like browser root stores. > > You say "trust repository" here -- but we are talking about a > "certificate repository", right? I agree that the terminology is > confusing! In > https://tools.ietf.org/html/draft-ietf-lamps-hash-of-root-key-cert-extn-04 > , > it says: > > In enterprise and application-specific environments where a directory > service or certificate repository is available, the oldWithNew and > newWithOld certificates SHOULD be published before the successor to > the current Root CA self-signed certificate is released. In > environments without such a directory service or repository, > recipients SHOULD keep both the old and replacement Root CA self- > signed certificate in the trust anchor store for some amount of time > to ensure that all end-entity certificates can be validated until > they expire. > > The fact the draft contemplates a scenario "without such a directory > service or [certificate] repository" but where the relying party still > has access to a "trust anchor store" suggests that these can't be the > same thing. > > That said, i agree that the specification of a certificate repository is > unclear in the document, and it doesn't point to any other documentation > or specific examples of how to operate such a repository, or even what > capabilities such a repository should offer. > > I've proposed text to Russ about how a relying party with access to a > cert repo (or what i imagine a certificate repository to be) could > minimize the risk of accidental transvalidity due to cert repo > unavailability, but as Russ said at the top of this thread, he thinks > that guidance is overkill for the draft. > > --dkg > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --0000000000003dc780057fbdd0f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Forgive what is probably a very stupid question, but isn&#= 39;t this term suitably addressed in RFC 5280? Specifically, Sections 3, 3.= 3, and 4.2.2.2?

The notion of a repository was, I though= t, one of those fundamental givens about dealing with PKI, much in the same= way that this term has been an integral part of most of the standards for = publication and auditing of certificates.

On Thu, Jan 17, 2019 at 11:1= 4 PM Daniel Kahn Gillmor <dkg@f= ifthhorseman.net> wrote:
On Fri 2019-01-18 03:37:21 +0000, Salz, Rich wrote:
>>=C2=A0 =C2=A0 The certificate repository, if i'm understanding = Russ's model correctly,
>>=C2=A0 =C2=A0 is something published by the Root CA (or the enterpr= ise network
>>=C2=A0 =C2=A0 operations team, or whatever), and consumed by the re= lying parties.
>=C2=A0 =C2=A0
> I disagree with that.=C2=A0 I am thinking of the trust repository as > something that is like browser root stores.

You say "trust repository" here -- but we are talking about a
"certificate repository", right?=C2=A0 I agree that the terminolo= gy is
confusing!=C2=A0 In
https://tools.ietf.org/htm= l/draft-ietf-lamps-hash-of-root-key-cert-extn-04,
it says:

=C2=A0 =C2=A0In enterprise and application-specific environments where a di= rectory
=C2=A0 =C2=A0service or certificate repository is available, the oldWithNew= and
=C2=A0 =C2=A0newWithOld certificates SHOULD be published before the success= or to
=C2=A0 =C2=A0the current Root CA self-signed certificate is released.=C2=A0= In
=C2=A0 =C2=A0environments without such a directory service or repository, =C2=A0 =C2=A0recipients SHOULD keep both the old and replacement Root CA se= lf-
=C2=A0 =C2=A0signed certificate in the trust anchor store for some amount o= f time
=C2=A0 =C2=A0to ensure that all end-entity certificates can be validated un= til
=C2=A0 =C2=A0they expire.

The fact the draft contemplates a scenario "without such a directory service or [certificate] repository" but where the relying party still=
has access to a "trust anchor store" suggests that these can'= t be the
same thing.

That said, i agree that the specification of a certificate repository is unclear in the document, and it doesn't point to any other documentatio= n
or specific examples of how to operate such a repository, or even what
capabilities such a repository should offer.

I've proposed text to Russ about how a relying party with access to a cert repo (or what i imagine a certificate repository to be) could
minimize the risk of accidental transvalidity due to cert repo
unavailability, but as Russ said at the top of this thread, he thinks
that guidance is overkill for the draft.

=C2=A0 =C2=A0 =C2=A0 --dkg
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--0000000000003dc780057fbdd0f6-- From nobody Fri Jan 18 08:59:43 2019 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 B8AE71311F1 for ; Fri, 18 Jan 2019 08:59:42 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWQoaP6ewFty for ; Fri, 18 Jan 2019 08:59:39 -0800 (PST) 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 8074C1311ED for ; Fri, 18 Jan 2019 08:59:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 96034300A31 for ; Fri, 18 Jan 2019 11:41:21 -0500 (EST) 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 fH-H4H-MFF34 for ; Fri, 18 Jan 2019 11:41:20 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 75511300400; Fri, 18 Jan 2019 11:41:20 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: <05ae01d4aeda$15cf07a0$416d16e0$@augustcellars.com> Date: Fri, 18 Jan 2019 11:59:36 -0500 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <794C2DA0-AD75-4788-87C3-3DCFBB946965@vigilsec.com> References: <05ae01d4aeda$15cf07a0$416d16e0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] ASN.1 module in draft-ietf-lamps-rfc5751-bis 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, 18 Jan 2019 16:59:43 -0000 Jim: To keep it simple in the final stages of publication, I suggest that the = ASN.1 module stay as it is, but add an additional Note at the from of = Appendix A: Note: An equivalent ASN.1 module that uses the 2002 version of ASN.1 is available in [RFC5911]. Russ > On Jan 17, 2019, at 10:01 PM, Jim Schaad = wrote: >=20 > I don't remember that I ever raised the issue while dealing with = updates to > this document, however one question is should we have updated the = ASN.1 > module from the current 1988 module to one which is derived from RFC = 5911 > which is using current ASN.1. >=20 > We are currently in AUTH48 so this is the last chance to update this = is > desired. >=20 > Jim From nobody Fri Jan 18 09:53:13 2019 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 79E07131271 for ; Fri, 18 Jan 2019 09:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pY0wKTrVXBvh for ; Fri, 18 Jan 2019 09:53:10 -0800 (PST) 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 320E813126C for ; Fri, 18 Jan 2019 09:53:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5FE04300AA7 for ; Fri, 18 Jan 2019 12:34:52 -0500 (EST) 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 yeyn8LpjWemE for ; Fri, 18 Jan 2019 12:34:51 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 37B94300250; Fri, 18 Jan 2019 12:34:51 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: <78AB2172-3C9F-4776-A9F5-9DEE0BF29DC5@akamai.com> Date: Fri, 18 Jan 2019 12:53:07 -0500 Cc: Daniel Kahn Gillmor , LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <154759132229.10674.3677145629770514716@ietfa.amsl.com> <6248C23D-646A-4ACF-A786-D8765870E885@vigilsec.com> <87won4e5j6.fsf@fifthhorseman.net> <87va2md7n5.fsf@fifthhorseman.net> <78AB2172-3C9F-4776-A9F5-9DEE0BF29DC5@akamai.com> To: Rich Salz X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Fri, 18 Jan 2019 17:53:12 -0000 Rich: >=20 >> The certificate repository, if i'm understanding Russ's model = correctly, > is something published by the Root CA (or the enterprise network > operations team, or whatever), and consumed by the relying parties. >=20 > I disagree with that. I am thinking of the trust repository as = something that is like browser root stores. A certificate repository is just a place to find certificates and CRLs. A trust anchor store is needed to validate the certificates that are = found there. Russ From nobody Fri Jan 18 09:56:55 2019 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 1A2C413126C for ; Fri, 18 Jan 2019 09:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvISXsApti7J for ; Fri, 18 Jan 2019 09:56:49 -0800 (PST) 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 2973C124C04 for ; Fri, 18 Jan 2019 09:56:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5CDA6300AA7 for ; Fri, 18 Jan 2019 12:38:31 -0500 (EST) 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 Y6-DvZJKbvPK for ; Fri, 18 Jan 2019 12:38:29 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 40FB2300250; Fri, 18 Jan 2019 12:38:29 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6B71478E-ABEF-4046-975A-63C33D6E039A" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 18 Jan 2019 12:56:45 -0500 In-Reply-To: Cc: LAMPS WG To: Ryan Sleevi References: <154759132229.10674.3677145629770514716@ietfa.amsl.com> <6248C23D-646A-4ACF-A786-D8765870E885@vigilsec.com> <87won4e5j6.fsf@fifthhorseman.net> <87va2md7n5.fsf@fifthhorseman.net> <78AB2172-3C9F-4776-A9F5-9DEE0BF29DC5@akamai.com> <87pnsud3gh.fsf@fifthhorseman.net> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Fri, 18 Jan 2019 17:56:53 -0000 --Apple-Mail=_6B71478E-ABEF-4046-975A-63C33D6E039A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ryan: I believe that I am using the terms consistent with the figure in = Section 3 of RFC 5280. Further, I am using the definition of trust anchor in a manner that is = aligned with RFC 5280, especially the section on path validation. Russ > On Jan 18, 2019, at 11:14 AM, Ryan Sleevi = wrote: >=20 > Forgive what is probably a very stupid question, but isn't this term = suitably addressed in RFC 5280? Specifically, Sections 3, 3.3, and = 4.2.2.2? >=20 > The notion of a repository was, I thought, one of those fundamental = givens about dealing with PKI, much in the same way that this term has = been an integral part of most of the standards for publication and = auditing of certificates. >=20 > On Thu, Jan 17, 2019 at 11:14 PM Daniel Kahn Gillmor = > wrote: > On Fri 2019-01-18 03:37:21 +0000, Salz, Rich wrote: > >> The certificate repository, if i'm understanding Russ's model = correctly, > >> is something published by the Root CA (or the enterprise network > >> operations team, or whatever), and consumed by the relying = parties. > > =20 > > I disagree with that. I am thinking of the trust repository as > > something that is like browser root stores. >=20 > You say "trust repository" here -- but we are talking about a > "certificate repository", right? I agree that the terminology is > confusing! In > = https://tools.ietf.org/html/draft-ietf-lamps-hash-of-root-key-cert-extn-04= = , > it says: >=20 > In enterprise and application-specific environments where a = directory > service or certificate repository is available, the oldWithNew and > newWithOld certificates SHOULD be published before the successor to > the current Root CA self-signed certificate is released. In > environments without such a directory service or repository, > recipients SHOULD keep both the old and replacement Root CA self- > signed certificate in the trust anchor store for some amount of = time > to ensure that all end-entity certificates can be validated until > they expire. >=20 > The fact the draft contemplates a scenario "without such a directory > service or [certificate] repository" but where the relying party still > has access to a "trust anchor store" suggests that these can't be the > same thing. >=20 > That said, i agree that the specification of a certificate repository = is > unclear in the document, and it doesn't point to any other = documentation > or specific examples of how to operate such a repository, or even what > capabilities such a repository should offer. >=20 > I've proposed text to Russ about how a relying party with access to a > cert repo (or what i imagine a certificate repository to be) could > minimize the risk of accidental transvalidity due to cert repo > unavailability, but as Russ said at the top of this thread, he thinks > that guidance is overkill for the draft. >=20 > --dkg > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm = > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --Apple-Mail=_6B71478E-ABEF-4046-975A-63C33D6E039A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Ryan:

I = believe that I am using the terms consistent with the figure in Section = 3 of RFC 5280.

Further, I am using the definition of trust anchor in a = manner that is aligned with RFC 5280, especially the section on path = validation.

Russ



On Jan 18, 2019, at 11:14 AM, Ryan Sleevi = <ryan-ietf@sleevi.com> wrote:

Forgive what is probably a very stupid question, but isn't = this term suitably addressed in RFC 5280? Specifically, Sections 3, 3.3, = and 4.2.2.2?

The = notion of a repository was, I thought, one of those fundamental givens = about dealing with PKI, much in the same way that this term has been an = integral part of most of the standards for publication and auditing of = certificates.

On Thu, Jan 17, 2019 at 11:14 PM Daniel = Kahn Gillmor <dkg@fifthhorseman.net> wrote:
On Fri 2019-01-18 03:37:21 +0000, = Salz, Rich wrote:
>>    The certificate repository, if i'm understanding = Russ's model correctly,
>>    is something published by the Root CA (or the = enterprise network
>>    operations team, or whatever), and consumed by the = relying parties.
>   
> I disagree with that.  I am thinking of the trust repository = as
> something that is like browser root stores.

You say "trust repository" here -- but we are talking about a
"certificate repository", right?  I agree that the terminology = is
confusing!  In
https://tools.ietf.org/html/draft-ietf-lamps-hash-of-root-key-c= ert-extn-04,
it says:

   In enterprise and application-specific environments where a = directory
   service or certificate repository is available, the = oldWithNew and
   newWithOld certificates SHOULD be published before the = successor to
   the current Root CA self-signed certificate is = released.  In
   environments without such a directory service or = repository,
   recipients SHOULD keep both the old and replacement Root CA = self-
   signed certificate in the trust anchor store for some = amount of time
   to ensure that all end-entity certificates can be validated = until
   they expire.

The fact the draft contemplates a scenario "without such a directory
service or [certificate] repository" but where the relying party = still
has access to a "trust anchor store" suggests that these can't be the
same thing.

That said, i agree that the specification of a certificate repository = is
unclear in the document, and it doesn't point to any other = documentation
or specific examples of how to operate such a repository, or even = what
capabilities such a repository should offer.

I've proposed text to Russ about how a relying party with access to a
cert repo (or what i imagine a certificate repository to be) could
minimize the risk of accidental transvalidity due to cert repo
unavailability, but as Russ said at the top of this thread, he thinks
that guidance is overkill for the draft.

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

= --Apple-Mail=_6B71478E-ABEF-4046-975A-63C33D6E039A-- From nobody Fri Jan 18 12:26:25 2019 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 D8B5D13137E for ; Fri, 18 Jan 2019 12:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcFjhQy965Kg for ; Fri, 18 Jan 2019 12:26:21 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9462131384 for ; Fri, 18 Jan 2019 12:26:20 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 3DAF3F99A; Fri, 18 Jan 2019 15:26:16 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 389D9207EB; Fri, 18 Jan 2019 15:26:11 -0500 (EST) From: Daniel Kahn Gillmor To: Ryan Sleevi Cc: "Salz\, Rich" , Russ Housley , LAMPS WG In-Reply-To: References: <154759132229.10674.3677145629770514716@ietfa.amsl.com> <6248C23D-646A-4ACF-A786-D8765870E885@vigilsec.com> <87won4e5j6.fsf@fifthhorseman.net> <87va2md7n5.fsf@fifthhorseman.net> <78AB2172-3C9F-4776-A9F5-9DEE0BF29DC5@akamai.com> <87pnsud3gh.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXECaehYJKwYBBAHaRw8BAQdAAiJ1/GyBM4kgpY/nx+sXytMi8I+x8MW0/NBq3jepKpG0FWRr Z0BmaWZ0aGhvcnNlbWFuLm5ldIiWBBMWCAA+FiEEcj40OsADMfA0c+aDe+WhH6N+hyEFAlxAmqEC GwEFCQPCZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQe+WhH6N+hyEp2wD+Ig2iiYPwXjfb yw9lIIZmFKUYmRJd/bxJFB9Zg5KPuSYBAKviNfLfhKg3na9rG0w2TT0EFbUWpOYFOIRW9TwbzsQP uDMEXECavBYJKwYBBAHaRw8BAQdAtW9Zh3mX94C9zXb6aWJ674REC+HObFdCsomqfpP4HIuI9QQY FggAJgIbAhYhBHI+NDrAAzHwNHPmg3vloR+jfochBQJcQSAKBQkB4bjOAIF2IAQZFggAHRYhBPCE Qkmi1yrjQoOwunkS3HEugE01BQJcQJq8AAoJEHkS3HEugE01GpwA/jfo1+yK5mTC5zobZLLkVc6o iUDyttDVJ62Xm1rJwYomAQC8CYfvCoXbZ51Nt60HhD7pTUcAMZfzA3tmc/8/J7jVCgkQe+WhH6N+ hyGxBAD/bDkQ2GpT6Cb5f21PXRKedDH9qqC0IAvW3yhKbZYMyVgA/14ZCT7qq6RKSXpssGm3aIoP DVXR9C332d9qveku/UMJuDgEXECaxxIKKwYBBAGXVQEFAQEHQNQj/u2sk+AagtqNdkAbtKHe9Kjd vtV0U3tS9Azbyl1tAwEIB4h+BBgWCAAmAhsMFiEEcj40OsADMfA0c+aDe+WhH6N+hyEFAlxBIBYF CQHhuMMACgkQe+WhH6N+hyEjoAEA2vfPD73af46XNV3Xwmx9pkyukkfTGsoqxjcqiklcYSIA/1kl YqSe6yBa95fK5wIW1faW/uP6Q+NJr+yb4SzugvoK Date: Fri, 18 Jan 2019 15:26:10 -0500 Message-ID: <875zulhfvh.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Fri, 18 Jan 2019 20:26:23 -0000 --=-=-= Content-Type: text/plain On Fri 2019-01-18 11:14:51 -0500, Ryan Sleevi wrote: > Forgive what is probably a very stupid question, but isn't this term > suitably addressed in RFC 5280? Specifically, Sections 3, 3.3, and 4.2.2.2? > > The notion of a repository was, I thought, one of those fundamental givens > about dealing with PKI, much in the same way that this term has been an > integral part of most of the standards for publication and auditing of > certificates. that does give a more precise definition of "repository" than the current draft, thanks for those pointers. maybe the current draft should point to those references? however, it's not clear to me from a read-through of those sections (and their inclusion by reference to the X.509 standards themselves) that there's a place for the CA to put oldWithNew in the repositories identified by an id-ad-caRepository in a id-pe-subjectInfoAccess extension. In particular, 5280 says: The id-ad-caRepository OID is used when the subject is a CA that publishes certificates it issues in a repository. since oldWithNew is *not* issued by the old root cert C1, it seems slightly off to put it there. otoh, 5280 doesn't say that *only* certs signed by the subject may be placed in that repository, so it's not much of a stretch there. Would it help if the current draft explicitly expanded the definition? Do people have examples of a root cert with an id-ad-caRepository in the AIA field? I don't see any in my local root store. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTwhEJJotcq40KDsLp5EtxxLoBNNQUCXEI2YgAKCRB5EtxxLoBN NT7OAP9fYMb3Q0zaExmyvpMlkAjgDX8VrYWAkWFdAMXbUPNvrAEAuKND4sX3YVv9 bERNjTwYTILKwn34LqUaSr71jwTZCA8= =L/l7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 18 15:17:33 2019 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 1839D131493 for ; Fri, 18 Jan 2019 15:17:32 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVmTrt0ozBKK for ; Fri, 18 Jan 2019 15:17:30 -0800 (PST) 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 61F1313145C for ; Fri, 18 Jan 2019 15:17:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9435C3005D0 for ; Fri, 18 Jan 2019 17:59:12 -0500 (EST) 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 Gl4xDTvnIcAM for ; Fri, 18 Jan 2019 17:59:11 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 27D23300425; Fri, 18 Jan 2019 17:59:11 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: <875zulhfvh.fsf@fifthhorseman.net> Date: Fri, 18 Jan 2019 18:17:27 -0500 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <0230057F-D39E-49A5-8DAE-35DA2B1B9B0D@vigilsec.com> References: <154759132229.10674.3677145629770514716@ietfa.amsl.com> <6248C23D-646A-4ACF-A786-D8765870E885@vigilsec.com> <87won4e5j6.fsf@fifthhorseman.net> <87va2md7n5.fsf@fifthhorseman.net> <78AB2172-3C9F-4776-A9F5-9DEE0BF29DC5@akamai.com> <87pnsud3gh.fsf@fifthhorseman.net> <875zulhfvh.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Fri, 18 Jan 2019 23:17:32 -0000 > On Jan 18, 2019, at 3:26 PM, Daniel Kahn Gillmor = wrote: >=20 > Signed PGP part > On Fri 2019-01-18 11:14:51 -0500, Ryan Sleevi wrote: >> Forgive what is probably a very stupid question, but isn't this term >> suitably addressed in RFC 5280? Specifically, Sections 3, 3.3, and = 4.2.2.2? >>=20 >> The notion of a repository was, I thought, one of those fundamental = givens >> about dealing with PKI, much in the same way that this term has been = an >> integral part of most of the standards for publication and auditing = of >> certificates. >=20 > that does give a more precise definition of "repository" than the > current draft, thanks for those pointers. maybe the current draft > should point to those references? >=20 > however, it's not clear to me from a read-through of those sections = (and > their inclusion by reference to the X.509 standards themselves) that > there's a place for the CA to put oldWithNew in the repositories > identified by an id-ad-caRepository in a id-pe-subjectInfoAccess > extension. In particular, 5280 says: >=20 > The id-ad-caRepository OID is used when the subject is a CA that > publishes certificates it issues in a repository. >=20 > since oldWithNew is *not* issued by the old root cert C1, it seems > slightly off to put it there. otoh, 5280 doesn't say that *only* = certs > signed by the subject may be placed in that repository, so it's not = much > of a stretch there. Would it help if the current draft explicitly > expanded the definition? >=20 > Do people have examples of a root cert with an id-ad-caRepository in = the > AIA field? I don't see any in my local root store. I have not seen the id-ad-caRepository in self-signed certificates. To address your point about definitions, I suggest: Some enterprise and application-specific environments offer a directory service or certificate repository to make certificate and CRLs available to relying parties. Section 3 in [RFC5280] describes a certificate repository. When a certificate repository is available, the oldWithNew and newWithOld certificates SHOULD be published before the successor to the current Root CA self-signed certificate is released. ... Russ From nobody Wed Jan 23 11:30:27 2019 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 ACC0D130F25 for ; Wed, 23 Jan 2019 11:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.854 X-Spam-Level: X-Spam-Status: No, score=-8.854 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEG421B7EM_5 for ; Wed, 23 Jan 2019 11:30:19 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A881130F18 for ; Wed, 23 Jan 2019 11:30:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=VjS/Z950RanfiFEZ5NbMSK3nz6LM+bGC5W65gZA83QY=; b=nMdQTDSzWbmLY6dnatDZSzIjKA oNlQ4VP+5sI3sQ5W6iCYa+/rMyVAs3jV/IeLVI3DAMwI+vijQDLAlKVihlEBIIwSdy7189MNRszVl jn9ZHv8wR4JfrEOkEcuJaBgEgr8Nq0eEPQ16bvnHHVre18Wn1bHILGHjPNJwq/o4V7tc=; Received: ; Wed, 23 Jan 2019 11:30:17 -0800 To: Rob Stradling , Phillip Hallam-Baker Cc: SPASM References: <026b92e4-055d-42b4-1448-883a01ddad50@eff.org> <1598a7ed-f3ee-2673-7d32-80993389f372@sectigo.com> From: Jacob Hoffman-Andrews Message-ID: <8a1e5c46-6943-420c-afcc-525b087b9cc1@eff.org> Date: Wed, 23 Jan 2019 11:30:17 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <1598a7ed-f3ee-2673-7d32-80993389f372@sectigo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] 6844bis: Merging sections 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, 23 Jan 2019 19:30:24 -0000 Any further thoughts on this PR? I'd like to merge and publish a new draft tomorrow. From nobody Wed Jan 23 11:50:12 2019 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 B3303130ED0 for ; Wed, 23 Jan 2019 11:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQ3a45KqDYcU for ; Wed, 23 Jan 2019 11:50:07 -0800 (PST) Received: from mail1.bemta23.messagelabs.com (mail1.bemta23.messagelabs.com [67.219.246.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E0A312785F for ; Wed, 23 Jan 2019 11:50:07 -0800 (PST) Received: from [67.219.247.52] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-d.us-east-1.aws.symcld.net id 63/9E-09496-865C84C5; Wed, 23 Jan 2019 19:50:00 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTWUwTURSGuZ12OiBDLqXIkYBKFRM1U9u6BKM mPBjTFxJjog+Ky5SOtFra2ikRjUZMRRTUoDEuBBQMblUTI1qJoCCKRBQUMK5oRUkUUOMWNiPa mYuKb/+533/P+c/kDkNpeul4RsjxCh4n79DREUrbDNM8ztZgTjfc9k1MySv8pkjpef9MnXLsc UYqZW4uzFeZKyoGFWZ/x3fVYmq5yu60uHLWqGz9l3bQ7ta0nLyX7Ypc1GIuQBGMEu+hYN+dPk oqNLhIAUcGPqtIEUSwfahYXYDCGRob4PH1RkUBYhgtXgofy9OlYwonQtH+HiT5Y3A+gp/Bbrn Q4l0IPv1sRZJLizMgUHNDbqTEyfDp/m6lpFm8EnJfH6HJtG4KTle1yyAcp8KXE7XyBYTHQn/T eQUZFwfPu47LGrAWOlvv0UTHQvfbYRXxp0Ppt3paSgo4CZ5d4YglEdqOF8rhAPvU8KKslyIgD XxPAmoCuhBUH61QETANhl68GdEO+PX1yYhOgJtfX1HkwgcV9N2/I6+pwVY46K8fSTQe/Hs7lc T0kILKK7nynhQuQxAov47IB4iGu0e7lEVoSvGo9YpH+4pH+YiJg2s36iiiJ8DVjyUhrQ7p+XD ZSk6T4GBhp5roObCz5Qtdhhg/mm3x2DNt3ize7uCMBgNnNJq4FM40S89v5qz6bJETeNHLGfX8 RlEvbsrKcFj1TsF7CYWenNXNQBW6WpBZj8YxCl0s21FlTtdEWVzWTTZetK32ZDsEsR4lMIwO2 IZbIRbtETKFnLV2R+jd/sHAROq0bL6EWdHNZ4n2TIKa0Eym7kRnKcXUDL0tpTRKp8spxMexSy Urlqy2bOffRn/+gTaUGB/DorCwME2kW/Bk2b3/8x4UxyBdDPu0NtQl0u70/p3XE4qiCEUJLJO jePl/KD4XrTNZhmpWNe6PGuB2V1s2lK/24Q9Bt6akOW1ebIDrPdumb1jAHlrv1Jge5c1NrT23 vjrCc/jk3G3P+5ObXQmTfoDLULKhfUxlR2PSVvHd3kHTg61nonyT64zDLmvQ30TfagkuWejrP XWgfcv08EWLXpWeW5j3IDw5bmzyvYvvpl5YoVOKNt44jfKI/G9pt9DX/gMAAA== X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-26.tower-424.messagelabs.com!1548272999!250822!1 X-Originating-IP: [104.47.50.59] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29835 invoked from network); 23 Jan 2019 19:50:00 -0000 Received: from mail-by2nam05lp2059.outbound.protection.outlook.com (HELO NAM05-BY2-obe.outbound.protection.outlook.com) (104.47.50.59) by server-26.tower-424.messagelabs.com with AES256-SHA256 encrypted SMTP; 23 Jan 2019 19:50:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sX4H660m57SSaxAWrQ/vcOE7uyMhTT9dGSz2ZMs9uLU=; b=rTK2Pm86fYFkUxDo1y5nabh5W0BkliSKvPOC2nF//pDd0Jn36WNK9r3Vaa5hj1ozozhc0y6CNZOwmfBTXZcpaqD9pbwt5kp9VTc7HUGVd96f/KXVZx5HauaaHlcYsowXvNnV5TsO2y2+qvG+oWF8bfxv92/UtAYySXTM+yBmeiQ= Received: from DM5PR14MB1116.namprd14.prod.outlook.com (10.173.131.10) by DM5PR14MB1594.namprd14.prod.outlook.com (10.173.222.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.17; Wed, 23 Jan 2019 19:49:52 +0000 Received: from DM5PR14MB1116.namprd14.prod.outlook.com ([fe80::b807:5f96:1035:baeb]) by DM5PR14MB1116.namprd14.prod.outlook.com ([fe80::b807:5f96:1035:baeb%7]) with mapi id 15.20.1558.016; Wed, 23 Jan 2019 19:49:52 +0000 From: Tim Hollebeek To: Russ Housley , Daniel Kahn Gillmor CC: LAMPS WG Thread-Topic: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt] Thread-Index: AQHUrfJRqdhTDP+WUUy800dyQk+81KWyidAAgAHEZgCAABQhgIAABSEAgADOhICAAEY4AIAAL9uAgAehW5A= Date: Wed, 23 Jan 2019 19:49:52 +0000 Message-ID: References: <154759132229.10674.3677145629770514716@ietfa.amsl.com> <6248C23D-646A-4ACF-A786-D8765870E885@vigilsec.com> <87won4e5j6.fsf@fifthhorseman.net> <87va2md7n5.fsf@fifthhorseman.net> <78AB2172-3C9F-4776-A9F5-9DEE0BF29DC5@akamai.com> <87pnsud3gh.fsf@fifthhorseman.net> <875zulhfvh.fsf@fifthhorseman.net> <0230057F-D39E-49A5-8DAE-35DA2B1B9B0D@vigilsec.com> In-Reply-To: <0230057F-D39E-49A5-8DAE-35DA2B1B9B0D@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [98.111.253.32] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR14MB1594; 6:sr0KChd8nrMWekPF6amTp6XNUbfZBg46rUPaEoULJGWOudwqEX0619a6lNbXutdFHC1e+enmMLLvAd/rKx1rzC0238nIrv58GiUElG2i3ooVj5DHyA+eC+jt98ilW3PJ9FW6TYmQ553KrX/VIEB/Vnw7e3zrZQ34q0g+mDN8HnXrgdIMkHnpG2IjYhn990CUhIF0EnLMvxeWfMDxrhb3wGI5UTsBUiRkWqs9ecOCl3WcOCaenRYA8OBl/n5ClEDMKt5Xlll57NMsng0U+ifn1AI2TRxGf6tQovlbI5t8u/GGgoFqSw6eVVqDJp3FquEDdfbPCow06lwru0aDR7qmAvr9QIsSStxO2qoVlK2yAxwubbq9EWSsRsGcnWo+5pzFsYfT4LZk3SaBEYL/193Z1CyUx8eRo4v8IHDemDyA8ET0gXWtPy8G4MT4+rJSRoYBOlG+GQUMJDeYvmCc6HNajQ==; 5:zMWecbou5IQciUT/eM3Us6k01NonvRhVnIz+b0RmB8tX6hnUseW0pdMBPHFO0GUOAfgjPZR8NEuqDSEF8uiOeGbUVEh5nZ9x1irfyeEZhSn0SRPR7wPa8UsoNj1v59Fm8s9sm0/vj8acISx/AZA6dACc2cZeJNefmtwsW/7LF3Zgu+BjsJY8Lox2IOXvRZ/gCO8VAZWJ/IR+WHLB0IfLJg==; 7:oC72s66Wwz1Mod609cFImrjSSWH8QrUQF2nTi//veA3yC12I0kK6mvh6e0abzQKvB82LFpaMiurRlpE8sANo9RSeXwQqZGnf76IO/H8y5aTkLotvaiLiJdB8hvTBKdnZ3+12XdTshksj9Bi9+DOIhA== x-ms-office365-filtering-correlation-id: fefa6bd9-1e0b-44ff-25f7-08d6816bf0db x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605077)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:DM5PR14MB1594; x-ms-traffictypediagnostic: DM5PR14MB1594: x-microsoft-antispam-prvs: x-forefront-prvs: 0926B0E013 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6029001)(376002)(39860400002)(366004)(136003)(346002)(396003)(13464003)(199004)(189003)(44832011)(7736002)(305945005)(26005)(6306002)(102836004)(6116002)(3846002)(74316002)(9686003)(106356001)(186003)(446003)(14454004)(8676002)(81166006)(81156014)(256004)(6246003)(8936002)(53546011)(2906002)(6506007)(966005)(105586002)(53936002)(68736007)(11346002)(71200400001)(33656002)(478600001)(7696005)(71190400001)(6436002)(66066001)(4326008)(97736004)(99936001)(486006)(229853002)(93886005)(316002)(25786009)(99286004)(55016002)(86362001)(476003)(76176011)(110136005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR14MB1594; H:DM5PR14MB1116.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: YGuNlgGoRcCJAU8Wa20whag6wFpBYcqeDBEP1VG3QjUywT/TZ+0CmkC0SiP3IcpHyRV8jS6ugJnrcSwd7MRQpJmmpmEFHqHgBl3airNnwMXx634mrJMZSeBKMi2Gdw2rUGBJpKhQnqabXEwtTT2aByIY9ECuza5DR3qAplK1NBEquuXJl8ABcpBiOIWuKLCjOX4hie+1TOxqMTmK4zQlz70n0xUgQ5Ldi+3jpafzuCgewq6ii++vHTnFwpJ6fNR4jGndbRxsp+wul+iwwbkuMWfvdX6n/uHaUduga0tlLciiv+uLbJri6+607KhRHs5/kV7VSwDYpxpP/Ez592LvCW47eNuWTjqe7vFKbm6nHi4X6stDzAWjkDD/UbsAghCejgL2/FwehgOrE0uUbycmhaAEY621aOv6NtZm/DoKuZ0= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_028A_01D4B32A.E1149D90" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: fefa6bd9-1e0b-44ff-25f7-08d6816bf0db X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2019 19:49:52.1461 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR14MB1594 Archived-At: Subject: Re: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Wed, 23 Jan 2019 19:50:11 -0000 ------=_NextPart_000_028A_01D4B32A.E1149D90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Any comments on resolving this issue as Russ suggested? It seems to clarify the issue helpfully. -Tim > -----Original Message----- > From: Spasm On Behalf Of Russ Housley > Sent: Friday, January 18, 2019 6:17 PM > To: Daniel Kahn Gillmor > Cc: LAMPS WG > Subject: Re: [lamps] HashOfRootKey when no certificate repository exists > [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt] > > > > > On Jan 18, 2019, at 3:26 PM, Daniel Kahn Gillmor > wrote: > > > > Signed PGP part > > On Fri 2019-01-18 11:14:51 -0500, Ryan Sleevi wrote: > >> Forgive what is probably a very stupid question, but isn't this term > >> suitably addressed in RFC 5280? Specifically, Sections 3, 3.3, and 4.2.2.2? > >> > >> The notion of a repository was, I thought, one of those fundamental > >> givens about dealing with PKI, much in the same way that this term > >> has been an integral part of most of the standards for publication > >> and auditing of certificates. > > > > that does give a more precise definition of "repository" than the > > current draft, thanks for those pointers. maybe the current draft > > should point to those references? > > > > however, it's not clear to me from a read-through of those sections > > (and their inclusion by reference to the X.509 standards themselves) > > that there's a place for the CA to put oldWithNew in the repositories > > identified by an id-ad-caRepository in a id-pe-subjectInfoAccess > > extension. In particular, 5280 says: > > > > The id-ad-caRepository OID is used when the subject is a CA that > > publishes certificates it issues in a repository. > > > > since oldWithNew is *not* issued by the old root cert C1, it seems > > slightly off to put it there. otoh, 5280 doesn't say that *only* > > certs signed by the subject may be placed in that repository, so it's > > not much of a stretch there. Would it help if the current draft > > explicitly expanded the definition? > > > > Do people have examples of a root cert with an id-ad-caRepository in > > the AIA field? I don't see any in my local root store. > > I have not seen the id-ad-caRepository in self-signed certificates. > > To address your point about definitions, I suggest: > > Some enterprise and application-specific environments offer a > directory service or certificate repository to make certificate and > CRLs available to relying parties. Section 3 in [RFC5280] > describes a certificate repository. When a certificate repository > is available, the oldWithNew and newWithOld certificates > SHOULD be published before the successor to the current > Root CA self-signed certificate is released. ... > > Russ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm ------=_NextPart_000_028A_01D4B32A.E1149D90 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 CQUxDxcNMTkwMTIzMTk0OTQ0WjAvBgkqhkiG9w0BCQQxIgQgW29oF31cBTtihuEKZwhl9RnrjC4H 4GtcoUemmzP6p7owgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAKb1skEhzfAKFN1lKmM6gUfBotlzeJTcj3IQy3ZPvQTiBlURxdfBunPNHJk8k7Z2QHUSbXSf CjtAPidjxnCyxmQruexUZzYAy46mjBvf1yNl+PTnXuJfZaBDMAinycAvSBQmxn3i1gdr++SngI4f zqicVApytPeJ1HJBdVxvnpaoSFK1KqUi8AI5zllcTWvJD1kjY1qfrQqqQNERqmeKjYHlBl0Zxdcw oQIwErI8bq0wGzM+E9kB7d1NyeEdcQmD0PlPc5mJJLkaDL7qFjE+H/ZbD2xRqSihSC+KvHEhXDvJ UQ/lCFbdMpvlFHPzaHY4juTlVh9uehO3K7laWsg8ElUAAAAAAAA= ------=_NextPart_000_028A_01D4B32A.E1149D90-- From nobody Wed Jan 23 16:17:35 2019 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 6292612950A for ; Wed, 23 Jan 2019 16:17:34 -0800 (PST) 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_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qUde8-8tHhR for ; Wed, 23 Jan 2019 16:17:33 -0800 (PST) Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com [209.85.167.172]) (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 DA7C012D4EA for ; Wed, 23 Jan 2019 16:17:32 -0800 (PST) Received: by mail-oi1-f172.google.com with SMTP id y1so3411054oie.12 for ; Wed, 23 Jan 2019 16:17:32 -0800 (PST) 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=uYIHGnXdDWKnFMh9TFjEQ8fLo6vm0CFDnmWNL+yaavk=; b=IoT7qi5OAvM5Pv3U1p7QfqvPP9stKVbM9Kky2zgKCW206G2VPlt92REc+b6ho5z5we evIQRft1Er0i7m9pUhE6frD4/QnIgEairAbKTScTWae7tElolpVn8bXWGUtwuE5o9zfj n+s1JDeVpZMlsaHDEiUM3ZZqYTbUGVYxUVCOthhO84EESZU+0fgOtqufZE0KpE4U7xqN 3TJieNKEWrbSluHhXGpkZfwpBdiCU0YC2zvENq0m4xQ8ftGHUcHTuZgKR+g0dhyCIxRb o1z+9k/uXHUmKGnfejgLjpURFX9MaZZwgCuYJBeuuCd6DS/ljtlYIJdf0HmqQeI0taoH AQuw== X-Gm-Message-State: AJcUukfT3+IC0rzsbWEa6S4OjRFwHRMNQl55dWqBtWwx4fow+K7y+VZL 9n/y8NPS/N4BqUHWoA6R6PhIP2F1i5FC0wbsB88= X-Google-Smtp-Source: ALg8bN4pnhw8pUQX/wloXUv7qaW+PCiWyXL7dkc3a/KBmM07rnObmbxDcWq73q36Hb20DBsknC2q8TnWxomtav9l3TI= X-Received: by 2002:aca:5fc5:: with SMTP id t188mr2875470oib.103.1548289051851; Wed, 23 Jan 2019 16:17:31 -0800 (PST) MIME-Version: 1.0 References: <026b92e4-055d-42b4-1448-883a01ddad50@eff.org> <1598a7ed-f3ee-2673-7d32-80993389f372@sectigo.com> <8a1e5c46-6943-420c-afcc-525b087b9cc1@eff.org> In-Reply-To: <8a1e5c46-6943-420c-afcc-525b087b9cc1@eff.org> From: Phillip Hallam-Baker Date: Wed, 23 Jan 2019 19:17:19 -0500 Message-ID: To: Jacob Hoffman-Andrews Cc: Rob Stradling , SPASM Content-Type: multipart/alternative; boundary="000000000000f200280580292213" Archived-At: Subject: Re: [lamps] 6844bis: Merging sections 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, 24 Jan 2019 00:17:34 -0000 --000000000000f200280580292213 Content-Type: text/plain; charset="UTF-8" Working on it now. On Wed, Jan 23, 2019 at 2:30 PM Jacob Hoffman-Andrews wrote: > Any further thoughts on this PR? I'd like to merge and publish a new > draft tomorrow. > --000000000000f200280580292213 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Wor= king on it now.=C2=A0

On Wed, Jan 23, 2019 at 2:30 PM Jacob Hoffma= n-Andrews <jsha@eff.org> wrote:
Any further thoug= hts on this PR? I'd like to merge and publish a new
draft tomorrow.
--000000000000f200280580292213-- From nobody Thu Jan 24 02:48:56 2019 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 555B31310ED for ; Thu, 24 Jan 2019 02:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=comodoca.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 zqQ3B8x5zTbN for ; Thu, 24 Jan 2019 02:48:52 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740049.outbound.protection.outlook.com [40.107.74.49]) (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 9CF381310D6 for ; Thu, 24 Jan 2019 02:48:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector1-sectigo-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pumv/tWGnYx2rqckqmAEo7C8IilXHRyL6kwfSnuQPLk=; b=En3ODp7rgUiFJcmRpl8izE1t5VnK8up5C2ObdBL/TmEfxNgSh1SOdMSLdoB/WEs7khJ9Qxkn2kAhUbDKylpgzzEcvlC+hFJT2kQA9/JgvQnuCeieTz4T06UV8LWz3qaGOFnVXhwLZpzSItxswDnl9QZs3jP78iOO13g9U4vS3N8= Received: from DM6PR17MB2716.namprd17.prod.outlook.com (20.178.224.155) by DM6PR17MB2124.namprd17.prod.outlook.com (20.176.92.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.27; Thu, 24 Jan 2019 10:48:48 +0000 Received: from DM6PR17MB2716.namprd17.prod.outlook.com ([fe80::9820:6f4a:7762:166b]) by DM6PR17MB2716.namprd17.prod.outlook.com ([fe80::9820:6f4a:7762:166b%5]) with mapi id 15.20.1558.016; Thu, 24 Jan 2019 10:48:48 +0000 From: Rob Stradling To: Jacob Hoffman-Andrews CC: Phillip Hallam-Baker , SPASM Thread-Topic: [lamps] 6844bis: Merging sections Thread-Index: AQHUqhL5ib9P35WXpkCU0lqSsNR+2qWvDkSAgAAYs4CAAAQ8AIAOJMqAgABQM4CAALBoAA== Date: Thu, 24 Jan 2019 10:48:48 +0000 Message-ID: <704fdb9b-a1e9-aed7-8af5-3cf48a7e3f3a@sectigo.com> References: <026b92e4-055d-42b4-1448-883a01ddad50@eff.org> <1598a7ed-f3ee-2673-7d32-80993389f372@sectigo.com> <8a1e5c46-6943-420c-afcc-525b087b9cc1@eff.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: CWLP265CA0184.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:4d::28) To DM6PR17MB2716.namprd17.prod.outlook.com (2603:10b6:5:122::27) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rob@sectigo.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2a02:1788:4ff:1000:f68e:38ff:fe7a:a226] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR17MB2124; 6:h07ZLF5fmXfeF+muNrnFXvk372CcqjOlSZaIqTg1s4bVxJIfI9Ipe8zLpMSzPY0QKQ6DrpLMBUWJkwa7xYysf4X4umlCwFnS7zz9ftM3/zO4zUYmQoBP/UVHKg7ed3XFiPsWqkSWN2h4Yp2o6MrVlc5ToBgalFl3vN0pVLKDwu+pL7pdJu3nc7QKJI1EuWFvSIl7DsiCSPEJDL/ZLhwIQWvcIm7S3zCV94xwMrpEcKF1QFElViSBwLoopWnTJaqdUA2C+bXTAo58JxheGYY/rhti4+/nEyqxHrBxbWx9B0Jx+REPVRSjbMen6zZLmsqgG7QkLU4ksmyzF52c91eiR2nhDd194DAiITDDssqAjUeeQgoj5Z+eXyliRTO5QRmiJqYoAM0tK91jYAJIJ5cX7QOFUCOh36e5WQo3HpYvt2JqzdtggTKf6uFVz3NInVD0ig19MNW3gOrL93m/aebZHg==; 5:CKS5Oe42eEbDcnwx6OxExWFvVRTutxIj30GxHKA+r/K1NUTEMxOzvEjqZ69iVmBaexHslU3AWzn8eB/v1hZTOT4dABwRyCP1Vj8y865UITw0fIxNl7GUJy2198J0TBd7/vPSmEmcwL9/uzn9dPJs4FbZwQx5kLXqQ0PKYPbgQzhNx3IZ1J3aJP2VcEG5lTLUd2TNKId9E7OT4fv3JTfIkw==; 7:E8uoZjwnyp6Btr5EjjUDqWNMNMGRN7cMZArxh7DMrGqLAX2YkJvV01zPhJ1Jhshh3ym3XxjhELB3I31hDiCv4ME640a9BpObufey74LhFai3YfFVGnQx5LPn8gl92ZJX3N5QGgscE+oDfH5iHK4Z0w== x-ms-office365-filtering-correlation-id: 91427542-a810-411e-0c4a-08d681e9854b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605077)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM6PR17MB2124; x-ms-traffictypediagnostic: DM6PR17MB2124: x-microsoft-antispam-prvs: x-forefront-prvs: 0927AA37C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(39850400004)(136003)(396003)(189003)(199004)(14454004)(102836004)(966005)(2906002)(53546011)(478600001)(4326008)(6506007)(386003)(186003)(53936002)(93886005)(256004)(106356001)(8936002)(6246003)(14444005)(36756003)(6512007)(46003)(105586002)(316002)(6116002)(6306002)(25786009)(97736004)(31686004)(8676002)(81156014)(54906003)(476003)(2616005)(6916009)(446003)(11346002)(99286004)(81166006)(86362001)(486006)(52116002)(31696002)(68736007)(76176011)(71190400001)(71200400001)(4744005)(6436002)(305945005)(6486002)(7736002)(229853002)(19400905002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB2124; H:DM6PR17MB2716.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: sectigo.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: CQP/V77JEZpKKnc34prRX0zBrQbKapHJyytNJUErRObT2pTllh+Z1X+qZnmGyWOmhrADAlR8fVZc+AoCwR1Pxmmcd5ohh0yam+Y51rWqfvcEBibE6OZgHM1cAJQ21ZqrjfXOTJh8twV2f/X7cnhm2w3Fe4rQk7RmUkom/qyplCZvmmb+5bLTGPkmngeAUTlqPRSPFEot/8c+WJno0PDWrBusBI0VfldxKws1YXKAS05Emd6N2ZbbDfxYpQkwHH2nqEHlCaWSeIq4amtYqP/KQ4mEQz/gJVdeGeo/zibQdn3Xm78yrJPpRcOCAGmzv/iJ/KtATGSzFlNJBaH/x3RC9gY8BLGiK689fl5FqrtWZkOmflZ0QJIpx58PLTVX+Rsrqvvk1WfXqcRsUhZMjzbSZ1NgG8C+sPgwyi7uvKTEyTE= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 91427542-a810-411e-0c4a-08d681e9854b X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2019 10:48:47.3378 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0e9c4894-6caa-465d-9660-4b6968b49fb7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB2124 Archived-At: Subject: Re: [lamps] 6844bis: Merging sections 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, 24 Jan 2019 10:48:55 -0000 SGkgSmFjb2IuICBUaGFua3MgZm9yIGRvaW5nIHRoaXMgUFIuICBJJ3ZlIGp1c3Qgc3VibWl0dGVk IGEgcmV2aWV3IChzZWUgDQpodHRwczovL2dpdGh1Yi5jb20vanNoYS9jYWEtc2ltcGxpZmljYXRp b24vcHVsbC81KSB0aGF0IHJlcXVlc3RzIHNvbWUgDQptaW5vciBjaGFuZ2VzLg0KDQpPbiAyNC8w MS8yMDE5IDAwOjE3LCBQaGlsbGlwIEhhbGxhbS1CYWtlciB3cm90ZToNCj4gV29ya2luZyBvbiBp dCBub3cuDQo+IA0KPiBPbiBXZWQsIEphbiAyMywgMjAxOSBhdCAyOjMwIFBNIEphY29iIEhvZmZt YW4tQW5kcmV3cyA8anNoYUBlZmYub3JnIA0KPiA8bWFpbHRvOmpzaGFAZWZmLm9yZz4+IHdyb3Rl Og0KPiANCj4gICAgIEFueSBmdXJ0aGVyIHRob3VnaHRzIG9uIHRoaXMgUFI/IEknZCBsaWtlIHRv IG1lcmdlIGFuZCBwdWJsaXNoIGEgbmV3DQo+ICAgICBkcmFmdCB0b21vcnJvdy4NCj4gDQoNCi0t IA0KUm9iIFN0cmFkbGluZw0KU2VuaW9yIFJlc2VhcmNoICYgRGV2ZWxvcG1lbnQgU2NpZW50aXN0 DQpFbWFpbDogcm9iQHNlY3RpZ28uY29tDQpCcmFkZm9yZCwgVUsNCk9mZmljZTogKzQ0MTI3NDAy NDcwNw0KU2VjdGlnbyBMaW1pdGVkDQoNClRoaXMgbWVzc2FnZSBhbmQgYW55IGZpbGVzIGFzc29j aWF0ZWQgd2l0aCBpdCBtYXkgY29udGFpbiBsZWdhbGx5IA0KcHJpdmlsZWdlZCwgY29uZmlkZW50 aWFsLCBvciBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbi4gSWYgeW91IGFyZSBub3QgdGhlIA0KaW50 ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gdXNlLCBjb3B5LCBvciBm b3J3YXJkIGl0LCANCmluIHdob2xlIG9yIGluIHBhcnQgd2l0aG91dCB0aGUgZXhwcmVzcyBjb25z ZW50IG9mIHRoZSBzZW5kZXIuIFBsZWFzZSANCm5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJlcGx5IGVt YWlsLCBkaXNyZWdhcmQgdGhlIGZvcmVnb2luZyBtZXNzYWdlcywgYW5kIA0KZGVsZXRlIGl0IGlt bWVkaWF0ZWx5Lg0K From nobody Thu Jan 24 12:58:12 2019 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 9F87F128CE4 for ; Thu, 24 Jan 2019 12:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvCNH1HuHX8e for ; Thu, 24 Jan 2019 12:58:09 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8904E12875B for ; Thu, 24 Jan 2019 12:58:09 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 3A31CF9A0; Thu, 24 Jan 2019 15:57:37 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id A5DE120554; Thu, 24 Jan 2019 12:30:36 -0500 (EST) From: Daniel Kahn Gillmor To: Tim Hollebeek , Russ Housley Cc: LAMPS WG In-Reply-To: References: <154759132229.10674.3677145629770514716@ietfa.amsl.com> <6248C23D-646A-4ACF-A786-D8765870E885@vigilsec.com> <87won4e5j6.fsf@fifthhorseman.net> <87va2md7n5.fsf@fifthhorseman.net> <78AB2172-3C9F-4776-A9F5-9DEE0BF29DC5@akamai.com> <87pnsud3gh.fsf@fifthhorseman.net> <875zulhfvh.fsf@fifthhorseman.net> <0230057F-D39E-49A5-8DAE-35DA2B1B9B0D@vigilsec.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Thu, 24 Jan 2019 12:30:36 -0500 Message-ID: <87zhrq3qv7.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Thu, 24 Jan 2019 20:58:11 -0000 --=-=-= Content-Type: text/plain On Wed 2019-01-23 19:49:52 +0000, Tim Hollebeek wrote: > Any comments on resolving this issue as Russ suggested? It seems to clarify > the issue helpfully. I agree that it helps to clarify what is meant by a "certificate repository". Thanks, Russ! I still think that the draft lacks concrete guidance on how a relying party should deal with this new revocation mechanism in the context of a certificate repository that might sometimes be unavailable. More seriously, it still lacks concrete guidance for relying parties that have no expectation or knowledge of a certificate repository in the first place. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXEn2PAAKCRB2GBllKa5f +IT6AQCg2VbKqnPPDYrEkI3hmz3i7ugRK0m6ADSovWHUwddw7wEA9w/wU43C2weD arE45Lf7e1PehN7qF4OwnOkZ4TC5nQ4= =Hdvt -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 24 16:18:37 2019 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 E619D1311F3 for ; Thu, 24 Jan 2019 16:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfYpP8DY78li for ; Thu, 24 Jan 2019 16:18:34 -0800 (PST) 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 690F0130EC8 for ; Thu, 24 Jan 2019 16:18:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 926783005D5 for ; Thu, 24 Jan 2019 19:00:16 -0500 (EST) 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 CfuJq7MfmwUI for ; Thu, 24 Jan 2019 19:00:15 -0500 (EST) Received: from [192.168.2.94] (65-123-255-137.dia.static.qwest.net [65.123.255.137]) by mail.smeinc.net (Postfix) with ESMTPSA id E919E3002B4; Thu, 24 Jan 2019 19:00:14 -0500 (EST) From: Russ Housley Message-Id: <51BC8C3B-3BFC-42C4-94E2-75F4A53E9E6B@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_2AD198C5-BE7C-4BC3-A1C4-6C5D676B0179"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 24 Jan 2019 19:18:30 -0500 In-Reply-To: <87zhrq3qv7.fsf@fifthhorseman.net> Cc: LAMPS WG To: Daniel Kahn Gillmor References: <154759132229.10674.3677145629770514716@ietfa.amsl.com> <6248C23D-646A-4ACF-A786-D8765870E885@vigilsec.com> <87won4e5j6.fsf@fifthhorseman.net> <87va2md7n5.fsf@fifthhorseman.net> <78AB2172-3C9F-4776-A9F5-9DEE0BF29DC5@akamai.com> <87pnsud3gh.fsf@fifthhorseman.net> <875zulhfvh.fsf@fifthhorseman.net> <0230057F-D39E-49A5-8DAE-35DA2B1B9B0D@vigilsec.com> <87zhrq3qv7.fsf@fifthhorseman.net> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Fri, 25 Jan 2019 00:18:36 -0000 --Apple-Mail=_2AD198C5-BE7C-4BC3-A1C4-6C5D676B0179 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 24, 2019, at 12:30 PM, Daniel Kahn Gillmor = wrote: >=20 > On Wed 2019-01-23 19:49:52 +0000, Tim Hollebeek wrote: >> Any comments on resolving this issue as Russ suggested? It seems to = clarify >> the issue helpfully. >=20 > I agree that it helps to clarify what is meant by a "certificate > repository". Thanks, Russ! >=20 > I still think that the draft lacks concrete guidance on how a relying > party should deal with this new revocation mechanism in the context of = a > certificate repository that might sometimes be unavailable. >=20 > More seriously, it still lacks concrete guidance for relying parties > that have no expectation or knowledge of a certificate repository in = the > first place. That is right, and I do not think it belongs in this document. I know this is your position, and you know this is my position. i would really like other on this list to voice their views. Russ --Apple-Mail=_2AD198C5-BE7C-4BC3-A1C4-6C5D676B0179 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCXEpV1gAKCRCK5O7Q9ZwR y7+KAKCgTaFbcJoG8Gsg6o+GCJwQzjnJbgCeMngKbIz49JyvqB4mfHDNSrK4f38= =Q+pe -----END PGP SIGNATURE----- --Apple-Mail=_2AD198C5-BE7C-4BC3-A1C4-6C5D676B0179-- From nobody Thu Jan 24 16:30:22 2019 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 DD417131235 for ; Thu, 24 Jan 2019 16:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.254 X-Spam-Level: X-Spam-Status: No, score=-5.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ULdWB7PFkWc1 for ; Thu, 24 Jan 2019 16:30:19 -0800 (PST) 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 69051131232 for ; Thu, 24 Jan 2019 16:30:19 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x0P0M9SF004190; Fri, 25 Jan 2019 00:30:17 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=ET+Y1KncHMWI3MuUnbP24Bc58367ukQ+4pShjVQsjgw=; b=dciQTGB2g7M5WMA8nepGg9vgz6C29Y/4eYi7+qasVjl0bZ8f53H7CDH8D6PQ8ikCFGIK +pro9yRgCeVwKQRtrwGqlBe2pcwcodhrfLc99pgWTucwu6g8RzO8Vi4o67Cy8pt6LvDQ RqXUUdu3IkOQCpx98NEBG/5OW/4pRlDuudxs/lbJMFR/SlfoJWWsNyh8FFMY8NA2I2XW zH4Ox7lc5jAQH8ctvgEPBq3Ha7NEhTus71FbRrdwKEJvPXh863EeI3y+rQGVNaS+NDk+ WgZrEGVHsagvZESBgUJpkYwPMMNgjpK9VXNbwXoh0WnJOXjvzLKwGVdAXP7vXCeDCfg0 6g== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2q7p1v8bwx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Jan 2019 00:30:16 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x0P0GmwN003575; Thu, 24 Jan 2019 19:30:16 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2q4hua6e82-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 24 Jan 2019 19:30:16 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 24 Jan 2019 18:30:14 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Thu, 24 Jan 2019 18:30:14 -0600 From: "Salz, Rich" To: Russ Housley , Daniel Kahn Gillmor CC: LAMPS WG Thread-Topic: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt] Thread-Index: AQHUrfJRb465P3pybE6BGW6+84BbnaWympMAgAIYOAD//8BPAIAAWPMAgADOhICAAEY4AIAAL9uAgAehqQCAAWtrAIAAcfgA//+vdQA= Date: Fri, 25 Jan 2019 00:30:14 +0000 Message-ID: <6D7C5165-68E8-42BF-BED0-14D8BD0D0906@akamai.com> References: <154759132229.10674.3677145629770514716@ietfa.amsl.com> <6248C23D-646A-4ACF-A786-D8765870E885@vigilsec.com> <87won4e5j6.fsf@fifthhorseman.net> <87va2md7n5.fsf@fifthhorseman.net> <78AB2172-3C9F-4776-A9F5-9DEE0BF29DC5@akamai.com> <87pnsud3gh.fsf@fifthhorseman.net> <875zulhfvh.fsf@fifthhorseman.net> <0230057F-D39E-49A5-8DAE-35DA2B1B9B0D@vigilsec.com> <87zhrq3qv7.fsf@fifthhorseman.net> <51BC8C3B-3BFC-42C4-94E2-75F4A53E9E6B@vigilsec.com> In-Reply-To: <51BC8C3B-3BFC-42C4-94E2-75F4A53E9E6B@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190115 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.47.113] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-24_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=899 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901250000 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-24_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=892 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901250001 Archived-At: Subject: Re: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Fri, 25 Jan 2019 00:30:21 -0000 SSBkb24ndCB0aGluayBlaXRoZXIgb2YgeW91IHdpbGwgYmUgc3VycHJpc2VkIHdoZW4gSSBzYXkg dGhhdCBpdCBpcyBub3QgbmVlZGVkIGluIHRoaXMgZG9jdW1lbnQuIDopDQogDQoNCg== From nobody Thu Jan 24 17:01:18 2019 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 AE84112D4E9 for ; Thu, 24 Jan 2019 17:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.554 X-Spam-Level: X-Spam-Status: No, score=-11.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vu4hYTx1-HL9 for ; Thu, 24 Jan 2019 17:01:14 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E755128D09 for ; Thu, 24 Jan 2019 17:01:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=gq1XMFGfieQn6uffhOwufCXj1Ag3tOb/YJIlVYY7SOI=; b=3/HI4pbDVrYy9uK+62UEhgpW1U mfjwopIFrq1XZBNf6l4mpjO/76g1D9mzS3XdAQNTD1tQ9J/tSAiKc0dn+bJip4vlGMKeLIaTirR3t 9irysvrJMFxd/KB9BVJqF2/WeKOPrN2LZy39vGSlg6WnNVeK4BJTJpE+OCxvMMXt/4OE=; Received: ; Thu, 24 Jan 2019 17:01:13 -0800 To: SPASM From: Jacob Hoffman-Andrews Message-ID: Date: Thu, 24 Jan 2019 17:01:12 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [lamps] CAA: Title case for Defined Terms? 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, 25 Jan 2019 01:01:16 -0000 Rob Stradling pointed out something on https://github.com/jsha/caa-simplification/pull/5: In the Defined Terms section, we use title case, but we don't consistently use title case when referring to them. For instance we define "Issuer", "Property" and "Wildcard Domain Name", but in the text refer to "issuer", "property", and "wildcard domain name". What's the best practice on whether to use title case when referring to defined terms in the body of an RFC? From nobody Thu Jan 24 17:54:24 2019 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 9295512950A for ; Thu, 24 Jan 2019 17:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJxlq2A0WDEZ for ; Thu, 24 Jan 2019 17:54:20 -0800 (PST) Received: from mail1.bemta23.messagelabs.com (mail1.bemta23.messagelabs.com [67.219.246.208]) (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 CC6CB129508 for ; Thu, 24 Jan 2019 17:54:19 -0800 (PST) Received: from [67.219.247.52] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-d.us-east-1.aws.symcld.net id A4/DD-01919-A4C6A4C5; Fri, 25 Jan 2019 01:54:18 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTb0xTVxjGe+7tbS+EO4+ljtdGttjEaUhupV2 iLHHGJX6oTZY5Eo3RLu5Cr73V9kJ6SywmBtQhG8iGCW5IQChRjI2JjslYFjTaD/7BSGw/IEyY NPBBm9INUUQz/9zbg8o+neec5/c+73uSc1jalDJYWDEcEoOy4LcacvXS2jXreZff5S4+dpMpq WucpUpSD0eNJaeGyzfRzjuN9Yzz9OnnlDM69oTZSu9kfHJZRfhbRhpo+pWqTGwOX667Qdeizi 8aUA6rx8domImbGlAua8LHKRi4mKbIZgJBz1gXpVEGXAzDl2+ommXNeBtMR9zaMY0Lofl4Cml 8Pq5H8PLBo+zGjL9HkHkZRxplxvshcm0OkXaroLcjkg3i8Ddwdi5ImrUwUNter9eYHLwJXvX9 ndUIfwjPBs9TpFsB/DXVmdWAzZCM3zYQvQweTb5iCO+GjtmYQcsHvBJG+3iCFEKiszE7G+AjR mj44SxNjC/hu/7rBmJMIZhuP8cQowgOj/QsQH54+LhZT/QKuH1hgiEF9xkYb5swaoYJe6AlGl uY6COINiUXCu7SMD8iaQU07kIwf+569gocXgq3Tk7pm9EnbYtu17aYa1vEEYiHP69cpYn+GPq n21VtVPUGuOQhpyuhpTFpJHodHB2aMXQhNorWlwV9XikUEHx+3l5czNvtDnXl7escNuEA77FV KbwoKCHebhP2KzalOlDu99hkMdSL1Bfnqczt/gNlznhjaDlLWZdxB11b3KYPyio81ZKgSLuDV X5RiaEVLGsF7rd9LrdpaVD0iuE9Pr/6bN/awOZZzdzkXtXmlEohoPi8xBpEn7JXu5MdNDvwYr KDNunlClm0FHCtWhLWUKlKfhf09gskUKEln0M6nc6UVykGA77Q//0UKmCRNZ9bq6Xk+eTQu34 pdRRKHeX37U5tlJDw3rLUov5Dg3UjDzxckQjb/i1NVOnsZTO9Gw8vES6utngjrmTmxbWcIVd6 7r78NHYvfaa1NPxZ+T+p16ur5Zqf4j+2rhnPnT+iXBobjw+lS2vMUk/EUJ2J/Pd5d2JXOuN4n fnFcSLws+7C7h3DLdTWQ31N5VFn4u7T0c1jXxV8PVuzfJXDqlckwV5EBxXhDVReTqH9AwAA X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-40.tower-424.messagelabs.com!1548381256!329362!1 X-Originating-IP: [104.47.40.55] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9025 invoked from network); 25 Jan 2019 01:54:17 -0000 Received: from mail-co1nam03lp2055.outbound.protection.outlook.com (HELO NAM03-CO1-obe.outbound.protection.outlook.com) (104.47.40.55) by server-40.tower-424.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 25 Jan 2019 01:54:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5Gq9D3R4D2nUYqKxca8FMO+q3mWLtQiY+A/PyTsW5i0=; b=TZtYdFsZecj+0fB/LLWX8hh2PfUZKZE3E6aK6dX0a828U90qcxRodV4FavhRLdBPQOjoxvvbTPkv5dsglBn+zEQAy6CMfWMxAcuDboeP3k2I9nNHnynqCaZsIFtaI0d4ncslsBO+MNs6CpibKVET5MCkrwDiGKdrENjPJwXlPMs= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1362.namprd14.prod.outlook.com (10.172.149.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.28; Fri, 25 Jan 2019 01:54:16 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::34c2:edc4:19ee:d9b0]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::34c2:edc4:19ee:d9b0%10]) with mapi id 15.20.1558.016; Fri, 25 Jan 2019 01:54:15 +0000 From: Tim Hollebeek To: Russ Housley , Daniel Kahn Gillmor CC: LAMPS WG Thread-Topic: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt] Thread-Index: AQHUrfJRqdhTDP+WUUy800dyQk+81KWyidAAgAHEZgCAABQhgIAABSEAgADOhICAAEY4AIAAL9uAgAehW5CAAWu5AIAAcfcAgAAZgFA= Date: Fri, 25 Jan 2019 01:54:15 +0000 Message-ID: References: <154759132229.10674.3677145629770514716@ietfa.amsl.com> <6248C23D-646A-4ACF-A786-D8765870E885@vigilsec.com> <87won4e5j6.fsf@fifthhorseman.net> <87va2md7n5.fsf@fifthhorseman.net> <78AB2172-3C9F-4776-A9F5-9DEE0BF29DC5@akamai.com> <87pnsud3gh.fsf@fifthhorseman.net> <875zulhfvh.fsf@fifthhorseman.net> <0230057F-D39E-49A5-8DAE-35DA2B1B9B0D@vigilsec.com> <87zhrq3qv7.fsf@fifthhorseman.net> <51BC8C3B-3BFC-42C4-94E2-75F4A53E9E6B@vigilsec.com> In-Reply-To: <51BC8C3B-3BFC-42C4-94E2-75F4A53E9E6B@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [98.111.253.32] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1362; 6:FxCcbeI70CnkIVlTp/h682IWLw/B6Zfokk90H0E36XTpesy1yc21/EQvfkqLgb3x6e/dUyzq39tpI5/4+HdIb0IgeR8kHLW1HH/AT+5Sdh7LXA03yMp+Ipow5AbbEudlq99LEBBa6qkpcQxO28FZO5AiwXoFQJbT8pdvTLBb/hv0IeXvyLk+L0htAdnyOJYpG6v6In0HaNQoaEYK4khs6hs3xx0uozBOcdSv086olw+aB1KquUkSRff9nt9ma+KBlqg3+dy8fSF9hKMzA2jVw7QISKSDZNAnhRqcEKMXKRbIpix6N5ZYKoo4GIS4LDrGtDgwr96dtpPofMepwcTksTf2QyfYzU1zv70Lr0xGXvyifmdQqIn4muiC8KYAvwaRwlmLH2GKty8Uql4KoXidxRSpaCRgQdwK+YgtE0JT4530n6qeGTfpkv9Vv0uWJo6RM1vs1c1O57OFPceTvgEI2Q==; 5:eDaMngcOJjU72qnTHetUUt0xHBGHVP3NkM8Updk8SA9/2CwvX9lf0hYUtl313dZaK0Pa8u/iH5P83hHm/U79/lcaRsEk33sZobwe/5/wFWgsaE8PqluIPO/56eNUW65ffPldXqPVNxW9uHNImXZlxxjn9TIxYW3ziuw5Wx/Bd4vhbU+rezw84lT8lRlSKYY0SsJkhhkhnxf9SGluZL0+Vw==; 7:Mi6R1tG2f5edSXqwUEiLTOxNlzHcd6j15MmtrwK9KZ4+rFT1UHNAlOvAY+gaBYUNbbSfclVzWQ3Nz2OKnFFVE2O1TVrHkSQ/e7ebjrr7mJFl3/awS0j2aqXg5MHVI4QvmB19H+Pe33zmDedmpu9HVw== x-ms-office365-filtering-correlation-id: 1681c569-1086-41e0-b0f7-08d682680308 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1362; x-ms-traffictypediagnostic: BN6PR14MB1362: x-microsoft-antispam-prvs: x-forefront-prvs: 0928072091 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6029001)(366004)(396003)(136003)(376002)(346002)(39860400002)(199004)(189003)(13464003)(71190400001)(71200400001)(93886005)(316002)(7736002)(305945005)(76176011)(7696005)(446003)(8936002)(99286004)(102836004)(81166006)(81156014)(44832011)(26005)(6506007)(476003)(11346002)(53546011)(486006)(110136005)(74316002)(86362001)(68736007)(186003)(8676002)(66066001)(256004)(14454004)(2906002)(3846002)(6116002)(33656002)(6436002)(229853002)(4326008)(25786009)(99936001)(105586002)(106356001)(53936002)(6246003)(55016002)(97736004)(478600001)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1362; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5YdQ4wjLSsVwcODEet5HIyR+ipYGnwc+niLPFyEXNPHtzpQcLTWmE/QsI1e9LfRCW458z2bVOwdiE8edKVLzomrZX6WAeTrmYPUfgOK2U1mOJUC2w/N2B3UHuoM/EQbmmeqfN1bbzBPDimoKKI2A9TVgmDdycABEvOvVuAmg1EvllimHvQxCMrMB7Xlj0i963hBwlj1ni11QlrO6ZBqch5tO7Onk+YbGpE0RWzl/cVR0DxHR1mvOBqq6YpGFkKNMLDh7nhIUJMlBD8/UfWCYwSuBpRqRivAfijk3lPh/zjtTZbh8ItyfXirEhNc0QyjdcB9SK4LYGI7MTKtRRwc3+PtLkgh8CK7VIYyPKzi2njNQRswDbciQTyvI4MdAnd8JR/vn2/fYCLbhXH75MZeEUWdzXujvlFasU88HASeqlpM= Content-Type: multipart/signed; micalg=2.16.840.1.101.3.4.2.1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_002F_01D4B426.F1D51EA0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1681c569-1086-41e0-b0f7-08d682680308 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2019 01:54:15.6362 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1362 Archived-At: Subject: Re: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Fri, 25 Jan 2019 01:54:23 -0000 ------=_NextPart_000_002F_01D4B426.F1D51EA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Is there anyone other than Daniel who thinks this is necessary? There is always the opportunity to address this in additional drafts and revisions if it turns out to be needed. There are no concrete proposals for addressing this, and I'm struggling to understand why that guidance needs to be in this document, so I'd suggest that it would be best if this issue did not block adoption of this draft. -Tim > -----Original Message----- > From: Spasm On Behalf Of Russ Housley > Sent: Thursday, January 24, 2019 7:19 PM > To: Daniel Kahn Gillmor > Cc: LAMPS WG > Subject: Re: [lamps] HashOfRootKey when no certificate repository exists > [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt] > > > > > On Jan 24, 2019, at 12:30 PM, Daniel Kahn Gillmor > wrote: > > > > On Wed 2019-01-23 19:49:52 +0000, Tim Hollebeek wrote: > >> Any comments on resolving this issue as Russ suggested? It seems to > >> clarify the issue helpfully. > > > > I agree that it helps to clarify what is meant by a "certificate > > repository". Thanks, Russ! > > > > I still think that the draft lacks concrete guidance on how a relying > > party should deal with this new revocation mechanism in the context of > > a certificate repository that might sometimes be unavailable. > > > > More seriously, it still lacks concrete guidance for relying parties > > that have no expectation or knowledge of a certificate repository in > > the first place. > > That is right, and I do not think it belongs in this document. > > I know this is your position, and you know this is my position. > > i would really like other on this list to voice their views. > > Russ ------=_NextPart_000_002F_01D4B426.F1D51EA0 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 CQUxDxcNMTkwMTI1MDE1NDA1WjAvBgkqhkiG9w0BCQQxIgQgz80IkKPNS53J4EQ8FaEUtOxN7BzH 9KQZ97d4Nmv1eRIwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAC9gtsZnqtJQzSqopyqNV2vG+fPvEymstlV++mEMXRpPQLZZmeY/pz1br2D2h/KQmbqsh93N 8HToP+85tsq12LIK7LOR6FnWvJ6kqwetlwVLJWF6m7VEFemmFwawPmt18cerPjSOStyhuxxFj1g/ Vzvkl3jSCBAPi7CPAGser5koMrc5wa355z8+/U69bZLIR59/5Dh8saRBWysMfpZ+8rqRckzdAMPR T2RBTcVclwftXv84cncSeoac8AGwUZ5spcru6Y6b8IB85u5ZCi82Qq+G0roGuh93P40vVjr1tfUY TVTC6+p3FMeleoCxGi7YFPFXtTBd+oRQq5EmGE4Y65kAAAAAAAA= ------=_NextPart_000_002F_01D4B426.F1D51EA0-- From nobody Thu Jan 24 17:58:36 2019 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 C68B012950A for ; Thu, 24 Jan 2019 17:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0e1Xe1qmrmxL for ; Thu, 24 Jan 2019 17:58:33 -0800 (PST) Received: from mail1.bemta23.messagelabs.com (mail1.bemta23.messagelabs.com [67.219.246.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B10C129508 for ; Thu, 24 Jan 2019 17:58:33 -0800 (PST) Received: from [67.219.247.52] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-d.us-east-1.aws.symcld.net id F1/9F-09496-74D6A4C5; Fri, 25 Jan 2019 01:58:31 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0hTYRjHfc85247m5DS1Pa0bjuyDcZaTTMv CgoolFAbhhzDq6E5utc2xM8miMCy6qEGElVppyNK8lF1s3U1XIWnYFW0R5dSyDBWz24Iu5+zV sk/v733+z+X/wEOTqpdyDc3nOnmHjbNo5SGUad7sBHalNSU91ntvfmLpc788sbwzcylhGPrUL zO4XH4ilVgvM9sysnM3yUwXrtVR9jPJuUN9LmI3KlxSgEJoiiki4fsZv0z6qJjDBIx86kYFKF j8dCPoaZwmsZyJhc7brYTEEcxSqDx+gJQ4nEmAE939JI4nwuXBFoQ5Dh421Mkkppho8OfXBFj JbID71V8J3H8RjBbVBGqDmSTo+jiskBgxU+BbW30gh2TU8LKvIsDARIDvSbsccyR86P0l9qRF jgLvFRaHZ8DTikIk7QLMHgXszW8Zy18ND9vrZVjoQ3CnxqXAQgz87rqFMFvAN9wzFp8O7Q3dY wVeGbQ3uRXYtRGKaz1y7DQdTo16xibMhNpDPgoXPCbhiL8h4INkTiP4XVZE4f0nw4PSPmrc7E nvZ/Iwii6bsGrZxJqyCTU4iYUbTc0k5llwdfCkyAqRF0OjEUejoLjQp8C8APZ1jMhPI7oWJWQ 4zFkmp5UzW1h9bCyr18eJLxunj9dxO1ijLkdgeU5wsnodt03QCdutmRajzsY7LyHxzoz2kK5r yF2d5UFTaUIbqdyVsipdFZaRbdxu4gTTRkeOhRc8aDpNa0F5eWtKumqyg8/iczebLeKxjstAh 2ojlL1bRFkp2DmrYM7CUhti6eZK3ylSRdmybbxGrSyRejBSkinH9rfF+Mk/RTM04UoUFBSkCr XzDqvZ+b8+gNQ00oYr50ldQs02599JA6IJQjThTjNIJpzcP0mzG3kWrDn6uu5A/c/M602GdS2 N8d8yUjcczKOTitQhYe87sp9Rr8rNvTeR+vy5Ys2yuMLKd23b3JPeDCRNrZq75u1yd6ss/oVq Ts+PhV/zF3baYzbqhjdVrWgdKBkm8nSf73aknV2709ucl3ysgq1+FHppRe2Wi3Obv+QZjt8WV h+K3p/Sr6UEE6ePIR0C9wfxNyDE7QMAAA== X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-7.tower-424.messagelabs.com!1548381509!330448!1 X-Originating-IP: [104.47.36.55] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14394 invoked from network); 25 Jan 2019 01:58:30 -0000 Received: from mail-sn1nam02lp2055.outbound.protection.outlook.com (HELO NAM02-SN1-obe.outbound.protection.outlook.com) (104.47.36.55) by server-7.tower-424.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 25 Jan 2019 01:58:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8DFSceYA4JfP3vAg3cJGrGXJAJrBizEViUyJCQXP/o0=; b=RM33bz/VbKbmhMAtLrnssL3+NtSsCouuItUNJiDV5cxfDDaZhLxsAlw/kYnfMkp4+cZYRHCkEf5glmv2n/tuRcpKK+zYxSj0yuYV6GbsKrTnptXF3QXWxWS+NziLuAgIJmO+lvgvyfGCpkPi8davH7MaBv/On8VF6Sbqx1gQnO0= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1105.namprd14.prod.outlook.com (10.173.161.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.16; Fri, 25 Jan 2019 01:58:29 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::34c2:edc4:19ee:d9b0]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::34c2:edc4:19ee:d9b0%10]) with mapi id 15.20.1558.016; Fri, 25 Jan 2019 01:58:29 +0000 From: Tim Hollebeek To: Jacob Hoffman-Andrews , SPASM Thread-Topic: [lamps] CAA: Title case for Defined Terms? Thread-Index: AQHUtEl+yHKlKISCdkmJnBQ7J4GVOKW/Oa8A Date: Fri, 25 Jan 2019 01:58:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [98.111.253.32] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1105; 6:TplP2urchnyuMQ8F/r1PLplLI73RXzbgf6LTpPW9/y93kv749cu7BU4LoUUjs/eLxb8WF552JGHGkm1I/ZKO40mki3V2m1wFvBaEkam8XkbEi8NGpn/1kKSfFl5LGflS1ll/FDo9CAUo8qhIuTL/x9t99c8PRQul7PP+io6vzsCgmddIAi3MtM4OzLF34fnKPxlM0KeMfw+wUSRRsPnbl3CPMmp6HMVC3m0so6j88hYtOj1n74qERpvTx9jbX3kdmEDv2zF9zT7LQkOJu9oGUjkFvagnLp1mx6mxqsaSaS10JTgYLpEAaVjR8Wye4JJxAFg4D/xDDZ+ERtsRoXkFuBZDUzGnDRgMlPCap1iDNVs5UcHycOtrt50bcd82SGvnjBXlT/0Vz+pRy52Zk+3n0eCgc35an9Yj7Y3o5O4IyzXTu3gxSCUN37bqVCmEATXBaBYsAO45NukQjnGfsGvE0g==; 5:w8ZSfvnlU0PAtIrbf2spMQrNc9Rv7YMofNwI6tkU/L6pYFSZtenDN/62M3sGufA6j9eoSgC4J2ld2lRPl9PP2jbkOIVjBL2fqnK2GHaOCbEOsz4OE7jtNBJNeSTIHIKVTH7XfWsUXBxR8OGpibFy6ZXdo3vG+JfTcuDWQnm3Pxujx6ompWgCKaFTNfxkCN2K2G8qDccCv5II6SjVH6umfQ==; 7:tp1RXsaqQ72BlwVsTRtDKcjRaFKwhvDDDYLv46OysnI9zkXF63CrnhkLJKlm+uNhjk5LiuFnyh9j5GkvYYBnZHsh9ZIvKO0jhcsSESuEoMNOg3qvlBig8g5GYZSrBWs4BKniCJfPEyngXYkn+fBhZg== x-ms-office365-filtering-correlation-id: 8326c95e-902e-40d6-f404-08d6826899f8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605077)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1105; x-ms-traffictypediagnostic: BN6PR14MB1105: x-microsoft-antispam-prvs: x-forefront-prvs: 0928072091 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(396003)(39860400002)(376002)(346002)(13464003)(199004)(189003)(476003)(14454004)(7696005)(486006)(478600001)(6306002)(11346002)(446003)(76176011)(110136005)(229853002)(316002)(53546011)(6506007)(99286004)(71190400001)(9686003)(102836004)(2906002)(99936001)(6436002)(966005)(71200400001)(44832011)(26005)(186003)(6346003)(66066001)(55016002)(97736004)(81166006)(81156014)(8936002)(8676002)(53936002)(7736002)(6246003)(74316002)(105586002)(86362001)(68736007)(256004)(25786009)(6116002)(3846002)(33656002)(106356001)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1105; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ZN5dWIEqSXNonMi2HEAfWmn8z5suKWdq386yafGmp1lsGatPSuX/zwtq2sRmtisvEqjKZ6I6VuUg2ZvgfqAa736MqyqH2xZmCFWYn9sEOg4l1lbVl55s39SDJybi0Icmgz4qIm41vOFNICv/cr1WkIN/MISKUP1U86uRT+aCRkzCOBr8jnr7/P6Bse8nKAa/z/aNSBW88UBQvWJLErFTt9BP4tVw7ig0uqdyB9hcIs7tBh+wkCDWrApQ7Vs32wuxVc8RT01vKrhT9dCn5Ic4gmP/1rBql56eg8uc4i9vLtnUd7d+bHZQujKYVTsnp9YSP9n+4H0hlxxK3AH/RSd7WHEWv9JddDLqOt9iPzenPBWcZU9fdOL6CDcYRsLS/T0Tk8AT1R+xJIRuSq9raIysDJRPmhCO7lmw8dTJRJmqUJ8= Content-Type: multipart/signed; micalg=2.16.840.1.101.3.4.2.1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0034_01D4B427.88F77530" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8326c95e-902e-40d6-f404-08d6826899f8 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2019 01:58:28.8540 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1105 Archived-At: Subject: Re: [lamps] CAA: Title case for Defined Terms? 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, 25 Jan 2019 01:58:36 -0000 ------=_NextPart_000_0034_01D4B427.88F77530 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Title Case Should Be Used Consistently For Defined Terms. This Makes It Clear That It Is A Defined Term. Rob Stradling is a Smart Person and if we aren't doing that consistently, we MUST Fix That. -Tim > -----Original Message----- > From: Spasm On Behalf Of Jacob Hoffman- > Andrews > Sent: Thursday, January 24, 2019 8:01 PM > To: SPASM > Subject: [lamps] CAA: Title case for Defined Terms? > > Rob Stradling pointed out something on > https://github.com/jsha/caa-simplification/pull/5: > > In the Defined Terms section, we use title case, but we don't consistently use > title case when referring to them. For instance we define "Issuer", "Property" > and "Wildcard Domain Name", but in the text refer to "issuer", "property", > and "wildcard domain name". > > What's the best practice on whether to use title case when referring to > defined terms in the body of an RFC? > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm ------=_NextPart_000_0034_01D4B427.88F77530 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 CQUxDxcNMTkwMTI1MDE1ODE5WjAvBgkqhkiG9w0BCQQxIgQgJNGz+yzoE3qLR5CLQ67pajXNmGs4 ycqiJTqYE304i8YwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBALNLFaBCAh7kYip45t2nfiD7b+YlB6zU54cpo+0dxGAIWMrCpjf+aEIr+zokCwz0+GGFN5am /tccUdO4v5vvPt3NJWQG8+fLV140gvdrFjccjtvH6lpEofaprXw3NchB+NzZOYNkVWOouali1DDq SfguVhTj7y9Lm3gM4QQ2ykzNI5tx/XOuBIhs694PdbsPAel0xwu6EgCYNWgsN1PF+08DQ4eFvp8i yVK9Vc2vT+tcw1V6sYYB96s+vPu9BFOLxiUgkk3RqpdrSzY1t9YRi2sYuADuE7/Lr3e2WXE7yuij QOka0jaj2AgjgN0qqN6OPSK+bWeNPzZE0EgeYscYefsAAAAAAAA= ------=_NextPart_000_0034_01D4B427.88F77530-- From nobody Thu Jan 24 19:11:29 2019 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 EF9981294FA for ; Thu, 24 Jan 2019 19:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7E5Y-6vb_2n6 for ; Thu, 24 Jan 2019 19:11:25 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760112.outbound.protection.outlook.com [40.107.76.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3154912950A for ; Thu, 24 Jan 2019 19:11:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p1q8CG0tVq2VGGr+CBRa0xTn1nh6JcQHGmNtPbrRMsM=; b=qjGfLliBb3rTdzDpkKfLRaGaWRGiFrBLZnXIntxXC2tI6S9iB8yguIRDGvXFtb6EKcJbB4xhEVYq++mg/qakQlWFyStswPkzivAyomHRtWhJr6EdIMuAubNltaqpul1bEWWqVo/FtW3XIop5e4ZReBpeLZWlmrwnTZtPZPisCno= Received: from SN2PR01CA0082.prod.exchangelabs.com (2603:10b6:800::50) by SN6PR01MB3759.prod.exchangelabs.com (2603:10b6:805:17::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.17; Fri, 25 Jan 2019 03:11:24 +0000 Received: from BY2NAM03FT048.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::202) by SN2PR01CA0082.outlook.office365.com (2603:10b6:800::50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.16 via Frontend Transport; Fri, 25 Jan 2019 03:11:23 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT048.mail.protection.outlook.com (10.152.85.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.11 via Frontend Transport; Fri, 25 Jan 2019 03:11:23 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0P3BISm029617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 24 Jan 2019 22:11:20 -0500 Date: Thu, 24 Jan 2019 21:11:18 -0600 From: Benjamin Kaduk To: Tim Hollebeek CC: Russ Housley , Daniel Kahn Gillmor , LAMPS WG Message-ID: <20190125031117.GI49072@kduck.mit.edu> References: <87va2md7n5.fsf@fifthhorseman.net> <78AB2172-3C9F-4776-A9F5-9DEE0BF29DC5@akamai.com> <87pnsud3gh.fsf@fifthhorseman.net> <875zulhfvh.fsf@fifthhorseman.net> <0230057F-D39E-49A5-8DAE-35DA2B1B9B0D@vigilsec.com> <87zhrq3qv7.fsf@fifthhorseman.net> <51BC8C3B-3BFC-42C4-94E2-75F4A53E9E6B@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6029001)(136003)(376002)(396003)(39860400002)(346002)(2980300002)(13464003)(189003)(199004)(97756001)(26005)(2906002)(106466001)(186003)(86362001)(478600001)(88552002)(356004)(229853002)(53416004)(246002)(4326008)(1076003)(93886005)(53546011)(6246003)(336012)(305945005)(426003)(23726003)(486006)(956004)(11346002)(8936002)(50466002)(8676002)(446003)(126002)(476003)(76176011)(104016004)(46406003)(7696005)(6916009)(55016002)(966005)(316002)(6306002)(106002)(58126008)(75432002)(54906003)(47776003)(16586007)(786003)(33656002)(36906005)(26826003)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR01MB3759; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM03FT048; 1:mPY1XzwA71OYpAOaNn8iJV68f9C1bdQ3Q7fkdBicphaoi31fskCO2RG2X91AHNfB/zUJXW+0WM3lpNic3SPZqNGXK2c5Xg6pRgH8VmNCGoPrde0sdspyGsenAYpDiaAAC/ZxT32GdjK7S7Pv+QPcZ5wCS4TF/J7cxeF8AKMu9DI= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 45fb904d-1b64-4bf3-6919-08d68272c969 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060); SRVR:SN6PR01MB3759; X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB3759; 3:feZI64gG6bADGR32YKezQ1eqP/ULMSxg0RZ5UKuMmOwEJ5qLb9hrSSFrM+U5dgkR3jf7zeF1xC5DJDjQm1EuF3Q4rCeF3cEisqK9Rl9l0rzhrPwUkqGkNYpJMSRNhV4MAnZe/Fb0Z78qu6DJVMchS/5B6SN1ICWyBZjGz8EpTcbqGW1nP2pNIp6w/6onOMaxkHcJauWXjFvIPL/SK7gmD2MyykDANgJ0ooMJ0da754siPXJpFjRMhrN9NKAuad2Cur2uT2bK74PUupi2r+tnkjkWx38zder2n3oDk26EYA7TRLMXQcEjmyfVb2CJL4rDczZy8Fq1hZs6jURgebp/cvmcC8HJy8v0IZKn+xDPOiV/2LLLCndG4h8kduEYOx8K; 25:VdDCY4aYTyA4b7Ed2G+da2b90abzvvA2i818RKvaVq9Vc+qZak6EdWTi8/fP8VbcYXzpXJJ0CiWLsQYlaeBSSZvgFx+j8/MrMWJMVokrZSfho3b7Bkr1ZL4rmBYDpDpNjOrVpyJwX826317nVNUBrl2f4pVwi78fY8rLvLU6iQWCD7zWQushupUpF2vXigPjLmLAe4cojH88jzgcHqaEVkvnpe4otLdMoeG0cCtlU+6bV/j4AnVnFB7XkHthaowEeLkJxEWz/rVzdfqaYn8b6zkuNQpx0oozCgBK4oZCwAXfzQVPw5lFkKDeUZ4R6CCA72eNgd69cGQS5VJK31/ovw== X-MS-TrafficTypeDiagnostic: SN6PR01MB3759: X-LD-Processed: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB3759; 31:fRoWnUhKIEay23hK8oE5AZnjBRcLiTzLoX+qaNdbtcgomIbu3K9BLl62tEh8MnD9ct/Z7IfNRPQ+GHMa89bqy396hcka3W3Gd0qLoanbevl5fNQUGutmJJ5mmLQzo2JLS3vvyS3Ez0yX1lwraVRlHEfDesAIHPJ8ItNq++s9bMKrE1fBZ1dhIra/Vo9NlKObpig1Z2kw0BZvb6mzZHyDtMEM4JC/hpb1qBYVva+VTdg=; 20:cd+3/fzWHxuwMyPquU1WRtjHbehf4kgg8VrtjcWWYrqrdMShs5tdztxiSag0NAHpj1EjoYGBZsH8388hAdCLPbXdzpHM0fR9u2Zppz8P1CTXvwn1s5zsV7qtxhC3TJ8j2+AKjBrSFRaWHCKZeLyOE2gyuOzBmOUSAmVNzUAQEiKvVUkSA65eVxGVZ2uAfuB9bY4nskBXbnPNWLiyhpcbhJHMe5NsnFhWep4pQ0E2TrXCAhCGV8CbPw2uIZ5IL67AxY9TirKdi2g0uRHtk6gpqPETjyeo8grTL3NylT0j9AMLzGrljdPG7Uco8otfB7+9RIu71OEMyFQJ7j+bnC10EGtuvTpPJL9sFkz+3t+fA8MG7N5jMb/Y8i3Td5o8a/TRNwGzTTzXUk7LGgWbENGh8ZKPz3VvrBG3XeBTBhjVQSVLdM80/LBuGdduuxTS+Y4n4n7YpFwSPcv0q/6lQJfWn4VPO2fyAn+56iZ/3cU14fqHhwQw8hSjT+CWLC6kyh8LhAdYfdw+rxA+HOxAMLOb+D6b7WE1rn4zkU0HZ93MBBc865VfYdNs3LXooyGzzwQ2keffBvQnAmQGUceIoQPRskpyo8S0aZX8LJfNTX3y5zg= X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB3759; 4:QzDDghl78QEToNyRfm97wjilRH/51wHqRawnbG1ZbcGrCHEvsvA8psDnkVaoT3WLZ9zTYFc9iMtyXwuh7XzHYaoDJMLYAL8C7PkZFlXIoLBcDYVQtSgvHfIySDTdGVeCeX/I/IULsgUeVvD0WafgxRlZMrZuUb7zP6Z4dRXPMCarRZI5lzpXZO+BSiTfXyxw8q/oPTdlOxi+bCpjJawt+FzjcPyHuPsX1qoycD4y2OwM762B0KalGE9mr/x6TmfXVNwVUMqMYqr4XFeMopJ/Cj8lK3zNud0CAzQLKCx7nzpT4pGvuw/D6ESdSBkHftS6 X-Forefront-PRVS: 0928072091 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN6PR01MB3759; 23:ngtIz2Y6F9wkd6ul5xTHK9iTuEpeBMxonRnM937Vo?= =?us-ascii?Q?0UNCpYz1qNb1o4myhkvxUtP3h5b8LBEIE9YzneUFZHoC/ttbqMfzM3sDDXyn?= =?us-ascii?Q?uN+UzJjW6M6w94YlQ0DdWB9m0IuGnHc9KMAQ20u8xHq0Oe4W8GE/oJRs7K36?= =?us-ascii?Q?PPA5MTp8XKzdsAi9VfuSMGhdlgBEinTygw98ynX/HrREB7EfEutxRA0ACgYd?= =?us-ascii?Q?ituKmgJhYrC/tjUMk3Z8EJFT7YgKua1Gqt4HcyriWbt+vf+g6dcXKb4zLJ/F?= =?us-ascii?Q?fiwSgy1wh7N5LjrS3VVxQLNCE9avZVn1SBd+2PIEV2xzTJh1FFDVnDkypyCY?= =?us-ascii?Q?fjRl9Zuwq4LU1ogTSeqlm1J5ySdhzJG6yCj4TIfy2OZh0ukigqiSRuN+rhCQ?= =?us-ascii?Q?pULBqkuiLivKh+3IaXP1VkRXQhgl2+bYyN2I3SW3z7bSPTRUL8fdcKiFHmlC?= =?us-ascii?Q?HNhdADObmHz8jZ18aJ689N6YURfEm8oanx9uVxpEfOxkM47j4tY4QHTSDmBt?= =?us-ascii?Q?VxtmuID7GhzbHwYajs/1pNxHgBCJhEtxPoIMEnUffn8cZR/iiLQipPvnlHqg?= =?us-ascii?Q?pbARXvKBba+nUVPx0p0Cas+qQQ9WJQsptSYCHdG7vwh8hvcLksRJOFWuAmc8?= =?us-ascii?Q?YipvTFUu4zswPJH73sYM1PnrF0OmBgtf4HVhteErhLoZMovNJSLw3pTI/E2B?= =?us-ascii?Q?q3U2eP9t3v9JNVDBzHbN/taJgRGPmUdejG5IhfPvXezpJxNieePsmO/mT/gD?= =?us-ascii?Q?Aa/IoErCbdX5A3bAkzW9avang4qsnnGfISRIC4keHjPQH9xAwRRuLvwl4NAz?= =?us-ascii?Q?d1Bc3JGTd4PGwwcy4u2DCIMQabrs9OsuOQsOgvdInyXHo2m+UmCASSf2FARo?= =?us-ascii?Q?IzKHsGbyo8slHQN6v7RPHJyeiDY7yZWWGMnKgwXuX/qrt8Xmys/tjN+0kQ7W?= =?us-ascii?Q?bf/TH1l7GE972fw7bPNHlS742kbc9bTenRk+FXPokK7/VnpAvhATm2EEKos5?= =?us-ascii?Q?4vz4gEbmMcrnOGrPvrPLeczTTb3s0Yk+rQiwkO8ANQQhCW9qzrn4Xk0Tf/p0?= =?us-ascii?Q?YziYF2h8FfQhF1pUY9qKKDngBxVeNYFlK514WBvokl5beUfnSLYOQ1j7yF74?= =?us-ascii?Q?JDWwqFoP4APH6lHydhuRQK61duO+Bcx88FRmG5lK7d03N7D7TSEsaSIhBPdd?= =?us-ascii?Q?lt7iJ9Mcie+jY86PjKWwXCLhrhOwAlHKjeMjgbaGxQb8sYad9LqqzqJKaAYu?= =?us-ascii?Q?+N4Lw17xhbUcTUkteqSUGpJjKr0xSrfDVKilqG9BMmJFh4YHhIvPUm5hoNWy?= =?us-ascii?B?dz09?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: YXCRLICNSh0aK4M2Crv90PCj2xiENhsF9z7TYPCLuWIXvy8YM5V5dE0Jewd4u+e1bfdx1X0/TF4sErK7+7bf8g1VRYSjVL3RmJpjGsuIILXm/RnGsaQZ7sdM+fKrSqBfDB8txVP1b/XzNVf03ODmtjoQbROB5l4BbL6Sfs/k0TJRDoAtmJrhQnHic451FC0u3930QYREZ2mbod6yA6UPNzSkiSsoNOxjtkkDY58DUs9fq1vnkCVv3QGQ3b5FJNkl9mH1gSohNnPTJwV4H4UwZ0s/DME1CXkTlwug6hcTnJPMFxuOwCg5vhCp3NjeZOsq4g2ATLntfVWZ1XYtSdKXzkxv43shOtWgG7ciLk9uXiZc4fYLngGECdOtRPFZIpuaXO2Q+Vpfrj1I1gQAmbRy3+knGCVfBG5d9hQzEues//g= X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB3759; 6:txzHsNiQxutnpdZbJEEFjJtxF7kvW7S2VIFkhPUcg3hOZmM8U9952AvIwYBgbvXkk4MDMtXEPjz5W7pUUiabElpyZW+1dHdCYN8/3+RmMhhALTz80FGoAAI83k//ZSQQk/DOOjF7pk8cnuMlOT3wrMBbpQxDsNSZlgrGL1azRnGjj7HnxM4GR4cScJ5n4uYLR7RaByQoUV9xuS0bDjIFtQq1LBG61jGHH+GwPl4iXyzrMDa6SLP9K/vYSYgGQJWMAVNRWSZrPPcpOZvwI3i6nGUmQv0MuJaUKYUnuHAtezfc1axmzCcvelFmn3t9j1JM/Lp4sCb7n0ZifOgM8Cij1x2pIhdFn7IWBLQ3vPNdjvzldOPgDROg3/Rq5CxiNQci6n2vFNjruHth4/b8Pa0GPPR4zwA2uWJ4eo8jymnESiVM5IYirlJ35bSUhclIvmyV2c18IjxaeOgvoMkSSODJMA==; 5:FlwNj5qilSMk1FY5UA/7cB7929DhiLd/0mTnP6s3vqIQ8rOrV9h8e9A0FlOktAJJYBCCbAew3w95h4X6bAPzpV7zSMt2csQFaPu8S2sTno7ulFjPHxFXXjXjY+LM+XkXAu77iHKRpqk7COLT7tSG5276Pr6hkw4juFVhEGrWuXUIZu4beD4UJ6I4Z+BFfIgKa8luzlLmr1bvSA0J7QIRvA==; 7:iy2HGTYcQ1sftEWihG1ZeGcs9DvBXI7js42prZzKad+AIUy/9j09TgS0Ihy/MkC7wWxjm5IfifeMhyLIc93xJ1cFi2kCiiFXlUg781wpPVexYJBzxW00wB3VMn/ff4+vcp1W5wqYS+QCU0DfvfCqPw== X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jan 2019 03:11:23.2608 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 45fb904d-1b64-4bf3-6919-08d68272c969 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR01MB3759 Archived-At: Subject: Re: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Fri, 25 Jan 2019 03:11:28 -0000 This thread prompted me to read the document. My main concern is that section 2 still says that "[a]s discussed in Section 5, the recipient can remove the current Root CA certificate immediately in some situations", but Section 5 no longer has any discussion of removing the trust anchor (and when it is safe to do so). (We have discussion of retaining both old and new, but not any explicit discussion of removing the old.) Given that the whole point of this extension is to be able to retire the old Root CA certificate, resolving this disparity by removing the quoted text from section 2 seems undesirable, which would seem to require us to state more explicitly when it is safe to effect the immediate removal. -Ben On Fri, Jan 25, 2019 at 01:54:15AM +0000, Tim Hollebeek wrote: > Is there anyone other than Daniel who thinks this is necessary? > > There is always the opportunity to address this in additional drafts and > revisions if it turns out to be needed. > > There are no concrete proposals for addressing this, and I'm struggling > to understand why that guidance needs to be in this document, so I'd > suggest that it would be best if this issue did not block adoption of this > draft. > > -Tim > > > -----Original Message----- > > From: Spasm On Behalf Of Russ Housley > > Sent: Thursday, January 24, 2019 7:19 PM > > To: Daniel Kahn Gillmor > > Cc: LAMPS WG > > Subject: Re: [lamps] HashOfRootKey when no certificate repository exists > > [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt] > > > > > > > > > On Jan 24, 2019, at 12:30 PM, Daniel Kahn Gillmor > > wrote: > > > > > > On Wed 2019-01-23 19:49:52 +0000, Tim Hollebeek wrote: > > >> Any comments on resolving this issue as Russ suggested? It seems to > > >> clarify the issue helpfully. > > > > > > I agree that it helps to clarify what is meant by a "certificate > > > repository". Thanks, Russ! > > > > > > I still think that the draft lacks concrete guidance on how a relying > > > party should deal with this new revocation mechanism in the context of > > > a certificate repository that might sometimes be unavailable. > > > > > > More seriously, it still lacks concrete guidance for relying parties > > > that have no expectation or knowledge of a certificate repository in > > > the first place. > > > > That is right, and I do not think it belongs in this document. > > > > I know this is your position, and you know this is my position. > > > > i would really like other on this list to voice their views. > > > > Russ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Jan 24 21:00:38 2019 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 2DAD8129508 for ; Thu, 24 Jan 2019 21:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbCYjindefLu for ; Thu, 24 Jan 2019 21:00:33 -0800 (PST) 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 B375F129BBF for ; Thu, 24 Jan 2019 21:00:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 051AC300AAB for ; Thu, 24 Jan 2019 23:42:13 -0500 (EST) 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 ZAlMz5GJFSRS for ; Thu, 24 Jan 2019 23:42:10 -0500 (EST) Received: from [172.20.10.105] (rrcs-173-196-183-153.west.biz.rr.com [173.196.183.153]) by mail.smeinc.net (Postfix) with ESMTPSA id E5ABC300400; Thu, 24 Jan 2019 23:42:09 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: <20190125031117.GI49072@kduck.mit.edu> Date: Fri, 25 Jan 2019 00:00:25 -0500 Cc: Tim Hollebeek , LAMPS WG , Daniel Kahn Gillmor Content-Transfer-Encoding: quoted-printable Message-Id: References: <87va2md7n5.fsf@fifthhorseman.net> <78AB2172-3C9F-4776-A9F5-9DEE0BF29DC5@akamai.com> <87pnsud3gh.fsf@fifthhorseman.net> <875zulhfvh.fsf@fifthhorseman.net> <0230057F-D39E-49A5-8DAE-35DA2B1B9B0D@vigilsec.com> <87zhrq3qv7.fsf@fifthhorseman.net> <51BC8C3B-3BFC-42C4-94E2-75F4A53E9E6B@vigilsec.com> <20190125031117.GI49072@kduck.mit.edu> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Fri, 25 Jan 2019 05:00:36 -0000 Thanks for the careful read, Ben. I will break the paragraph into two; it is getting too long anyway. = And, I wall add the part that got lost in the recent edits. Some enterprise and application-specific environments offer a directory service or certificate repository to make certificate and CRLs available to relying parties. Section 3 in [RFC5280] describes a certificate repository. When a certificate repository is available, the oldWithNew and newWithOld certificates SHOULD be published before the successor to the current Root CA self-signed certificate is released. Recipients that are able to obtain the oldWithNew certificate SHOULD immediately remove the old Root CA self-signed certificate from the trust anchor store. In environments without such a directory service or repository, recipients SHOULD keep both the old and replacement Root CA self- signed certificate in the trust anchor store for some amount of time to ensure that all end-entity certificates can be validated until they expire. The recipient MAY keep the old Root CA self-signed certificate until all of the certificates in the local cache that are subordinate to it have expired. Russ > On Jan 24, 2019, at 10:11 PM, Benjamin Kaduk wrote: >=20 > This thread prompted me to read the document. My main concern is that > section 2 still says that "[a]s discussed in Section 5, the recipient = can > remove the current Root CA certificate immediately in some = situations", but > Section 5 no longer has any discussion of removing the trust anchor = (and > when it is safe to do so). (We have discussion of retaining both old = and > new, but not any explicit discussion of removing the old.) Given that = the > whole point of this extension is to be able to retire the old Root CA > certificate, resolving this disparity by removing the quoted text from > section 2 seems undesirable, which would seem to require us to state = more > explicitly when it is safe to effect the immediate removal. >=20 > -Ben >=20 > On Fri, Jan 25, 2019 at 01:54:15AM +0000, Tim Hollebeek wrote: >> Is there anyone other than Daniel who thinks this is necessary? >>=20 >> There is always the opportunity to address this in additional drafts = and >> revisions if it turns out to be needed. >>=20 >> There are no concrete proposals for addressing this, and I'm = struggling >> to understand why that guidance needs to be in this document, so I'd >> suggest that it would be best if this issue did not block adoption of = this >> draft. >>=20 >> -Tim =20 >>=20 >>> -----Original Message----- >>> From: Spasm On Behalf Of Russ Housley >>> Sent: Thursday, January 24, 2019 7:19 PM >>> To: Daniel Kahn Gillmor >>> Cc: LAMPS WG >>> Subject: Re: [lamps] HashOfRootKey when no certificate repository = exists >>> [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt] >>>=20 >>>=20 >>>=20 >>>> On Jan 24, 2019, at 12:30 PM, Daniel Kahn Gillmor >>> wrote: >>>>=20 >>>> On Wed 2019-01-23 19:49:52 +0000, Tim Hollebeek wrote: >>>>> Any comments on resolving this issue as Russ suggested? It seems = to >>>>> clarify the issue helpfully. >>>>=20 >>>> I agree that it helps to clarify what is meant by a "certificate >>>> repository". Thanks, Russ! >>>>=20 >>>> I still think that the draft lacks concrete guidance on how a = relying >>>> party should deal with this new revocation mechanism in the context = of >>>> a certificate repository that might sometimes be unavailable. >>>>=20 >>>> More seriously, it still lacks concrete guidance for relying = parties >>>> that have no expectation or knowledge of a certificate repository = in >>>> the first place. >>>=20 >>> That is right, and I do not think it belongs in this document. >>>=20 >>> I know this is your position, and you know this is my position. >>>=20 >>> i would really like other on this list to voice their views. >>>=20 >>> Russ >>=20 >=20 >=20 >=20 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Fri Jan 25 03:11:05 2019 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 8E561130DC9 for ; Fri, 25 Jan 2019 03:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=comodoca.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 Eaxae9ZDX9mx for ; Fri, 25 Jan 2019 03:11:01 -0800 (PST) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730040.outbound.protection.outlook.com [40.107.73.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1740130934 for ; Fri, 25 Jan 2019 03:11:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector1-sectigo-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5kJEH4QABcgwfoNXiDRCINBPBFLeQomRz+Kw5N60l2M=; b=qGd433SC7eizsfCqYy6XRKOBa5XyRAbOrCvlcKRm7DO67bJfWOnhnnxUdvsu7g65tL9CdiA4YNz/s8F9Z+AazoWJsPUKsyBIdKVvmT5ydZLzTbZF0Xn3BAW9XXidHJcq4cPeOVS9C2pl5WhiE2HS4pErXgUZEBAWdv7frc/sRcU= Received: from DM6PR17MB2716.namprd17.prod.outlook.com (20.178.224.155) by DM6PR17MB2780.namprd17.prod.outlook.com (20.178.225.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.18; Fri, 25 Jan 2019 11:10:59 +0000 Received: from DM6PR17MB2716.namprd17.prod.outlook.com ([fe80::9820:6f4a:7762:166b]) by DM6PR17MB2716.namprd17.prod.outlook.com ([fe80::9820:6f4a:7762:166b%5]) with mapi id 15.20.1558.021; Fri, 25 Jan 2019 11:10:59 +0000 From: Rob Stradling To: Tim Hollebeek , Jacob Hoffman-Andrews , SPASM Thread-Topic: [lamps] CAA: Title case for Defined Terms? Thread-Index: AQHUtEl/ybSg4bNKuE6grrQ1xaOn96W/OloAgACaWIA= Date: Fri, 25 Jan 2019 11:10:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0065.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:60::29) To DM6PR17MB2716.namprd17.prod.outlook.com (2603:10b6:5:122::27) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rob@sectigo.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2a02:1788:4ff:1000:f68e:38ff:fe7a:a226] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR17MB2780; 6:hZmAVe70b466/Sz8CxSv583NaBNJW5GPfeSDn8vkdgvR8RkzoKPdJ1FpdJlGnVejv5JyCkB2oB+Jdpy81IoubPnMSoLFPfxNeH0n7Md7M8JjhF6STjvV3FqhHKoCFMKvj5sosu+QGqClakzg5v3tm9foiPQaQ1lYNFYVEz9MTFZT4apb4a+uH5deUDOn7ECoWU8lTsFBPediNY/ykuyRLIff82FzeTSBu07j6PMLVh+WHFvgYt3Fi0Z0hORXe41BHQ4yufYwpvG/xDhcaVKMyeprfktZijYOs23L/xJkYpgqRvLZxQDIAgip9NsSyfYH5e4yQry6fzkK3iolMWREsMlgu5VcXNvC+TgZjD12zoGktSfPZM162lPcjQ/NT9+c0+ZnB74qwSkpdK7olBRzi5JHLOhfFeG6FpyyVqUXoIwXZcZbOLF/pcGCqul+K0PmEvBwBHwvWLhpG9KjuAb/1g==; 5:IOwKT9ryMBn8z53oaKkgaYtoIdhDJ83nmPhfXKoE7P1EKTz5TPqLjM+vKZ880nGpNuo7d4lNMGo2umpGcjKsSa3OJsDD3q0hXsp2QCNib2tsWnkrMu04fRYOxZKU+jPsneRY3FjXKUcmLXPgkYpkEbMAxK/O75sSZDFb9XIMFC5fQi41r+wutMDuwNgV9Ug62Z3DcdjxRp4liQzD1z8G6g==; 7:et/E5JHn+mWoTYqcIUebA2blsFMnGfq6gsZY2uvtEds6m3qSy6KUPmAW71S4ed8Rz82wPZpV6GU6waGxVAPaH5uodgkLfHcVX0s/GE9ldgytp9doFCPOkVvGpNNkFqHVa2Hmdj5QJl+/A+zikGn7xw== x-ms-office365-filtering-correlation-id: 85d77b99-2dee-41f4-e09c-08d682b5c8d8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:DM6PR17MB2780; x-ms-traffictypediagnostic: DM6PR17MB2780: x-microsoft-antispam-prvs: x-forefront-prvs: 0928072091 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(366004)(396003)(376002)(136003)(346002)(13464003)(199004)(189003)(71200400001)(71190400001)(14454004)(478600001)(2906002)(53936002)(25786009)(966005)(97736004)(11346002)(446003)(8936002)(486006)(6246003)(2616005)(476003)(6116002)(46003)(68736007)(186003)(86362001)(81166006)(102836004)(53546011)(6506007)(81156014)(31696002)(386003)(8676002)(31686004)(106356001)(6306002)(6512007)(76176011)(52116002)(110136005)(36756003)(105586002)(7736002)(6436002)(256004)(6486002)(305945005)(316002)(229853002)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB2780; H:DM6PR17MB2716.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: sectigo.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: E23gulMNvJnymI7dqEoLV15IlHGV8NCu74fmz/FX9f8AfBHCUh5l4Mduv4Vg11wu97J6YsUAfqZG4nXnuGHpYiApEp5J9HJ+k66Ptk0knWua/a1CWr+EIHRGDurdjftslRa9QC8tnWSwWGs7dMgO77garqAlPBuaYl3k8KGzD3Oz0pG5A5CcpnCRwce/KB9H+OV+nvLjGXxauzUaQ1k4D9cmAJv6QpUUh9Kv4YNc50oQliUwrhDNVmsjyb6Y9Smr5Ld2EkG3GEei339dy/7iGYqibXlU2lTXa+YI9TOc+6dQOwEuhSVqD0aZ7rEdtPJMoYx3wiS1WTdfrMHHyShIyKZ/AghoxyYfiOK2/anEc5QGBiU7/qcLrnU4KNrzIW9v53bur2ZH6iisIYDtMS3wFU2wuyThGQ0jgfmg1191U/4= Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 85d77b99-2dee-41f4-e09c-08d682b5c8d8 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2019 11:10:58.0284 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0e9c4894-6caa-465d-9660-4b6968b49fb7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB2780 Archived-At: Subject: Re: [lamps] CAA: Title case for Defined Terms? 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, 25 Jan 2019 11:11:04 -0000 On 25/01/2019 01:58, Tim Hollebeek wrote: > Title Case Should Be Used Consistently For Defined Terms. This Makes It > Clear That It Is A Defined Term. >=20 > Rob Stradling is a Smart Person Actually, I tend to dress down. It's not often that you'll find me in a=20 suit and tie. Oh, hang on..."Smart Person" must be a Defined Term, so=20 I'll just double-check the definition...ahhh, so you were complimenting=20 my intelligence rather than my dress sense. That's very kind. ;-) > and if we aren't doing that consistently, > we MUST Fix That. >=20 > -Tim >=20 >> -----Original Message----- >> From: Spasm On Behalf Of Jacob Hoffman- >> Andrews >> Sent: Thursday, January 24, 2019 8:01 PM >> To: SPASM >> Subject: [lamps] CAA: Title case for Defined Terms? >> >> Rob Stradling pointed out something on >> https://github.com/jsha/caa-simplification/pull/5: >> >> In the Defined Terms section, we use title case, but we don't consistent= ly > use >> title case when referring to them. For instance we define "Issuer", > "Property" >> and "Wildcard Domain Name", but in the text refer to "issuer", "property= ", >> and "wildcard domain name". >> >> What's the best practice on whether to use title case when referring to >> defined terms in the body of an RFC? --=20 Rob Stradling Senior Research & Development Scientist Sectigo Limited From nobody Fri Jan 25 07:27:45 2019 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 93E111294D0 for ; Fri, 25 Jan 2019 07:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whB_Y30Jl7j8 for ; Fri, 25 Jan 2019 07:27:41 -0800 (PST) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700118.outbound.protection.outlook.com [40.107.70.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A2E130D7A for ; Fri, 25 Jan 2019 07:27:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jxaPs6wNo3uj2J1vrRZ+uxIHqM2shArVzhwvXYfjb4c=; b=CepE+QP8L4R79g2oYTGX+JgWctS+dAn55BZuHscxV8B3JWMDPdh50aK5HE2LNNNEEH2Qei/UqgZNYQ9ePnutHx2rhDDaDCi9cVJjYZJpWgmC55zIdtif5jvUZB1guY+iXbzPxur0jHrPEBc6Th5exgyQ7eEunNECy2pRMzlxit8= Received: from BL0PR0102CA0024.prod.exchangelabs.com (2603:10b6:207:18::37) by SN6PR01MB4493.prod.exchangelabs.com (2603:10b6:805:e1::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.18; Fri, 25 Jan 2019 15:27:39 +0000 Received: from CO1NAM03FT034.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::209) by BL0PR0102CA0024.outlook.office365.com (2603:10b6:207:18::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.16 via Frontend Transport; Fri, 25 Jan 2019 15:27:38 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; fifthhorseman.net; dkim=none (message not signed) header.d=none;fifthhorseman.net; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT034.mail.protection.outlook.com (10.152.80.177) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.11 via Frontend Transport; Fri, 25 Jan 2019 15:27:37 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0PFRXKh005635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Jan 2019 10:27:35 -0500 Date: Fri, 25 Jan 2019 09:27:32 -0600 From: Benjamin Kaduk To: Russ Housley CC: Tim Hollebeek , LAMPS WG , Daniel Kahn Gillmor Message-ID: <20190125152732.GL49072@kduck.mit.edu> References: <87pnsud3gh.fsf@fifthhorseman.net> <875zulhfvh.fsf@fifthhorseman.net> <0230057F-D39E-49A5-8DAE-35DA2B1B9B0D@vigilsec.com> <87zhrq3qv7.fsf@fifthhorseman.net> <51BC8C3B-3BFC-42C4-94E2-75F4A53E9E6B@vigilsec.com> <20190125031117.GI49072@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6029001)(396003)(346002)(136003)(39860400002)(376002)(2980300002)(13464003)(199004)(51914003)(189003)(88552002)(186003)(4326008)(53416004)(956004)(36906005)(106002)(75432002)(966005)(54906003)(46406003)(126002)(93886005)(11346002)(7696005)(76176011)(16586007)(476003)(8676002)(486006)(104016004)(478600001)(55016002)(316002)(786003)(8936002)(14444005)(26005)(23726003)(2906002)(53546011)(6246003)(86362001)(26826003)(97756001)(6666004)(229853002)(6306002)(356004)(6916009)(1076003)(50466002)(47776003)(426003)(106466001)(336012)(305945005)(246002)(33656002)(446003)(58126008)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR01MB4493; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT034; 1:sN1iNf9XaQrtc+P0P353D7RdjmgCozGxwzcf/A3WmTN5fvwmgEpUz9+8VUF3vplcdrD2lusVi35YgzKpqxXzhHHKxFZPm5gJhwUCKvzw8ANtrZPwu2wI8b9LHLhcmbZHkV0sUa20qnJTQ0tYIe9TsJSJvPXz3tTxRNu1tNrThfQ= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 46f9e88d-a39a-47fd-a734-08d682d9a37d X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060); SRVR:SN6PR01MB4493; X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB4493; 3:Wihvh8XBuSUzH1qv64P0wkRwNCjxBJYgj3lV6DZtAlGLSu0dbe5+DXVLpCReOpBQrW3hVfPUcuUY8wgM7NJXxPORP5mjCG68kWPLYhtACDen14l3TvgZZBim/VigShe6keGePRLQIXmRkybs0d63G19FSM7e29Gex0Q5PZEjJHhxp8nAxA3nzNM5CDlkuyD+y9faa7wUJjfRnJ6ynQnfq3sFVtsK0nSBYLnwjSAeHbzbbUo+a69D6ddICjsX3PpDjPILDiSqh5nNWOU19OuoSdP5vo6gWLS/v8fOPm/MqqXxVeV9O5iiaN0Ivq1wS+Ryhy2xinMmPHmq2GzvS70mj45jDQwO4dgHbNO9nFENghDqX89crVpOB1Qyg2kbzz/V; 25:nYAs2r4s7GIkoNv8mxii9SlEOQkRMvB6WYwXUsPeSHfZAxItI+kwSMNanLLGCJYtd7QJomCv23YqMWn/o5IA61AnJVHBiq82WjMeqHRALgQ3C5GnLx4hHzV04yqz4KPLBTbld2TiAv5tX7YA1Ho1YNM/q3PJ4B8N15eeeVfxHe49OtbsfItBxAsx0w40tTnJp3RQUo1LYkmq7T1lJQj15hYT5WS3+5gj4p8QQAYMuMQouYgPHXV7l6l4K8+v2t0oNyoFhwF/6sE/EVdBzxe4LN/JTMF6dGfJW8zMwydF+QWqqJv2NkCWpJuEYpgyh+k5Uijaio8HrDk07mCAq412ww== X-MS-TrafficTypeDiagnostic: SN6PR01MB4493: X-LD-Processed: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB4493; 31:b1p96tJSY1k4YR5yYcGu91Zrb4RC450+sOlZpP7q7xvvc7+BRE+0HsT8g3FxDjWcz2JtJN+6icd9Dxa2oqyKrtzou9AwJYXe8NQSQtq3yI7m7wJRRtA2C9tRh6Eu2Na6TqCt5BdlGiXH1joTIYz9Azw0KCZIxxn4jl7MZ9fqC8NU+Ioo9mbnuyI5mswSy4MbSWejT1AHEzZX5MBOf7So3ukmGTjAZwXFYqdnvFysHPU=; 20:7b3OXmCPyc5Jaz80pF6fXzLXDihhtiviXZ+wP/vHGc0PbpeVwt91N+9cTHlO5cOxhC9DEFVYqNRxz6iJZr6jCLwNThov1PYPhLxruBCN69tcUTgIZoKDhe/TkbTvCVQWJbCl0f4ap3uB977cUUq/kgi0fuQH+gAljIOrp1Fb7tO5v6o4P3tD0u9NPi24WEWU65WtGiieD3NHdSP5wWb6T/iRYgtStLhrtG/g9M8SIPfUzMwkFugJIhBtyLn8cFeSXN4JV3g+KkycapNg9mT+QhIx6lrsUhM1i4i88zjAsfszZ2GfYOoTs22pEVazJgZAtHi2KML8NwZvQeBss1vmSZJZWp4wPpv5nxcl8HA3NoNrzG1YQ/yCPuV6pXzynLGyKJk7Y+bpmbWfUQQrM4LbEg7PveufRK3q/8J/agPqETRqHbSPNNVAbbPx+vgxZaFFICnADZyKO8KeYl+K0h+zPCKTmVOPqPAxkiIZ3g8YS6zF84IevRB1/hu586b4Id1uCKUIy+aoVNLCCRYUssPKMFGdPrLCXWAxe9kL0ImKyXo6jgS0JzxNvD1eMVeOQhc6yghO+/+x9AJH4P3+ihjsDqs3yMcJ6kU2xz4c/kc656w= X-Microsoft-Antispam-PRVS: X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB4493; 4:707hAzSu0u97lpu5mfaVWr1wC72g7fmOMYe4HxFtd3DKUSuYFiCbco0HEwH37NnVxBHOCuGHBqUgYeXa03Xzcjplnm0xg9rO2P06ZRENexC6pHA4KBAEE0FHeK6xJGiBXjfJuQ68Vum+3xQ6g1ktQKKCyyb8WahM9lqnVkd/TotGeiFMn/DbaajSYdGHa8f0NLh9xoqSQilwUDgj8e4qgH/c6dLlD1KH4I3SnbLGiTvcjwG7aWcGGTVrk+706bl6032HCeRjFOficUk4Ppyzrl8vNE7e0yYl2qK5HayXOxz+bnK1Ts13E2J88a+rzgTv X-Forefront-PRVS: 0928072091 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN6PR01MB4493; 23:qn2cv7nH1ZQb788O1cFImuLh2U29qQiwOFz8rPooR?= =?us-ascii?Q?6xw+7eT8jwdtIktwiudDhE7vRSwNqH59GBMaeYaShRnCllBotIC3ya+dom3Y?= =?us-ascii?Q?B797WkHQAd6/6Jt4Mq70EBH5K1OS9dToRRaDZ0XiVjTz/LUTU22bqrbtsiWA?= =?us-ascii?Q?Igb0g214Q6WqAz2Svw6jlxzxmxZMqcSkoxSPiuDcEcZAHCiJYUx2UtmRQg4z?= =?us-ascii?Q?VQfev9UnHSp3dKy87z/QJgI7iGeDqe4EIkDhL3hZL1OHJEjHf4sbxPOtkIj9?= =?us-ascii?Q?v3mHCcLt2sBJ2ghfvjsnQIwPFcZrW4S2oX4GPOh03VGJJnjvFIq2JyU+aA5Q?= =?us-ascii?Q?4CWp/JG4rw7pVz0GT8QldepeP1JgEwnouymSOuRYDoWlIHvFlb+G60MeszN7?= =?us-ascii?Q?SBXI9l/CD6HUINKlHjjRMZoA9Wvqhy+x/CW4M1RFz1+sgWu7wWYD3iFZh/a3?= =?us-ascii?Q?7zzXSDnFe94dl6APA0wB6siwACe2/pljhlA7HTAbA7NTiyXw1pXGxCvHuGy9?= =?us-ascii?Q?nBK2eCK10o2SI3ocaraPoHE/wQNqdGlz7p7QdS6M/2GBCc5BHWkZoiJDDgPY?= =?us-ascii?Q?zsUJH8oBvTUKPqvgx3M9bfyQIt5cfwiwqMqVbx1821IbxtakoegSHRaEWcrf?= =?us-ascii?Q?nOGMJk0rIeWUap5A1yQ1Y3G5FlOy0yZpRD4Yig7f5aMhF8kPxvACAqucC3v8?= =?us-ascii?Q?JdYKBOhX578nGLac5OY05tPvAC2Xt6v2qP1+aYgLWsmQVl81Mp7/ttfofu1c?= =?us-ascii?Q?QwRGPwiXCA7ooDzBYRsQBT95zQQU1/aw5OZoUiTzpCrsxoJczp3WUdBB2jge?= =?us-ascii?Q?f2YMPjOEbW4uVGiW6pemVnLLuPGaRK0adTjOJXKUSQiPUfiI9EIlaZupWmuh?= =?us-ascii?Q?/NnBAud1eCKOujE0knMViPFITrsrbazkUh1Max9W05O1METjhTM8gN0X6Zlm?= =?us-ascii?Q?nqQB+VZjyTf65UkEri0J7/2VKS9VkkfFqXTndDP4FDoIhVER33O0WGZwnmll?= =?us-ascii?Q?EvYyy+j8MFopzbsiCI3S31y7iynKPwaIzjqqGw283+jAunsWTOBxPMsgVL9Z?= =?us-ascii?Q?UiTg/PsxELMIW14tUcL4bXNmI2aQTkNrOPQNPaYJw/WztaL8VtHxIKuABy4a?= =?us-ascii?Q?r6RgFlV30pcOmjLidFDCN2pal8PKj0YPzhGtU8twjVnwZX3yEywxGPBs+wVn?= =?us-ascii?Q?xdheFPfhmo5CLE7A/Q3qiyYQ2fIoiGDj223jHW6o+rbtEuaMr3dZt6NPwgFX?= =?us-ascii?Q?iJMwFBmtuFekmdqT0+MqZ65/BR86F06Jhvzg42NfOnGJ1l9aXWmXWvPxxWWr?= =?us-ascii?Q?QxPHx5/jk9/95XfPfHUiNBl/bUucKIyoEvHFObf6mUxqjOg1O1tMQQbb9abk?= =?us-ascii?Q?R2FIQ=3D=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: Gkpf2pqfMEiN+XRfZMQzDLsYqbXRO7I5Z7yzZzb0gUTe+6C2dnCvzAmEHc4trmPu9tHt2Elc5541OXDH6k1xspAe151Ihsfrnyla9B6S7N4zxcDTIlpnWVn2SE4ahwkr1vb1GLJP1by39Sg9JDgJuEtC082306Th2xlAyR7WqHRCg/E8+VGjF+zkqwiTo3ECyxIJDQi97M0GzwE+P20s8fjK3b5cG3fxsa3wMBv9oIwKwJL5ZC51/9Eps3RwBa/w4C4EsSyZK5VVcDmQJKZmV65YgsjIKmAfuiwz19jDdcv5QK9lJAyxbdErtMpdBwKXfREniJnE4ycESeufZyC4NaaD8T8RquhwGsdYDhRGn7Fw5PTPcxlzF4Y2DQ/7+evToax//jpcaBsH5euqao0lowhlRKFLOZlaYWflFLrE3fg= X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB4493; 6:V5Qg3HA2zRjzOTwlaCLcsHueJd0CVdvW1OMw7Iue1pwGw6kQttpkJzdmIgbPh+92KdG027hncOmSSGjFvxfg5FGLyHmcrLYaZQWhZbbrKLViS0DmoJCjpy+wWJk8qmPELhcmFn0lowwwStG3VyUoS5boHRQXjtIMlMLOAgkcLDnjch2VrcnM8DLzbO0RecxkbNydT8rpaglwagkCQkoWrparVu+TvWlbEZv6HIqM+U5ItIdg5Owh35TRX/asHff//RDTKkHLOUBlRmBUnhy4CmYb9OG+UcLZ4zFoVkIiRVUEAbzO+yQZuUDuw9R2adQ+p9EkHr/QIr8R1bfzzd88fu+Pu1gP8B7gO3o7C/X1ZxiLGLnFtROa2RCCv1tVT9qJXIcBXQwnyBICKspR9ikWUy2qf+hDEF589LcNFNg7m73vmaCOSmqkypqhmPFftjp8Voh1pwgZVLXWXQ5M3ctpWA==; 5:7gcOdrhV+yDnqxxTK6onkUtYn0tqk4rTMTNCleaqCTgCY+mulI/gGdY4T30lyDlx1W1G4TLkBUF2lS5Nq0TeAHW7V2RBiARlgfK4VGMyJwHHjEgQBm0lEIIBFKOCJcbFMsvUQ/oYgfUWnQLUdCtY0XIpFVMbp3RZFewDZG7jUEAl/BowmPBqfS/ut/OgdWJ+ycsYmkibLbOereJsgb03DQ==; 7:Jun5hYl/7DSMg8uaJwkVmLYj7hvKPfnnLHNetO0vG3FXy/QXSFu1GU8GSGmYzNsBo7lLyynjW/qRzCg9r3+GGWPy4ib5GOuKcv96lC1LWo4+goRHoXcgReyDog6IOxmKKRYggKttXEUWdiFOaxK/DA== X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jan 2019 15:27:37.7876 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 46f9e88d-a39a-47fd-a734-08d682d9a37d X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR01MB4493 Archived-At: Subject: Re: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Fri, 25 Jan 2019 15:27:44 -0000 Hi Russ, That looks much better; thanks! -Ben On Fri, Jan 25, 2019 at 12:00:25AM -0500, Russ Housley wrote: > Thanks for the careful read, Ben. > > I will break the paragraph into two; it is getting too long anyway. And, I wall add the part that got lost in the recent edits. > > Some enterprise and application-specific environments offer a > directory service or certificate repository to make certificate and > CRLs available to relying parties. Section 3 in [RFC5280] describes > a certificate repository. When a certificate repository is > available, the oldWithNew and newWithOld certificates SHOULD be > published before the successor to the current Root CA self-signed > certificate is released. Recipients that are able to obtain the > oldWithNew certificate SHOULD immediately remove the old Root CA > self-signed certificate from the trust anchor store. > > In environments without such a directory service or repository, > recipients SHOULD keep both the old and replacement Root CA self- > signed certificate in the trust anchor store for some amount of time > to ensure that all end-entity certificates can be validated until > they expire. The recipient MAY keep the old Root CA self-signed > certificate until all of the certificates in the local cache that are > subordinate to it have expired. > > Russ > > > > > On Jan 24, 2019, at 10:11 PM, Benjamin Kaduk wrote: > > > > This thread prompted me to read the document. My main concern is that > > section 2 still says that "[a]s discussed in Section 5, the recipient can > > remove the current Root CA certificate immediately in some situations", but > > Section 5 no longer has any discussion of removing the trust anchor (and > > when it is safe to do so). (We have discussion of retaining both old and > > new, but not any explicit discussion of removing the old.) Given that the > > whole point of this extension is to be able to retire the old Root CA > > certificate, resolving this disparity by removing the quoted text from > > section 2 seems undesirable, which would seem to require us to state more > > explicitly when it is safe to effect the immediate removal. > > > > -Ben > > > > On Fri, Jan 25, 2019 at 01:54:15AM +0000, Tim Hollebeek wrote: > >> Is there anyone other than Daniel who thinks this is necessary? > >> > >> There is always the opportunity to address this in additional drafts and > >> revisions if it turns out to be needed. > >> > >> There are no concrete proposals for addressing this, and I'm struggling > >> to understand why that guidance needs to be in this document, so I'd > >> suggest that it would be best if this issue did not block adoption of this > >> draft. > >> > >> -Tim > >> > >>> -----Original Message----- > >>> From: Spasm On Behalf Of Russ Housley > >>> Sent: Thursday, January 24, 2019 7:19 PM > >>> To: Daniel Kahn Gillmor > >>> Cc: LAMPS WG > >>> Subject: Re: [lamps] HashOfRootKey when no certificate repository exists > >>> [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt] > >>> > >>> > >>> > >>>> On Jan 24, 2019, at 12:30 PM, Daniel Kahn Gillmor > >>> wrote: > >>>> > >>>> On Wed 2019-01-23 19:49:52 +0000, Tim Hollebeek wrote: > >>>>> Any comments on resolving this issue as Russ suggested? It seems to > >>>>> clarify the issue helpfully. > >>>> > >>>> I agree that it helps to clarify what is meant by a "certificate > >>>> repository". Thanks, Russ! > >>>> > >>>> I still think that the draft lacks concrete guidance on how a relying > >>>> party should deal with this new revocation mechanism in the context of > >>>> a certificate repository that might sometimes be unavailable. > >>>> > >>>> More seriously, it still lacks concrete guidance for relying parties > >>>> that have no expectation or knowledge of a certificate repository in > >>>> the first place. > >>> > >>> That is right, and I do not think it belongs in this document. > >>> > >>> I know this is your position, and you know this is my position. > >>> > >>> i would really like other on this list to voice their views. > >>> > >>> Russ > >> > > > > > > > >> _______________________________________________ > >> 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 > From nobody Tue Jan 29 13:30:04 2019 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 D1BDE130FFE for ; Tue, 29 Jan 2019 13:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUpV6tbwracM for ; Tue, 29 Jan 2019 13:30:01 -0800 (PST) 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 A4995130ED7 for ; Tue, 29 Jan 2019 13:30:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DE8D2300A21 for ; Tue, 29 Jan 2019 16:11:43 -0500 (EST) 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 otloP1eILMEd for ; Tue, 29 Jan 2019 16:11:42 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id D9469300435; Tue, 29 Jan 2019 16:11:42 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <50E9F56D-A66D-4730-8107-2C878DA467D2@vigilsec.com> Date: Tue, 29 Jan 2019 16:29:59 -0500 Cc: LAMPS WG To: Tim Hollebeek X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [lamps] draft-ietf-lamps-cms-hash-sig-03 is ready for WG Last Call 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, 29 Jan 2019 21:30:03 -0000 Tim: At the meeting in Bangkok, the LAMPS WG felt that = draft-ietf-lamps-cms-hash-sig-03 was ready for WG Last Call. However, = it was felt that it would be preferable to wait for = draft-mcgrew-hash-sigs to reach the RFC Editor queue. That has now = happened! Please start the WG Last Call for draft-ietf-lamps-cms-hash-sig-03. Russ From nobody Wed Jan 30 11:24:46 2019 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 38537130F96 for ; Wed, 30 Jan 2019 11:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcCWX6OXVQvE for ; Wed, 30 Jan 2019 11:24:41 -0800 (PST) Received: from mail1.bemta23.messagelabs.com (mail1.bemta23.messagelabs.com [67.219.246.209]) (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 A327E130F8E for ; Wed, 30 Jan 2019 11:24:41 -0800 (PST) Received: from [67.219.247.52] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-d.us-east-1.aws.symcld.net id BC/60-12949-8F9F15C5; Wed, 30 Jan 2019 19:24:40 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTW0wTQRSGme5uWZE1QwtybEBj0UTRVmpIFdG I0cRbUFDig4HoQhdaUwrptorGB4xaCWj0gWjAalEJKPqAiFEbNaQ8eMErSlXUYANquCUaLkJU 4m6nKD7s5DvnP3POP5sZllKVhmtYocQh2G28VauMoM1LFhh1P8Yzs5NaD61aft6fl4Y21NaOK zLQTsZiyy0q2c2Yz9a8ZYr9W0p6X+WVIu/mchTB0vg4BacfdtFyoMKnFNDd4aJI8AnBO59bCq axSpwE/nsPFDJHYw0MlF0PshonQ8uTz0qSTwFv1ZlQjR5GPeOMzDSeD/1XGoN5DufAzaNvgz0 Rngk/Hl8L5ikcC509niADjobAyzYl4Rjo7Z5gSH02nBvyhfKz4Xn5SIjjod1TgWTTgA+HQ/Ox NwwR0qHj5h2GCD0IDjX9RERIhBOtbpqwFb7WP5U6sRLHwfBwFqn3MFDlqQs6UmETVDb8m9xwI kCTohcUPH/dHhxN4RoEgU5yZg5HwaOqHnrSn/vdMEV4G5zu7gjxVvhVUas4heZVT/kF1VN7VU /pRYp2Quv1k+GEdeC930IRngO3Bt0hXgyurrYQL4K6C/0Sh0u8EppNJDsXKisCoS5GcD37rqx B0xvQsly7pcDsKOQtVp0hKUlnMCyVPt1SQ7KeP6Az6Z2iTuBFh86g5/eJenF/YZ7VpLcJjiYk 3UBT8XT/bXSnvMCHZrEKbQy3KT0zWzUjt8i038yL5l12p1UQfSiOZbXAfR2TtCi7UCCU5Fus0 jWelIGN1EZzLlnmxGK+ULQUEOkxSmFbLgbOUWxz1xdp9cqrirYV2QRNLFclb8DyBrPT9rfd5M NoR/EaNYfCwsJUkcWCvdDi+F/vQ7Es0qo5Sno/qkiLzfF3ap9kSCEZOrAmQzbk4P9JmlL00Ll 1TBzOT5tITU9o3Le6E5gXsW3u3OT4G8lxvpyckcF5K/zrsz6ONNWvsE/wS8byK+/vFfHV+Ltr v2VRBy9zCWVGY3qMmJi6uHuXVc3utW+v+JCa8lv9Ps0LbeuOlCmiGja+XPhoz2c8OFozOi1vw DneY3pmHHKJt3dkrHJe0tKimTckUnaR/wPriObiEwQAAA== X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-26.tower-424.messagelabs.com!1548876278!600811!1 X-Originating-IP: [104.47.40.54] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24195 invoked from network); 30 Jan 2019 19:24:39 -0000 Received: from mail-co1nam03lp2054.outbound.protection.outlook.com (HELO NAM03-CO1-obe.outbound.protection.outlook.com) (104.47.40.54) by server-26.tower-424.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 30 Jan 2019 19:24:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c1o86M8uiJUCiS449vj6NTz6dT0M8rIwo+/vYk19VFk=; b=ivteSn8SiU6rsx3yaUCqU7CJqsBLVIJJGujPx3kN+ofTfKSF33Eeq4PQxEz9kZObapCP/ZPd4HulD9Pkmu4CG6xhXLnrLw7QsuwJ2YTAxzcV8lavNl9H3bo3W5U6CVRXDyonQTrbntc+/bcIQZaqtId0DRJocE4zdTgWYfVjBVA= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1282.namprd14.prod.outlook.com (10.173.164.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.17; Wed, 30 Jan 2019 19:24:37 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::34c2:edc4:19ee:d9b0]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::34c2:edc4:19ee:d9b0%10]) with mapi id 15.20.1558.025; Wed, 30 Jan 2019 19:24:37 +0000 From: Tim Hollebeek To: SPASM Thread-Topic: Last Call: draft-ietf-lamps-cms-hash-sig-03 Thread-Index: AdS40GKoFYXnwsS1QwKY9DVE0d/aRg== Date: Wed, 30 Jan 2019 19:24:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [8.46.76.49] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1282; 6:HJP+H4iDldrVEjO+pbnG9GXoSnJNj+ONdqXRElS2pfhdQFZGz0f5uPQGBv8bYelnqI+FTuBJX2M4HknyEiGb5BM7L+AvvvYq8r2/iGY/8F7VXzmWvWUx4UHG/bBF+M1uFI37H8y2ZXjDUuAsMGilK5hgZdGua++4zUKcwQRgkur4CkZw0/6UAoh/k14jW4ymuVVdzYJkk5oAxoQg/NwxD4izPo0xSMcjy7Fp7FlE+2OyyVHNxJMiy0Lxj/V77eNTZh5GgkB2CVSRG6L/jWt7NRUAsPdQ5myswECPm7/vKDd9g5V8+HH4bWbHtDPIFJq4W+uxpxANd6CVIyNAVAEaEZwr0HMOLBpce4JaVVVBIfrYzd9MDnaEh3lLwshLJYr+22hXdnyjFJSvHRuawy3/jdfot1TwSSQbYmHAmF/uwLInCyTCzfe3gNc0ctIQGhP0Xd/XVti5mqK/5NkBnY4c+g==; 5:1Hx4vqEvWqkav2l1NgCg/CCOw6b3AiBMDITefEfDKHLtmL0gqnEL6+FQnykQpCmD32MaT00/LXaO0tRvTU6DhfDcLz1Mz5G4WCe1YYAC3JuylBoA9MIA//wsEbvmTLuh8oCoTxV7rsxA+YJ/YcexvEET51AvCKdIhjHRm54VunZfvwIf5AhXxo/i7S9U0VbNRaFdW9H4iRHRoKZ2OFuxQg==; 7:z66oNI5bbI/vIHjYtNke2P8jly0jb0vlk8fna6XM2kLswCdXJqHDVDOKXuQNZWJBlD08yT4CEHCwoul16fa0F5EbbcbISEZnITu5n52E8g+/wBtHEvGJaQ+4ZVDXMhcTqSxM8MurtQtVzDaf8xmOIA== x-ms-office365-filtering-correlation-id: 09cd0031-e3db-4119-5ddf-08d686e892e6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1282; x-ms-traffictypediagnostic: BN6PR14MB1282: x-microsoft-antispam-prvs: x-forefront-prvs: 0933E9FD8D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(376002)(346002)(136003)(39850400004)(189003)(199004)(7736002)(6916009)(55016002)(99936001)(316002)(86362001)(9686003)(4744005)(256004)(14444005)(790700001)(6116002)(3846002)(14454004)(97736004)(8676002)(6506007)(74316002)(81156014)(81166006)(6436002)(476003)(66066001)(99286004)(68736007)(2906002)(26005)(186003)(25786009)(105586002)(106356001)(102836004)(6306002)(54896002)(7696005)(53936002)(486006)(71190400001)(33656002)(44832011)(71200400001)(8936002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1282; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: w3lNB30nie2CJYoBsE2aZiDk7FgTz+NZpqJTx/CaV8bTFJm2T84SIuz95khN0SiFiBk/TTciOmzbYrbfU9CQmR2a6PSzeD8BEUVK3iCIuN0ijjOPaWERyJ71J7wYO+WpH150ovTi5SbQS4Y3OEqX4jUecg0s359HC3XYGN9VEJIsTxWzaYcHHIvByT0BE0u2yQAiQdn3ZeW5UbDeP1YuEPNvkNpacMwzwH7hBQrPMWqTV8HEE2B3eDl0lcFmM1CNF/W33qHikqt0MHu08+lTuxgs5pWXFjcl46gDOB6CaSWLTJmU1rphzM3byyofNXhbbGdOQ653lop3bY4rnzuKvjCR8OtzEf1GsdZ1DYkONYTry/yx051Km48XtvDaik+PuDbQpLeTNzAnOlL4APV/iFPw/DVnSCHrLTKAa/3pMJ8= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_01A1_01D4B8A7.7D267AB0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 09cd0031-e3db-4119-5ddf-08d686e892e6 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2019 19:24:37.3408 (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-Transport-CrossTenantHeadersStamped: BN6PR14MB1282 Archived-At: Subject: [lamps] Last Call: draft-ietf-lamps-cms-hash-sig-03 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, 30 Jan 2019 19:24:44 -0000 ------=_NextPart_000_01A1_01D4B8A7.7D267AB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01A2_01D4B8A7.7D267AB0" ------=_NextPart_001_01A2_01D4B8A7.7D267AB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is the LAMPS WG Last Call for "Use of the HSS/LMS Hash-based Signature Algorithm in the Cryptographic Message Syntax (CMS)" . Please review the document and send your comments to the list by 14 February 2019. If no concerns are raised, the document will be forwarded to the IESG with a request for publication as Proposed Standard. -Tim ------=_NextPart_001_01A2_01D4B8A7.7D267AB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

This is the = LAMPS WG Last Call for “Use of the HSS/LMS Hash-based Signature = Algorithm in the Cryptographic Message Syntax (CMS)” = <draft-ietf-lamps-cms-hash-sig-03>.

 

Please = review the document and send your comments to the list by 14 February = 2019.

 

If no concerns are raised, the document will be = forwarded to the IESG with a request for publication as Proposed = Standard.

 

-Tim

 

------=_NextPart_001_01A2_01D4B8A7.7D267AB0-- ------=_NextPart_000_01A1_01D4B8A7.7D267AB0 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 CQUxDxcNMTkwMTMwMTkyNDE5WjAvBgkqhkiG9w0BCQQxIgQgiEhbvuhEhMeLMNMGTRHldhbfDOKx 8vge+29agKIajc4wgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAMD+1oA7i24+ISFfG4aUyzJItTBzjnjA8Bxp2Gb3sZMUA+zGYfPsOm/xzaZMTuVz5xW/OalQ DcqVvSWY02YAG5n4PbE2rQUE8TqFz7eamMhfLG/AuS8awXzS12yXVIBuuVd+DAlv0gYomP8bahw6 7ImvgKMSKWapxjY/PcnW466KGsEBLV5oyGYiMNB1cu8HdHThG9RhsZlwaBAXW/qHBg1KSli3qoox UuYPcuMzKQaOKu+zNwaTuskFbp42wJVKL+UuPwnuaHgUmBTdYKC6mJix5YN+Jy05o7dkBGt+Ylof InhXnxEqeDklMVm/9YRbY/yJYdD61ynmuCNCkaPdVaQAAAAAAAA= ------=_NextPart_000_01A1_01D4B8A7.7D267AB0-- From nobody Wed Jan 30 12:04:13 2019 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 CA3C8130FD6 for ; Wed, 30 Jan 2019 12:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.052 X-Spam-Level: X-Spam-Status: No, score=-19.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_ngBZwFBeCV for ; Wed, 30 Jan 2019 12:04:09 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FF2B130FBF for ; Wed, 30 Jan 2019 12:04:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5178; q=dns/txt; s=iport; t=1548878649; x=1550088249; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=rsHc0fK2QyDeGBaesSFsPLv/uPolyHRxeYaBDlwS5tk=; b=jReti8np0BXChdcneuyitfooOBagN/kNia4/simsSRnRMc1G4MLEonbe ULXKU7xIKlIH34GN6U/6bM+BY8ESSVWDqfVLgJovs6TCysN19+cf70dSj FuBxvYLqs3TrGsNz1m3mCdeeQHydwulWq7E+X5JMYhTY8vXO32IWxXHUM 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADoAVJc/5pdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ12Z4EDJwqME4tzgg2SH4VugXsLAQG?= =?us-ascii?q?EbAKDByI0CQ0BAwEBAgEBAm0ohUoBAQEBAx0QXAIBCBEEAQEvMh0IAQEEARI?= =?us-ascii?q?IgxuBHWStdooyjEAXgUA/gRGDEophApAEklQJApIoIIFrhTmJWoE1iUlQkSI?= =?us-ascii?q?CERSBJx84gVZwFTuCbIImGI4eQTGOYIEfAQE?= X-IronPort-AV: E=Sophos;i="5.56,542,1539648000"; d="scan'208,217";a="232943012" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jan 2019 20:04:08 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x0UK47oS019463 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 30 Jan 2019 20:04:07 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 30 Jan 2019 15:04:06 -0500 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1395.000; Wed, 30 Jan 2019 15:04:06 -0500 From: "Scott Fluhrer (sfluhrer)" To: Tim Hollebeek , SPASM Thread-Topic: Last Call: draft-ietf-lamps-cms-hash-sig-03 Thread-Index: AdS40GKoFYXnwsS1QwKY9DVE0d/aRgABY5rQ Date: Wed, 30 Jan 2019 20:04:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.57] Content-Type: multipart/alternative; boundary="_000_d07ed88179514efd848f3a98e6ef5129XCHRTP006ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.146, xch-rtp-006.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [lamps] Last Call: draft-ietf-lamps-cms-hash-sig-03 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, 30 Jan 2019 20:04:12 -0000 --_000_d07ed88179514efd848f3a98e6ef5129XCHRTP006ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just two spelling corrections... Nit: in the first line of section 4: "for an HHS/LMS public key" should be = "for an HSS/LMS public key" Nit: in the first line of section 6.2: "on the current sate" should be "on = the current state" From: Spasm On Behalf Of Tim Hollebeek Sent: Wednesday, January 30, 2019 2:25 PM To: SPASM Subject: [lamps] Last Call: draft-ietf-lamps-cms-hash-sig-03 This is the LAMPS WG Last Call for "Use of the HSS/LMS Hash-based Signature= Algorithm in the Cryptographic Message Syntax (CMS)" . Please review the document and send your comments to the list by 14 Februar= y 2019. If no concerns are raised, the document will be forwarded to the IESG with = a request for publication as Proposed Standard. -Tim --_000_d07ed88179514efd848f3a98e6ef5129XCHRTP006ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just two spelling corrections…

 

Nit: in the first line of section 4: “for an H= HS/LMS public key” should be “for an HSS/LMS public key”

 

Nit: in the first line of section 6.2: “on the= current sate” should be “on the current state”

 

 

 

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Tim Hollebeek
Sent: Wednesday, January 30, 2019 2:25 PM
To: SPASM <spasm@ietf.org>
Subject: [lamps] Last Call: draft-ietf-lamps-cms-hash-sig-03

 

 

This is the LAMPS WG Last Call for “Use of the= HSS/LMS Hash-based Signature Algorithm in the Cryptographic Message Syntax= (CMS)” <draft-ietf-lamps-cms-hash-sig-03>.

 

Please review the document and send your comments to= the list by 14 February 2019.

 

If no concerns are raised, the document will be forw= arded to the IESG with a request for publication as Proposed Standard.=

 

-Tim

 

--_000_d07ed88179514efd848f3a98e6ef5129XCHRTP006ciscocom_-- From nobody Wed Jan 30 13:41:48 2019 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 DDFDA130FF4 for ; Wed, 30 Jan 2019 13:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.655 X-Spam-Level: X-Spam-Status: No, score=-9.655 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOH4m2tLa2oK for ; Wed, 30 Jan 2019 13:41:45 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2B55130EBF for ; Wed, 30 Jan 2019 13:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=NkAOLq1d9Ks/2OHsiLIA4GZIGlnaKTtp5cYfsFrPSYg=; b=pWbWUI5nraMGnCPPsT0Co6fFCv Q0eb0RDwhPCW439RYo3i3E4/2VMnq/4JN8M38hZE88UsTsiVL41v92ydFjAGWABKw68isor/WO66B D+AVmSlKlbUPrQ+UdwzOi1b9IZESuFx181Yx07E68SjnQ6Wsa60lFu+4FiEL4/q3eAV4=; Received: ; Wed, 30 Jan 2019 13:41:43 -0800 To: Rob Stradling , Tim Hollebeek , SPASM References: From: Jacob Hoffman-Andrews Message-ID: Date: Wed, 30 Jan 2019 13:41:38 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [lamps] CAA: Title case for Defined Terms? 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, 30 Jan 2019 21:41:47 -0000 Here's a PR adding Title Case for all Defined Terms: https://github.com/jsha/caa-simplification/pull/8. I'm also going to work on a PR to use "Wildcard Name" instead of "Wildcard Domain Name" because it's confusing that Wildcard Domain Name is not a Domain Name. From nobody Wed Jan 30 13:47:25 2019 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 AF961131303 for ; Wed, 30 Jan 2019 13:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.554 X-Spam-Level: X-Spam-Status: No, score=-11.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UL7PVtcm4QPi for ; Wed, 30 Jan 2019 13:47:22 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F7F61313B9 for ; Wed, 30 Jan 2019 13:46:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:References:To:From:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=+az3O/QVZjuYvrLNOjnVes8Rdo5X6LY69OSo9SZoIuo=; b=XlHWXSihVEaXbrLuLLVYYGnvqA vc9bXP0t7tk5NjsXjT1hFdDss9/ZUz+a8mKrWqYwVSTYUmdBVsX8+objDSbAJdXWo/Vqso/6+nQbK coVPbZ69MLoNGRCCoduFOpOsyuy/kp4QKUwib7q3+yvE/RwjfZpCKGua06mduQkPI/HI=; Received: ; Wed, 30 Jan 2019 13:46:40 -0800 From: Jacob Hoffman-Andrews To: Rob Stradling , Tim Hollebeek , SPASM References: Message-ID: <63cbcb8a-cfba-596b-4d41-510273c8f717@eff.org> Date: Wed, 30 Jan 2019 13:46:39 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [lamps] CAA: Title case for Defined Terms? 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, 30 Jan 2019 21:47:24 -0000 And here's the one for "Wildcard Name": https://github.com/jsha/caa-simplification/pull/9 From nobody Wed Jan 30 14:49:49 2019 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 37983130EBD for ; Wed, 30 Jan 2019 14:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7IjvLK_dxLM for ; Wed, 30 Jan 2019 14:49:46 -0800 (PST) Received: from mail1.bemta23.messagelabs.com (mail1.bemta23.messagelabs.com [67.219.246.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24C56130E25 for ; Wed, 30 Jan 2019 14:49:45 -0800 (PST) Received: from [67.219.246.100] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-b.us-east-1.aws.symcld.net id 52/B7-21984-80A225C5; Wed, 30 Jan 2019 22:49:44 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1VSa2xLYRje13Pp0awcZ6u9FobGgianWjIqIy4 R2Q9iESKYy+l6rE3arunpokPYSJaYEWEsSo1lYtnmkrERzGyCdAuZhWGupSwWY6hbyOacfRuT 78/zvs/zvs/zJS9DcGE6kRH9PtHrFpx6WkPap06czjOGZRmmtwVJlsP3f9KWmx29hOVYe+Y8I u3D504qrbz8pyotmj8inVhNOdzWbP8Gyr6z9yrpqZrlb6iLqPNQgaUQaRiSLSLgxIlftFJw7D 4V/LjQosLFCwRlZz/IxTCGZk3QXn+7H8ezVqi5XEYpOI6dCUdedhK4b4Hz3Y0I40XwNf8gWYg Y2SIZbp2brbS17Fo48+gGgff3IAi1B/tnh7GpEPp+l1YwYkfB9+bqfi+CTYCOSGk/BjYewvda aIx18O51L4X1GRD80jTQHw9nPj5QYzwW2kp3I8UM2J1q6C7HZsAugac9rweICIL9v4IUJgzwL dKiVlID64QnN1ZhOAai0eVY0UzBnScWBXOsDYorB32ToHJPmMQrWwkoCtymlIJgjyM4VP2Qxt 8fCaHDEXIw3dHHUWIfSg4M+Whg6ExgyAwWGaB8R58a43FwsfsoEUBqGc+GCzbcnQDFu8MDihl QcPcTfRwxlWiG1evIsvtcgsPJm00m3myexssvJcUobOatxhyJFwXJx5uNwibJKOW6Mp02o1v0 1SD53GweVd8l9PtkVhMazaj0Om0xtyyDG27NtuXaBcm+3pvjFKUmNIZh9KBtmixzI71ilujf6 HDKNztIAxOrj9euVWit5BFckiMLU82IZ66XhYMER7qz3WJigvaVImIVkT3H/XfF4OW3obGJcV oUExPDxXpEr8vh+5/vQgkM0sdpvyhbYh1u31+nLjmESg6xeX66EsIn/KMS81DJ+6Su2uf8ggl z64pCofq2yVWudFJjqGg4+6ww1+fXpb/lPUFP6HLHwhHrDnQW1ba+MGw9dcBdV9JwqC1Fd2xe 6rYr4pyeWdz01tOPTBzzPO0gnVFydeb2XOdezZalfk3qmlLTp7wVKbsqhNpri6l8cuUC88LMv oopt97cn6RrjOpJyS6YDYRXEv4AgYo7aPQDAAA= X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-16.tower-384.messagelabs.com!1548888583!538824!1 X-Originating-IP: [104.47.36.51] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9607 invoked from network); 30 Jan 2019 22:49:44 -0000 Received: from mail-sn1nam02lp2051.outbound.protection.outlook.com (HELO NAM02-SN1-obe.outbound.protection.outlook.com) (104.47.36.51) by server-16.tower-384.messagelabs.com with AES256-SHA256 encrypted SMTP; 30 Jan 2019 22:49:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cbn8h67haGFhHLNqY5sCweFHVL/MoCWTX3VCr6QuXg4=; b=lKCr42WDPGQlwxTZDNuCdy3DGznW5B9WxHzh9GcSN73+JgYMju/Gpf7V4m2N+3AfFVYUcW0jB6lUVpQKMSRL70uNnA9cBQdAv6GxyjzzrvQgE7bUwsxKvFlCvOkojOlPh0Vba0KkF1Ja8bcGzUp+ogYag4SzTmZ538YOrIvtqeg= Received: from DM5PR14MB1116.namprd14.prod.outlook.com (10.173.131.10) by DM5PR14MB1146.namprd14.prod.outlook.com (10.173.131.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.19; Wed, 30 Jan 2019 22:49:42 +0000 Received: from DM5PR14MB1116.namprd14.prod.outlook.com ([fe80::b807:5f96:1035:baeb]) by DM5PR14MB1116.namprd14.prod.outlook.com ([fe80::b807:5f96:1035:baeb%7]) with mapi id 15.20.1558.021; Wed, 30 Jan 2019 22:49:42 +0000 From: Tim Hollebeek To: Jacob Hoffman-Andrews , Rob Stradling , SPASM Thread-Topic: [lamps] CAA: Title case for Defined Terms? Thread-Index: AQHUtEl+yHKlKISCdkmJnBQ7J4GVOKW/Oa8AgACbCoCACIvcAIAAEoAA Date: Wed, 30 Jan 2019 22:49:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [69.162.16.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR14MB1146; 6:VXS8Upc5p9pB5/HqplKQvxmxoLPQneCPE1RRWMSnXdHTdjEmDfCkO8UK0fOeuad5AbduqoDo69ZiFgWaWTrc9oiaaWPCjifqOWaSj70h/MIe/ZTsnbgMNIeodYwqjrjP3sJZxPS5l4XA7qH9p4AzOU6gmQxSx5eIlbI5FtdkgltXWYkVJHcQv8tQ+UmrCzurF1kQfLcDJ5jf4MV7ujo0p8sDtCpBqQkQxg0LQaT/L8yD3MAO3YHDC0yjzHX99QVai4IdOxc6jza71daxVxALJL/6uTicXay4eDHFTWM3rvJolwX7cw/AA1U/FcP9Fqes7s0M3k0Vmydcg3hfL+9k5wlShM5TAeg46+m4aErL7q1OGspfTb2ztloMJa7Wk7w4v04uyxjBjEAJQHNV6ecuvTSQgVlBitmCoPlyr1iA/u345tc/bUwovG7CoChGTmFjVZSYEs3IGxbhJKRBxQfnLw==; 5:VxPIPppMHDMpvsF7zmDWbBPvYV3joVQIBSrjfATyRDbJLNLlp+3WK31DaYJ2cD9LakQ4MwWoLMmP2rvVWGRwT7+Pyd8xTKQFWXYr6PcNLXjMN4v0ePsPDJcdGh8LUU/iQqPOSYZZTnNHqYXshkUI7oL4/n625UT8VIMiO9wxKtS1NKpqMJL43AUYa0TgjvoGDTcjs3ypCidPeREwOdGaWA==; 7:TVCJ9VjaM6sw7Bbkxl6T+GciwcnRopkuAX2Etc5TJC2FO53ZxmytnKCedtOCfAdZKCFQ+kEM8hscSqWD5+YyCFmIb8GisbzrY5j+nl63ANYOo6CupURAHp1ufh+QT/b9gsXKlwQ1XehF6bagRqe81A== x-ms-office365-filtering-correlation-id: f707db86-8a90-4992-bf96-08d68705393c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(49563074)(7193020); SRVR:DM5PR14MB1146; x-ms-traffictypediagnostic: DM5PR14MB1146: x-microsoft-antispam-prvs: x-forefront-prvs: 0933E9FD8D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(366004)(136003)(39860400002)(346002)(199004)(189003)(478600001)(55016002)(71190400001)(86362001)(7696005)(68736007)(71200400001)(3846002)(229853002)(6506007)(9686003)(8676002)(99286004)(6436002)(66066001)(558084003)(7736002)(446003)(105586002)(11346002)(476003)(305945005)(8936002)(76176011)(74316002)(53936002)(44832011)(6246003)(256004)(106356001)(25786009)(14454004)(81156014)(486006)(316002)(186003)(26005)(93886005)(99936001)(102836004)(33656002)(97736004)(6116002)(110136005)(81166006)(2906002)(14444005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR14MB1146; H:DM5PR14MB1116.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Vkrbe5zkkvzc3VheauoypD2Rv875+1ckpbKVYkEF6uIRr2ZSzZiKU8rnZBLPAfvlC2F5z/CHVrP6kNUoWLV4U1d8tpApEWLVgD59T+Psqtp1M1OF5PR2JddCq94QewFjFrEHNgirY22J4upSyjBHV+Ehv6L0WZC6O6fHppBc32iVkaFBUCV6xW0NtOuWCyt1y/c4W4cuRFllf6URIm4wAa9pCpFS64NbUncIei40Spo1Muwhi89LranvF3HVCaIGIx/woQ8LDP/kANdboB05yQJFjC63tp/EvwI1h2bZWYcRI+D4qQOmrQHXnqd6yJmasVF0E47SO6YZQKWTKNTybsy0KltNNlbIYbnr08ymhHkq1U/mHM2suJ6EHBZMKkQik4lnM1Ll/vDUSWjqZJdH71m89SzPVnDaFlHvtfkIYug= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_01C7_01D4B8AB.009B6790" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: f707db86-8a90-4992-bf96-08d68705393c X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2019 22:49:42.2971 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR14MB1146 Archived-At: Subject: Re: [lamps] CAA: Title case for Defined Terms? 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, 30 Jan 2019 22:49:48 -0000 ------=_NextPart_000_01C7_01D4B8AB.009B6790 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit While I appreciate this argument, is it important enough to justify a divergence of terminology with the Baseline Requirements? -Tim > I'm also going to work on a PR to use "Wildcard Name" instead of "Wildcard > Domain Name" because it's confusing that Wildcard Domain Name is not a > Domain Name. ------=_NextPart_000_01C7_01D4B8AB.009B6790 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 CQUxDxcNMTkwMTMwMjI0OTI4WjAvBgkqhkiG9w0BCQQxIgQgPP0eLtBTqpu2EPHFCWxGBfpw9HjG yKjcFFccYujGtlgwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAGHPTdhdO7k5lUxlPEtdSRW0Br/Wj9eGg1LY0DmRs4Jw1aSo21pVCR4ljl36yt1KF91lqEe1 dJgp8T+JQs3wOsPzvMzbm9+zvPJZlv9OrReZctb2144TudqCiqLdkFKcKxI2Q/P0YtjtiTMqwXCF mFNg39e/Pjr2n9wC+6ELCf/mnRaZrs3EkW8NJ35LYy2iggCNsbwjUO37EeY95rBarKjALO2GlWpX uA4ZHm12+tC76aMPJhd/uz5tUhzQZZ3pHE1TBTlLDze1DXRYpZg7g6fpwGjQPxdZ05kx5vqTX39k cR7C7iLF8O/ivQMbzZo3T5a/1hc4gzaOAPaQQza6WD4AAAAAAAA= ------=_NextPart_000_01C7_01D4B8AB.009B6790-- From nobody Wed Jan 30 16:37:04 2019 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 D4815130EDD for ; Wed, 30 Jan 2019 16:37:02 -0800 (PST) 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, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBDGyhzUl9_1 for ; Wed, 30 Jan 2019 16:36:59 -0800 (PST) Received: from mail-it1-f176.google.com (mail-it1-f176.google.com [209.85.166.176]) (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 636FE130EBF for ; Wed, 30 Jan 2019 16:36:59 -0800 (PST) Received: by mail-it1-f176.google.com with SMTP id c9so1369820itj.1 for ; Wed, 30 Jan 2019 16:36:59 -0800 (PST) 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=X+he+e5KyjwWpyhFanwIuLvOdbm6d8B99uRreXWII8E=; b=leuY8ERLHouzeBKSkiAy0KqP2lc+c4mkEHdYPitrjgzztf7gjyFXMeREp70ju3WB+w 7+5Br2/P4tHd9ZamBb0h6/y/ujjHhnkXEY/2BRmiAouWUsMkP1U7q5+otVO/zJJI+Rza dKLi3qwfNp5x1cZnAlFBzG94GhExZPV5Vglg2skOYoXfA6vlYq1W6B08YK/8OMSHjMcp gpxFZ4MxG4xxBzUl5lWgh8D/00WRH5ORHMaUgukY/dbQ3e3NQGlebRO0KFC1l4OBha1g c9yrlJCi8CLyhFuWhXuLhNwd9/dKWFEV0PbozQoBBoWPRMs2YooNsn8HwCwuUPmit2KI k0JA== X-Gm-Message-State: AJcUukfUPa7gCCXL30grEPHnnuO9liM306WMlze6LKUM8WXDJv0Yi7aM 9QuaA70VRAcso8PjDzEmkb6R0Pq4 X-Google-Smtp-Source: ALg8bN4B7TCGc+eenKfY85XqebbNhvH89K2rKnkWlCxPu5jxQBsMi2UeZ4AjYzESeDb20Ydt+w9c/Q== X-Received: by 2002:a24:1f0d:: with SMTP id d13mr16375454itd.140.1548895018052; Wed, 30 Jan 2019 16:36:58 -0800 (PST) Received: from mail-it1-f169.google.com (mail-it1-f169.google.com. [209.85.166.169]) by smtp.gmail.com with ESMTPSA id m37sm1983191iti.6.2019.01.30.16.36.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Jan 2019 16:36:57 -0800 (PST) Received: by mail-it1-f169.google.com with SMTP id z7so1298801iti.0 for ; Wed, 30 Jan 2019 16:36:57 -0800 (PST) X-Received: by 2002:a02:9c53:: with SMTP id h19mr21128916jal.31.1548895017264; Wed, 30 Jan 2019 16:36:57 -0800 (PST) MIME-Version: 1.0 References: <63cbcb8a-cfba-596b-4d41-510273c8f717@eff.org> In-Reply-To: <63cbcb8a-cfba-596b-4d41-510273c8f717@eff.org> From: Ryan Sleevi Date: Wed, 30 Jan 2019 19:36:46 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Jacob Hoffman-Andrews Cc: Rob Stradling , SPASM , Tim Hollebeek Content-Type: multipart/alternative; boundary="0000000000004c6d430580b639f6" Archived-At: Subject: Re: [lamps] CAA: Title case for Defined Terms? 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, 31 Jan 2019 00:37:03 -0000 --0000000000004c6d430580b639f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable RFC 8449 / BCP 219, in the discussion of Domain Names, notes that IETF documents have been inconsistent in the application of the term, such that the use of a wildcard can be valid in the wireform of a domain, but not conform with the rules for hostnames or presentational syntax. I say this because, on the balance, I don=E2=80=99t have strong feelings fo= r or against this change. It may be that referencing BCP 219 provides a more stable set of definitions here, if necessary, than the BRs. On Wed, Jan 30, 2019 at 4:47 PM Jacob Hoffman-Andrews wrote: > And here's the one for "Wildcard Name": > https://github.com/jsha/caa-simplification/pull/9 > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --0000000000004c6d430580b639f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
RFC 8449 / BCP 219, in the discussion of Domain Name= s, notes that IETF documents have been inconsistent in the application of t= he term, such that the use of a wildcard can be valid in the wireform of a = domain, but not conform with the rules for hostnames or presentational synt= ax.

I say this bec= ause, on the balance, I don=E2=80=99t have strong feelings for or against t= his change. It may be that referencing BCP 219 provides a more stable set o= f definitions here, if necessary, than the BRs.
--0000000000004c6d430580b639f6-- From nobody Thu Jan 31 07:15:00 2019 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 E121B1286D9 for ; Thu, 31 Jan 2019 07:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.564 X-Spam-Level: X-Spam-Status: No, score=-4.564 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rso05GQOzcA7 for ; Thu, 31 Jan 2019 07:14:57 -0800 (PST) Received: from mail1.bemta24.messagelabs.com (mail1.bemta24.messagelabs.com [67.219.250.209]) (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 0CB341295D8 for ; Thu, 31 Jan 2019 07:14:56 -0800 (PST) Received: from [67.219.251.52] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-c.us-west-2.aws.symcld.net id E4/30-21710-FE0135C5; Thu, 31 Jan 2019 15:14:55 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELsWRWlGSWpSXmKPExsWSoa9hovtOIDj G4N9EfYuZV36yWRy99Y/ZYtL9uYwW864lO7B4vPv0nNVjyZKfTB5fGvk9mnfvZglgiWLNzEvK r0hgzZix7TRjwc+Mis0/5zE3MC5O7mLk4mAR6GGWmD+hjbGLkZNDSGAik8SivTwQ9gNGicsna 0BsNgEDiWt7jzOB2CICPhK/Jr9hBbGZBawlPk9aBdYrLGAuMfvBc2aIGguJzW8PMkLY4RINrx eB2SwCqhJHZsxgAbF5BWIlPmw5zwxyhJDAMyaJn0/62UESnAJBEvcPvmUDsRkFxCS+n1rDBLF MXOLWk/lgtoSAiMTDi6fZIGxRiZeP/7FC1MdIzP18CCquILHu/VV2CFtW4tL8bkYIu5ld4uX0 YAjbV2L+9kvMEPYTRomlj8MgbC2JA5ebWCHsHInLPQehemUk+t5+ZgQ5WkKgi01i35wLrJDQS pGYsgpmsZzEqt6HLBBFF5gl3i5bCvYms8ACRonzr54wQvwvKHFy5hOWCYzqs5B8NwtZ3SwkdR BFURINl/oYIWwtiSVN/9khbG2JZQtfM0PYmhJfJtxmQRVnB7JtJLakQEQVJaZ0P4TqNJNoO/e RbQEj9ypG86SizPSMktzEzBxdQwMDXUNDI11DYwtdC2O9xCrdZL3SYt3y1OISXSO9xPJiveLK 3OScFL281JJNjMDUmVLQFbyDcXZ3+iFGSQ4mJVHe1NdBMUJ8SfkplRmJxRnxRaU5qcWHGGU4O JQkeIO4gmOEBItS01Mr0jJzgEkcJi3BwaMkwrucHyjNW1yQmFucmQ6ROsVoz3Fg0cO5zBx9G5 8ByS33QeQuECnEkpeflyolzqsC0iYA0pZRmgc3FJZ1LjHKSgnzMjIwMAjxFKQW5WaWoMq/YhT nYFQS5n0IMoUnM68EbvcroLOYgM6qcgwAOaskESEl1cC4JPmNQeZHrt4v53dFnrwl8+WD2eQ4 BhGGNxo3jXhv39oZeiJe4TDr4sB0BxvpQ5PWarmeWb68oNXapmX1iag/3KEpQpfL/AT9p07/9 vdYSXgci+CBD0LG8yc9Yu7KO55mVpXHZvtNyWRpQIT39hsbhZzcT06ZMymh9qdFofmLe3fOVm vJ9x1UYinOSDTUYi4qTgQAflb+uzUEAAA= X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-18.tower-364.messagelabs.com!1548947693!513988!1 X-Originating-IP: [104.47.40.52] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27237 invoked from network); 31 Jan 2019 15:14:54 -0000 Received: from mail-co1nam03lp2052.outbound.protection.outlook.com (HELO NAM03-CO1-obe.outbound.protection.outlook.com) (104.47.40.52) by server-18.tower-364.messagelabs.com with AES256-SHA256 encrypted SMTP; 31 Jan 2019 15:14:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ewusd9dm5J6WJ2mISfSBTMuvnhXXoX0z9ybaAmVXEuA=; b=JpY6xCNR5J88gXPLUYB2mJJOeEGDL7Lk3+gf1+Cr2+q4do/CeB2k9bfP4pRyFQP4Db9peknbaEml8aZRSzRPRASVZMg3Vz1CWN5tLXKll61bPgoPFIWehNSn105ELqIK8V/+t6xlHCmFTO9BiLaYqWXD7n0azggOAWB+82adADg= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1298.namprd14.prod.outlook.com (10.173.159.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.17; Thu, 31 Jan 2019 15:14:51 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::34c2:edc4:19ee:d9b0]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::34c2:edc4:19ee:d9b0%10]) with mapi id 15.20.1580.017; Thu, 31 Jan 2019 15:14:51 +0000 From: Tim Hollebeek To: Ryan Sleevi , Jacob Hoffman-Andrews CC: Rob Stradling , SPASM Thread-Topic: [lamps] CAA: Title case for Defined Terms? Thread-Index: AQHUtEl+yHKlKISCdkmJnBQ7J4GVOKW/Oa8AgACbCoCACIvcAIAAAWeAgAAviACAAPT6sA== Date: Thu, 31 Jan 2019 15:14:51 +0000 Message-ID: References: <63cbcb8a-cfba-596b-4d41-510273c8f717@eff.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [69.162.16.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1298; 6:7bmS0q7gtvIbHMjxsN8CslLDEGSrI41KhgwUTyMScFmzPB0csklJGSyv7qL+ASM4uFSfX5hI7onzMuUZhT3fvRd85SVLcjfzSyPliRYFxXjugZAhUCl83YT9o+TiO0wZu4Y+2FxBYDjSXA7SspUozxAwEUOZXp4MEYiiPk/koeNsOFcmHd+icSKVKvxK8VdZZQuAhkYKt78rPiPBom0eX5mdyYYsqeRzCWb4Z9PsGrKTypcUvZ6NqpWEOEC9SdVEfJqvqzKHBMnBBAv7FsAiEFVEUPB6YHVAtb6scb0Hmomio+1T8AdpwWZt9xHVmn4DX7MeCcKIL0PaXUp4Zr4kxkww54FVzIJLg0O99pzGc5Oa+7d1lNohJk54kUIi2K3FQn6YDDPeujVs0N4sJWQtvmdKgWfOXTI7o5X331rq7LvN0W4ibQ/OgUPxMexFr+SyeS0VRsXX2F3llnQ0BtTtqw==; 5:vDOKaAoy2BrcSM+2UR1kCM3kZlRy4sg7jkuvGFdtKCmbmKccOfPZr5FJgcEKq+BN4ih6bXJyFHLPg6ENsGd+ZPr/4MtUnxVQVmIE0Egu0Nm5iht5Eqa53uFaaddZt2Zza/metkgk6Xei2ECzDMiOLleYJxGNQ/VXPQ5F5MTCG+9tq+luQMnS/gY/6id3w9qh6eRjCru92k+3+vwKystkqw==; 7:ReKYDVhaiWgFJFIEkwClVpVYY9JsCl9bbtHWBsD34o7s2dCuteKrPFfksmY7lUXeTqHicF/P2x5bL+f0df7Hxm5a1upiWuRnSUS7l6j4PRCIhnuirK70Am5Hvsx4rjhTZwITHRlYJuJbG38Q52ezBQ== x-ms-office365-filtering-correlation-id: 29d23e71-a5ab-4fa9-9f18-08d6878ed931 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1298; x-ms-traffictypediagnostic: BN6PR14MB1298: x-microsoft-antispam-prvs: x-forefront-prvs: 09347618C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(346002)(376002)(39860400002)(396003)(199004)(189003)(606006)(11346002)(71200400001)(71190400001)(446003)(476003)(44832011)(53936002)(76176011)(7696005)(33656002)(486006)(236005)(7736002)(74316002)(6506007)(256004)(53546011)(9686003)(6246003)(6306002)(54896002)(55016002)(186003)(966005)(66066001)(25786009)(478600001)(3846002)(14454004)(6116002)(4326008)(81166006)(6436002)(102836004)(99936001)(68736007)(790700001)(93886005)(316002)(26005)(8936002)(99286004)(54906003)(106356001)(110136005)(105586002)(2906002)(86362001)(229853002)(97736004)(8676002)(81156014)(19400905002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1298; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Tzg9toISGwn3W7l7sUpeI8qKoe/Ro9YvSfccHFkKCJIE5nxs+/K7rXUqKZmrAvBMVDJEXnBl84e60rTYPXxHRu2cCtEdQWWAbDpIpn+chR06T9/qk0Ab3m8ZkFGxtXUusnDtUqPg1s0gYRqjAQAEHX6s0b2IAshzSPqGmnntnMZc/2oLywt+t3jeQ8baJrRNIFEg3hfSzdv+vEJb8qJOpzx/mAV8UBpLNHP7oPrO7PN8FTgvnAFKQIA2ADifwtG/ZdJ8ZZZyGoSPWIkF1dsTYeARNSpxnm3IpOZP9fZPqzt+CI3z3Hj/v15Rmo+fuRKJ3GQ0mptOty2uvtfD5kz9Dsc48Jhj0KrnY2+D0Z4pyStkz7gg0+oasDTRaQ9YGOk0teUpSEvUHjPhPSPhjaJCpT4b9aRTzZGxtUmNF8WcQQ0= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_01F1_01D4B934.A075CE20" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 29d23e71-a5ab-4fa9-9f18-08d6878ed931 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2019 15:14:51.7676 (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-Transport-CrossTenantHeadersStamped: BN6PR14MB1298 Archived-At: Subject: Re: [lamps] CAA: Title case for Defined Terms? 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, 31 Jan 2019 15:15:00 -0000 ------=_NextPart_000_01F1_01D4B934.A075CE20 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01F2_01D4B934.A075CE20" ------=_NextPart_001_01F2_01D4B934.A075CE20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yup, thanks for pointing out BCP 219. While =E2=80=9CWildcard Domain = Name=E2=80=9D may not be an ideal term, it does seem to be an = established one. =20 -Tim =20 From: Ryan Sleevi =20 Sent: Wednesday, January 30, 2019 4:37 PM To: Jacob Hoffman-Andrews Cc: Rob Stradling ; SPASM ; Tim = Hollebeek Subject: Re: [lamps] CAA: Title case for Defined Terms? =20 RFC 8449 / BCP 219, in the discussion of Domain Names, notes that IETF = documents have been inconsistent in the application of the term, such = that the use of a wildcard can be valid in the wireform of a domain, but = not conform with the rules for hostnames or presentational syntax. =20 I say this because, on the balance, I don=E2=80=99t have strong feelings = for or against this change. It may be that referencing BCP 219 provides = a more stable set of definitions here, if necessary, than the BRs. =20 On Wed, Jan 30, 2019 at 4:47 PM Jacob Hoffman-Andrews > wrote: And here's the one for "Wildcard Name":=20 https://github.com/jsha/caa-simplification/pull/9 = =20 _______________________________________________ Spasm mailing list Spasm@ietf.org =20 https://www.ietf.org/mailman/listinfo/spasm = =20 ------=_NextPart_001_01F2_01D4B934.A075CE20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Yup, = thanks for pointing out BCP 219.=C2=A0 While =E2=80=9CWildcard Domain = Name=E2=80=9D may not be an ideal term, it does seem to be an = established one.

 

-Tim

 

From: Ryan = Sleevi <ryan-ietf@sleevi.com>
Sent: Wednesday, January = 30, 2019 4:37 PM
To: Jacob Hoffman-Andrews = <jsha@eff.org>
Cc: Rob Stradling = <rob@sectigo.com>; SPASM <spasm@ietf.org>; Tim Hollebeek = <tim.hollebeek@digicert.com>
Subject: Re: [lamps] CAA: = Title case for Defined Terms?

 

RFC 8449 / BCP 219, in the discussion of Domain Names, = notes that IETF documents have been inconsistent in the application of = the term, such that the use of a wildcard can be valid in the wireform = of a domain, but not conform with the rules for hostnames or = presentational syntax.

 

I = say this because, on the balance, I don=E2=80=99t have strong feelings = for or against this change. It may be that referencing BCP 219 provides = a more stable set of definitions here, if necessary, than the = BRs.

 

On = Wed, Jan 30, 2019 at 4:47 PM Jacob Hoffman-Andrews <jsha@eff.org> = wrote:

And = here's the one for "Wildcard Name":
https://github.com/jsha/caa-simplification/pull/9
_______________________________________________
Spasm mailing = list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

------=_NextPart_001_01F2_01D4B934.A075CE20-- ------=_NextPart_000_01F1_01D4B934.A075CE20 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 CQUxDxcNMTkwMTMxMTUxNDM4WjAvBgkqhkiG9w0BCQQxIgQgtH3XY6LvkqdrAA58pqa+kNpuBCUZ QVRIDccpuSD4NUkwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAIiqPyMqo/2hgASI7Doxb+B9+bsNoNsaIBptBv93T34dHAnpvvJbiATDReWy/YbyfcskMHnU EAGljmxnLPgatUyxZeTtBYSgTrdwkeQMr7rv5xx2SnGl4yN+SO4kGFNSbJ1dST38/EKsvAcYh0o3 dOO11PgXDC4ShDZnUNreOnAKPq/gzwrdZj+00uCs/aQvnfqrpAsWyDuVjIgcKixcs9drmx2P0vKn 4jzTjy0XZVrFfiRrEulLSshbjTsT3EGd7TiVnMk7q/b5Mwrx2zYuxK6r7EHL4K3u+X+HnUasZTxQ mWtkryWYi9WFW0lprM/okpe+CifKueOfa3b4Z+aIdD0AAAAAAAA= ------=_NextPart_000_01F1_01D4B934.A075CE20-- From nobody Thu Jan 31 07:39:19 2019 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 AC33312958B; Thu, 31 Jan 2019 07:39:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <154894915065.9991.7323845609116688683@ietfa.amsl.com> Date: Thu, 31 Jan 2019 07:39:10 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-hash-of-root-key-cert-extn-05.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: Thu, 31 Jan 2019 15:39:11 -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 : Hash Of Root Key Certificate Extension Author : Russ Housley Filename : draft-ietf-lamps-hash-of-root-key-cert-extn-05.txt Pages : 10 Date : 2019-01-31 Abstract: This document specifies the Hash Of Root Key certificate extension. This certificate extension is carried in the self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate. This certificate extension unambiguously identifies the next public key that will be used at some point in the future as the next Root CA certificate, eventually replacing the current one. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-extn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-hash-of-root-key-cert-extn-05 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-hash-of-root-key-cert-extn-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-hash-of-root-key-cert-extn-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 31 07:39:27 2019 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 3A3A5129C6A for ; Thu, 31 Jan 2019 07:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_-T7v9-1zpo for ; Thu, 31 Jan 2019 07:39:10 -0800 (PST) Received: from mail1.bemta24.messagelabs.com (mail1.bemta24.messagelabs.com [67.219.250.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC413128CB7 for ; Thu, 31 Jan 2019 07:39:09 -0800 (PST) Received: from [67.219.250.196] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-b.us-west-2.aws.symcld.net id D7/76-27452-C96135C5; Thu, 31 Jan 2019 15:39:08 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTaUwTaRjHeefqiMxmLFQeibpr143G7JSWRqm xHvhhrRoTVz5oDCpTO9ImpTQzRZAQgydKpV6YAIp4bdZUIy4aJV6LGKJiPWNRUCNVIlKjaCAq GtROpyh++z3P//9cyfvSuPo9lUILhR5BdPFOLRVP2FO1adzekZlZ+u0NZtMmby9mCr9sU5n+/ a8KM+1vXTmLsNz0lpKWI0f6Mcv6QDNu8T/uIxcSS0mHy5pXmE3ae6tKKPft7MInFZ9QCbqyuA zF0wS7DYeqa5W4HKjZHRg0b12HlKADQff9CrIMDaMpVg+tF69iZYimk9g58ChgkdM4Ow9OPa3 FZH8iW4pg4Gl3tDiJ3YLgzcDdWLAbQeBFEJdLCPYP6Aq2qGRm2GWwp/NtbPZtAroGtkaFYawR +vrfUTIjdiR8aDmOKfOSob2zNsrAJkHo7g1KYQ10P/9CKv4sqOltiuV/gxM9QZXCY+BerTe6E bAbVPC5/TIh3wPsAnhYPlHJdyKo21kXGzAJXn29QSrshPVlpTEeDb7XvbFGuym4XP8yWqBmbV DhH5w8FvzlIUIx3cGhPRBQKSccQPBPq6TcPwKuV3USO9CE6iHXVQ+xVQ+xKXkOzl1qxBX+Fc6 +3hdhVYTNcNqmZMdBhTekUngKbL71jjqAaD9Kt4qOHLsnl3c4OYNezxkMaZzBaOSMU3R8EWfV 5UtcgSB5uDQdXyDppDW5K502nUvw1KPI67O5N41vQA825jShUTSm1TDCq0VZ6l+sebY1dl6yr xDznYLUhEbTtBaY6ZrMLPUIUcgRClc5nJEnPCgDnaBNYv6UZUZy87mSI0eRWpCRbjwUqsHpC5 +e1+BqwpXnElKSmfuylZWt9nzX90aD3+EeGpOSyKC4uDh1glsQcx2en/UwSqaRNpExy10SHC7 P93nhyCpYZJWijIXyKh7+h5RSguZl1h1b/tVKtvWXhzWNTENC6uE50se1p+fOJDNDmoxZf5tJ 90Fxr++knqrsOVh8Z/oWf6vvd7Hof9z3ogDpzwyfvThbPFy8KxgKn/c+8+2au3pB+5KejVOx9 PnpLX8V9+xU1WecNE3uejstdcZNoY1KDMYfe9hx1Fy5R9PX0Zyq1RKSnTdMwkWJ/wbrHSPhCQ QAAA== X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-12.tower-344.messagelabs.com!1548949147!466458!1 X-Originating-IP: [104.47.34.50] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12218 invoked from network); 31 Jan 2019 15:39:07 -0000 Received: from mail-by2nam01lp2050.outbound.protection.outlook.com (HELO NAM01-BY2-obe.outbound.protection.outlook.com) (104.47.34.50) by server-12.tower-344.messagelabs.com with AES256-SHA256 encrypted SMTP; 31 Jan 2019 15:39:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CbtEXW0oDXsjzn0wjFBWI2CguIo+W8WOhOhbNggGbFs=; b=B7QecGWpm2J3ki3DWhJzgPG6D+CtmnqYwu4zqGBsmNTRPqOvcZ69SkQykNJt6tZEXGpu9EmAIh3wz9d3f5Tj8Q3zZeVF2emKnvodMy6ilNqbu8vXv5YNS8cBT5bO/9iXEc5cen2+jqs2AOL5fTHGLNo2izV1ib54JMnFj/4nmJA= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1492.namprd14.prod.outlook.com (10.172.151.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.16; Thu, 31 Jan 2019 15:39:05 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::34c2:edc4:19ee:d9b0]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::34c2:edc4:19ee:d9b0%10]) with mapi id 15.20.1580.017; Thu, 31 Jan 2019 15:39:05 +0000 From: Tim Hollebeek To: Benjamin Kaduk , Russ Housley CC: LAMPS WG , Daniel Kahn Gillmor Thread-Topic: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt] Thread-Index: AQHUrfJRqdhTDP+WUUy800dyQk+81KWyidAAgAHEZgCAABQhgIAABSEAgADOhICAAEY4AIAAL9uAgAehW5CAAWu5AIAAcfcAgAAZgFCAABbIAIAAHn2AgACvNwCACXCjQA== Date: Thu, 31 Jan 2019 15:39:05 +0000 Message-ID: References: <87pnsud3gh.fsf@fifthhorseman.net> <875zulhfvh.fsf@fifthhorseman.net> <0230057F-D39E-49A5-8DAE-35DA2B1B9B0D@vigilsec.com> <87zhrq3qv7.fsf@fifthhorseman.net> <51BC8C3B-3BFC-42C4-94E2-75F4A53E9E6B@vigilsec.com> <20190125031117.GI49072@kduck.mit.edu> <20190125152732.GL49072@kduck.mit.edu> In-Reply-To: <20190125152732.GL49072@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [69.162.16.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1492; 6:nIHXzjd0wndBT/SM6FeX6SsS4aASDDU1Njzz755GSTfO/6t6J+DbusN8wY6e7dcHy6wJCRZUUIdYceADpcdJpPufT3EuYxcUpnsUmnTWT7qBous2t20CGazOmPmtnnhNdyf58UOjeRlZbDmilGZszoWS0sQ9DLgBQG/Os7XDAYEjHajIzd83lRokN7B8o0vTEzAHoLwguGrh0Vfeu3ykgEU13jWapwr7mp/s+WsGNqykFYeWIkoZuyjENqxOVgeANyhxSuqfSzBSh/0WisnbszEna3x1fSZgSsP38mxoI3KXDS22AMYHqAWIua1ri9w/m2bsce0qKA45loo3/U7I/u6H/o3PCExT/nD4VduWFNYiDL3TlKU3vXj4WLfAp3bhz6bO+B6AfEH7FD/G9/c9UiZxNvzFWvvFZKR2zMCr9CYVux/T6Eg29qllAMSQvPOxHw+r2S3imrJTMPRPJjO9+A==; 5:VFTaajfo3bd9KTG6BhmA7GMtOkx0T5gGMuLQLvSf/lkGkptMaQNaxPU6DduVGyPqMVJgMaskHckLHgLCiNipycGtVsLmtj3s8dId03Tf++W/0dDF9ji7HcQbptG+Br23wEKYWnnR9q6gnWnB9tI7ApJ86nWB9wiRGjb5VdZ+OCj8Eoiax+cLSuUjYTze87Ap8wK9TQp/9xibNtjRs0IloQ==; 7:RBf3gPfF6MAZMWpi1Ddsy+MwZj+5qxqaN8iwvsNTpgK2MG3yRoy+Z1EJK7pub5E714uhc9A1a7Gb9mJraWUoeFAvFG6Vb5f4ZBSvYHBTg+Z9oIA/YWrMaL2w9+QDIV1e0xqc5d2GH5qAewZ6RmhfdQ== x-ms-office365-filtering-correlation-id: 3bd96c7b-56fd-492d-b6a1-08d687923b72 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1492; x-ms-traffictypediagnostic: BN6PR14MB1492: x-microsoft-antispam-prvs: x-forefront-prvs: 09347618C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6029001)(376002)(396003)(346002)(39850400004)(136003)(366004)(189003)(199004)(51914003)(13464003)(71190400001)(33656002)(9686003)(97736004)(256004)(93886005)(14444005)(71200400001)(14454004)(4326008)(6306002)(99936001)(966005)(478600001)(68736007)(2171002)(6246003)(6436002)(99286004)(316002)(53936002)(66066001)(106356001)(105586002)(86362001)(54906003)(81156014)(8676002)(2906002)(102836004)(25786009)(55016002)(81166006)(6506007)(305945005)(229853002)(6116002)(486006)(53546011)(3846002)(26005)(11346002)(74316002)(476003)(44832011)(446003)(110136005)(186003)(76176011)(7696005)(8936002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1492; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ZZJkevkxdMGjrtjJoDZREst1Liwt2aAb5R3jmodg6XvfSo0aavbtLUAOI8Vt4u0am35IZIcBKIBFVQv9naoPLS6QhmQWvutw39GapV39a2aDThH2FjG4gnRuI6y7Qi0f7pgiOfdd5Lb/3NP+Xaz5wxLow0soB2Y6XW/4nn9If2/kPhSwBYlqtEnRipVSdfplkbjL+e535s2VacbeOS4DN3YCKfA2s30NTlCBU0cfrI4GffY8zrTrlX1AFlnnQoLenGB7rxAMLwIkoafYZWjaGIjy1A4sAxW9mLPc3L2awrZwnCt7QxS3uCq0DOo9x6YxQbnAMq4xShqHKfCdQ/5QrRxJAlbzxNXZa2+2MGJrzGsAIc1EWyR9fBmw0a4oOpPk3dtDku3jwfePnWFfQlkCcT+5JAh7nav3xpRrv93q1QE= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0221_01D4B938.02592210" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3bd96c7b-56fd-492d-b6a1-08d687923b72 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2019 15:39:05.0661 (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-Transport-CrossTenantHeadersStamped: BN6PR14MB1492 Archived-At: Subject: Re: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Thu, 31 Jan 2019 15:39:14 -0000 ------=_NextPart_000_0221_01D4B938.02592210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It appears that no one else shares DKG's concerns. The consensus appears to be to proceed with the document with the edits Russ made for Ben. -Tim > -----Original Message----- > From: Benjamin Kaduk > Sent: Friday, January 25, 2019 7:28 AM > To: Russ Housley > Cc: Tim Hollebeek ; LAMPS WG > ; Daniel Kahn Gillmor > Subject: Re: [lamps] HashOfRootKey when no certificate repository exists > [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt] > > Hi Russ, > > That looks much better; thanks! > > -Ben > > On Fri, Jan 25, 2019 at 12:00:25AM -0500, Russ Housley wrote: > > Thanks for the careful read, Ben. > > > > I will break the paragraph into two; it is getting too long anyway. And, I wall > add the part that got lost in the recent edits. > > > > Some enterprise and application-specific environments offer a > > directory service or certificate repository to make certificate and > > CRLs available to relying parties. Section 3 in [RFC5280] describes > > a certificate repository. When a certificate repository is > > available, the oldWithNew and newWithOld certificates SHOULD be > > published before the successor to the current Root CA self-signed > > certificate is released. Recipients that are able to obtain the > > oldWithNew certificate SHOULD immediately remove the old Root CA > > self-signed certificate from the trust anchor store. > > > > In environments without such a directory service or repository, > > recipients SHOULD keep both the old and replacement Root CA self- > > signed certificate in the trust anchor store for some amount of time > > to ensure that all end-entity certificates can be validated until > > they expire. The recipient MAY keep the old Root CA self-signed > > certificate until all of the certificates in the local cache that are > > subordinate to it have expired. > > > > Russ > > > > > > > > > On Jan 24, 2019, at 10:11 PM, Benjamin Kaduk wrote: > > > > > > This thread prompted me to read the document. My main concern is > > > that section 2 still says that "[a]s discussed in Section 5, the > > > recipient can remove the current Root CA certificate immediately in > > > some situations", but Section 5 no longer has any discussion of > > > removing the trust anchor (and when it is safe to do so). (We have > > > discussion of retaining both old and new, but not any explicit > > > discussion of removing the old.) Given that the whole point of this > > > extension is to be able to retire the old Root CA certificate, > > > resolving this disparity by removing the quoted text from section 2 > > > seems undesirable, which would seem to require us to state more > explicitly when it is safe to effect the immediate removal. > > > > > > -Ben > > > > > > On Fri, Jan 25, 2019 at 01:54:15AM +0000, Tim Hollebeek wrote: > > >> Is there anyone other than Daniel who thinks this is necessary? > > >> > > >> There is always the opportunity to address this in additional > > >> drafts and revisions if it turns out to be needed. > > >> > > >> There are no concrete proposals for addressing this, and I'm > > >> struggling to understand why that guidance needs to be in this > > >> document, so I'd suggest that it would be best if this issue did > > >> not block adoption of this draft. > > >> > > >> -Tim > > >> > > >>> -----Original Message----- > > >>> From: Spasm On Behalf Of Russ Housley > > >>> Sent: Thursday, January 24, 2019 7:19 PM > > >>> To: Daniel Kahn Gillmor > > >>> Cc: LAMPS WG > > >>> Subject: Re: [lamps] HashOfRootKey when no certificate repository > > >>> exists > > >>> [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt] > > >>> > > >>> > > >>> > > >>>> On Jan 24, 2019, at 12:30 PM, Daniel Kahn Gillmor > > >>> wrote: > > >>>> > > >>>> On Wed 2019-01-23 19:49:52 +0000, Tim Hollebeek wrote: > > >>>>> Any comments on resolving this issue as Russ suggested? It > > >>>>> seems to clarify the issue helpfully. > > >>>> > > >>>> I agree that it helps to clarify what is meant by a "certificate > > >>>> repository". Thanks, Russ! > > >>>> > > >>>> I still think that the draft lacks concrete guidance on how a > > >>>> relying party should deal with this new revocation mechanism in > > >>>> the context of a certificate repository that might sometimes be > unavailable. > > >>>> > > >>>> More seriously, it still lacks concrete guidance for relying > > >>>> parties that have no expectation or knowledge of a certificate > > >>>> repository in the first place. > > >>> > > >>> That is right, and I do not think it belongs in this document. > > >>> > > >>> I know this is your position, and you know this is my position. > > >>> > > >>> i would really like other on this list to voice their views. > > >>> > > >>> Russ > > >> > > > > > > > > > > > >> _______________________________________________ > > >> 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 > > ------=_NextPart_000_0221_01D4B938.02592210 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 CQUxDxcNMTkwMTMxMTUzODUwWjAvBgkqhkiG9w0BCQQxIgQgAUa5poAQxH1M4kX/EnQfDpzbqXse vYCLQkhZ731WolEwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAMFt/psQ4rQ0nEhsOwjRcSPv5SiMFSaighDd0sAPXxCLjtYX8YZiiHMknDvr98x9td/jVS4T XuyK7lFwIwii2Aok9EdmmdNZi0IGInbt1BhoWkbuJM0RaB6+QhI0oDWMNz6R3f1hHbmbpCqfxKwu GZE2dWRLDGjwXE+FGlscei2q68sE3hevee5qwJq0mcvqeODCiHk19YpOLnvdBcaqYAB/8WmXzMiI i9junge+bKz3qwY0OFMUdRXvxs61/KGOnOB3OBVnZfgQg8y0rCv1gStmqhQ3LXnwHXXMam2sXcmp vPZB66sIvauVwesKzmhznrQmDlHDGq2scpfMNfGbfSgAAAAAAAA= ------=_NextPart_000_0221_01D4B938.02592210-- From nobody Thu Jan 31 07:42:27 2019 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 4FF35128CB7 for ; Thu, 31 Jan 2019 07:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sVJE_v9byvd for ; Thu, 31 Jan 2019 07:42:23 -0800 (PST) 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 7417E124408 for ; Thu, 31 Jan 2019 07:42:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BE61A3004AD for ; Thu, 31 Jan 2019 10:24:04 -0500 (EST) 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 RmGCTho3ck_y for ; Thu, 31 Jan 2019 10:24:02 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id DD7C03002B4 for ; Thu, 31 Jan 2019 10:24:02 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 31 Jan 2019 10:42:19 -0500 References: <87pnsud3gh.fsf@fifthhorseman.net> <875zulhfvh.fsf@fifthhorseman.net> <0230057F-D39E-49A5-8DAE-35DA2B1B9B0D@vigilsec.com> <87zhrq3qv7.fsf@fifthhorseman.net> <51BC8C3B-3BFC-42C4-94E2-75F4A53E9E6B@vigilsec.com> <20190125031117.GI49072@kduck.mit.edu> <20190125152732.GL49072@kduck.mit.edu> To: LAMPS WG In-Reply-To: Message-Id: <5BBDEEE1-5DC7-4094-9179-BCCA19D8AAC0@vigilsec.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] HashOfRootKey when no certificate repository exists [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.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: Thu, 31 Jan 2019 15:42:26 -0000 Thanks. I just posted -05 which includes the text proposed earlier in = this thread. Russ > On Jan 31, 2019, at 10:39 AM, Tim Hollebeek = wrote: >=20 > It appears that no one else shares DKG's concerns. The consensus = appears to > be to proceed with the document with the edits Russ made for Ben. >=20 > -Tim >=20 >> -----Original Message----- >> From: Benjamin Kaduk >> Sent: Friday, January 25, 2019 7:28 AM >> To: Russ Housley >> Cc: Tim Hollebeek ; LAMPS WG >> ; Daniel Kahn Gillmor >> Subject: Re: [lamps] HashOfRootKey when no certificate repository = exists >> [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt] >>=20 >> Hi Russ, >>=20 >> That looks much better; thanks! >>=20 >> -Ben >>=20 >> On Fri, Jan 25, 2019 at 12:00:25AM -0500, Russ Housley wrote: >>> Thanks for the careful read, Ben. >>>=20 >>> I will break the paragraph into two; it is getting too long anyway. > And, I wall >> add the part that got lost in the recent edits. >>>=20 >>> Some enterprise and application-specific environments offer a >>> directory service or certificate repository to make certificate = and >>> CRLs available to relying parties. Section 3 in [RFC5280] = describes >>> a certificate repository. When a certificate repository is >>> available, the oldWithNew and newWithOld certificates SHOULD be >>> published before the successor to the current Root CA self-signed >>> certificate is released. Recipients that are able to obtain the >>> oldWithNew certificate SHOULD immediately remove the old Root CA >>> self-signed certificate from the trust anchor store. >>>=20 >>> In environments without such a directory service or repository, >>> recipients SHOULD keep both the old and replacement Root CA self- >>> signed certificate in the trust anchor store for some amount of = time >>> to ensure that all end-entity certificates can be validated until >>> they expire. The recipient MAY keep the old Root CA self-signed >>> certificate until all of the certificates in the local cache that = are >>> subordinate to it have expired. >>>=20 >>> Russ >>>=20 >>>=20 >>>=20 >>>> On Jan 24, 2019, at 10:11 PM, Benjamin Kaduk wrote: >>>>=20 >>>> This thread prompted me to read the document. My main concern is >>>> that section 2 still says that "[a]s discussed in Section 5, the >>>> recipient can remove the current Root CA certificate immediately in >>>> some situations", but Section 5 no longer has any discussion of >>>> removing the trust anchor (and when it is safe to do so). (We have >>>> discussion of retaining both old and new, but not any explicit >>>> discussion of removing the old.) Given that the whole point of = this >>>> extension is to be able to retire the old Root CA certificate, >>>> resolving this disparity by removing the quoted text from section 2 >>>> seems undesirable, which would seem to require us to state more >> explicitly when it is safe to effect the immediate removal. >>>>=20 >>>> -Ben >>>>=20 >>>> On Fri, Jan 25, 2019 at 01:54:15AM +0000, Tim Hollebeek wrote: >>>>> Is there anyone other than Daniel who thinks this is necessary? >>>>>=20 >>>>> There is always the opportunity to address this in additional >>>>> drafts and revisions if it turns out to be needed. >>>>>=20 >>>>> There are no concrete proposals for addressing this, and I'm >>>>> struggling to understand why that guidance needs to be in this >>>>> document, so I'd suggest that it would be best if this issue did >>>>> not block adoption of this draft. >>>>>=20 >>>>> -Tim >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Spasm On Behalf Of Russ Housley >>>>>> Sent: Thursday, January 24, 2019 7:19 PM >>>>>> To: Daniel Kahn Gillmor >>>>>> Cc: LAMPS WG >>>>>> Subject: Re: [lamps] HashOfRootKey when no certificate repository >>>>>> exists >>>>>> [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt] >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> On Jan 24, 2019, at 12:30 PM, Daniel Kahn Gillmor >>>>>> wrote: >>>>>>>=20 >>>>>>> On Wed 2019-01-23 19:49:52 +0000, Tim Hollebeek wrote: >>>>>>>> Any comments on resolving this issue as Russ suggested? It >>>>>>>> seems to clarify the issue helpfully. >>>>>>>=20 >>>>>>> I agree that it helps to clarify what is meant by a "certificate >>>>>>> repository". Thanks, Russ! >>>>>>>=20 >>>>>>> I still think that the draft lacks concrete guidance on how a >>>>>>> relying party should deal with this new revocation mechanism in >>>>>>> the context of a certificate repository that might sometimes be >> unavailable. >>>>>>>=20 >>>>>>> More seriously, it still lacks concrete guidance for relying >>>>>>> parties that have no expectation or knowledge of a certificate >>>>>>> repository in the first place. >>>>>>=20 >>>>>> That is right, and I do not think it belongs in this document. >>>>>>=20 >>>>>> I know this is your position, and you know this is my position. >>>>>>=20 >>>>>> i would really like other on this list to voice their views. >>>>>>=20 >>>>>> Russ >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> _______________________________________________ >>>>> Spasm mailing list >>>>> Spasm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/spasm >>>>=20 >>>> _______________________________________________ >>>> Spasm mailing list >>>> Spasm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spasm >>>=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Jan 31 08:07:13 2019 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 C992D124408 for ; Thu, 31 Jan 2019 08:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lLItLo32S9i for ; Thu, 31 Jan 2019 08:07:09 -0800 (PST) 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 834E5123FFD for ; Thu, 31 Jan 2019 08:07:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A7A14300AAD for ; Thu, 31 Jan 2019 10:48:51 -0500 (EST) 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 UZPqhVEMp82O for ; Thu, 31 Jan 2019 10:48:49 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id C8A773002B4; Thu, 31 Jan 2019 10:48:49 -0500 (EST) From: Russ Housley Message-Id: <29800B65-CE39-4BA4-B6D1-F2E6F870E1D6@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_53B2151B-B265-40BB-B5A3-4DBAA9CB8226" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 31 Jan 2019 11:07:06 -0500 In-Reply-To: Cc: Tim Hollebeek , SPASM To: Scott Fluhrer References: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [lamps] Last Call: draft-ietf-lamps-cms-hash-sig-03 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, 31 Jan 2019 16:07:12 -0000 --Apple-Mail=_53B2151B-B265-40BB-B5A3-4DBAA9CB8226 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Scott: Thanks for the careful read. I have made these changes in my edit = buffer. Russ > On Jan 30, 2019, at 3:04 PM, Scott Fluhrer (sfluhrer) = wrote: >=20 > Just two spelling corrections=E2=80=A6 > =20 > Nit: in the first line of section 4: =E2=80=9Cfor an HHS/LMS public = key=E2=80=9D should be =E2=80=9Cfor an HSS/LMS public key=E2=80=9D > =20 > Nit: in the first line of section 6.2: =E2=80=9Con the current sate=E2=80= =9D should be =E2=80=9Con the current state=E2=80=9D > =20 > =20 > =20 > From: Spasm > = On Behalf Of Tim Hollebeek > Sent: Wednesday, January 30, 2019 2:25 PM > To: SPASM > > Subject: [lamps] Last Call: draft-ietf-lamps-cms-hash-sig-03 > =20 > =20 > This is the LAMPS WG Last Call for =E2=80=9CUse of the HSS/LMS = Hash-based Signature Algorithm in the Cryptographic Message Syntax = (CMS)=E2=80=9D . > =20 > Please review the document and send your comments to the list by 14 = February 2019. > =20 > If no concerns are raised, the document will be forwarded to the IESG = with a request for publication as Proposed Standard. > =20 > -Tim > =20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm = --Apple-Mail=_53B2151B-B265-40BB-B5A3-4DBAA9CB8226 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Scott:

Thanks for the careful read.  I have made these changes = in my edit buffer.

Russ


On Jan = 30, 2019, at 3:04 PM, Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com> = wrote:

Just two = spelling corrections=E2=80=A6
 
Nit: in the first line of section 4: = =E2=80=9Cfor an HHS/LMS public key=E2=80=9D should be =E2=80=9Cfor = an HSS/LMS public key=E2=80=9D
 
Nit: in = the first line of section 6.2: =E2=80=9Con the current sate=E2=80=9D = should be =E2=80=9Con the current state=E2=80=9D
 
 
 
From: Spasm <spasm-bounces@ietf.org> On Behalf = Of Tim = Hollebeek
Sent: Wednesday, January 30, 2019 = 2:25 PM
To: SPASM <spasm@ietf.org>
Subject: [lamps] Last Call: = draft-ietf-lamps-cms-hash-sig-03
 
 
This is the LAMPS WG Last Call for =E2=80=9CUse of the = HSS/LMS Hash-based Signature Algorithm in the Cryptographic Message = Syntax (CMS)=E2=80=9D <draft-ietf-lamps-cms-hash-sig-03>.
 
Please = review the document and send your comments to the list by 14 February = 2019.
 
If no = concerns are raised, the document will be forwarded to the IESG with a = request for publication as Proposed Standard.
 
-Tim
 
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

= --Apple-Mail=_53B2151B-B265-40BB-B5A3-4DBAA9CB8226-- From nobody Thu Jan 31 08:52:51 2019 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 5A24A126F72; Thu, 31 Jan 2019 08:52:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <154895356334.9999.2498953479309699647@ietfa.amsl.com> Date: Thu, 31 Jan 2019 08:52:43 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-07.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: Thu, 31 Jan 2019 16:52:43 -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 : Use of the SHAKE One-way Hash Functions in the Cryptographic Message Syntax (CMS) Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-cms-shakes-07.txt Pages : 16 Date : 2019-01-31 Abstract: This document describes the conventions for using the SHAKE family of hash functions with the Cryptographic Message Syntax (CMS) as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms, as message digests and message authentication codes. The conventions for the associated signer public keys in CMS are also described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-shakes-07 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-shakes-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-shakes-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 31 08:53:22 2019 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 89F9E130E7F; Thu, 31 Jan 2019 08:53:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <154895359052.9987.14350868932808350314@ietfa.amsl.com> Date: Thu, 31 Jan 2019 08:53:10 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-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: Thu, 31 Jan 2019 16:53: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 : Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA using SHAKEs Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-pkix-shake-08.txt Pages : 15 Date : 2019-01-31 Abstract: Digital signatures are used to sign messages, X.509 certificates and CRLs (Certificate Revocation Lists). This document describes the conventions for using the SHAKE function family in Internet X.509 certificates and CRLs as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms. The conventions for the associated subject public keys are also described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-pkix-shake/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-pkix-shake-08 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pkix-shake-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-pkix-shake-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 Thu Jan 31 08:56:46 2019 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 B5776128D0C for ; Thu, 31 Jan 2019 08:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.643 X-Spam-Level: X-Spam-Status: No, score=-14.643 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R113sxPvSkS9 for ; Thu, 31 Jan 2019 08:56:43 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B84A130DD8 for ; Thu, 31 Jan 2019 08:56:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2026; q=dns/txt; s=iport; t=1548953799; x=1550163399; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Nm2pxr0L7wUp0gub0vbp1s6bluEZhlfsDgNhNUYhUAQ=; b=XjqOrcOYTHh5EdjrqQKjfxkGNDSv0PEQZHrjZgzQ6eznmfh7pLZ/vhSq 8fzeXfYOhJWlolFbHk2r3HNxJfwMe6bHyjVuyvZngqi6CRPNDtk6fILVe sRlprF27IntS0TvmOutW+w/OWHCZt+lS53RWkzJ7MrMNp1Ni7/L6v3/XP A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAB0J1Nc/4ENJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggNngQMnCowTi3KCDZgOgXsLAQEYC4R?= =?us-ascii?q?JAoMOIjQJDQEDAQECAQECbRwBC4VKAQEBAQMBATg0FwQCAQgRBAEBHxAnCx0?= =?us-ascii?q?IAgQTCIMbggEPrW6EMgIOQYUqjEAXgUA/gRGDEoMeAQECAQEWgSCGBwKiYQk?= =?us-ascii?q?Chy2KfiGBa1KEbIsUiiCFLohkgxwCERSBJx84gVZwFRohgmwJgh0YiF+FP0E?= =?us-ascii?q?xjT+BLoEfAQE?= X-IronPort-AV: E=Sophos;i="5.56,545,1539648000"; d="scan'208";a="233353857" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2019 16:56:38 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x0VGucJQ023449 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 31 Jan 2019 16:56:38 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 31 Jan 2019 10:56:37 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1395.000; Thu, 31 Jan 2019 10:56:37 -0600 From: "Panos Kampanakis (pkampana)" To: "spasm@ietf.org" Thread-Topic: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-07.txt Thread-Index: AQHUuYV5NeZsXL6sx0udAo16GtRlTqXJmILA Date: Thu, 31 Jan 2019 16:56:37 +0000 Message-ID: <740063441680442e9e7cc37dec5d8467@XCH-ALN-010.cisco.com> References: <154895356334.9999.2498953479309699647@ietfa.amsl.com> In-Reply-To: <154895356334.9999.2498953479309699647@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.211.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-07.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: Thu, 31 Jan 2019 16:56:45 -0000 This new version addresses Russ' latest nits while in WGLC.=20 Panos -----Original Message----- From: Spasm On Behalf Of internet-drafts@ietf.org Sent: Thursday, January 31, 2019 11:53 AM To: i-d-announce@ietf.org Cc: spasm@ietf.org Subject: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-07.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Limited Additional Mechanisms for PKIX and= SMIME WG of the IETF. Title : Use of the SHAKE One-way Hash Functions in the Cr= yptographic Message Syntax (CMS) Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-cms-shakes-07.txt Pages : 16 Date : 2019-01-31 Abstract: This document describes the conventions for using the SHAKE family of hash functions with the Cryptographic Message Syntax (CMS) as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms, as message digests and message authentication codes. The conventions for the associated signer public keys in CMS are also described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-shakes-07 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-shakes-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-shakes-07 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Jan 31 08:57:28 2019 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 4D6A2130EE6 for ; Thu, 31 Jan 2019 08:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.054 X-Spam-Level: X-Spam-Status: No, score=-19.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbsIXw0drXy8 for ; Thu, 31 Jan 2019 08:57:20 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AB57130EAC for ; Thu, 31 Jan 2019 08:57:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2113; q=dns/txt; s=iport; t=1548953840; x=1550163440; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=c9cGug1HnhgcRrl623+Pw7ELXFw31kaZCRMqevpnqSk=; b=hzuElENjw5Ta5ILOe2j71z4IudDdDELSAaOnjQeciF4o8Gu8XU64jhoF +2C58atp0i92RLcNjdi7/M9ZigHER/avItXdFez+WgnekZYAOqFK1g85j dYWTPNQG5n0lPSLEMpESNjTx38CREdiupP2mjx30909+bMNM6wgDwb9OU Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAClKFNc/5RdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggNngQMnCowTi3KCDZgOgXsLAQEYC4R?= =?us-ascii?q?JAoMOIjQJDQEDAQECAQECbRwBC4VKAQEBAQMBATg0FwQCAQgRBAEBHxAnCx0?= =?us-ascii?q?IAgQTCIMbggEPrWSEMgIOQYUqjEAXgUA/gRGDEoMeAQECAQEWgSCGBwKiYQk?= =?us-ascii?q?Chy2KfiGBa1KEbIsUiiCFLohkgxwCERSBJx84gVZwFRohgmwJgh0YiF+FP0E?= =?us-ascii?q?xjT+BLoEfAQE?= X-IronPort-AV: E=Sophos;i="5.56,545,1539648000"; d="scan'208";a="234237918" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2019 16:57:11 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x0VGvApj031865 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 31 Jan 2019 16:57:11 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 31 Jan 2019 10:57:10 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1395.000; Thu, 31 Jan 2019 10:57:10 -0600 From: "Panos Kampanakis (pkampana)" To: "spasm@ietf.org" Thread-Topic: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-08.txt Thread-Index: AQHUuYWOxVlDkevtp0SkzOzDgAH6VqXJmLdw Date: Thu, 31 Jan 2019 16:57:10 +0000 Message-ID: <34322e539c5d4a8182e8a3bfec4e9a05@XCH-ALN-010.cisco.com> References: <154895359052.9987.14350868932808350314@ietfa.amsl.com> In-Reply-To: <154895359052.9987.14350868932808350314@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.211.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-08.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: Thu, 31 Jan 2019 16:57:27 -0000 This new version addresses the latest nits identified by Russ while in WGLC= . Panos -----Original Message----- From: Spasm On Behalf Of internet-drafts@ietf.org Sent: Thursday, January 31, 2019 11:53 AM To: i-d-announce@ietf.org Cc: spasm@ietf.org Subject: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Limited Additional Mechanisms for PKIX and= SMIME WG of the IETF. Title : Internet X.509 Public Key Infrastructure: Additio= nal Algorithm Identifiers for RSASSA-PSS and ECDSA using SHAKEs Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-pkix-shake-08.txt Pages : 15 Date : 2019-01-31 Abstract: Digital signatures are used to sign messages, X.509 certificates and CRLs (Certificate Revocation Lists). This document describes the conventions for using the SHAKE function family in Internet X.509 certificates and CRLs as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms. The conventions for the associated subject public keys are also described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-pkix-shake/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-pkix-shake-08 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pkix-shake-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-pkix-shake-08 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Jan 31 10:12:52 2019 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 DCE76130E09 for ; Thu, 31 Jan 2019 10:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.154 X-Spam-Level: X-Spam-Status: No, score=-10.154 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwvUJIDg_k_k for ; Thu, 31 Jan 2019 10:12:48 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B389F130E7D for ; Thu, 31 Jan 2019 10:12:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Md7S69fe+5EtY8g8T+0NXIEjLmF2lAdQJc1+N9Jgoi0=; b=4aIkwV9c59spNuWqYfRki04/PF uyG44KoghrHv9kHC7fDkpxC2rRyFpBl8LtwORNMhfR/cpLHO41qt/sBH8NZJLISmCHpjXj4UdoIFZ xLWvnSOER33T5Ai8kzFAm642x/sCPeEvaxxc/C9eZ/8TSLRcvUfyvaTMJcMVYU3ZB9f0=; Received: ; Thu, 31 Jan 2019 10:12:47 -0800 To: Tim Hollebeek , Ryan Sleevi Cc: Rob Stradling , SPASM References: <63cbcb8a-cfba-596b-4d41-510273c8f717@eff.org> From: Jacob Hoffman-Andrews Message-ID: <39d1117e-6e75-dc2b-63a5-a4879aedb861@eff.org> Date: Thu, 31 Jan 2019 10:12:46 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [lamps] CAA: Title case for Defined Terms? 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, 31 Jan 2019 18:12:51 -0000 That makes a lot of sense, thanks. I'll close PR 9 and leave it as "Wildcard Domain Name".